Spring Cloud Note（1）- 系统架构演变过程

最新推荐文章于 2022-06-05 15:56:59 发布

右京先生

最新推荐文章于 2022-06-05 15:56:59 发布

阅读量195

点赞数 1

分类专栏： Spring Could 文章标签： spring cloud

本文链接：https://blog.csdn.net/jwsl999/article/details/119884773

版权

Spring Could 专栏收录该内容

4 篇文章 0 订阅

订阅专栏

Spring Cloud Note（1）- 系统架构演变过程

系统架构演变过程

好的架构是演变出来的！

随着IT行业的不断发展，网站应用的规模也在不断的扩大，导致系统架构也在不断的进行快速的迭代变化。从互联网早期到现在，系统架构大体经历了下面几个过程：

单体应用架构
垂直应用架构
分布式架构
SOA架构
微服务架构
Service Mesh（服务网格）

单体应用架构

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

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

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

当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架(ORM)是影响项目开发的关键。

在这里插入图片描述

优点

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

缺点

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

垂直应用架构

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

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

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

在这里插入图片描述

优点

系统拆分实现了流量分担，解决了并发问题
可以针对不同模块进行优化和水平扩展
可以实现负载均衡，容错率提高
- 当一个模块水平扩展（集群）后，假设有三台服务器S1，S2，S3。当前有100个请求进来，每台服务器应该各处理三分之一。有可能出现全部请求S1，这不是我们想要的，要分流，每个服务期都处理三分之一
一个系统的问题不会影响到其他系统，提高容错率

缺点

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

分布式架构

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

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

在这里插入图片描述

优点

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

缺点

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

SOA架构

服务治理

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

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

1525530804753

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

没有SOA会出现什么问题

服务越来越多，需要管理每个服务的地址
调用关系错综复杂，难以清理依赖关系
服务过多，服务状态难以管理，无法根据服务情况动态管理。

SOA 服务治理需要做什么

服务注册中心实现服务自动注册和发现，无需人为记录服务地址
服务自动订阅服务列表自动推送，服务调用透明化，无需关心依赖关系
动态监控服务状态监控报告，人为控制服务状态

优点

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

缺点

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

微服务架构

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

服务拆分没有具体的标准，根据具体的业务进行拆分。

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

在这里插入图片描述

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

微服务架构比 SOA架构粒度会更加精细，让专业的人去做专业的事情（专注），目的提高效率，每个服务于服务之间互不影响，微服务架构中，每个服务必须独立部署，微服务架构更加轻巧，轻量级。

SOA 架构中可能数据库存储会发生共享，微服务强调独每个服务都是单独数据库，保证每个服务于服务之间互不影响。项目体现特征微服务架构比 SOA 架构更加适合与互联网公司敏捷开发、快速迭代版本，因为粒度非常精细。

1525532344817

优点

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

缺点

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

微服务的特点

单一职责：微服务中每一个服务都对应唯一的业务能力，做到单一职责
微：微服务的服务拆分粒度很小，例如一个用户管理就可以作为一个服务。每个服务虽小，但“五脏俱全”。
面向服务：面向服务是说每个服务都要对外暴露服务接口API。并不关心服务的技术实现，做到与平台和语言无关，也不限定用什么技术实现，只要提供Rest的接口即可。
自治：自治是说服务间互相独立，互不干扰
- 团队独立：每个服务都是一个独立的开发团队，人数不能过多。
- 技术独立：因为是面向服务，提供Rest接口，使用什么技术没有别人干涉
- 前后端分离：采用前后端分离开发，提供统一Rest接口，后端不用再为PC、移动段开发不同接口
- 数据库分离：每个服务都使用自己的数据源
- 部署独立，服务间虽然有调用，但要做到服务重启不影响其它服务。有利于持续集成和持续交付。每个服务都是独立的组件，可复用，可替换，降低耦合，易维护

1526860071166