系统架构演化过程

为什么要了解系统架构的演化过程

• 技术发展认知
• 技术选型、创新

技术发展认知

技术为什么出现？技术可以理解为是一种方案，它们不是突然诞生的，而是为了解决某一个或某一类问题才而出现。

当问题解决之后，随着项目的运行发展，业务需求与用户量不断增加后，新的问题也会随之出现，这个时候又会促使技术的进一步发展。

系统架构的演化过程也是如此，因此除了理解技术架构方案外，还需理解技术架构的发展所解决的问题，这样可以更深刻的理解技术

技术选型与创新

了解系统架构的发展过程也可以对自己在项目过程中具有启发作用，系统架构的演化过程几乎是大多数系统发展的路程，我们可以将其结合于自己的项目中，来解决项目在发展过程中所带来的问题。

演变过程

单体架构

单体架构是大多数项目的初期架构，应用程序、缓存、数据库都在同一台服务器中。

这一架构的开发速度比较快，成本低。系统的问题主要集中在应用程序的业务实现上。

分层-分布式

但是随项目的运行，内部的数据量及系统所承载的用户活跃量开始增加，会出现系统资源分配不均衡等问题，这时系统服务根据功能拆分，单独部署服务。

在这一架构中各个服务依据各自的特点选择合适的机器，以此充分利用到服务器的资源，同时在这一阶段从整体的架构上来讲就已经构成了分布式架构。

集群

而随用户的增加及软件服务的运行中会出现机器的意外停止，高可用及流量负载就成为了这一架构的问题，为了解决这个问题在当前的架构下发展就提出了采用集群作为解决方案。

集群不止是在应用服务上，在数据库/缓存上都可以应用，当下为分布式+集群的架构。

微服务

在当下的架构中对软件项目而言应用程序是整体部署，随系统的运行会发现，存在一些模块它的用户访问量明显远远大于其他模块，并且在一些模块中业务的变更复杂度远高于其他模块，因此在应用程序的基础上就进行拆分，根据业务及访问热度拆分成多个服务分别部署在不同机器上，从而演化成为微服务。

实际上在软件的系统发展阶段中，针对任务的多样性也提出了很多的技术解决方案，如针对搜索的es、针对异步任务的kafka或rabbitmq等等，它们在项目的发展中也会应用到系统架构中。

分布式\集群\微服务

在前面整体架构的演变中已经介绍了从单体到微服务的发展过程，其中需注意分布式、集群、微服务的概念。

分布式与集群：在作用层面上都是针对服务器部署，而两者的区别在于分布式是在多个机器部署所做的事情和功能不一样但是整体是维持运行同一个系统。而集群是多台机器做相同的事情具有相同的功能。

在业界中常有分布式与微服务的比较，实际上两者是没有可比的关系，微服务是针对应用程序的设计而不是服务的部署，微服务是应用程序根据需求拆分成多个微服务。

理论上拆分后的微服务是可以部署在同一台机器，但是这样体现不了价值，因此一般微服务会分开部署，这时又符合分布式的定义，顾可以成微服务分布式架构。

微服务中的核心要素-拆分原则

项目拆分与复杂度

微服务项目开发是拆分得越细节越单一越好吗？

答案是不是的，因为当一个系统拆分为两个服务或多个服务的时候，整个项目的开发/维护/运营的复杂度及所遇到的问题、所需要的团队人员也会随之增加。所以拆分的越细复杂度也就越大，如果处理不好就可能给自己挖坑呢？

软件服务的拆分往往会考虑如下因素

1. 团队人员：人数/技术，无论项目是单体还是微服务最终还是需要依托于团队整体完成，所以团队的人数技术实力会影响到项目涉及的技术架构，及解决问题的能力
2. 业务需求：团队成员满足条件的情况下，还需基于业务公司发展的需求。如果在单体架构下可以满足业务的需求则用单体，在软件项目开发中趋向最优节约资源的方式实现功能。

微服务的拆分维度有哪些

微服务的拆分维度方式有多种，如下4种是常见运用的方式，其中模块维度与功能维度应用相对最多。

1. 模块维度：微服务架构中模块维度是最基本的拆分单位。根据系统整体一类功能集中在一起定义的模块进行拆分，如：将用户模块拆分为用户服务，将商品模块拆分为商品服务或将订单模块拆分为订单服务等。每个服务可以独立开发、测试和部署，具备清晰的职责边界和功能集合。
2. 功能维度：除了按照模块进行拆分外，针对具有较复杂的业务，较严格要求或具有较大的技术挑战的时候才会选择拆分出来，如：购物车功能，支付功能，秒杀功能等。
3. 读写维度：在系统中大多是读多写少，往往读的并发压力大，从整体服务功能中来看流量在读和写上就会出现明细的不均衡问题，这个时候可以将读和写拆分，再根据流量情况适当为读服务增加机器。如商品服务，就可以拆分为 读-商品服务 、写-商品服务。
4. AOP维度：AOP是面向切拆分，是将被用于跨多个模块或功能的关注点，如日志记录、性能监控、异常处理等功能。拆分程独立的服务，供其他微服务调用，以确保这些关注点的一致性和复用性。

除了上面4种拆分方式外，也可以根据分层架构的方式进行拆分，比如MVC三层结构，可以拆分为交付服务，业务服务，数据处理服务。在拆分的时候应该根据具体业务需求和开发团队的实际情况来确定。

小结

在本节中主要介绍微服务的拆分原则，拆分维度与方式有很多种，其中模块维度与功能维度的拆分是应用较为简单也最普遍的方式，另外需要注意拆分不是越细越好，而是要结合项目与团队及需求的实际情况进行合理拆分。

微服务中的核心要素服务化

进行拆分后一定是微服务？

在上一节中讲到微服务的拆分方式有很多种，但我们平时做项目的时候拆分出来的服务或者功能可以称为微服务吗？

答案：不一定

如果我们对系统拆分只是把相同的功能拆分出来使得程序更好复用和维护那么组件就可以满足这个需求，如果只是将服务单独拆分出来独立提供业务实际就是一个子系统，那么如何做才能说是微服务项目呢？

理解服务化

微服务实际上是一种形式与思想的转变，在传统的单体项目开发中以一份代码部署一个服务来实现需求的项目，而微服务项目的开发则是将一份项目代码，拆分为多个服务代码，每一个服务代码部署运行并最终一起实现需求的项目。

虽然拆分为多个维度的服务，但是在本质和方向上仍然以完整的业务为主，服务与服务之间定然会存在相关的联系，这就是微服务中的服务化。

服务化是指：将系统中的各个功能模块（或称为服务）通过独立的服务提供，并以服务为粒度进行拆分、开发、部署和管理的过程。服务化的目标是将系统拆分成多个自治的服务单元，以提高系统的可维护性、可扩展性和可测试性。

服务化关键的几个信息：

1. 单一职责：每个服务应该具有清晰的单一职责，即每个服务应该专注于完成某一个明确的功能或业务领域。这样可以保证服务的内聚性和独立性。
2. 独立开发和部署：每个服务可以独立开发和部署。不同的服务可以由不同的团队进行开发，团队可以根据需求独立地进行服务的迭代和升级，而不会影响到整个系统。
3. 轻量级通信：服务之间通过轻量级的RPC通信机制进行交互，这样可以降低服务之间的耦合度，使得服务之间的协作更加灵活和可靠。
4. 自治性：每个服务具有一定的自治性，即服务可以独立做出决策，并维护自己的数据存储和业务逻辑。这样可以保证服务的独立性和灵活性。
5. 可伸缩性：通过将系统拆分为多个服务，可以实现对某些高负载服务的独立扩展，而其他不需要扩展的服务则可以保持原样。这样可以提高系统的整体性能和可伸缩性。

与子系统、组件对比

微服务 VS 组件

微服务在实现的功能上是具有与组件很强的相似性，但是又具有关键性的不同，微服务的服务之间升级和修改并不会影响到相互调用的服务修改；

组件在使用上会要求包含业务系统内部，需要业务系统进行集成，如果组件的功能发生了修改，则所有引用此组件的业务系统都需要进行组件升级；

微服务 VS 子系统

在微服务中服务与服务虽然是各自单独部署运行，但是在功能上 具有耦合性，相互之间是围绕整个项目的核心业务展开规划的，在服务之间单独部署但又相互依存。

子系统是单独独立开发的，具有单独的独立体系业务，相互之间并不是相互依存的关系，因此即便某一个系统出现问题也不影响其他系统的业务运行。

小结

在本节中主要重点是理解什么是服务化及服务化的特征，当拆分出来的服务实现了服务化之后及可以认为是微服务。

微服务中的核心要素-通讯机制

对内：rpc与消息队列

对微服务内部服务之间的访问往往以rpc和消息队列为主。

RPC通信，是属于同步调度，在概念定义上描述是一种远程过程调用协议，用于不同服务之间的同步调用。通过RPC一个服务可以像调用本地函数一样调用远程服务的方法。

消息队列是一种异步通信机制，广泛应用于微服务架构中。服务可以将消息发送到消息队列，而不需要直接与接收方进行通信。其他服务可以从队列中订阅并消费这些消息。

通俗理解：

• RPC通信：这种方式相当于直接电话沟通。当一个服务需要与另一个服务交流时，它会直接发起调用，就像拨打电话一样。这种同步方式可以快速得到对方的反馈，非常适合需要即时处理的任务。然而，这也意味着调用方必须等待被调用服务处理完任务并响应，这可能会导致调用方在等待过程中无法执行其他任务。

  消息队列：使用消息队列的通信更像是发送电子邮件。服务不直接与其他服务通信，而是将信息发送到一个中间的消息系统，其他服务则从这个系统中订阅并接收信息。这种方式的优点是发送方发送消息后可以继续执行其他操作，不需要等待接收方的响应，从而提高了系统的效率。缺点是消息的处理不是实时的，可能会有一定的延迟。

RPC VS 消息队列

	RPC	消息队列
调度方式	同步	异步
时效	即时	延迟
建议	适合耗时小，要求即时性，以及变化较多的任务类型	适合耗时大，可以不要求即时性的任务

对外restful Api

微服务项目除了内部服务之间的通信外，也有对外暴露接口提供服务，通过定义restful api，每个服务暴露自己的HTTP接口以对外提供相应的功能。

小结

本节主要讲解在微服务中的通信机制rpc/消息队列/api，除了这些外还可以通过websocket进行通信，在微服务中主要采用的是rpc与消息队列做服务之间的通信为主，对外主要以restful api为主。

微服务中的核心要素-无状态

微服务中的状态是指是什么

“状态” 普遍的理解就是一个事物的多种形态，比如用户的就有 “冻结”,“正常”两种状态，那微服务中的状态又指什么呢？

概念的定义:在微服务中，如果一个数据需要被多个服务共享，才能完成一笔交易，那么这个数据被称为状态。进而依赖这个“状态”数据的服务被称为有状态服务，反之称为无状态服务

举个例子：

用户的会话信息：用户在登入后服务器记录用户登入的会话信息

在单体项目中session一般以存储在服务器本身上，这个时候如果拆分为多个服务之后，其他服务是没有存储用户的session信息记录的，它们只能从用户服务中获取，以便在整个系统中保持用户状态的一致性。

在整个环节中用户服务就需要维护用户登入的会话信息，因此这个会话信息就成为了一种状态，而其他服务需要从用户服务中获取登入信息，该状态就升级为了服务之间的状态，这就是微服务中的服务状态。

从结构上可以看出因为“状态”关系，如果用户服务出现意外停止运行，那么其他服务器因需要用户服务器的状态信息而无法正常执行业务，则直接影响到整个系统的稳定，因此微服务中会提倡无状态。

如何实现无状态？

在微服务中如果一个数据需要被多个服务共享，那么它就是有状态的，而结合于业务来分析大致可以分为两大类型：共享状态，流程状态。

共享状态型

之前列举的例子就是共享类型，用户状态的信息需要被其他的服务所依赖，但是在业务中除了本身服务对状态维护其他服务不会维护该信息，只做读取操作。

如果是这一类型，我们可以采取分布式数据库或缓存的方式实现数据的共享来解决这个问题。如果用户服务出现异常，其他服务也仍然可以从分布式缓存中获取到信息继续完成相关的业务。

【扩展】在微服务中的设计模式，对于各个服务是独享自己的数据库的。

流程状态型

是指该状态数据在服务之间会随业务的流程走向而发生状态更改，在特定的流程环节又有相关服务会订阅该数据状态的变化。

典型的例子：订单发货，订单从生成→待支付→完成支付→待发货→发货→到货→签收

这其中订单信息会在各个订单服务，支付服务，库存等服务发生变更，并相关服务会订阅或读取该任务记录消息。

针对该类型可以采取基于消息队列的事件驱动来实现解决，如下图在绘制时不考虑库存因素。

如上，在用户支付成功后由订单将信息发送至kafka的某一个主题中，而其他如订单/库存/物流等服务则订阅主题信息的变化，然后再做相应的任务处理。从图上可以明显的发现，订单服务/物流服务/支付服务之间的耦合实践是很低的.

小结

本节中重点在于理解微服务中服务之间的状态，状态是指服务在处理请求时所需要的数据或信息的集合。状态可以是服务内部的数据，也可以是与其他服务共享的数据。状态可以包括用户的会话信息、请求参数、中间计算结果、数据库记录等。在微服务中并不是不允许有状态的存在，而需要根据情况来定。