企业应用架构演进史

企业应用架构会随着业务的变化不断演进，每一种架构在某一阶段都非常好地支撑了当时的业务模式。信息化技术刚开始应用于业务时，我们可能使用一个单机软件就可以实现一个信息系统。随着技术的发展和逐步复杂的业务需求，企业应用架构又经历了客户端/服务器（Client/Server，C/S）、浏览器/服务器（Browser/Server，B/S）、面向服务的架构（Service-Oriented Architecture，SOA）、前后端分离、微服务架构、Serverless等阶段。

单体架构

单体应用并不是单机应用，生产环境的单体应用通常是在一个集群环境下的多个节点部署的。单体应用架构是指业务功能的实现全部在一个进程（process）内完成。用户请求的接收、相关业务逻辑的调用、从数据库中获取数据等处理全部在一个进程内完成。

在B/S模式中，应用架构进一步细分，基于模型-视图-控制器（Model-View-Controller，MVC）开发框架成为B/S架构的主流。MVC是一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。

分布式架构

分布式架构是由一组通过网络进行通信、为了完成共同的任务而协同工作的计算机节点组成的系统架构。分布式系统的出现是为了用廉价、普通的机器完成单台计算机无法完成的计算和存储任务，其目的是利用更多的机器处理更多的业务以及数据。

需要明确的是，我们不能为了分布式而分布式，当应用规模不大时，单体架构恰恰是开发、运行最高效的一种模式。分布式系统要解决的问题本身就是和单体应用系统一样的，而由于分布式系统多节点、通过网络通信的拓扑，会引入很多单体应用系统所没有的一致性与性能问题，为了解决这些问题又会引入更多的机制、协议，带来更多的问题。

SOA架构

SOA是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。

SOA的整体架构分为3层：最底层是单体应用，可记录系统，满足局部的业务能力；中间层是SOA层，实现各个单体应用之间的协同，满足企业内部核心的业务流程；最上层是门户层，实现协同业务或新业务的暴露。

SOA把业务逻辑抽象成“可复用、可组装”的服务，通过服务的编排实现业务的快速再生，其目的是把原先固有的业务功能转变为通用的业务服务，实现业务逻辑的快速复用，这一步解决的核心问题是“复用”。实施SOA的关键目标是实现企业IT资产的最大化作用。

SOA是真正意义上的面向企业全局的设计，但是SOA并没有发挥出SOA设计者预期的效果，而沦为一种应用集成的工具。

微服务架构

微服务架构提倡将单一应用程序划分成一组小的服务，服务之间互相协同、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于HTTP协议的RESTAPI）。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应当尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。

SOA提供了粗粒度的服务能力，即大块业务逻辑的封装。而微服务则更加轻量化，提供单独任务或小块业务逻辑的服务封装；按照微服务的初衷，服务要按照业务的功能进行拆分，直到每个服务的功能和职责单一，甚至不可再拆分为止。

微服务虽然也有一个“服务注册中心”，但一般只用于应用系统启动时注册或拉取服务地址，服务消费者会把这些地址列表缓存在本地客户端，真正调用时并不会通过服务注册中心，而是直接从本地客户端的服务地址缓存中读取目标地址信息，是一个“去中心化”的运行架构，消除了单点瓶颈，可扩展性也会更强。

服务网格架构

采用微服务架构后，应用系统能够做到快速迭代、持续交付。但微服务架构也存在一些明显的弊端：第一，对于采用RPC协议的微服务架构，不同微服务之间的调用存在协议绑定的问题；第二，开发人员除了关注业务逻辑的实现，还需要在微服务模块中处理一系列问题，比如服务注册、服务发现、服务通信、负载均衡、服务熔断、请求超时重试等，这是非常糟糕的。

服务网格是用于处理微服务和微服务通信的“专用基础设施层”，通常被实现为与应用程序代码一起部署的轻量级网络代理矩阵。它通过这些代理来管理复杂的服务拓扑，可靠地传递服务之间的请求。从某种程度上说，这些代理接管了应用程序的网络通信层，并且不会被应用程序所感知。

Istio提供一种简单的方式来建立已部署的服务的网络，具备负载均衡、服务到服务认证、监控等功能，而不需要改动任何服务代码。Istio在服务网络中统一提供了许多关键功能：流量管理、可观察性、策略执行、服务身份和安全、各种环境支持、集成和定制等。

服务网格架构通过sidecar将服务治理与业务解耦并下沉到基础设施层，使应用更加轻量化，让业务开发更聚焦于业务本身，以体系化、规范化的方式解决微服务架构下的各种服务治理挑战。

Serverless架构

Serverless架构理念核心思想是将提供服务资源的基础设施抽象成各种服务，以API的方式提供给用户按需调用，真正做到按需伸缩、按使用收费。它是传统云计算平台的延伸，是PaaS向更细粒度的BaaS和FaaS的发展，真正实现了当初云计算的目标。目前业界较为公认的Serverless架构主要包括两个方面，即提供计算资源的函数服务平台FaaS以及提供托管云服务的后端服务BaaS。

Serverless 不是没有服务器，而是应用不用关心服务器和系统，而只需关注代码，平台提供者将处理其余部分工作，剩下的运维等工作都不需要操心。这样消除了对传统的海量持续在线服务器组件的需求，降低了开发和运维的复杂性，降低了运营成本，并缩短了业务系统的交付周期，使用户能够专注在价值密度更高的业务逻辑的开发上。

Serverless是一种架构思想，秒级启动、极致弹性、按需计费、无限容量、不用关心部署位置、支撑全托管免运维的后端服务。