不能为了拆服务而拆服务
比如我们现在有B端的两个Portal，简称PA、PB，两个Potral的后台PC。按照常规的做法，会把PA，PB，PC里重要的模块拆分成单独的服务，数据库也根据对应的模块切分成多个库。这样
一来开发的时候，经常会发生没法级联查询，feign客户端可能会出现回环调用，业务发生变化时数据库中的表需要下沉或者上提，运维成本等等问题。
个人觉得细化服务比较适合C端一些比较大的功能模块，比如订单，而B端重业务，日活和QPS都没C端那么大，拆分过细，反而不利于整个项目。
我认为的拆法（真正意义上微服务稍加改动）
首先提取出PA PB PC的相同表，上提至base数据库及base服务.
建立PA PB PC对应的数据库，并形成PAS PBS PCS三个服务，对应三个数据库。
三个服务只存在各自对应数据库的连接池，如需使用其它数据库，则通过feign调用。
根据业务变化，上提数据库表及对应的服务。
根据性能变化，拆分数据库表及服务。
接着上述第五点，服务拆分的前提，我认为
- 耦合性，耦合性，耦合性！这个我觉得是最重要的，如果这个模块和另外的一些模块耦合性非常高，必定这个模块没法拆出来，只能想办法降低耦合性。
- 无状态。
拆分服务后又会面临新的问题
所有服务是否在交付状态，这时候需要自动化测试。
分布式事务，这块实现方式很多，根据侵入性和性能选择你的框架。
跨表查询（join），可以再应用层做，数据量大可以放在ES里完成。
附上一篇有实战意义的文章
https://cloud.tencent.com/developer/article/1422167
PS：只有团队够大，微服务才能有发挥的空间。就3 4个人，单体服务还是最合适的，快速迭代，完成产品经理的需求，性能都是后话。
总结下这两点才是关键！
- 自动化测试
- 持续集成