良好的微服务设计能够使前期的降级保护更加轻松，否则将会令人十分头疼。
上面几个设计准则强烈建议采纳：
- 繁多职责
- 高内聚
低耦合
- 暗藏外部实现
- 防止代码库共享
- 防止数据适度裸露
- 防止数据库共享
- 最小化同步调用
- 最小化硬件共享
- 防止应用平台独特性技术
这三大准则是面向对象设计中的外围，同样实用于微服务设计。
1. 繁多职责
每个微服务只应负担一个职责。
比方一个微服务中有两大性能：
- 商品分类管理
- 购物车
把它们放在一起看起来问题不大，因为应用的技术雷同、性能和数据上会有比拟严密的分割，在组织构造上，通常是由同一个开发小组负责。
然而，这会造成两个性能有大量的代码耦合。
工夫长了之后，会带来和单体架构一样的问题，保护难、测试难、部署难 ……
所以，依照“繁多职责”准则，应该分为两个微服务。
2. 高内聚
关系严密的行为应放在一起。
比方有2个微服务：
- 订单治理
- 订单金额统计
“订单金额统计” 服务须要申请 “订单治理” 服务，以获取所需数据。
例如价格、税、服务费 ……
刚开始所有安好，但忽然某一天上头减少税种了，须要更改新的计算规定。
那么，订单服务就要提供新的数据，金额统计服务也须要更改计算形式。
也就是说，每次变更根本都须要两个服务一起改，是紧耦合的。
因为订单金额统计服务的逻辑只与订单相干，所以应该并入订单服务。
把严密相干的行为放在一起，实现高内聚。
3. 低耦合
一个服务的变更不要影响其余服务。
此准则波及到多个方面。
3.1 暗藏外部实现
比方上一节 “高内聚” 中，把金额统计服务并入了订单治理服务，那么，之前金额统计服务中的 “统计接口” 还须要对外裸露吗？
当初曾经是订单服务的外部性能了，统计后果能够作为订单对象中的数据，所以无需对外裸露，避免误操作和造成不必要的耦合关系。
3.2 防止共享代码库
共享代码确实十分不便，然而会造成底层代码关联度太强。
对于当前的降级十分不便，例如某个服务想把语言版本升级，但共享库应用的是低版本，其中某些用法在高版本中是过期的，这就很难堪了。
想要完满的防止也是不事实的，只能尽量躲避。
例如不共享，各服务从新造轮子，这样服务之间就有边界了。
但这个形式只实用于须要共享的库是十分稳固的，不怎么须要改了，否则的话相干服务都须要改。
再比方把共享库的粒度放大，防止造成性能特地全的大库。
大库必然导致被援用的范畴十分广，影响面大。
如果粒度很小的话，波及的服务也就少。
3.3 防止数据适度裸露
例如用户服务有一个获取用户详情的接口，返回用户所有信息。
购物车服务获取用户信息时，就会拿到很全的数据，例如包含领取信息。
这是没必要的，只须要返回用户的根本属性即可。
非凡的属性应通过另外的接口提供。
适度裸露会减少服务间的耦合度。
3.4 防止数据库共享
一个服务想获取另一个服务的数据时，只应该通过接口，而不是间接从对方的数据库中拿。
否则，这种数据层面的耦合会带来噩梦。
3.5 最小化同步调用
比方订单服务创立订单的时候须要调用很多其余服务，例如用户、商品、领取、库存、物流。
间接同步调用各个服务的接口吗？
不事实，如果其中有一个服务接口调用失败，那么创立订单就失败了。
最好应用事件驱动的异步调用。
同步调用会产生网络的阻塞，对被调用服务的可用性要求极高，所以要谨慎应用。
3.6 防止硬件基础设施的共享
服务设计得很好，但如果硬件部署没有布局好，一样十分苦楚。
例如两个服务部署在一台服务器上，服务B 十分耗费资源，那么服务A可能就没法用了。
所以，不能疏忽硬件这个关键点，要依据各个服务的特点做好平衡部署。
3.7 防止应用平台个性技术
例如 Java RMI 做近程调用不错，但它是平台个性，要求服务单方都用一套技术，这种高耦合就不如平台独立的 REST 更自在了。