微服务是一个很抽象的概念，它的划分更是抽象。
划分的粒度太粗，服务太重；
划分的粒度太细，在分布式系统中会让开发、测试、部署和运维都变得极其困难。
所以，应该如何划分呢？
一、要遵守两个原则
1、单一职责
把因相同原因变化的东西聚合在一起，需要调整的类也都放在一起；
2、自治原则
满足资源隔离，每个服务的数据私有。
二、大佬们的拆分思想
1、第一种拆分
1.1 纵向拆分
从业务维度拆分，关联紧密的服务放在一起，相对独立的业务单独拆分出来；
1.2 横向拆分
把公共的服务拆分出来，被多个服务调用，并且依赖资源相对独立；
2、第二种拆分
2.1 服务拆分要迎合业务需要，充分考虑业务的独立性和专业性；
2.2 拆分后的维护成本要低于拆分前，从人力，物力，时间等方面综合考虑；
2.3 拆分不仅仅是架构的调整，组织结构上也要做相应的适应性优化，不再以前端，后台，产品部横向划分，而是以服务为中心来分配人数；
2.4 拆分最有价值的结构是提高了系统的可扩展性，把具有不同扩展性要求的服务拆分出来，分别部署，降低成本，提高效率。
2.5 考虑软件发布频率，按照 8 / 2 原则进行拆分，把20%经常变动的部分进行抽离，把80%不经常变动的单独部署和管理。
3、第三种拆分
3.1 基于业务逻辑，按照业务的职责进行识别划分。
3.2 基于稳定性，把模块按照稳定性进行排序，稳定的，不经常修改的划分在一块，不稳定的，经常修改的划分在一起。
3.3 基于可靠性，把模块按照可靠性进行排序，可靠性高的核心模块归在一起，可靠性不高的非核心模块归在一起。
3.4 基于高性能，把模块按照高性能进行排序，对性能较高的模块归在一起，性能要求不高的放在一起；
总结
业务的属性很关键，当然其他辅助属性也很关键，必要时候可考虑自由组合。
三、同事的拆分思想
1、划分的视角
简单模块，早期项目，先根据功能的聚合拆封呢，宁整勿拆；
成熟的项目，核心的功能，要基于领域划分，新功能的增加不要轻易改动现有的模块；
2、拆分的粒度
警惕过细粒度造成复杂度的提升、效率的下降；
与其问什么时候该拆，不如问什么时候不得不拆；
3、服务的分类
基础服务，尽量简单以求可靠；
纵向服务，剥离分必要逻辑，聚焦业务；
横向服务，注意解耦，保持灵活性；
4、总结
我们总会在一些决策上出错
那么尽量减少每个决策的影响范围
所以 坚持低耦合，已扩展；
拒绝 复杂度提升，调用链过长；
参考链接：https://mp.weixin.qq.com/s/f4BmAvkoYMC7nOB0IlVbVQ?from=groupmessage&clicktime=1563412876&sessionid=0&subscene=1&ascene=0&fasttmpl_type=0&fasttmpl_fullversion=4666101-zh_CN-zip&fasttmpl_flag=21&realreporttime=1563412876165
