系统架构的演变过程（整理）

  • 杂谈
  • 正文
  • 概述
  • 单体应用架构
  • 优点
  • 缺点
  • 垂直应用架构
  • 优点
  • 缺点
  • 分布式架构
  • 优点
  • 缺点
  • SOA架构
  • 优点
  • 缺点
  • 微服务架构
  • 微服务架构与SOA架构的不同
  • 优点
  • 缺点
  • Service Mesh(服务网格)


杂谈

公司目前使用的架构是SOA，准备往微服务转化，博主在自行研究的过程中，对整个系统架构有了较为全面的理解，这是之前没有注意到的，所以还是觉得有必要整理一下。

在大学的时候，制作了一个简易的班级日常活动系统，现在看起来是 单体应用架构 ,刚进公司实习的时候，进行维护的一个人员管理系统是 垂直应用架构 ，转正后进的部门做知识图谱，运用的是 SOA架构，现在正准备往 微服务

正文

概述

随着IT行业的不断发展，网站应用的规模也在不断的扩大，导致系统架构也在不断的进行快速的迭代变化。

从互联网早期到现在，系统架构大体经历了下面几个过程：

  1. 单体应用架构
  2. 垂直应用架构
  3. 分布式架构
  4. SOA架构
  5. 微服务架构
  6. Service Mesh(服务网格)

接下来我就总结一下每种系统架构是什么样子的， 以及各有什么优缺点。

单体应用架构

单体应用架构也就是大家在早期所学习的JavaEE知识SSH或者SSM架构模式，会采用分层架构模式：数据库访问层、业务逻辑层、控制层，从前端到后台所有的代码都是一个小的开发团队去完成。

该架构模式没有对我们业务逻辑代码实现拆分，所有的代码都写入到同一个工程中里面，适合于小公司开发团队或者个人开发。

这种架构模式最大的缺点，如果该系统一个模块出现不可用、会导致整个系统无法使用。

系统架构的演变 系统架构演变过程_分布式

优点

  • 项目架构简单，小型项目的话， 开发成本低
  • 项目部署在一个节点上， 维护方便

缺点

  • 全部功能集成在一个工程中，对于大型项目来讲不易开发和维护
  • 项目模块之间紧密耦合，单点容错率低
  • 无法针对不同模块进行针对性优化和水平扩展

垂直应用架构

随着访问量的逐渐增大，单一应用只能依靠增加节点来应对，但是这时候会发现并不是所有的模块都会有比较大的访问量。

这时候单体应用的架构就不能够满足我们的需求，我们需要将系统里面的模块拆分开来，这样对于需要水平扩展的节点，是比较友好的。

比如，我的前台系统用户访问量变大，我就只需要增加前台系统的节点进行水平扩展就可以了。

系统架构的演变 系统架构演变过程_系统架构的演变_02

优点

  • 系统拆分实现了流量分担，解决了并发问题，而且可以针对不同模块进行优化和水平扩展
  • 一个系统的问题不会影响到其他系统，提高容错率

缺点

  • 系统之间相互独立， 无法进行相互调用
  • 系统之间相互独立， 会有重复的开发任务

分布式架构

分布式架构 也是基于垂直应用架构演变而来，当垂直应用越来越多，重复的业务代码就会越来越多。这时候，我们就思考可不可以将重复的代码抽取出来，做成统一的业务层作为独立的服务，然后由前端控制层调用不同的业务层服务呢？

这就产生了新的分布式系统架构。它将把工程拆分成表现层和服务层两个部分，服务层中包含业务逻辑。表现层只需要处理和页面的交互，业务逻辑都是调用服务层的服务来实现。

系统架构的演变 系统架构演变过程_系统架构的演变_03

优点

  • 抽取公共的功能为服务层，提高代码复用性

缺点

  • 系统间耦合度变高，调用关系错综复杂，难以维护

SOA架构

在分布式架构下，当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心对集群进行实时管理，比如，上面分布式架构中的前台页面系统，需要访问下面多个服务，十几二十个呢？下面的用户服务也被十几二十个调用者调用？

此时，用于资源调度和治理中心(SOA Service OrientedArchitecture，面向服务的架构)是关键。

系统架构的演变 系统架构演变过程_java_04


中间的这层服务治理，现在主流用dubbo，但是早期是有人用WebService或者是ESB企业服务总线，底层通讯协议SOAP协议（Http+XML）实现传输。

优点

  • 使用注册中心解决了服务间调用关系的自动调节

缺点

  • 服务间会有依赖关系，一旦某个环节出错会影响较大( 服务雪崩 )
  • 服务关心复杂，运维、测试部署困难

微服务架构

微服务架构模式是从SOA架构模式演变过来， 比SOA架构模式粒度更加精细，让专业的人去做专业的事情（专注），目的是提高效率，每个服务与服务之间互不影响，微服务架构中每个服务必须独立部署、互不影响，微服务架构模式体现轻巧、轻量级、适合于互联网公司开发模式。

微服务架构倡导应用程序设计程多个独立、可配置、可运行和可微服务的子服务。服务与服务通讯协议采用Http协议，使用restful风格API形式来进行通讯，数据交换格式轻量级json格式通讯，整个传输过程中，采用二进制，所以http协议可以跨语言平台，并且可以和其他不同的语言进行相互的通讯，所以很多开放平台都采用http协议接口。

系统架构的演变 系统架构演变过程_系统架构的演变_05

微服务架构与SOA架构的不同

  • 微服务架构比 SOA架构粒度会更加精细，让专业的人去做专业的事情（专注），目的提高效率，每个服务于服务之间互不影响，微服务架构中，每个服务必须独立部署，微服务架构更加轻巧，轻量级。
  • SOA 架构中可能数据库存储会发生共享，微服务强调独每个服务都是单独数据库，保证每个服务于服务之间互不影响。
  • 项目体现特征微服务架构比 SOA 架构更加适合与互联网公司敏捷开发、快速迭代版本，因为粒度非常精细。

优点

  • 服务原子化拆分，独立打包、部署和升级，保证每个微服务清晰的任务划分，利于扩展
  • 微服务之间采用Restful等轻量级http协议相互调用

缺点

  • 分布式系统开发的技术成本高（容错、分布式事务等）

Service Mesh(服务网格)

Service mesh这一概念其实出现的时间并不长，并且已经有相当数量的不同的方法来解决“service mesh”的问题，如管理微服务通信。目前，确定了三种service mesh创建的通信层可能存在的位置：

  • 每个微服务导入的library
  • 在特定节点提供服务给所有容器的节点agent
  • 与应用程序容器一起运行的sidecar容器

嗯…扯不动了…O(∩_∩)O哈哈~以后有开发到这种架构的项目我再完善吧。