关于分布式:做好微服务架构并非易事

概念

微服务 (Microservices Architecture) 是一种架构格调，一个大型简单软件应用由一个或多个微服务组成。零碎中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于实现一件工作并很好地实现该工作。在所有状况下，每个微服务代表着一个小的业务能力。

微服务是依据具体业务畛域边界划分进去的能独立运行的程序，并且能够独立部署，能够依据业务量横向扩大，批改不会影响其余程序失常运行。简略一句话：微服务是有肯定边界的有本人上下文的服务架构理念。

微服务长处

1. 微服务更容易的扩大，它基本上是独立的。应答互联网利用中大并发的零碎能够做到主动弹性应答。
2. 每个微服务能够由不同的团队，采纳不同的技术栈开发，只有遵循约定的协定即可，每个微服务的批改不会影响到其余服务的失常运行。
3. 微服务的架构思维摒弃了中心化的架构格调，进一步升高了零碎间的耦合度，无论是在开发阶段或部署阶段都是独立的。
4. 微服务因为能够疾速开发和交付，所以在新技术的接管能力上要远远高于其余零碎，例如：将一个传统的零碎批改微服务能够疾速上云，能够疾速采纳 k8s 部署。
5. 每个微服务都遵循雷同的协定规范，所以再团队之间的沟通上能够缩小很多不必要的麻烦。

微服务毛病

微服务虽好，但也并非完满。

服务数量

微服务从字面意思就能够晓得强调服务的“微”，然而这个微的粒度，少数人都了解谬误，有人说：微到不能再微是微服务划分的理念。我不这样认为，微服务的畛域边界是依据具体业务来划分，适度的划分，只会导致微服务的数量急剧减少，团队的效率急剧下降。有的团队只有 5~6 集体，然而却拆分出几十个微服务零碎，均匀每个人要保护 5~10 个微服务，这样做给团队带来的只有负面效应。无论是开发，测试，还是运维都须要在多个微服务之间不停的切换。

当微服务上线之后，几十个微服务须要启动几十个过程，在退出了负载平衡与消息中间件后，过程的数量还会继续增加。运维与编排全副这些服务是个“令人望而生畏的工作”。

当微服务粒度过细，会造成代码复用度进一步升高，一些通用的代码你可能须要在多个服务间进行 copy，如果某段代码有问题，你同时须要批改多个服务代码，当然同种语言能够应用代码共享库来解决，然而在多语言的状况下是行不通的。

事务管理

无论微服务怎么样划分边界，业务上无奈防止在多个服务间的事务性操作。最简略的下单场景：很多状况下订单和用户资产是不同的微服务，当用户领取胜利，扣除用户资产和更改订单状态（还有缩小商品库存）应该是一个原子性操作，如果在以前的单体利用专用一个数据库的状况下，用 DB 的事务很容易实现原子性操作，然而在微服务环境下，实现事务有肯定的难度，尤其是当服务间采纳异步操作的时候，这就很简单了，这要求咱们得“治理好相关联的 ID 以及分布式事务，将各种动作绑定在一起”。

服务关系

服务划分过细，单个服务的复杂度的确降落了，但整个零碎的复杂度却回升了，因为微服务将零碎内的复杂度转移为零碎间的复杂度了。从实践的角度来计算，n 个服务的复杂度是 n×(n-1)/2，整体零碎的复杂度是随着微服务数量的减少呈指数级减少的。下图形象了阐明了整体复杂度：

调用链太长

服务间的通信都采纳规范的 Http 或者 Rpc 协定，只有是通过网络的调用，就会消耗资源，就会破费更多的执行工夫。如果一个申请须要程序的调用 N 层服务，那么这个申请所破费的工夫是不容忽视的，这在大并发的零碎中是致命的性能损耗存在，零碎的吞吐量会大幅降落。尽管减少硬件在肯定水平上会缓解这种问题，然而却在基本上解决不了问题，而且在老本上会大幅度回升。

另外，服务的调用链太长，定位系统问题很难。一个业务申请会通过 N 个微服务，任何一个服务有问题，都有可能会导致业务失败。因为调用的微服务过多，而且异样有扩散的属性，疾速定位服务问题对于开发以及测试来说，是一件很简单并且很难的事件。如下图所示：

如果服务 C 产生故障，开发定位问题的时候须要从服务 A 开始追踪，而后追踪服务 B，而后是服务 C，如果调用链更长的话，还须要持续追踪。当定位到问题之后，可能曾经过来了几个小时，这在一些敏感的零碎中是不容许的。如果服务的复杂性如下图所示，该怎么办呢？

微服务的架构设计中，做好服务的追踪是很重要的

自动化撑持

如果没有相应的自动化零碎进行撑持，都是靠人工去操作，那么微服务岂但达不到疾速交付的目标，甚至还不如一个大而全的零碎效率高。

1. 没有自动化测试撑持，每次测试时须要测试大量接口。
2. 没有自动化部署撑持，每次部署 6 ~ 7 个服务，几十台机器，运维人员敲 shell 命令逐台部署，手都要敲麻。
3. 没有自动化监控，每次故障定位都须要人工查几十台机器几百个微服务的各种状态和各种日志文件。

当服务的数量达到肯定水平，如果如上图所示，服务的治理难度就会被提上日程。当微服务的品种和数量越来越多，如果没有微服务的治理零碎去撑持，微服务的劣势就会变为劣势，包含每个服务的注册和发现，每个服务的部署，每个服务的隔离，甚至每个服务的路由。

如果还是人工去干涉这些，最终服务零碎将会变的一片凌乱，微服务推重的疾速交付，横向扩大等个性也将变的简单。

微服务的重点不止在边界的划分，还有服务的治理。就像容器一样，容器很重要，然而容器编排同样重要。

参考文档：从 0 开始学架构

更多精彩文章

• 分布式大并发系列
• 架构设计系列
• 趣学算法和数据结构系列
• 设计模式系列