微服务拆分的原则？

系统的迁移或者重构本身就是一个非常漫长和痛苦的过程，可以先以接口的方式来迁移。在网关或者Nginx层做分发。比如/user/query_user这个接口，20%的流量切到新的服务上，80%的流量还是老的服务上。万一新系服务出现问题还可以再迁移到老的服务。等一段时间后流量逐步增加 50%，80%，100%，然后这个接口老系统就废除了，由新服务来提供服务。以此类推。

前面有同学答了DDD拆分，这一套方法论太理论化了，实际场景很难用上。根据经验来看，已有系统尽量不要动，新开发功能用微服务架构，可以从已有代码中复用代码，但是千万别大规模修改已有代码。

新的微服务划分时候，有几点原则可参考一下：

1. 按功能重要程度拆分不同微服务
2. 数据尽量内聚，不要拆出太多分布式事务，当前分布式事务是业界难题
3. 依赖分层，不要有循环依赖

服务拆分大的前提可以参考DDD领域驱动设计。进一步讲，业务需要考虑三方面问题：1.服务边界切分；2.服务依赖梳理；3.服务交互规范标准；服务边界切分需要依赖”低耦合，高内聚“的原则，明切业务单元的边界，尽可能减少同一个业务的不同服务单元的调用依赖；服务依赖，需要明确一个业务构成过程中的服务依赖关系，避免出现回环依赖，双向依赖的场景。最好的方式是实现链式依赖调用；服务交互规范，从协议以及数据传输规范层面说明服务与服务之间的交互方式，包括采用的通信协议，数据传递格式等；
服务迁移的过程中，首先要考虑接口变化情况，对于前后端分离的架构，可以采用restful的方式进行，尽可能避免接口的平凡变更。同时复用原有的业务代码实现。线上迁移过程中，可以利用负载路由的控制实现逐步发布。