当前位置: 首页> 房产> 政策 > 微服务拆分原则

微服务拆分原则

时间:2025/7/11 15:19:08来源:https://blog.csdn.net/HcJsJqJSSM/article/details/141952698 浏览次数:0次

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

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

2.单一责任原则(SRP)

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

3.松耦合原则

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

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

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

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

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

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

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

7.通过CI/CD实现devops (开发运维一体化),提升工程效能

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

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

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

9.基于吞吐量进行微服务拆分

这是一条扩展原则,是一条针对特定场景的的微服务拆分原则。
识别领域模型中性能压力较大、高吞吐量的功能,并且进行解耦,解除独立的微服务。
两个好处:
避免高吞吐服务,拖累整个系统的性能, 由于局部的性能拖累整体性能。
解耦之后,可以对高吞吐量服务定制个性化的 扩容缩容策略、熔断保护策略、限流策略。

10.基于技术异构因素进行微服务拆分

这是一条扩展原则,是一条针对特定场景的的微服务拆分原则。
领域模型中有些功能虽然在同一个业务域内,但在技术实现时可能会存在较大的差异,也就是说领域模型内部不同的功能存在技术异构的问题。
有的可能用go,有的则是 Java,当然,还有的微服务用大数据架构。  

关键字:微服务拆分原则

版权声明:

本网仅为发布的内容提供存储空间,不对发表、转载的内容提供任何形式的保证。凡本网注明“来源:XXX网络”的作品,均转载自其它媒体,著作权归作者所有,商业转载请联系作者获得授权,非商业转载请注明出处。

我们尊重并感谢每一位作者,均已注明文章来源和作者。如因作品内容、版权或其它问题,请及时与我们联系,联系邮箱:809451989@qq.com,投稿邮箱:809451989@qq.com

责任编辑: