这里我大概分为这么几个流派：
保守派：
大多场景是本身已经存在了一个单体巨无霸系统，考虑的是如何拆分的问题，拆少了吧，达不到预期拆分效果，还增加了整体复杂度，不如不拆；拆太碎了吧，工作量忒大了，相当于重做。所以折中一下，大概按照系统的粒度，把一个大型系统拆分成为数不多的几个中型系统。
比如原项目是一个商城系统，包括商城前台，订单管理，商品管理等后台功能。
拆分后： 商城前台、个人中心、商城后台。
优点：不是很明显，但是已经初步具备 商城前台的性能可伸缩（大部分性能集中在商城的用户端），并且子系统可以略微提高可用性。
不足：性能伸缩非常有局限性，因为瓶颈集中在数据层，一旦卡在比如订单、商品数据的操作，该卡该宕的并不能改善。
总结：这是已有系统进行微服务化的必经之路，先把大系统拆成多个中系统，然后再继续拆成更多的小系统，但在拆分过程中非常考究业务架构的设计能力，包括公用服务的抽取，单个服务的划分范围、原服务拆分后的调用路径层级不可过深等。
极致派：
不管三七二十一，先进行整体设计，思路按照一个CURD拆成一个微服务工程这样来。
其实这确实是比较追求极致的风格，相当于把单体工程的每一个业务功能拆分成了一个微服务。
优点：如果数据层以及各服务调用链路设计得当，确实是很理想的方案，再配合一套微服务治理与持续集成的框架，整个系统非常清晰，可用性以及可扩展性极高。
不足：对于业务设计的要求还是非常高的，并且对于开发团队的协作和文档要求也极高，本身一个业务的实现，现在要跨多个工程，多个人，难免效率会降低。
总结：在开发团队整体协作良好，文档详尽的环境下，这不失为一个理想的架构方案。反之呢，效率会大打折扣，并且项目运行后整体可控性也不容乐观。
理性派：
其实呢，最好的方案，是完全按照实际情况来考虑的方案。
是大团队还是小团队？极致地拆分，对于大团队，是能提高整个效率的，很多以前只能一个后端人员串行完成的工作量，微服务化后可以并行协作。
微服务是一个长期的，可持续集成的过程，原有系统进行微服务化也不必一蹴而就，可分阶段大拆中，中拆小，小拆微。
微服务设计小例：
目前博主负责的几个项目呢，有的还处于巨无霸模式，有的是新项目，所以一起手就是大几十个微服务工程，各有各的好处以及蛋疼的点吧。
之前的章节大概讲述了 SpringCloud Alibaba的概念，组件，初步使用等内容。
接下来我想利用一个麻雀虽小五脏俱全的电商demo，来以一个较为合理的结构来进行微服务架构的完整实践。
大概长这样，代码我还没开始写，这个系列之后就以这个例子展开吧。（想写一个确实完整实用的微服务系列）
这是我的微服务初步设计，基本上是按 业务模块划分+注重公共抽取 这样一个思路，大家也可以一起讨论哈。
