写在前面的一句话：使用微服务架构的大型软件公司，都是从使用一体化应用程序开始的。一旦它们达到了可扩展性和可维护性的极限，它们就会将一体化机器分解为独立的部件或服务。

微服务的划分是一个难点，如何处理好：(1)微服务不能太大，也不能太小 (2) 紧密耦合程度如何把握？

微服务颗粒度划分与设计原则：

一、业务原则：

1. 这个微服务不会与其他的服务共享数据库表，注意是表，不是库,即避免多个微服务引用同一个表的服务，如果有他们均属于同一个微服务。

2.这个微服务具有最少量的数据库表：这个表尽量少，这个可能要看业务需求，不是绝对。

3.这个微服务可能是有状态（即和数据库有关），或者无状态（即非数据库）的。

4.单一责任原则，又称这是一个真理的单一来源，即这个服务是系统中某一件事的唯一真理来源，即这个微服务在整个系统中代表功能的唯一性，它具有时空不变性的特质，同时满足有限业务范围内进行设计，从而实现交付的敏捷。

5.微服务颗粒度与2个披萨的关系：你有几个2 pizza团队，最好就拆成几个微服务，只有一个开发人员时尽量做单体应用，不要没事找事找刺激拆成10个微服务，最终这个开发人员还会把他合成一个。

   微服务的本质就是团队的分工，微服务要求纵向的2 pizza团队（7，8个人以内）（无数个小团队，包含开发、测试、运维）。

  坚持以康威定律作为指导思想。

6.微服务从业务层面分为核心业务和非核心业务，要紧持业务与技术分离后，把参与者与一个或者多个业务原子行为组合在一起就形成了微服务。

7.适当的边界：关注微服务的功能范围，一个服务的大小应该等于满足某个特定业务能力所需要的大小；

8.非唯一性依赖：至少被2个以上其它微服务依赖的功能模块，才有必要独立成一个微服务

总结：拆分的粒度太细和太粗都是不合理的，根据业务需要，能够满足上层服务对底层服务自由编排并获得更多的业务功能即可，并需要适合团队的建设和布局。因此，这里倡导对微服务的拆分适可而止，原则是拆分到可以让使用方自由地编排底层的子服务来获得相应的组合服务即可，同时要考虑团队的建设及人员的数量和分配等。

二、技术原则：

  1.部署独立性

  2.动态扩展、

  3.避免产生频敏的跨库查询

  4.避免产生频繁的分布式事务。

三、治理原则：

 1.在业务分层的基础上，根据业务细分规则，对微服务分组；

 2.各个分组之间通过API网关集成；

 3.通过API网关实现级轻量级消息路由，鉴权；

 4.运行时管理，如服务降级，限流，监控等可在API网关实现，让微服务功能纯粹；

  5.避免通过数据库集成；

  6.避免部署多个版本来兼容。

四、微服务设计发展的一个思想趋势：

前台UI遵循以用户为中心的设计思想。以用户为中心的设计就是完全站在用户的角度来思考前台UI的设计，使用清晰合理的界面逻辑来帮助用户达成目标。前台UI应该尽可能的轻，这样才能够快速地去适配不同用户的不同需求。

后台微服务遵循以业务为中心的设计思想。以业务为中心的设计就是完全站在业务处理的角度来思考微服务的设计，需要考虑业务处理的各种场景，使用合理的设计达到微服务之间的隔离性高，扩展性好等目标。因为业务领域的东西不会经常变化，并且随着市场的发展对于服务的需求量可能会呈现指数级的增加，所以后台服务应该尽可能地保持稳定和维持很好的扩展性，这样整个微服务集群才能够向外稳定地提供服务。

服务中台遵循以用户为中心的流程来驱动微服务之间的协作的设计思想。服务中台起到协调前台UI和后台微服务之间的作用，针对不同用户的不同处理流程，可以驱动不同的微服务之间进行协作，从而满足不同的业务处理需求的目的。服务中台应该尽可能地强大，这样才能够应付用户的各种不同的业务处理需求。