Spring Cloud Note（1）- 系统架构演变过程
系统架构演变过程
好的架构是演变出来的！
随着IT行业的不断发展，网站应用的规模也在不断的扩大，导致系统架构也在不断的进行快速的迭代变化。从互联网早期到现在，系统架构大体经历了下面几个过程：
- 单体应用架构
- 垂直应用架构
- 分布式架构
- SOA架构
- 微服务架构
- Service Mesh（服务网格）
单体应用架构
单体应用架构也就是大家在早期所学习的JavaEE知识SSH或者SSM架构模式，会采用分层架构模式：数据库访问层、业务逻辑层、控制层，从前端到后台所有的代码都是一个小的开发团队去完成。
该架构模式没有对我们业务逻辑代码实现拆分，所有的代码都写入到同一个工程中里面，适合于小公司开发团队或者个人开发。
这种架构模式最大的缺点，如果该系统一个模块出现不可用、会导致整个系统无法使用。
当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架(ORM)是影响项目开发的关键。
优点
- 项目架构简单，小型项目的话， 开发成本低，开发速度快
- 项目部署在一个节点上， 维护方便
缺点
- 全部功能集成在一个工程中，对于大型项目来讲不易开发和维护
- 项目模块之间紧密耦合，单点容错率低，并发能力差
- 无法针对不同模块进行针对性优化和水平扩展
垂直应用架构
随着访问量的逐渐增大，单一应用只能依靠增加节点来应对(增加服务器数量)，但是这时候会发现并不是所有的模块都会有比较大的访问量。
这时候单体应用的架构就不能够满足我们的需求，我们需要将系统里面的模块拆分开来，这样对于需要水平扩展的节点，是比较友好的。
比如，我的前台系统用户访问量变大，我就只需要增加前台系统的节点进行水平扩展就可以了。
优点
- 系统拆分实现了流量分担，解决了并发问题
- 可以针对不同模块进行优化和水平扩展
- 可以实现负载均衡，容错率提高
- 当一个模块水平扩展（集群）后，假设有三台服务器S1，S2，S3。当前有100个请求进来，每台服务器应该各处理三分之一。有可能出现全部请求S1，这不是我们想要的，要分流，每个服务期都处理三分之一
- 一个系统的问题不会影响到其他系统，提高容错率
缺点
- 系统之间相互独立， 无法进行相互调用
- 系统之间相互独立， 会有重复的开发任务
分布式架构
分布式架构 也是基于垂直应用架构演变而来，当垂直应用越来越多，重复的业务代码就会越来越多。这时候，我们就思考可不可以将重复的代码抽取出来，做成统一的业务层作为独立的服务，然后由前端控制层调用不同的业务层服务呢？
这就产生了新的分布式系统架构。它将把工程拆分成表现层和服务层两个部分，服务层中包含业务逻辑。表现层只需要处理和页面的交互，业务逻辑都是调用服务层的服务来实现。
优点
- 抽取公共的功能为服务层，提高代码复用性
缺点
- 系统间耦合度变高，调用关系错综复杂，难以维护
SOA架构
服务治理
在分布式架构下，当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心对集群进行实时管理，提高集群利用率。比如，上面分布式架构中的前台页面系统，需要访问下面多个服务，十几二十个呢？下面的用户服务也被十几二十个调用者调用？
此时，用于资源调度和治理中心(SOA Service Oriented Architecture，面向服务的架构)是关键。
中间的这层服务治理，现在主流用dubbo，但是早期是有人用WebService或者是ESB企业服务总线，底层通讯协议SOAP协议（Http+XML）实现传输。
没有SOA会出现什么问题
- 服务越来越多，需要管理每个服务的地址
- 调用关系错综复杂，难以清理依赖关系
- 服务过多，服务状态难以管理，无法根据服务情况动态管理。
SOA 服务治理需要做什么
- 服务注册中心 实现服务自动注册和发现，无需人为记录服务地址
- 服务自动订阅 服务列表自动推送，服务调用透明化，无需关心依赖关系
- 动态监控服务状态监控报告，人为控制服务状态
优点
- 使用注册中心解决了服务间调用关系的自动调节
缺点
- 服务间会有依赖关系，一旦某个环节出错会影响较大( 服务雪崩 )
- 服务关系复杂，运维、测试部署困难，不符合DevOps思想。
微服务架构
微服务架构模式是从SOA架构模式演变过来， 比SOA架构模式粒度更加精细，让专业的人去做专业的事情（专注），目的是提高效率，每个服务与服务之间互不影响，微服务架构中每个服务必须独立部署、互不影响，拥有自己的数据库。微服务架构模式体现轻巧、轻量级、适合于互联网公司开发模式。
服务拆分没有具体的标准，根据具体的业务进行拆分。
微服务架构倡导应用程序设计程多个独立、可配置、可运行和可微服务的子服务。服务与服务通讯协议采用Http协议，使用restful风格API形式来进行通讯，数据交换格式轻量级json格式通讯，整个传输过程中，采用二进制，所以http协议可以跨语言平台，并且可以和其他不同的语言进行相互的通讯，所以很多开放平台都采用http协议接口。
微服务架构与SOA架构的不同
微服务架构比 SOA架构粒度会更加精细，让专业的人去做专业的事情（专注），目的提高效率，每个服务于服务之间互不影响，微服务架构中，每个服务必须独立部署，微服务架构更加轻巧，轻量级。
SOA 架构中可能数据库存储会发生共享，微服务强调独每个服务都是单独数据库，保证每个服务于服务之间互不影响。项目体现特征微服务架构比 SOA 架构更加适合与互联网公司敏捷开发、快速迭代版本，因为粒度非常精细。
优点
- 服务原子化拆分，独立打包、部署和升级，保证每个微服务清晰的任务划分，利于扩展
- 微服务之间采用Restful等轻量级HTTP协议相互调用
缺点
- 分布式系统开发的技术成本高（容错、分布式事务等）
微服务的特点
- 单一职责：微服务中每一个服务都对应唯一的业务能力，做到单一职责
- 微：微服务的服务拆分粒度很小，例如一个用户管理就可以作为一个服务。每个服务虽小，但“五脏俱全”。
- 面向服务：面向服务是说每个服务都要对外暴露服务接口API。并不关心服务的技术实现，做到与平台和语言无关，也不限定用什么技术实现，只要提供Rest的接口即可。
- 自治：自治是说服务间互相独立，互不干扰
- 团队独立：每个服务都是一个独立的开发团队，人数不能过多。
- 技术独立：因为是面向服务，提供Rest接口，使用什么技术没有别人干涉
- 前后端分离：采用前后端分离开发，提供统一Rest接口，后端不用再为PC、移动段开发不同接口
- 数据库分离：每个服务都使用自己的数据源
- 部署独立，服务间虽然有调用，但要做到服务重启不影响其它服务。有利于持续集成和持续交付。每个服务都是独立的组件，可复用，可替换，降低耦合，易维护
Service Mesh（服务网格）
Service mesh这一概念其实出现的时间并不长，并且已经有相当数量的不同的方法来解决“service mesh”的问题，如管理微服务通信。目前，确定了三种service mesh创建的通信层可能存在的位置：
- 每个微服务导入的library
- 在特定节点提供服务给所有容器的节点agent
- 与应用程序容器一起运行的sidecar容器
424
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
