SpringCloud微服务实战(4)-服务拆分原则

1 微服务拆分的起点 1.1 如何拆分? 先明白起点和终点

• 起点 既有架构的形态
• 终点 好的架构不是设计出来的，而是进化而来的，一直在演进ing

单一应用架构=》垂直应用架构=》分布式服务架构=》流动计算架构

需要考虑的因素与坚持的原则 什么适合微服务

以下业务形态不适合：

• 系统中包含很多很多强事务场景
• 业务相对稳定，迭代周期长
• 访问压力不大，可用性要求不高

康威定律

• 沟通的问题会影响系统设计 Organizations which design systems are constrained toproduce designs which are copies of the communication structures of these organizations. 任何组织在设计一套系统(广义概念上的系统)时，所交付的设计方案在结构上都与该组织的沟通结构保持一致。

微服务的团队结构

• 传统 V.S 微服务

4 微服务拆分 4.1 拆法

• DDD
• OOP ( by name./ by verb. )

4.2 最佳实践

◆ 职责划分 ◆ 通用性划分

4.3 粒度合理

◆ 良好地满足业务 ◆ 幸福感 ◆ 增量迭代 ◆ 持续演进

拆分案例

AKF Scale Cube扩展立方模型

非常有用的三维可扩展性模型：X轴水平复制、Z轴数据分区、Y轴功能解耦。

在此模型中，通过在负载均衡器后面运行克隆来扩展应用程序称为 X 轴扩展。另外两种缩放是Y轴缩放和Z轴缩放。微服务架构是 Y 轴缩放的应用，但我们也来看看 X 轴和 Z 轴缩放。

X 轴

包括在负载均衡器后面运行应用程序的多个副本。如果有 N 个副本，则每个副本处理 1/N 的负载。这是一种简单、常用的扩展应用程序的方法。

缺点

• 因为每个副本都可能访问所有数据，所以缓存需要更多内存才能有效
• 没有解决不断增加的开发和应用程序复杂性的问题

Y轴

与由运行多个相同的应用程序副本组成的 X 轴和 Z 轴不同，Y 轴缩放将应用程序拆分为多个不同的服务。每个服务负责一个或多个密切相关的功能。有几种不同的方法可以将应用程序分解为服务：

• 使用基于动词的分解并定义实现单个用例（例如结账）的服务
• 按名词分解应用程序并创建服务，负责与特定实体相关的所有操作，如客户管理

应用程序可能会结合使用基于动词和基于名词的分解。

使用 Z 轴

缩放时，每个服务器运行相同的代码副本。在这方面，它类似于 X 轴缩放。最大的区别是每个服务器只负责数据的一个子集。系统的某些组件负责将每个请求路由到适当的服务器。一种常用的路由标准是请求的属性，例如被访问实体的主键。另一个常见的路由标准是客户类型。例如，通过将付费客户的请求路由到容量更大的一组不同的服务器，应用程序可能会为付费客户提供比免费客户更高的 SLA。

Z 轴分割通常用于缩放数据库。数据根据每条记录的属性在一组服务器上进行分区（也称为分片）。在此示例中，RESTAURANT 表的主键用于对两个不同数据库服务器之间的行进行分区。请注意，通过将一台或多台服务器部署为副本/从属服务器，可以将 X 轴克隆应用于每个分区。 Z 轴缩放也可以应用于应用程序。在此示例中，搜索服务由多个分区组成。路由器将每个内容项发送到适当的分区，在那里它被索引和存储。查询聚合器将每个查询发送到所有分区，并组合每个分区的结果。

好处

• 每个服务器只处理数据的一个子集
• 提高了缓存利用率，并减少了内存使用和 I/O 流量
• 提高了事务的可伸缩性，因为请求通常分布在多个服务器
• 改进了故障隔离，因为故障只会使部分数据不可访问

缺点

• 增加了应用程序的复杂性
• 需要实施分区方案，这可能很棘手，尤其是在我们需要重新分区数据时
• 不能解决增加开发和应用程序复杂性的问题。为了解决这些问题，我们需要应用 Y 轴缩放

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Hlmx2wZA-1682860982007)(/Users/javaedge/Downloads/%E6%88%AA%E5%9B%BE/Player%20Screenshot/1-4%E5%BE%AE%E6%9C%8D%E5%8A%A1AKF%E6%8B%86%E5%88%86%E5%8E%9F%E5%88%99_0001.jpg)]

AKF（Availbility, Scalability, and Flexibility）拆分原则是一种软件架构设计方法，用于将大型应用程序拆分为独立的、可扩展的组件：

• Availbility(高可用性) 将应用程序分解成组件，以最小化这些组件之间的依赖关系，从而实现在一个组件崩溃或出现故障时，系统中其他组件的正常运行。

• Scalability(可扩展性) 通过将应用程序拆分为多个较小的服务来提高系统的可扩展性和吞吐量。在需要处理更多请求时，可以轻松的添加更多的服务器实例，并且每个组件都可以根据其特定的需求进行垂直或水平扩展。

• Flexibility（灵活性） 通过使用服务组合来创建新的功能，使得应用程序更具灵活性，新服务可以随着业务需求更容易地添加到现有架构中。

总之，AKF 拆分原则可以帮助开发人员通过将应用程序划分为较小的、松耦合的组件并提供相应的服务来增强软件系统的可持续性、高可用性、易于维护性。

如何拆“功能”

• 单一职责、低耦合、高内聚
• 关注点分离
  • 按职责
  • 按通用性
  • 按粒度级别

服务和数据的关系

• 先考虑业务功能，再考虑数据
• 无状态服务

web 和 webflux

旧版只有web一种模式，默认使用web。新版需指定，新增依赖 org.springframework.boot.spring-boot-starter-web

Web 是 Spring Boot 中基于 Servlet 规范的传统 Web 编程模式，使用 Tomcat 或 Jetty 等容器来部署。

而 WebFlux 是 Spring Boot 2.0 引入的新型编程模式，基于 Reactor 和 Reactive Stream 规范实现了响应式编程，适用于处理非常高的并发请求和 I/O 密集型操作。Webflux 支持多种反应式容器，如 Netty、Undertow。

在新版的 Spring Boot 中，如果需要使用传统的 Web 编程模式，则需要明确指定 Spring Boot 的spring-boot-starter-web依赖；如果需要使用基于响应式编程的 WebFlux，需要新增 Spring Boot 的spring-boot-starter-webflux依赖，并相应地调整应用程序代码。

需要注意的是，在选择使用传统 Web 还是 WebFlux 时，需要根据自己的应用场景以及性能需求进行选择。如果应用程序对性能有较高的要求，特别是需要处理非常高的并发请求或者 I/O 密集型操作，那么选择 WebFlux 将更加合适；而如果不需要处理太高的并发量，且应用程序已经基于传统的 Servlet 架构开发，并且部署在传统的 Servlet 容器中，那么使用传统的 Web 编程模式就可以了。

须有此二注解，否则NPE

编码技巧

测试类可直接继承启动类的测试类，减少注解个数，做到最大可能的解耦

sb引用了gson

所以无需指定版本

如何拆“数据”?

• 每个微服务都有单独的数据存储
• 依据服务特点选择不同结构的数据库类型
• 难点在确定边界
• 针对边界设计API
• 依据边界权衡数据冗余

参考

• 康威定律
• https://martinfowler.com/articles/microservices.html
• https://akfpartners.com/growth-blog/scale-cube