「这是我参与2022首次更文挑战的第9天，活动详情查看：2022首次更文挑战」
本章主要针对微服务的开发实进行梳理和总结，主要解决在迭代过程中，微服务拆分的时机一些原则和实践过程的步䠫，便于后续时机项目中已做参考，此次分享大纲如下分为两篇进行阐述:
拆分的必要性与时机
很多时候说服团队特别是上级支持对现有系统进行微服务拆分是一件比较困难的事情，不能一蹴而就，也不能太过心急，很多时候不得不考虑业务的持续更新和系统的整体稳定等,以下主要从其必要性和如何验证月实施3个方面简单阐述。
必要性
评估一个项目是否需要做微服务拆分，主要从有以下几个信号
- 信号1：业务上下文复杂，难以理解
- 信号2：系统复杂度上升,开发效率下降
- 信号3：整体质量水平下降
验证与想法
当我们感受到了以上几个信号后，说明系统已经主键臃肿，开发困难，问题排查等各方面都成逐渐有难度了，这个过程中，作为架构师，我们应该及时的组织讨论，通过一些有效手段进行组织对现有业务进行分析和梳理，建议的思路和方法如下：
- 事件风暴：
- 8 XFlow：徐昊推出的业务建模方法 8X Flow 法，用于解决微服务、分布式事务为主导的架构风格中的业务建模问题。这个方法同样可以用于构建中台系统 业务逻辑：源自业务运营的逻辑，是领域中立且运营特定的，其复杂度来自于流程本身，关注的是如何盈利和成本结构（或者可以理解为对外体现为利润或现金，对内体现为成本和绩效承诺），常见于：合同、法务、会计、审计等。
领域逻辑：源自问题域的逻辑，是运营中立而领域特定的，其复杂度来自于问题本身，关注的是如何解决问题，常见于：算法、计划、统计、优化等。
- 数据表分析：结合现有系统，对其数据库表结构进行分析，做逆向工程再优化
实施的时机
当收到信号，也找到对应的方法，接下来就是找准时机进行开工了(当前前提是与你的上级和业务沟通好，尽量不影响业务的前提下)；主要的实际我认为主要有两个：
- 服务核心业务变化频率较低时：一般业务迭代都有一个周期，在业务需求不是很多或不是很频繁的时候，开展服务的拆分工作；当然拆分的时候也不一定是全部都来做拆分，为了业务演进，可能还得留部分人员继续既有业务，之后再做迁移。
- 业务即将发生较大调整或演进时：当业务要做比较大的重构时，正好乘着这个东风，梳理业务同时也调整系统结构，之后再统一发布一个大版本，这里需要注意提前做好既有业务数据的迁移和脚本话方面工作。
