1. 微服务拆分
1.1 康威法则
康威定律 (康威法则)：”设计系统的架构会与产生该系统的组织的通讯结构相匹配”。
简而言之，这意味着一个组织在设计软件系统时，系统的架构往往会反映出该组织内部的沟通和协作方式。例如，如果一个组织被划分为多个团队，每个团队负责一个独立的模块，那么最终的软件系统也可能是由多个独立的模块组成。
康威法则的实际意义在于提醒我们，组织结构和沟通方式会直接影响到软件系统的设计和质量。因此，在设计和开发软件时，优化组织结构和沟通方式是非常重要的。
1.2 拆分时机
- 项目初期规划：在项目初期，通过深入的需求分析和架构设计，识别出系统的核心业务领域和功能模块。此时进行微服务拆分，可以为后续的开发和扩展打下坚实基础。
- 业务需求增长：随着业务需求的增长和复杂度的增加，单体应用可能变得难以维护和扩展。此时，可以考虑将一些业务逻辑复杂且相对独立的模块拆分为微服务。
- 团队规模扩大：当开发团队规模扩大时，单体应用可能导致团队之间的协作和沟通变得困难。此时，可以通过拆分微服务，将不同的服务分配给不同的团队进行开发和维护。
性能问题：当系统遇到性能瓶颈，某些模块的负载过高时，可以通过拆分这些模块为独立的微服务，分别进行优化和扩展。
弹性需求：对于有明显弹性需求的模块，可以独立拆分和部署，以便根据负载动态扩展。
模块耦合度高：当系统中模块之间的耦合度过高，导致变更一个模块需要修改多个模块时，可以考虑通过微服务拆分来降低耦合度。
频繁发布需求：当需要频繁发布和更新某些功能模块时，可以将这些模块拆分为独立的微服务，以便独立部署和发布，减少对其他模块的影响。
技术栈更新：当需要对系统的某些部分进行技术升级（如采用新的数据库、框架或语言）时，可以考虑将这些部分拆分为独立的微服务，以便逐步升级。
技术实验：可以在不影响现有系统的情况下，对某些模块进行技术实验，将其拆分为微服务，进行独立的技术尝试和验证。
2. 拆分原则
2.1 业务能力拆分
- 基于业务领域：将系统拆分为独立的业务领域，每个微服务对应一个特定的业务能力。例如，电子商务系统可以拆分为订单服务、用户服务、库存服务等。
- 单一职责原则：每个微服务应该有明确的边界和单一职责，避免跨多个业务领域。
2.2 独立部署原则
- 独立部署：每个微服务应该能够独立构建、部署和扩展。这样可以提高系统的灵活性和响应速度。
- 独立开发：不同团队可以独立开发和维护不同的微服务，减少团队之间的依赖和协调成本。
2.3 数据隔离
- 独立数据库：每个微服务应该有自己的数据库，避免共享数据库带来的耦合问题。
- 数据同步：通过事件驱动的方式实现跨服务的数据同步，而不是直接访问其他服务的数据库。
2.4 容错性
- 避免环形依赖：尽量不要有服务之间的环形依赖或双向依赖，可以将共同依赖的服务功能进行下沉，拆分为第三方服务。如果在业务流程上允许异步解耦的，可以考虑引入消息中间件来处理。
- 接口应该实现幂等性：微服务拆分之后，服务之间的调用当出现错误的时候，往往都会重试，但是为了不要下两次单，支付两次，微服务接口应当实现幂等性。
- 阶段性合并：大原则：分久必合，合久必分。
3. 中台
3.1 概念
中台这个概念是由阿里在2015年提出”小前台，大中台”战略思想。所谓中台，就是将各个业务线中可以复用的一些功能抽取出来，剥离个性，提取共性，形成一些可复用的组件。
为了满足前台的快速迭代需求和后台的稳定性需求，伟大的架构师们，创造性的提出了“中台”概念，核心是将后台的逻辑层拆出来，形成”前台（应用层）-中台（逻辑层）-后台（数据层）“的产品架构。在这一产品架构下，当前台需求来临时，中台能快速的进行响应，从而提升了研发效率，降低了创新成本。
