微服务拆分原则

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

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

2.单一责任原则（SRP)

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

3.松耦合原则

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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