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