点击 程序员小胖 关注公众号 每日技术干货，第一时间送达！
导语：随着互联网的发展, 网站应用的规模也在不断的扩大, 进而导致系统架构也在不断的进行变化. 从互联网早起到现在, 系统架构大体经历了下面几个过程: 单体应用架构--->垂直应用架构--->分布式架构--->SOA架构--->微服务架构，当然还有大家都不怎么熟悉的的Service Mesh(服务网格化). 接下来我们就来了解一下每种系统架构是什么样子的, 以及各有什么优缺点。
单体应用架构
互联网早期, 一般的网站应用流量较小, 只需一个应用, 将所有功能代码都部署在一起就可以, 这样可以减少开发、部署和维护的成本。比如说一个电商系统, 里面会包含很多用户管理、商品管理、订单管理、物流管理等等很多模块,我们会把它们做成一个web项目, 然后部署到一台tomcat服务器上.
优点:
- 项目架构简单, 小型项目的话, 开发成本低
- 项目部署在一个节点上, 维护方便
缺点:
- 全部功能集成在一个工程中, 对于大型项目来讲不易开发和维护
- 项目模块之间紧密耦合, 单点容错率低
- 无法针对不同模块进行针对性优化和水平扩展
垂直应用架构
随着访问量的逐渐增大, 单一应用只能依靠增加节点来应对, 但是这时候会发现并不是所有的模块都会有比较大的访问量.
还是以上面的电商为例子, 用户访问量的增加可能影响的只是用户和订单模块, 但是对消息模块的影响就比较小. 那么此时我们希望只多增加几个订单模块, 而不增加消息模块. 此时单体应用就做不到了, 垂直应用就应运而生了.
所谓的垂直应用架构, 就是将原来的一个应用拆成互不相干的几个应用, 以提升效率. 比如我们可以将上面电商的单体应用拆分成:
- 电商系统(用户管理 商品管理 订单管理)
- 后台系统(用户管理 订单管理 客户管理)
- CMS系统(广告管理 营销管理)
这样拆分完毕之后, 一旦用户访问量变大, 只需要增加电商系统的节点就可以了, 而无需增加后台和CMS的节点.
优点:
- 系统拆分实现了流量分担, 解决了并发问题, 而且可以针对不同模块进行优化和水平扩展
- 一个系统的问题不会影响到其他系统, 提高容错率
缺点:
- 系统之间相互独立, 无法进行相互调用
- 系统之间相互独立, 会有重复的开发任务
分布式架构
当垂直应用越来越多, 重复的业务代码就会越来越多. 这时候, 我们就思考可不可以将重复的代码抽取出来, 做成统一的业务层作为独立的服务, 然后由前端控制层调用不同的业务层服务呢？这就产生了新的分布式系统架构. 它将把工程拆分成表现层和服务层两个部分, 服务层中包含业务逻辑. 表现层只需要处理和页面的交互, 业务逻辑都是调用服务层的服务来实现.
优点:
- 抽取公共的功能为服务层, 提高代码复用性
缺点:
- 系统间耦合度变高,调用关系错综复杂,难以维护
SOA架构
在分布式架构下, 当服务越来越多, 容量的评估, 小服务资源的浪费等问题逐渐显现, 此时需增加一个调度中心对集群进行实时管理. 此时, 用于资源调度和治理中心(SOA Service OrientedArchitecture, 面向服务的架构)是关键.
优点:
- 使用注册中心解决了服务间调用关系的自动调节
缺点:
- 服务间会有依赖关系, 一旦某个环节出错会影响较大( 服务雪崩 )
- 服务关心复杂, 运维、测试部署困难
微服务架构
微服务架构在某种程度上是面向服务的架构SOA继续发展的下一步, 它更加强调服务的"彻底拆分".
优点:
- 服务原子化拆分, 独立打包、部署和升级, 保证每个微服务清晰的任务划分, 利于扩展
- 微服务之间采用Restful等轻量级http协议相互调用
缺点:
- 分布式系统开发的技术成本高（容错、分布式事务等）
微服务架构目前是企业开发中使用使用频率最高的架构, 后续会持续更新微服务每个服务组件从零到一集成使用, 以及后续使用中产生的问题。
服务网格(Service Mesh)
针对单体架构的种种问题, 微服务架构被推到了台前，将单体应用拆分后由多个微服务构建的复杂系统，系统中各个微服务之间彼此通过网络进行通信，很好地解决了单体服务中存在的问题。而微服务中最大的挑战便是如何以标准化的方式管理微服务以及如何保证复杂网络环境中微服务间的可靠通信，确保整个系统的最大可用性，提供尽可能高的SLA。
虽然微服务架构使用频率很高但是从软件设计的角度仍存在以下缺点:
- 耦合性很高, 每个应用都需封装负载均衡、服务发现、安全通信以及分布式追踪等功能
- 灵活性差, 复用率低下, 不同的应用需要重复实现管理复杂,当其中一项如负载均衡逻辑发生变化,需要更新所有服务
- 可运维性低,所有组件均封装在业务逻辑代码中,不能作为一个独立运维对象
- 对开发人员能力要求很高
针对上面面临的问题, 发现了更好的解决方案, OSI定义了开放系统的层次结构、层次之间的相互关系以及各层所包括的可能的任务, 上层并不需要对底层具体功能有详细的了解, 只需按照定义的准则协调工作即可.因此, 我们也可参照OSI七层模型将公用库设计为位于网络栈和应用业务逻辑之间的独立层, 即透明网络代理, 新的独立层完全从业务逻辑中抽离, 作为独立的运行单元, 与业务不再直接紧密关联. 通过在独立层的透明网络代理上实现负载均衡、服务发现、熔断、运行时动态路由等功能, 该透明代理在业界有一个非常新颖时髦的名字：Service Mesh。
在这种方案中, Service Mesh作为独立运行层, 它很好地解决了微服务所面临的挑战, 使应用具备处理网络弹性逻辑和提供可靠交互请求的能力. 它使得耦合性更低、灵活性更强, 跟现有环境的集成时间和人力代价更小, 也提供多语言支持、多协议支持, 运维和管理成本更低. 最主要的是开发人员只需关注业务代码逻辑, 而不需要关注业务代码以外的其他功能, 即Service Mesh对开发人员是透明的.
引用资料《Service Mesh实战：基于Linkerd和Kubernetes的微服务实践》
