微服务设计原则

本文主要是介绍微服务设计原则，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

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

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

• 单一职责
• 高内聚
• 低耦合
  • 隐藏内部实现
  • 避免代码库共享
  • 避免数据过度暴露
  • 避免数据库共享
  • 最小化同步调用
  • 最小化硬件共享
  • 避免使用平台独特性技术

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

1. 单一职责

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

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

• 商品分类管理
• 购物车

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

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

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

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

2. 高内聚

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

比如有2个微服务：

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

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

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

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

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

也就是说，每次变更基本都需要两个服务一起改，是紧耦合的。

因为订单金额统计服务的逻辑只与订单相关，所以应该并入订单服务。

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

3. 低耦合

一个服务的变更不要影响其他服务。

此原则涉及到多个方面。

3.1 隐藏内部实现

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

现在已经是订单服务的内部功能了，统计结果可以作为订单对象中的数据，所以无需对外暴露，防止误操作和造成不必要的耦合关系。

3.2 避免共享代码库

共享代码的确非常方便，但是会造成底层代码关联度太强。

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

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

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

但这个方式只适用于需要共享的库是非常稳定的，不怎么需要改了，否则的话相关服务都需要改。

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

大库必然导致被引用的范围非常广，影响面大。

如果粒度很小的话，涉及的服务也就少。

3.3 避免数据过度暴露

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

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

这是没必要的，只需要返回用户的基本属性即可。

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

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

3.4 避免数据库共享

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

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

3.5 最小化同步调用

比如订单服务创建订单的时候需要调用很多其他服务，例如用户、商品、支付、库存、物流。

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

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

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

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

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

服务设计得很好，但如果硬件部署没有规划好，一样非常痛苦。

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

所以，不能忽略硬件这个关键点，要根据各个服务的特点做好均衡部署。

3.7 避免使用平台特性技术

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

这篇关于微服务设计原则的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！