随着时代的发展，在互联网浪潮的推动下我们的生活正在发生变化。软件架构也不例外。

下图是一个简单的架构变迁历

不过不管架构如何变，其本质都是在落实 “分而治之”　这一理念。

谈到分布式架构，就不得不说目前火热的微服务架构以及新兴的服务网格架构。而这些架构出现也不是横空出世，是一点点累积的过程，一切变革都是必然的。 对比传统行业应用，互联网应用需要面对海量的数据，更高业务复杂度，更高并发访问，传统的服务架构明显无法支撑这一需求，而架构的转变也自然而然的发生。

下面我们来谈谈，从早期到现在架构的演进。

JEE/SSH/SSM

在早期的系统开发中，服务开发采用的是分层架构的模式，也就是　MVC 模式。针对控制端的UI 界面处理，业务逻辑处理以及数据库操作进行三层的一个架构划分。这样的架构划分，对于早期的架构开发来说，已经足够。 MVC 划分针对是逻辑上的划分，而非物理上的划分，应用在部署时，将所有内容打成一个包运行在web容器中，运行在同一个JVM中，运行在同一个进程中。该架构就是　All in one 的一种架构。 随着互联网时代的到来，互联网带来的高并发，复杂的业务场景中，采用该架构的应用越来越臃肿，业务代码耦合度增强，代码变得难以维护，服务性能受到明显影响产生瓶颈。

于是架构的开始转变。

SOA-Web Service/ SOA-ESB

在互联网软件架构中针对JEE/SSH/SSM　单一应用部署存在的瓶颈问题提出了解决方案 SOA (Service-Oriented Architecture) -服务化架构。

Web Service

SOA 架构通过将业务功能进行拆分，拆分成不同的服务，不同的服务进行各自的部署。这样解决了单一应用开发造成的业务越来越复杂，耦合越来越高开发难维护难的问题。针对不同服务各自进行部署同时解决了单一应用性能问题，并且可以针对不同服务功能进行不同的服务配置，提高资源利用率。

不过web service 也存在问题，web service 服务间通信是通过向 web service 目录　注册，获取服务列表完成的，这使得　web service 目录成为系统高可用的一个瓶颈，同时webservice 在服务间通信采用的 SOAP协议，而 SOAP 协议结构复杂，数据量大，造成的网络开销大，导致系统响应慢等问题的存在。

ESB

ESB 架构模式是　Web Servicer 的变种，其不同于 Web Service 之处在于其增加一条总线。而这条总线能够干嘛用，它主要是用来规范服务通信的，如果ServiceA 使用的JAVA开发的,ServiceB 使用的是 C++ 开发，Service B 属于其他的业务模块要打通其于Service A 的通信，这时候需要面对就是更这两个服务采用的需要是同一个协议规范。而这条总线干的就是将不同标准的协议格式进行统一转化，然后进行服务间的通信，这样减少了针对两个服务的侵入性系统修改，实现可插拔的模式。下一次来一个新的服务应用，就插上去，不要了就拔掉，针对于不同语言编写的服务实现可插拔式，无侵入的优势。

微服务

微服务是最近比较火热的一个架构模式，微服务汲取了SOA 的架构设计思想演变的一种新的架构模式。 微服务在架构中，不同于 SOA 的服务化，微服务直接将某一个功能独立成一个服务应用，支持独立部署、独立开发、独立数据库，在不考虑业务场景的情况下，能能够独立部署，独立运行。 服务间通过协议，如：http 协议进行通信协议。使得整个应用在开发中能够快速开发，敏捷上线。不过其存在的问题也很明显，如：不同功能模块如果由不同开发组进行分别开发，沟通成本会增加。在应用开发中也同样会存在很多问题，如分布式事务，数据一致性等问题。

Service mesh

在互联网时代以及未来IOT 时代高速发展下，除了应时代而生的微服务架构，最近悄然而起的 Service Mesh 逐渐进入到我们眼中。 Service Mesh 在服务化应用变得越来越受欢迎。

谈到服务化，不得不谈的就是服务间通信，而服务间通信包括，服务发现，路由，监控，安全、日志、API网关等。

而其中 API 网关是整个系统的中转站，其承担了通信路由，服务熔断，超时管理等控制。因此 API 网关也会变得越来越臃肿。且由于 API网关的重要性其会成为系统的一个瓶颈。 这时候就得谈谈 Service Mesh 了。Service Mesh 是网络通信基础设施，可能将网络功能从 代码中剥离出来，通过Service Mesh 可以不用在代码中实现可靠的通信模式和断路器等控制，直接使用 service Mesh 用于控制和监控并提供服务应用程序中服务到服务的快速、安全、可靠的内部通信。

我们可以将Service Mesh看成路由器和交换机互联的设备组成的（第七层）网络。 其原理就是由代理 proxy 附属于某一应用程序，为该应用程序提供如路由，负载均衡，监控，通信等功能。并且该功能对应用代码无侵入。

CAP/BASE

谈到分布式，就不得不提　CAP 原理和 BASE 思想。

CAP

• Consistency:一致性 Availabillity:可用性 Partition tolerance:分区容错性

所谓的分布式架构就是将原本单一的应用，拆分多个应用，然后多个应用通过特定的协议进行通信。 在服务应用通信过程中，网络出现故障导致两个应用服务无法正常通信，这时候两个应用需要分别进行服务提供，这就是 CAP　中的　“P” 分区容错性。当我们确定了　“P” 为必然存在的条件，之后我们应该如何选择　“A”　和 “C”。换句话就是：在一个允许网络发生故障的系统中，该选择一致性还是可用性？

有的人会说：小孩子才做选择，我全部都要！

不过这边确实没办法都要！下面我们来举个栗子。 首先我们确定了　“P” 为必要条件。如图

在该环境中存在２个数据存储服务，其中　Server 1 和Server2是主从关系。 在某一时刻，Server 1收到了写请求，不过再同步到Server2的时候出现了网络故障，这时候Server1 和 Server2的数据是不一致的。 这时候有两种选择： 选”A”，可用性：也就是说Server1 和 Server2 仍然向外提供服务，但是这时候两台服务中的数据是不一致的。所以选择了可用性，就无法提供一致性。

选“Ｃ”，一致性：也就是说 Server1 和 Server2　需要等到网络恢复正常，两台服务中的数据一致之后，才对外提供服务。所以选择了一致性，就无法提供可用性。

那难道没有解决办法？

有，那就是 BASE 理论的提出

BASE

• BA:Basically Avaliable 基本可用 S:Soft state 软状态，状态可以有一段时间不同步。 Eventually consistent 最终一致性。

通过看 Base 理论的定义就能够得出 上面 CAP 的解决方案，那就是放弃强一致性，采用最终一致性的方案来解决。 且该理论思想也是实现分布式事物的理论思想。