微服务设计原则

---

前言

        良好的微服务设计可以使后期的升级维护更加轻松，否则将会令人非常头疼。

---

提示：以下是本篇文章正文内容，下面案例可供参考

一、单一职责

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

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

• 商品分类管理
• 购物车

        把它们放在一起看起来问题不大，因为使用的技术相同、功能和数据上会有比较紧密的联系，在组织结构上，通常是由同一个开发小组负责。但是，这会造成两个功能有大量的代码耦合。时间长了之后，会带来和单体架构一样的问题，维护难、测试难、部署难……

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

二、高内聚

        关系紧密的行为应放在一起。
比如有2个微服务：

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

        “订单金额统计”服务需要请求“订单管理”服务，以获取所需数据。刚开始一切安好，但突然某一天上头增加税种了，需要更改新的计算规则。那么，订单服务就要提供新的数据，金额统计服务也需要更改计算方式。也就是说，每次变更基本都需要两个服务一起改，是紧耦合的。

        因为订单金额统计服务的逻辑只与订单相关，所以应该并入订单服务。把紧密相关的行为放在一起，实现高内聚。

三、低耦合

        一个服务的变更不要影响其他服务。此原则涉及到多个方面。

        隐藏内部实现
        比如上一节“高内聚”中，把金额统计服务并入了订单管理服务，那么，之前金额统计服务中的 “统计接口” 还需要对外暴露吗？
        现在已经是订单服务的内部功能了，统计结果可以作为订单对象中的数据，所以无需对外暴露，防止误操作和造成不必要的耦合关系。
        避免共享代码库

        共享代码的确非常方便，但是会造成底层代码关联度太强。
        对于以后的升级非常不便，例如某个服务想把语言版本升级，但共享库使用的是低版本，其中某些用法在高版本中是过期的，这就很尴尬了。想要完美的避免也是不现实的，只能尽量规避。
        例如不共享，各服务重新造轮子，这样服务之间就有边界了。但这个方式只适用于需要共享的库是非常稳定的，不怎么需要改了，否则的话相关服务都需要改。
        再比如把共享库的粒度缩小，避免形成功能特别全的大库。大库必然导致被引用的范围非常广，影响面大。如果粒度很小的话，涉及的服务也就少。
        避免数据过度暴露
        例如用户服务有一个获取用户详情的接口，返回用户所有信息。购物车服务获取用户信息时，就会拿到很全的数据，例如包括支付信息。这是没必要的，只需要返回用户的基本属性即可。特殊的属性应通过另外的接口提供。过度暴露会增加服务间的耦合度。
        避免数据库共享

        一个服务想获取另一个服务的数据时，只应该通过接口，而不是直接从对方的数据库中拿。否则，这种数据层面的耦合会带来噩梦。
        最小化同步调用

        比如订单服务创建订单的时候需要调用很多其他服务，例如用户、商品、支付、库存、物流。直接同步调用各个服务的接口吗？
        不现实，如果其中有一个服务接口调用失败，那么创建订单就失败了。最好使用事件驱动的异步调用。同步调用会产生网络的阻塞，对被调用服务的可用性要求极高，所以要慎重使用。
        避免硬件基础设施的共享

        服务设计得很好，但如果硬件部署没有规划好，一样非常痛苦。例如两个服务部署在一台服务器上，服务B非常消耗资源，那么服务A可能就没法用了。所以，不能忽略硬件这个关键点，要根据各个服务的特点做好均衡部署。
        避免使用平台特性技术
        例如Java RMI做远程调用不错，但它是平台特性，要求服务双方都用一套技术，这种高耦合就不如平台独立的REST更自由了。

原文链接