互联网的蓬勃发展，网站应用规模的不断扩大，导致了系统架构也在不断的进行变化。从互联网早期到现在，系统架构大体经历了下面几个过程: 单体应用架构—>垂直应用架构—>分布式架构—>SOA架构—>微服务架构，还有悄然兴起的Service Mesh(服务网格化)。本文主要对各系统架构出现的背景及其优缺点进行介绍和分析。
1、单体架构
架构产生背景
单体架构是将所有的功能集成于一个服务中，即最终会打包成一个具体的应用，例如jar包或war包，然后部署在一个web容器中运行（如tomcat、weblogic、jboss）。每个项目包括所有的层级，如一个web工程里面包括了前端页面，web层代码，Service层代码，DAO层代码，把这些代码打包到一个项目当中，放到web容器中启动。如图所示：
物理服务器的CPU、内存、存储器、连接数等资源有限，单体系统能够承受的的QPS也是有限的，某个时段大量连接同时执行操作，会导致web服务和数据库服务在处理上遇到性能瓶颈。解决方案如下：
- 采用分而治之的思想，对大数据库、大表进行分割，以便实施更好的控制和管理。
- 是采用集群技术，通过增加新的服务器来分散并发访问流量（即使用多台服务机进行CPU、内存、存储的分摊，以提供更好的性能）。
虽然通过集群可以提升并行处理能力以及对于高可用的实现，但是同时还需要考虑到业务的复杂度，如果仍然把所有的业务逻辑全部耦合在一起放在一个 war 包中来管理，那对于代码的维护和扩展来说是非常困难的。而且如果某个业务功能出现故障，会导致整个系统不可用。所以这个阶段要做的就是降低业务的耦合度，提升系统的容错性。
优点：
- 项目架构简单，适用于与小型项目，开发成本低。
- 系统的简易性：系统语言风格、业务结构，接口格式均具有一致性，服务都是耦合在一起的，不存在各个业务通信问题。
- 易于部署与升级：相对于微服务架构中的每个服务独立部署，单体系统只需将单个目录下的服务程序统一部署和升级。
- 易于测试：单体应用一旦部署，所有的服务或特性就都可以使用了，简化了测试过程，无需额外测试服务间的依赖，测试均可在部署完成后开始。
- 较低的维护成本：只需维护单个系统即可。运维主要包括配置、部署、监控与告警和日志收集四大方面。相对于单体系统，微服务架构中的每个服务都需要独立地配置、部署、监控和日志收集，成本呈指数级增长。
缺点：
- 全部功能集成在一个工程中，对于大型项目来讲不易开发和维护。
- 复杂性高：由于是一个单体的系统，所以整个系统的模块是耦合在一起的，单点容错率低。模块的边界比较模糊、依赖关系错综复杂。功能的调整，容易带来不可知的影响和潜在的bug风险。
- 服务性能问题：单体系统遇到性能瓶颈问题，只能横向扩展，增加服务实例，进行负载均衡分担压力。无法纵向扩展，做模块拆分。
- 扩缩容能力受限：单体应用只能作为一个整体进行扩展，影响范围大，无法针对不同模块进行针对性优化和水平扩展。
- 无法做故障隔离：当所有的业务功能模块都聚集在一个程序集当中，如果其中的某一个小的功能模块出现问题（如某个请求堵塞），那么都有可能会造成整个系统的崩溃。
单体架构易于开发、维护和部署。在用户量不多的情况下，该架构完全可以满足需求，一旦用户量以及业务的复杂化，再加上代码的高度耦合，系统的维护和横向扩展异常困难。当用户量达到需要负载均衡来支持时，不得不使用多台服务器，但并不是应用中的每个功能模块都需要负载均衡，因此在扩展时必然会导致资源的浪费。例如：订单管理模块每秒访问1k次，用户管理每秒200次，这时扩展时连带用户管理一起扩展了，意义不大。总而言之，单体不易扩展与维护，代码的耦合度高。
2、垂直应用架构
架构产生背景
随着访问量的逐渐增大，单体应用只能依靠增加节点来应对，这时候我们会发现并不是所有的模块都会有比较大的访问量。以上面的电商为例，用户访问量的增加可能影响的只是用户和订单模块，但是对消息模块的影响就比较小. 那么此时我们希望只多增加几个订单模块，而不增加消息模块. 此时单体应用就做不到了，垂直应用架构就应运而生了。
所谓的垂直应用架构，就是将原来的一个应用，按照系统的业务或功能分类拆成互不相干的几个应用，每个子应用可以由不同的业务团队负责，以提升效率。比如我们可以将上面电商的单体应用拆分成:
- 电商系统(用户管理 商品管理 订单管理)
- 后台系统(用户管理 订单管理 客户管理)
- CMS系统(广告管理 营销管理)
拆分完毕之后，如果用户访问量变大，只需增加电商系统的节点就可以，而无需增加后台和CMS的节点。
优点：
- 系统拆分实现了流量分担，解决了高并发问题。
- 可以针对不同模块进行优化和水平扩展。
- 容错性高，一个系统的问题不会影响到其他系统，提高容错率（只需要针对出错的系统进行停机维护即可）。
缺点：
- 系统之间相互独立，相互调用的复杂度提高。
- 系统之间相互独立，会有重复的开发任务。
3、分布式架构
架构产生背景
当垂直应用越来越多，以业务功能纬度拆分出来的多个子系统会存在比较多的共享业务，这就导致了重复的业务代码越来越多。这时候，我们就思考可不可以将重复的代码抽取出来，做成统一的业务层作为独立的服务，然后由前端控制层调用不同的业务层服务呢？分布式架构就这样应运而生了。
分布式架构根据服务化的思想把一个垂直应用进行业务上的拆分，把一些通用的、会被多个上层服务调用的模块独立拆分出来，形成一些共享的基础服务。拆分后包括2个服务，一个是基础服务，另一个是业务功能，通过业务功能去调用相应的基础服务就构成了分布式应用。这样就很好的解决了服务与服务之间的调用问题。
优点：
- 抽取公共的功能为基础服务层，提高代码复用性。
- 解决了垂直应用架构中的系统之间调用的问题，降低了系统间的耦合度。
缺点：
- 随着服务层体积的增大，应用越来越多，服务的评估，治理与统一治理越来越难
4、SOA架构
架构产生背景
在分布式架构下，当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心对集群进行实时管理。由此形成了SOA(Service-Oriented Architecture)概念，即面向服务的架构。它可以根据需求通过网络对松散耦合的粗粒度应用组件（服务）进行分布式部署、组合和使用。一个服务通常以独立的形式存在于操作系统进程中。
在SOA模型中，所有的功能都被定义成了独立的服务，所有的服务通过服务总线(ESB)或流程管理器来连接。这种松散耦合的结构使得能够以最小的代价整合已经存在的各种异构系统，当然，由于需要实现对各种异构系统的适配(通常使用ESB来完成不同系统之间的协议转换及数据格式转换)，因此，其本身也会引入更多的复杂性。比较流行的SOA有ESB，DUBBO等。
优点:
- 使用注册中心解决了服务间调用关系的自动调节。
- 抽取公共的功能为服务，提高开发效率。
- 对不同的服务进行集群化部署解决系统压力。
- 基于ESB/DUBBO进一步减少了系统的耦合。
缺点:
- 服务间会有依赖关系，一旦某个环节出错会影响较大( 服务雪崩 )。
- 抽取服务的粒度较大。
- 服务关心复杂，运维、测试部署困难。
5、微服务架构
架构产生背景
微服务架构在某种程度上是面向服务架构SOA继续发展的下一步，它更加强调服务的"彻底拆分"。通过对服务尽可能的拆分，直到不能拆分为止，并独立打包运行，服务调用层与服务提供方通过轻量级的http协议进行交互，达到完全解耦的效果，每次交互只需要一个简单的http请求即可，无需复杂的调用技术。每个服务遵循单一职责原则，通过http接口向外提供功能。
优点：
- 服务原子化拆分，独立打包、部署和升级，保证每个微服务清晰的任务划分，利于扩展。
- 微服务遵循单一职责原则，采用restful等轻量级协议传输。
- 小团队的交付周期缩短，运维成本也大幅度下降。
缺点：
- 分布式系统开发的技术成本高（容错、分布式事务等）。
- 微服务过多，服务治理成本高，不利于系统维护。
SOA和微服务架构的区别
SOA是一种设计方法，其中包含多个服务，服务之间通过相互依赖最终提供一系列的功能。一个服务通常以独立的形式存在于操作系统进程中，各个服务之间通过网络调用。微服务架构和SOA类似，是在SOA基础之上的升华，强调的重点是“业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分成多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。
- SOA 关注的是服务的重用性、以及解决企业内部的信息孤岛问题。
- 微服务关注的是解耦，解耦和可重用性在特定的角度来看是一样，但本质上是不同的。解耦是降低业务之间的耦合度（也就是微服务关注的服务粒度），而可重用性关注的是服务的复用。
- 微服务会使用更轻量级的通信协议，使用 Restful 风格的 API。轻量级协议可以很好的支持多种语言，使语言生态更加丰富。
- 微服务会更多的关注 Devops 的持续交付，因为服务粒度更细使得开发运维变得更加重要。所以微服务与容器化技术的结合更加紧密。
- SOA是微服务的超集。
| 功能 | SOA | 微服务 |
|---|---|---|
| 组件大小 | 大块业务逻辑 | 单独任务或小块业务逻辑 |
| 耦合度 | 通常松耦合 | 总是松耦合 |
| 公司架构 | 任何类型 | 小型、专注于功能交叉团队 |
| 管理 | 着重中央管理 | 着重分散管理 |
| 目标 | 确保应用能够交互操作 | 执行新功能、快速拓展开发团队 |
| 调用方式 | RPC(较重) | HTTP(较轻) |
6、Service Mesh（服务网格）了解
Service mesh是近几年才出现的一个新兴概念，可以解决微服务之间通信愈发复杂的问题，是一种控制应用程序不同部分彼此共享数据的方式。
Service mesh能够适应分布式微服务环境的独特性质。在搭建在微服务中的大规模应用程序中，有许多既定的服务实例，它们跨本地和云服务器运行。所有这些移动部件显然使得各个微服务难以找到他们需要与之通信的其他服务。Service mesh可以在短时间内自动处理发现和连接服务，而无需开发人员以及各个微服务自行匹配。
这个图分为2部分，上面一个叫控制面，下面是服务集群。首先看服务集群中的服务，可以看出每个服务节点上必然有2个服务：
- 真实的服务，这个图中就是绿色的APP，它提供正真的业务服务，所有的业务逻辑它来实现，并提供服务。
- 一个代理服务，也叫边车，英文一般叫做Sidecar，它作为APP的代理，负责所有进入和出去APP流量的管理，所有的经过APP的访问都必须经过Sidecar。可以做流量管控，服务发现，返回值改写，服务容错，服务鉴权，访问统计等等等。代理在 service mesh 中被称为数据平面（data plane），数据层截获不同服务之间的调用并对其进行“处理”；
为了管理这些APP和Sidecar，还需要一个控制平面（control plane），它主要直接管理Sidecar，间接管理APP。主要是收集Sidecar的信息，下发控制信息到Sidecar，为Sidercar提供一些必要的服务支持。控制平面协调代理的行为，并且为操作者提供 API，使你能够操控和测量整个网格，也可以对接各种服务发现机制(如K8S服务发现)。
通过服务网格，你可以：
- 维护，配置和保护应用程序中所有或选定的微服务之间的通信。
- 在微服务中配置和执行网络功能，例如网络弹性，负载均衡，网络中断，服务发现等。
- 网络功能与业务逻辑相分离，耦合性低。因此，开发人员可以专注于应用程序的业务逻辑，而与网络通信相关的所有或大部分工作都由服务网格来处理。
- 由于服务到服务的代理通信使用的是诸如HTTP1.x / 2.x，gRPC等标准协议，因此开发人员可以使用任何技术来开发单个服务。
评论区