行业动态

部署MVC架构的Web应用程序，即从头到尾的发展史，来喽！

澜梦IT攻略，我们来了！

使用 MVC 架构部署 Web 应用程序后的典型情况。 上图中整个蓝色部分是服务端边界，负责应用或代码的在线运维。 所要解决的问题的边界是服务器端的边界，即服务器端的运维。

那么，我们先来看看服务端运维的发展史，也就是从头到尾的发展史。 假设有一个 Web 应用程序。 开发此 Web 应用程序涉及开发工程师和运输工程师的角色。 研发工程师只关心应用的业务逻辑。 具体来说，在整个基于MVC的Web应用开发中，从服务端接口View层到业务逻辑层、数据存储Model层、Web应用的整体版本管理和在线bug修复、运维工程师只关心适用的服务端运维。 事务。 负责部署在线小程序web应用，绑定域名，监控日志。 当用户访问量大的时候，他就会扩展这个应用。 当用户流量低的时候，他会收缩应用。 当服务器停止时，他重新启动或更换服务器。

时代。 最初，研发工程师不需要担心与部署相关的事情。 每当研发工程师发布新应用时，运营工程师负责将最新代码上线。 传输维护工程师必须管理迭代版本发布、分支合并、实时应用程序和问题回滚。 如果在线出现问题，则必须记录日志并将其发送给开发工程师。

Era 完全隔离了研究开发和运输维度。 这种完全隔离的好处是显而易见的：研发工程师可以专注于自己的业务，而运维工程师则变成了工具工人，处理大量的运维工作和大量的琐事。

时代。 运维工程师发现，很多事情都是重复性的工作。 万一网上出现故障，他们还得抓日志发给研发工程师，效率很低。 因此，运维工程师开发了一系列的运维控制台，让研发工程师可以处理在线导入和日志抓取的工作。

这让运维工程师轻松了一点，但是架构优化和资源扩容计划必须要负责。 除了开发任务IT外包服务，开发工程师还会从传输维度控制台发布新版本来解决在线故障。 这时候就是开发和运维，研发工程师也是运维工程师的一部分工作，但是这部分工作应该由研发工程师负责（比如版本管理，在线故障等）。 而且，运维工程师工具化这部分工作，效率更高，趋向于更少。 工业时代。 运维工程师也可以根据研发工程师的开发流程进一步完善运维控制台，实现代码的自动发布：扫码-测试-灰度验证-上线。 这样，开发工程师只需要将最新的代码合并到Git仓库指定的分支中，剩下的由代码自动发布的管道负责。 这个时候研发工程师不需要运维。 没有 NoOps，研发工程师又回到了起点。 您只需要关心您的应用业务。

运营工程师还可以发现资源优化和可扩展性场景，并利用性能监控流量来估计解决方案。 这样，运维工程师的运维工作也实现了全自动化。 那么对于研发工程师来说，运维工程师的存在感越来越弱，运维工程师要做的事情越来越少，被自动化工具所取代。 这是。

未来。 实现无运维后，运维工程师必须提供更多的基础服务IT外包服务，建设基础设施，提供更智能、更省资源、更周到的服务。 研发工程师完全不用担心运输维度，可以专心处理自己的业务，提升用户体验，考虑商业价值。

无运维NoOps并不是说服务端运维不存在，而是通过无所不知、无所不能的服务覆盖研发引入的所有需求，让研发工程师越来越不了解它。 另外，NoOps是一种理想状态，我们可以无限接近NoOps，所以可以说less不是。

定义了解决问题的边界，即服务端的运维。 less说明了解决问题的目的，即没有运输NoOps。 所以应该叫服务端空跑维度，这才是需要解决的问题。

什么是无服务器

需要解决的是让运维工程师的工作完全透明。 研发工程师只关心业务逻辑，不需要关心传输和在线维护的各种问题。 为了达到这种状态，意味着网络服务器的整体运维工作是极其抽象的。 越是抽象的东西，它包含的信息量就越大，所以很难定义。

但总的来说，是指以下两种。

狭义上（最常见）是指架构=FaaS架构=（事件驱动）FAS（ as a ）BAS（BAS）广义上是指服务端非运维，即，具有特色的云服务。

文/上海澜梦IT外包专家