本文先从软件系统架构模式的演进做一个总结，然后针对每种架构模式分析，总结出架构演进的核心技术点。
架构演进历程
到目前为止，我们知道的架构模式有很多，比如单体架构、SOA架构、微服务架构、中台架构、服务网格架构等，这些架构是怎么一步步演进的呢？我们先从下面这种图开始了解吧：
01-01-架构演化.png
下面我们先对架构演进图做简要分析：
1.单体架构：从上图我们可以看到，软件架构模式是从左往右一步步演进的。大部分软件系统开始都是基于单体架构来设计的，这样才能保证系统的快速上线试行。
2.SOA/水平分层架构：在系统有一定的流量和数据之后，单体架构可能无法支撑快速发展的业务了，这是根据实际的业务场景有两种选择，一种是基于业务垂直拆分的SOA架构，另一种是基于请求的水平分层架构。至于如何选择，我们后续再分析。
3.微服务架构：当我们架构演进为水平分层或SOA架构后，若业务持续的高速发展，终将触达系统的瓶颈，下一步做的可以基于当前的拆分方式，再加入另外的拆分。比如原来是水平拆分的，那就继续基于业务的垂直拆分。若原来是垂直拆分的，那就基于请求再做水平拆分。这就是完整的微服务架构了。
微服务架构基本就可以支持任意量级的系统了，不管业务怎么发展，只要持续的进行垂直和水平拆分都能保证系统的三高要求。
4.服务网格架构：当系统架构采用微服务架构后，为了完成服务的健康安全的运作，就需要注册发现、服务的间通讯、服务熔断降级、服务监控等一系列的服务治理支撑。而每个微服务都需要依赖一系列的jar包（通常由基础团队开发）来实现服务治理，这样每个微服务都和基础jar强绑定了。因此服务网格架构就应运而生，服务网格就是将所有服务治理相关的功能都下沉到独立的进程(sidecar)，同时该进程和微服务部署在同一个Docker容器中。这样微服务就和sidecar物理解耦了。
5.中台架构：中台架构不是一种独立的架构模式，更多是一种组织机制和业务机制，同时将共性能力下沉。需要的是先从组织机构上独立出来，然后在业务层面将共性的能力独立出来，最后由中台组织对中台的服务负责。
6.云原生架构：云原生架构是从运维侧来构建的，基于现有的Docker容器以及Kubernetes来完成服务的云端化。
在上述的架构演进历程中，演进的方式可以用一个字来比较贴近的描述：拆。接下来我们就逐个的了解和分析
单体架构
架构设计
先看下单体的架构图：
01-02-单体架构-基础.png
从上述图中可以看到，单体架构主要包括如下三部分：
-
客户端：包括web、app等供用户使用的客户端。
-
服务端：负责业务逻辑计算的进程（Process），包括了接受请求、业务逻辑处理、读写数据库、封装返回结果等功能。
-
数据存储：负责存储数据，并提供数据操作API。
一般实际使用时，我们除了开发上述的单体服务之外，为了提升系统的可用性和性能，会借助负载均衡器、DNS、CDN等来完善部署架构。
-
DNS：使用了DNS后，我们就可以多机房部署系统，在需要的时候进行DNS切换即可。
-
CDN：CDN主要时对系统使用到的静态资源做缓存，一方面静态资源的访问速度，另一方面避免了静态资源的流量落到应用服务器。使用CDN时还需要部署独立的文件服务器以供CDN做回源，文件服务器可以使用Nginx和对象存储。
-
负载均衡：负载均衡从网络七层模型来分的话，有基于硬件物理层的F5、基于四层LVS、还有基于七层网络的Nginx（现在的Nginx也支持四层负载）。
详细架构见下图：
01-02-单体架构-普适.png
适用场景
单体应用的适用场景主要集中在以下几种常见：
-
业务常见简单、功能不负责、研发人员较少。比如常见的ERP、O2O、OA等系统。
-
创业公司初期，在创业公司早期，最需要的是快速开发上线，使用单体是最合适的。
-
性能要求极其苛刻，有些场景对RT（Response Time）要求严格，比如一个请求需要在几十毫秒完成响应，这个时候最好的办法就是尽量减少任何的网络请求。具体的案例比如量化交易。
优缺点
-
优点
-
开发简单
-
测试简单
-
部署简单
-
扩容简单
-
-
缺点
-
耦合，所有服务代码耦合在一起，运行耦合在一起。
-
读写性能瓶颈，单点数据库容易成为性能瓶颈。
-
重构
-
重构时机
-
业务复杂，耦合度高，开发效率低时。
-
性能问题，数据库单点性能瓶颈时。
-
-
重构方法
-
数据库拆分：垂直拆分（分库）、水平拆分（分表）。
-
应用拆分：水平拆分（功能维度）、垂直拆分（业务维度）。
-
SOA架构
架构设计
SOA架构也常成为面向服务架构，该架构的特点时服务按照业务维度进行拆分，同时数据库也进行业务垂直拆分，每个服务拥有独立的数据库。
服务在启动时注册到ESB总线上，服务之间通过ESB总线进行通讯。ESB总线可以理解成一个独立的服务，主要功能为保存注册到ESB上面的服务路由信息，并且将请求分发到对应的服务。
架构图如下所示：
01-03-面向服务架构-基础.png
如上所示，每个服务其实就是一个单体服务，其内部设计与上述单体架构完全一致。
适用场景
个人认为主要适用与两个场景：
-
一是在传统的企业内部，存在大量的不同业务的系统，若需要进行系统间互通时，可适用SOA架构。不管时对系统的改造来说，还是对各系统的兼容性上都是比较适用的。
-
二是在若公司的业务场景中，只有少量的服务是需要提供服务给其他多个业务系统使用时，也可使用SOA架构。
优缺点
主要说下个人认为的缺点吧：
-
仅垂直拆分，每个服务其实还是单体服务，终究可能触达单体服务的瓶颈。
-
服务通过ESB通讯，ESB容易成为系统瓶颈，同时服务的调用链路增加了一层。
水平分层架构
架构设计
老规矩先看架构图吧：
01-04-水平分层架构-基础.png
从图中可以看出，水平分层架构是基于功能的方向进行拆分的。从一个请求进入到服务器后，经过了图中的网关层、业务逻辑层、数据访问层、数据库，最终完成数据库操作后一步步返回。
水平分层架构在很多公司可能不会把数据访问层独立出来，但是经过多方了解，数据访问层独立出来的好处也是比较明显的，首先大部分应用都是对数据的操作，而逻辑计算部分其实是比较简单的。此时我们把数据访问层独立出来，就可以分别对业务逻辑层和数据访问层做独立的扩容。其次在涉及服务间调用时，我们只需要业务访问层直接访问下游的数据访问层即可。这样我们在设计时就可以要求服务调用不允许横向调用，这个原则对应模块化编程来说是很重要的。
下面我们详细分析下各层的核心功能吧：
-
网关层：是对非业务相关的功能的统一前置处理。
-
请求鉴权
-
数据完整性校验：对传输包体的长度和数据完整进行校验。
-
协议转换：外部输入协议一般使用https+json，而在服务端使用的协议一般为TCP+二进制，因此我们需要对输入的协议进行转换后才能发送到业务服务。
-
服务路由：根据输入的请求URI或者CMD进行服务的路由转发。
-
服务治理：限流、降级、熔断等。
-
-
业务逻辑层
- 业务逻辑判断、服务编排
-
数据访问层
-
CRUD
-
ORM
-
Sharding分库分表
-
屏蔽底层存储差异性（Mysql、Redis、MongoDB）
-
架构图中，有同步架构和异步架构之分，主要是为了在服务请求性能瓶颈是，在网关和业务逻辑层直接增加MQ，从而提升吞吐量。
关于同步还是异步架构，其实需要分析异步架构的适用场景，首先对请求来说分为读写请求，而读请求是不能使用异步架构的，那就是写请求我们可以使用异步架构来提升写性能。其次还需要对写请求进行二次分析，主要分析写请求是AP还是CP（关于CAP理论我们在其他章节中进行详细阐述），对CP的写请求来说，追求的是强一致性，因此也是不适合使用异步架构。最终我们可以得出异步架构适合AP场景的写请求。
适用场景
其实单独的水平分层架构适用场景还是比较少的，一般在一些业务单一但是流量较大的场景比较合适。
优缺点
主要是缺点比较明显：每层的粒度过粗，若业务稍微复杂，该架构就容易出现耦合的问题了。
微服务架构
终于到了微服务架构了，微服务架构也是目前使用最多的架构。但是微服务架构其实设计和理解起来都不难，其实就是把SOA架构和水平分层架构合起来了。
架构设计
老规矩先看架构图吧：
01-05-微服务架构-基础.png
从图中我们可以看出，微服务是对单体架构进行垂直拆分+水平拆分后的产物。但是注意垂直拆分是需要一拆到底的，也就是包括数据库也需要拆分。我在很多小公司看到的情况是数据库只有一个，但是服务有十多个，这种情况我更新称之为为了微服务而微服务。
微服务架构的难点有两方面，一方面是拆分粒度，另一方面是拆分后引入的较多的复杂性（服务发现、服务治理、数据一致性、分布式锁等）。这里主要阐述下拆分粒度，而其他的复杂性在其他章节慢慢来进行设计和解决。
关于拆分粒度，主要都是基于业务拆分吧。还有种情况就是有时需要对API粒度进行拆分，什么时候适合进行API粒度拆分呢，个人认为这种情况：读写比例较大的请求，且读请求影响了写请求。
适用场景
微服务的适用场景就比较多了，目前大部分的互联网业务，业务比较复杂，流量也容易突增。这时候适用微服务架构是比较合适的，这也是微服务架构流行的主要原因吧。
优缺点
首先想说的是微服务架构不是银弹，一个是微服务架构带来的复杂性能否解决，另一方面是微服务架构种，每个服务都需要自己来进行服务发现以及服务熔断等一系列非业务性功能。
服务网格架构
服务网格架构最核心的就是解决了上面微服务架构中提出的问题，将服务注册、服务发现、服务降级熔断等等所有非业务的功能都独立了出来。由单独的进程来进行相关功能，同时该进程需要和微服务部署在同一台机器或者容器中。
架构设计
老规矩先看架构图：
01-07-服务网格架构图-基础.png
关于服务网格架构，因个人没有实际的实践场景，就不多进行深入的阐述了，主要表述下以下两点：
-
原则：Sidecar必须与应用进程部署在同一台机器上，否则有多了一层网络链路，那微服务的问题还是没有解决。
-
框架选型：据了解目前比较稳定的是Istio。
中台架构
我们主要理解的是中台架构不是一种独立的架构，它可以是基于微服务架构，也可以是基于水平分层架构或者SOA架构。
中台架构最主要的是聚焦在功能服务的下沉，有独立的组织机构，独立的业务机构来进行中台服务的研发。
关于中台架构我们看个架构图即可：
01-06-中台架构-基础.png
云原生架构
云原生架构也不是业务架构，其关注的是运维侧的架构，具体内容我们在运维篇章里面来详细阐述吧。
网友评论