要想做好微服务，其实有几条规则必须遵守-技术圈

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

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

单一职责
高内聚
低耦合

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

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

单一职责

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

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

商品分类管理
购物车

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

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

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

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

高内聚

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

比如有2个微服务：

订单管理
订单金额统计

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

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

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

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

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

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

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

低耦合

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

此原则涉及到多个方面。

隐藏内部实现

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

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

避免共享代码库

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

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

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

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

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

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

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

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

避免数据过度暴露

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

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

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

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

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

避免数据库共享

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

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

最小化同步调用

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

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

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

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

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

避免硬件基础设施的共享

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

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

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

避免使用平台特性技术

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

原文链接：https://segmentfault.com/a/1190000039963016

中国人发明的计算机，程序该怎么写呢？

分库分表就能无限扩容吗？