微服务的划分原则（1）
微服务设计原则中，如高内聚低耦合、复用、单一职责等这些常见的设计原则在此就不赘述了，我主要强调下面这几条：
第一条：要领域驱动设计，而不是数据驱动设计，也不是界面驱动设计。
微服务设计首先应建立领域模型，确定逻辑和物理边界以及领域对象后，然后才开始微服务的拆分和设计。而不是先定义数据模型和库表结构，也不是前端界面需要什么，就去调整核心领域逻辑代码。在设计时应该将外部需求从外到内逐级消化，尽量降低对核心领域层逻辑的影响。
第二条：要边界清晰的微服务，而不是泥球小单体。
微服务上线后其功能和代码也不是一成不变的。随着需求或设计变化，领域模型会迭代，微服务的代码也会分分合合。边界清晰的微服务，可快速实现微服务代码的重组。微服务内聚合之间的领域服务和数据库实体原则上应杜绝相互依赖。你可通过应用服务编排或者事件驱动，实现聚合之间的解耦，以便微服务的架构演进。
第三条：要职能清晰的分层，而不是什么都放的大箩筐。
分层架构中各层职能定位清晰，且都只能与其下方的层发生依赖，也就是说只能从外层调用内层服务，内层通过封装、组合或编排对外逐层暴露，服务粒度也由细到粗。应用层负责服务的组合和编排，不应有太多的核心业务逻辑，领域层负责核心领域业务逻辑的实现。各层应各司其职，职责边界不要混乱。在服务演进时，应尽量将可复用的能力向下层沉淀。
第四条：要做自己能 hold 住的微服务，而不是过度拆分的微服务。
微服务过度拆分必然会带来软件维护成本的上升，比如：集成成本、运维成本、监控和定位问题的成本。企业在微服务转型过程中还需要有云计算、DevOps、自动化监控等能力，而一般企业很难在短时间内提升这些能力，如果项目团队没有这些能力，将很难 hold 住这些微服务。
微服务的划分原则（2）
理论上一个限界上下文内的领域模型可以被设计为微服务，但是由于领域建模主要从业务视角出发，没有考虑非业务因素，比如需求变更频率、高性能、安全、团队以及技术异构等因素，而这些非业务因素对于领域模型的系统落地也会起到决定性作用，因此在微服务拆分时我们需要重点考虑它们。我列出了以下主要因素供你参考。
DDD原则：原则上基于领域模型驱动设计（ DDD , Domain Driven Design），根据业务领域边界上下文以及它们之间的关系来划分服务；
合并原则：对数据耦合度高的服务（如两个服务双向依赖），可以合并在一个服务中，例如“人资核心服务”包括“人才管理”、“用工管理”、“绩效管理、“组织岗位”等四个耦合度较高的服务；
业务需求频率：如果不同服务的变更和部署的频率不同，建议进行拆分，不要合成一个服务；例如“干部管理”，功能和数据独立，同时变更频率要求高，设计成一个独立的服务；
技术栈：如果不同服务用的技术栈类型不一致，建议进行拆分，不要合成一个服务；例如，“招聘管理”需要连接外网支持，设计成一个独立的服务；
数据一致性：根据业务对数据实时一致性的要求划分服务，一般把分析类的非实时数据服务与实时数据服务分开；例如“统计报表”和“数据质量管理”作为分析数据服务，设计成一个独立的服务；
性能及资源占用：根据CPU与内存等资源占用类别与大小，均衡地划分服务，便于将来对资源占用率高的服务动态横向扩展。例如“培训评价”服务的资源需求大，设计成一个服务；
组织架构和团队：服务划分应该与DevOps的团队规模和交付频率相匹配；一般一个独立的服务应由一个或两个个独立的敏捷团队来实现；
运维管控：服务的划分还需考虑服务的注册、管理、部署、监控的可操作性，服务管控系统越成熟，可以支持更多更细的服务。
安全边界：有特殊安全要求的功能，应从领域模型中拆分独立，避免相互影响。
微服务的划分原则（3）
颗粒度的选择-小单体/小服务/微服务
- 根据自身业务的特点、组织架构、技术能力选择合适的颗粒度维度；
- 中台建设可以多种颗粒度并存
- 可以根据业务的变化拆分/合并，没有最佳，只有最适合；
- 数据的架构设计选择是关键；
- 传统企业业务基本选择小服务mini-Service；
软件架构模式的演进（1）
软件架构模式大体来说经历了从单机、集中式到分布式微服务架构三个阶段的演进。随着分布式技术的快速兴起，我们已经进入到了微服务架构时代，进一步向云原生架构、Serverless架构和多运行时架构演进。
软件架构模式演进的三个阶段如上图：
第一阶段是单机架构：采用面向过程的设计方法，系统包括客户端 UI 层和数据库两层，采用 C/S 架构模式，整个系统围绕数据库驱动设计和开发，并且总是从设计数据库和字段开始。
第二阶段是集中式架构：采用面向对象的设计方法，系统包括业务接入层、业务逻辑层和数据库层，采用经典的三层架构，也有部分应用采用传统的 SOA 架构。这种架构容易使系统变得臃肿，可扩展性和弹性伸缩性差。
第三阶段是分布式微服务架构：随着微服务架构理念的提出，集中式架构正向分布式微服务架构演进。微服务架构可以很好地实现应用之间的解耦，解决单体应用扩展性和弹性伸缩能力不足的问题。
软件架构模式的演进（2）
微服务架构是一种基于服务化思想的架构模式，将单体应用拆分为一系列小型、独立的服务，每个服务都运行在独立的容器进程中，并使用轻量级通信机制进行服务间的通信。这种架构模式有助于提高系统的可伸缩性、灵活性和可维护性，使得企业内部能够更快地响应需求变化和市场变化。
微服务更像是一个服务之间的生态，专注于服务治理等方面，而服务网格更专注于服务之间的通信，以及和 DevOps 更好的结合。是微服务、服务网格、无服务器化三者核心思想的融合，是整个云原生下微服务框架发展的趋势。
微服务的演进策略
微服务的演进策略包括绞杀策略、修缮者策略、另起炉灶策略
1. 绞杀者策略
绞杀者策略是一种逐步剥离业务能力，用微服务逐步替代原有单体系统的策略。它对单体系统进行领域建模，根据领域边界，在单体系统之外，将新功能和部分业务能力独立出来，建设独立的微服务。新微服务与单体系统保持松耦合关系。 随着时间的推移，大部分单体系统的功能将被独立为微服务，这样就慢慢绞杀掉了原来的单体系统。绞杀者策略类似建筑拆迁，完成部分新建筑物后，然后拆除部分旧建筑物。
2. 修缮者策略
修缮者策略是一种维持原有系统整体能力不变，逐步优化系统整体能力的策略。它是在现有系统的基础上，剥离影响整体业务的部分功能，独立为微服务，比如高性能要求的功能，代码质量不高或者版本发布频率不一致的功能等。 通过这些功能的剥离，我们就可以兼顾整体和局部，解决系统整体不协调的问题。修缮者策略类似古建筑修复，将存在问题的部分功能重建或者修复后，重新加入到原有的建筑中，保持建筑原貌和功能不变。一般人从外表感觉不到这个变化，但是建筑物质量却得到了很大的提升。
3. 另起炉灶
顾名思义就是将原有的系统推倒重做。建设期间，原有单体系统照常运行，一般会停止开发新需求。而新系统则会组织新的项目团队，按照原有系统的功能域，重新做领域建模，开发新的微服务。在完成数据迁移后，进行新旧系统切换。对于大型核心系统我一般不建议采用这种策略，这是因为系统重构后的不稳定性、大量未知的潜在技术风险和新的开发模式下项目团队磨合等不确定性因素，会导致项目实施难度大大增加。
