微服务拆分原则

大道之简

于 2024-09-07 09:53:14 发布

阅读量148

点赞数 3

分类专栏：微服务治理文章标签：微服务 java

本文链接：https://blog.csdn.net/HcJsJqJSSM/article/details/141952698

版权

微服务治理专栏收录该内容

1 篇文章 0 订阅

订阅专栏

1.准备好微服务治理基础设施

微服务首先需要有微服务基础设施，没有微服务基础设施，实践微服务就是一场灾难。

2.单一责任原则（SRP)

SRP是微服务架构重要的原则。
1、每个微服务都应该负责一个单一的业务，并确保做好这个业务，这个业务粒度的大小取决于你对业务和架构综合考虑。
SRP能够确保微服务职责单一性、功能完整性拆分，这样，就便于维护、测试和部署。

3.松耦合原则

  什么事松耦合：松耦合是指每个微服务都应该是独立的，并通过API与其他服务进行通信。
  松耦合的优势：可以降低级联故障的风险，也可以提高服务可扩展性，提高微服务的可复用性。
  尽量做彻底解耦，包含数据库层的解耦：
  数据库层的解耦，就是避免一个微服务与其他微服务共享数据库，因为这可能会导致数据不一致，并且会使故障排查变得非常困难。
  每个微服务也都应该只管理自己的数据，每个微服务都有自己的数据库来存储数据，以确保可扩展性和可靠性。
  在设计微服务时，应该专注于创建小型、松散耦合和高度内聚的服务。

4.领域驱动原则，不数据驱动原则，也不是界面驱动原则

DDD是一种软件设计方法，它专注于特定业务领域的软件设计。
微服务架构、微服务设计非常适合采用DDD，为啥呢？
因为每个服务都可以设计为特定业务领域的具体实现。

5.架构分层职责明确，严守调用规范

各层职能定位清晰，只能上层调用下层，也就是说只能从外层调用内层服务，下层服务通过封装、组合或编排对上层暴露，服务粒度由细到粗。
微服务中，各层职能定位清晰：
基础层为各层提供资源服务
领域层负责领域业务逻辑的实现
应用层负责服务的编排和组合
接口层对外进行服务暴露

6.进行全方位的监控、记录

监控和日志记录对于微服务架构的安全、维护和调优都至关重要。
在拥有数百个微服务的项目中开发的主要困难之一是调试非常困难，因为服务分散、日志分散，很难找到失败的原因。
因此，每个服务都应该有日志记录和监控措施，以跟踪其性能并检测错误。

7.通过CI/CD实现devops （开发运维一体化），提升工程效能

CI/CD是一种软件开发运维过程实践，打通开发和运维环节，实现应用程序的构建、测试和部署自动化。
任何微服务都应该是可持续部署的，实现微服务的快速高效部署，缩短了微服务上线时间。

8.基于业务需求变化频率进行微服务拆分

这是一条扩展原则，是一条针对特定场景的的微服务拆分原则。
分离变和不变，是设计领域遵守的一条核心的原则。
识别变动频繁的业务需求和领域模型，考虑业务变更频率与相关度，将业务需求变动较高和功能相对稳定的业务进行分离。
经常性变动必然会导致代码的频繁修改和版本发布，分离变和不变，可以有效降低频繁变动业务对稳态业务的影响。