一百个架构师眼中，有100种微服务拆分的方式，那么我简单总结几个我在做类似的事情的时候会参考的一些原则：
1、职责。我们学面向对象的第一天，就被告知要职责单一，而一个微服务也一样，他应该聚焦于一件事儿，否则他就不够"微"，至少在电商中，我们要把用户和交易拆分开。
2、业务。我们说技术是为了业务服务的，所以微服务的构建需要围绕着业务来做，不同的业务需要独立出来，比如保险业务中，投保和理赔，就是不同的业务，那么就可以把他们拆分开。
3、中台化。当我们在做业务拆分、职责划分后，可能会有一些公共的部分，这部分内容分别在各自微服务实现一份也可以，单独独立出来也是可行的，所以如果考虑中台化的思想，一些公共的部分，是可以独立拆分出来的。
4、系统保障。在做微服务拆分的时候，可能需要根据不同的系统保障级别做拆分，比如秒杀和日常交易，就可以单独拆开，针对秒杀做单独的可用性保障。还有一种就是在线任务和离线任务，也是可以拆分开的，各自做可用性保障。
在线任务：就是你应用中一直都在运行的任务，比如你的订单系统，他的下单、退款正常这些操作都是在线任务。
离线任务：一般是那种异步扫表、或者定时执行的任务，比如订单的到期关闭等。
5、技术栈。要考虑技术栈，不同的技术栈，不要硬往一起融，最后只会让这个系统无法维护。
6、依赖关系。拆分之后，各个微服务之间，不要有循环依赖。依赖应该是单向的，而不是循环的，循环依赖会给服务治理，链路追踪带来很大的挑战，并且存在循环依赖一定是拆分的不够合理。
7、康威定律。最后一点，康威定律，应用架构要和组织架构一一对应。组织架构决定了业务架构、应用架构。说白了，就是多个团队一起维护一个微服务，一定会在沟通、（发布）冲突、谁来干等问题。
