系统架构的演变过程

单体架构

单体架构中,各个服务比如Mysql 和 Redis 以及应用程序部署在同一台机器上面,缺点是系统的资源过于紧张,服务之间耦合度过大 Pasted image 20250304204148.png 同时这一种单体架构中由演化成为分层设计,比如经典的 MVC 架构等,这一种架构的优点就是开发速度快,成本低

分布式

分布式的特点就是不同的服务部署在不同的机器上面,注意到即使每一个服务没有做拓展(也就是没有部署为集群),还是属于分布式的 Pasted image 20250304204355.png

集群

随着用户的增多以及服务运行中可能出现宕机的情况,高可用性和流量负载成为架构的问题,所以提出了集群的概念,注意到同一个集群中部署的都是同一个服务 Pasted image 20250304204526.png

微服务

以上的架构中,对于应用程序都是整体部署的,但是一个应用程序中的各个模块还是存储耦合度大的问题,以及每一个模块之间并发性不同,所以更具业务以及访问热度拆分服务为多个服务,所以产生了微服务架构,同时在一个系统中还需要各种中间件提供各种功能,比如消息队列, ES等,所以一个微服务系统的整体架构如下 Pasted image 20250304204837.png

分布式/集群/微服务之间的区别

  • 分布式: 只要涉及了不同的服务拆分到不同的服务器上面运行就可以认为是分布式架构,也就是只要 Mysql 和 Redis 不再本地机上面也是分布式的
  • 集群: 集群部署的都是同一个服务,设计的就是同一个服务的拆分
  • 微服务: 也涉及了服务拆分,只不过重点关注的是应用程序各个模块之间的拆分从而实现高内聚,低耦合

微服务核心要素之拆分原则

注意到微服务拆分的时候需要考虑拆分粒度,如果拆分的粒度比较大,近似于没有拆分,那么就会出现耦合度高的问题,但是如果拆分的粒度比较小,就会导致开发难度和运维的难度增大,下面从两个方面介绍拆分的几种原则

业务角度

  1. 模块维度：微服务架构中模块维度是最基本的拆分单位。根据系统整体一类功能集中在一起定义的模块进行拆分，如：将用户模块拆分为用户服务，将商品模块拆分为商品服务或将订单模块拆分为订单服务等。每个服务可以独立开发、测试和部署，具备清晰的职责边界和功能集合。
  2. 功能维度：除了按照模块进行拆分外，针对具有较复杂的业务，较严格要求或具有较大的技术挑战的时候才会选择拆分出来，如：购物车功能，支付功能，秒杀功能等。
  3. 读写维度：在系统中大多是读多写少，往往读的并发压力大，从整体服务功能中来看流量在读和写上就会出现明细的不均衡问题，这个时候可以将读和写拆分，再根据流量情况适当为读服务增加机器。如商品服务，就可以拆分为 读-商品服务 、写-商品服务。 一个比较好的例子如下: Pasted image 20250304210223.png

架构模块

  1. AOP维度：AOP是面向切拆分，是将被用于跨多个模块或功能的关注点，如日志记录、性能监控、异常处理等功能。拆分程独立的服务，供其他微服务调用，以确保这些关注点的一致性和复用性。
  2. 分层的维度: 比如按照三层架构进行拆分,使用比较少 Pasted image 20250304210343.png

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

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

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

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

服务化的关键信息如下:

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

微服务 VS 组件

  • 微服务在实现的功能上是具有与组件很强的相似性，但是又具有关键性的不同，微服务的服务之间升级和修改并不会影响到相互调用的服务修改；
  • 组件在使用上会要求包含业务系统内部，需要业务系统进行集成，如果组件的功能发生了修改，则所有引用此组件的业务系统都需要进行组件升级；

微服务 VS 子系统

  • 在微服务中服务与服务虽然是各自单独部署运行，但是在功能上 具有耦合性，相互之间是围绕整个项目的核心业务展开规划的，在服务之间单独部署但又相互依存
  • 子系统是单独独立开发的，具有单独的独立体系业务，相互之间 并不是相互依存的关系，因此即便某一个系统出现问题也不影响其他系统的 业务运行

微服务的核心要素之通信机制

微服务中的三种通信机制:

  • RPC机制: 微服务内部服务之间的通信,应用于服务与服务的内部
  • Http机制(Restful API): 向外界提供对于系统访问的接口
  • 消息队列: 单体架构项目中用于处理耗时的操作,但是在微服务中可以使用消息队列来进行通信

rpc vs 消息队列

  • rpc 的实时性比较高
  • 消息队列主要用于处理耗时业务,时效性不高

两者的对比如下: Pasted image 20250304212451.png

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

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

状态的类型分为共享性状态和流程性状态,共享型状态比如 session 等信息,流程型状态比如订单支付等信息,也就是订单的状态随着业务之间的互相调用而改变

实现无状态

  • 共享性状态: 使用分布式缓存缓存状态即可
  • 流程性状态: 使用消息队列维护即可