微服务设计原则

良好的微服务设计可使后期的升级维护更加轻松，不然将会使人很是头疼。

下面几个设计原则强烈建议采用：

• 单一职责
• 高内聚

• 低耦合

  • 隐藏内部实现
  • 避免代码库共享
  • 避免数据过分暴露
  • 避免数据库共享
  • 最小化同步调用
  • 最小化硬件共享
  • 避免使用平台独特性技术

这三大原则是面向对象设计中的核心，一样适用于微服务设计。

1. 单一职责

每一个微服务只应担负一个职责。

好比一个微服务中有两大功能：

• 商品分类管理
• 购物车

把它们放在一块儿看起来问题不大，由于使用的技术相同、功能和数据上会有比较紧密的联系，在组织结构上，一般是由同一个开发小组负责。

可是，这会形成两个功能有大量的代码耦合。

时间长了以后，会带来和单体架构同样的问题，维护难、测试难、部署难 ……

因此，按照“单一职责”原则，应该分为两个微服务。

2. 高内聚

关系紧密的行为应放在一块儿。

好比有2个微服务：

• 订单管理
• 订单金额统计

“订单金额统计” 服务须要请求 “订单管理” 服务，以获取所需数据。

例如价格、税、服务费 ……

刚开始一切安好，但忽然某一天上头增长税种了，须要更改新的计算规则。

那么，订单服务就要提供新的数据，金额统计服务也须要更改计算方式。

也就是说，每次变动基本都须要两个服务一块儿改，是紧耦合的。

由于订单金额统计服务的逻辑只与订单相关，因此应该并入订单服务。

把紧密相关的行为放在一块儿，实现高内聚。

3. 低耦合

一个服务的变动不要影响其余服务。

此原则涉及到多个方面。

3.1 隐藏内部实现

好比上一节 “高内聚” 中，把金额统计服务并入了订单管理服务，那么，以前金额统计服务中的 “统计接口” 还须要对外暴露吗？

如今已是订单服务的内部功能了，统计结果能够做为订单对象中的数据，因此无需对外暴露，防止误操做和形成没必要要的耦合关系。

3.2 避免共享代码库

共享代码的确很是方便，可是会形成底层代码关联度太强。

对于之后的升级很是不便，例如某个服务想把语言版本升级，但共享库使用的是低版本，其中某些用法在高版本中是过时的，这就很尴尬了。

想要完美的避免也是不现实的，只能尽可能规避。

例如不共享，各服务从新造轮子，这样服务之间就有边界了。

但这个方式只适用于须要共享的库是很是稳定的，不怎么须要改了，不然的话相关服务都须要改。

再好比把共享库的粒度缩小，避免造成功能特别全的大库。

大库必然致使被引用的范围很是广，影响面大。

若是粒度很小的话，涉及的服务也就少。

3.3 避免数据过分暴露

例如用户服务有一个获取用户详情的接口，返回用户全部信息。

购物车服务获取用户信息时，就会拿到很全的数据，例如包括支付信息。

这是不必的，只须要返回用户的基本属性便可。

特殊的属性应经过另外的接口提供。

过分暴露会增长服务间的耦合度。

3.4 避免数据库共享

一个服务想获取另外一个服务的数据时，只应该经过接口，而不是直接从对方的数据库中拿。

不然，这种数据层面的耦合会带来噩梦。

3.5 最小化同步调用

好比订单服务建立订单的时候须要调用不少其余服务，例如用户、商品、支付、库存、物流。

直接同步调用各个服务的接口吗？

不现实，若是其中有一个服务接口调用失败，那么建立订单就失败了。

最好使用事件驱动的异步调用。

同步调用会产生网络的阻塞，对被调用服务的可用性要求极高，因此要慎重使用。

3.6 避免硬件基础设施的共享

服务设计得很好，但若是硬件部署没有规划好，同样很是痛苦。

例如两个服务部署在一台服务器上，服务B 很是消耗资源，那么服务A可能就无法用了。

因此，不能忽略硬件这个关键点，要根据各个服务的特色作好均衡部署。

3.7 避免使用平台特性技术

例如 Java RMI 作远程调用不错，但它是平台特性，要求服务双方都用一套技术，这种高耦合就不如平台独立的 REST 更自由了。