重构系统的套路-微服务化

服务拆分

根据业务或组织架构进行基本服务拆分，每一个服务实例会拥有专属的网络地址、独立的计算资源，而且独立部署。客户端经过访问服务实例的地址来调用服务 API。不一样服务也能够相互调用。

统一配置管理

一个服务可能会跑多个实例，每一个服务实例都会须要作配置。为了方便统一调整配置，咱们能够把配置中心化，每一个服务实例都去找配置管理器（Configuration Manager）拿配置。当配置更新的时候，咱们也可让服务实例再去拿新的配置。

命名服务

多服务实例带来的问题：网络地址（好比 IP）很容易由于扩容、维护而变更，调用者难以实时获知可用的地址。

鉴于此，咱们能够把网络地址抽象成不容易变更的概念，好比给每一个服务一个固定的名字。互联网使用 DNS 来解决这个问题，对应到微服务基建里面就是服务名册（Service Registry）。

每一个服务实例在运行期间，都会以心跳的形式向服务名册发送注册信息，包括服务的 ID 、访问地址以及健康情况。

这样，须要访问服务的时候，客户端就能够先问服务名册拿可用的实例地址，而后再访问实例来调用服务。除了更好地定位实例地址，服务名册还能够在某些实例下线、维护或升级的时候把其临时从名册中去掉，让服务不断线。

服务之间的调用也是如此，先找名册拿网络地址，再进行调用。

网关

找名册要地址，而后调用服务 API，这些是每一个客户端都会去作的杂事，咱们彻底能够把这些事情抽象、集中，把服务的 API 整合到一个大的中心点，而后把要地址和调用服务 API 这样的细节封装起来，全部客户端都只跟这个中心点对话，再也不直接访问单个服务。

从结构上看，这个中心点把整个架构划分红了内外两部分，内部是全部的服务，客户端则在外部，中心点站在中间。它做为内外的惟一通道，被瓜熟蒂落地命名做“API 网关”（API Gateway），有时候也被称作“边缘服务”（Edge Service）。

API 网关做为惟一出入口，又占据了最前沿的有利位置，因此有时还会承载别的公共功能，好比咱们立刻会提到的鉴权。

鉴权和身份认证

鉴权（Auth）包括了两个部分：

• 身份认证（Authentication）和权限验证（Authorization）。
• 身份认证关心的是“你是谁”，权限验证关心的是“你能不能作某件事”。

身份和权限都是高度中心化的概念。

对于一个系统来讲，用户的身份必须是统一的。

权限稍微复杂一点。和身份不一样，权限一般分红两种类别：

• 功能权限和数据权限。

这样的划分对应了现实世界中常见的权限模式：

• 你的角色决定了你的职能，而职能范围一般由附加条件来限制。

明确鉴权中心化以后，咱们就能够开发一个公用的鉴权服务，执行身份认证和权限验证。下一个问题是：谁来发起鉴权？

全部服务的调用都要求调用者明确本身的身份，因此天然身份认证越靠前越好。做为出入口的 API 网关天然是发起身份认证的不二之选。

权限验证则稍微复杂，彻底值得另起一文详述。此处咱们暂时假定权限验证也由 API 网关来发起。

消息队列

开发继续进行，一切风平浪静，技术上暂时没有什么问题。不过，业务上有一个问题须要解决。

好比，咱们作一个在线商城，要求在订单成功建立的一刻，仓库就要启动备货和发货的流程。

问题是，订单和仓储是两个服务，不一样团队在负责，并且从关注点来讲，订单服务并不关心仓储相关的问题，因此订单服务不可能在建立订单的时候去主动通知仓储服务。仓储服务只能定时轮询订单服务，看看有没有新的订单。这不只麻烦，并且实时性不够。

这就意味着咱们须要再引入一个中心化的公共服务：

• 消息中介（Message Broker）。

当某个事件发生的时候（好比用户激活成功、订单建立成功），服务能够朝消息队列发一条消息。而其余服务能够订阅这些消息，并针对这些消息作出反应。

好比，仓储服务能够订阅订单建立成功的消息。这样，订单成功建立后，订单服务将这个消息发到消息中介，消息中介通知仓储服务，仓储服务一看，就问订单服务要新的订单信息，最后，启动出库流程。

消息中介除了能广播事件以外，还能作异步调用。把同步的调用转化成异步的回调。针对调用时间长和不要求实时结果的调用，能够增长性能，提高体验。

先后端分离

支撑一个业务有先后两端的研发工做，两者是不一样步的。 前端由业务流程和设计来驱动，但愿按顺序产出；后端则由业务资源和建模来驱动，但愿按模块来产出。

好比说，前端经常会由于设计的缘由调整本身须要的字段，然后端从建模的角度并无这个须要，也没有动力频繁地去跟随前端的调整，使得前端不得不在不稳定的网络条件下传输多余的信息，占用了宝贵的网络带宽。

此外，前端呈现某个业务步骤的时候，有两种信息不属于当前必备信息，但经常须要和必要信息一块儿展现。一种是状态信息，好比当前的登陆状态和用户名，短消息的数量等等。 一种是垂直相关的信息，好比在展现文章的时候顺便展现一下相关的文章。

这就要求前端在调用主服务的同时还要再调用多个不一样的服务。且不说这些服务有可能会有调用超时、出错的可能，仅仅是多出来一堆异步请求，就已经足够让前端效率下降一大截了。

在微服务体系下，这些问题更加严重，由于如今不只仅是先后端的差异，不一样服务还由不一样团队负责。这些团队的诉求和日程不一，很难作到前端所须要的快速响应。

这些问题和麻烦可能会催生一个“缓冲带”，好比后端出专人来负责对接前端的须要，或者前端派驻一我的到后端来谈需求。按康威定律，这种沟通体系，长此以往，很容易以软件的形式沉淀下来，造成一个专属的中间层。

• 第一是解耦先后端的工做，下降相互的影响。前端须要的东西能够写在中间层里，让它频繁变化也没有关系。后端若是尚未准备好，前端也能够在这一层模拟假的数据，不至于被阻塞。
• 第二则是提高前端的运行效率。前端能够把所须要的多个服务的东西统一汇总，一次拿完，省得发多个请求。

放置的位置则在 API 网关以内，让它能够享有 API 网关所带来的好处和保护。

最后是维护问题。按照“谁主张，谁举证”的原则，既然有了这个中间层，好处让前端得了，那么，理论上应该由前端来维护。

这样，一个主要为前端服务的中间层就定义好了。不一样类型的前端（桌面、移动）可能会有不一样的须要，为了不中间层的碎片化，咱们可让各个中间层都特定的前端类型紧密耦合，好比桌面专用、移动专用。如此，每一个中间层都像是某类型前端的专享后端，因此“前置后端”（Backend-for-Frontend，简称 BFF）也所以得名。

提升服务容错

如今，调试也方便了，咱们又继续开发。一开始没有什么问题，但部署到预生产环境的时候，又一个问题出现了：

• 整个体系的容错度很低。一个小错误容易被层层传递和放大，致使整个体系的崩溃。

咱们都知道，编程最麻烦的就是远程调用。本地调用大部分时候结果是“成功”或“失败”，但远程调用则极可能是“无响应”。“无响应”有多是正常的，对方可能稍后会给你结果，也多是由于对方已经死了，无法给你响应。最坏的结果，就是门口挤满了人，你们都在等你给结果，而你也在等别人给结果，资源所有占用来等，什么也作不了。

不过，远程调用是没法避免的。在微服务体系中，这个问题被进一步放大。这是由于微服务的模块化以服务为单位，而每一个服务独立部署和运维，使得服务之间的调用成了屡见不鲜。

在这种严峻的状况下，咱们必须从架构上尽可能提升整个服务体系的容错度，让个别服务的问题不至于影响到全局。

具体的作法，则是给远程调用加一个熔断阈值检查，当调用超时次数超过阈值时，就再也不调用，直接返回错误。过一段时间以后，再把阈值恢复，尝试继续调用，重复前面的过程。这个机制就是回路熔断，而这个工具则是回路熔断器（Circuit Breaker）。

除了隔离已经出错的服务实例，熔断器还有一个重要的功能是提供备用方案。虽然咱们把全部业务都拆成了服务，但服务有高低贵贱之分。有一些服务属于关键服务，一旦出问题，则整个流程没法继续，有一些则属于分支服务，即使错了，也不会影响大局。

好比说，购买商品的时候，经常会根据用户的习惯和当前正在购买的东西作一些推荐。负责推荐的服务出问题的话，大不了就不推荐了，不该该影响用户正常的购买流程。

同理，若是是在线点餐的地址定位服务出问题了，咱们也应该容许用户手动选择餐厅进行点餐——体验虽然不佳，但至少正常的流程仍然能够走完。基于这个考虑，熔断器应该为非必要的服务调用提供备用方案，尽可能保证核心流程的顺畅。

提高服务弹力

要正式上线，咱们还必须作好负载均衡（Load Balancing，下简称 LB），提高整个服务的弹性。要作负载均衡，从理论上有两种方式：

• 客户端负载均衡（Client-Side LB）：由客户端来决定如何分散请求。
• 中间方负载均衡（Mid-Tier LB）：由 DNS、网关等中间方来决定如何分散请求。

如今，服务名册中已经有了服务及其对应的实例地址列表，因此客户端的负载均衡最简便的方式就是把地址拉下来，而后依次或者随机选择可用的地址。

中间方的负载均衡则选择面较多，从最外层的 DNS 到网关均可以不一样程度地去按须要去作。

基础设施

在作扩展时，架构师应该注意区分哪些东西应该中心化，哪些东西应该由服务自行决定。 好比说，在本文提到的基建之中，（几乎是）强制彻底中心化的模块有：

• 配置管理
• 服务名册
• 消息队列

其中，配置管理和服务名册是全部服务都须要的基础设施，必然须要统一。消息队列和日志收集都是为了跨服务的操做和追踪，也必须中心化。

半中心化的模块则有：

• 路由
• 鉴权

路由和鉴权都必须统一，咱们前面讨论过。

不过，微服务可能会向外界暴露“自用”和“客用”等多套公共 API（好比快递公司内部使用的物流 API 和开放给第三方使用的物流 API），因此可能会有两个 API 网关，对应会有两套 API 目录和两套鉴权体系，因此，它们是“半中心化”。

这些都是中心化、半中心化的选择范例。每一次中心化的选择均可能会让整个架构变得死板，失去灵活性，因此，咱们在设计和扩展基建的时候应该特别注意这个问题。

除了中心化的选择以外，架构发展的另外一个关注点，是让业务保持“黑盒”。

咱们把每一个服务之间的关联抽取了出来，也把权限的定义和验证抽取了出来，每一个服务变得简单而纯粹，成了“纯业务式服务”，等同于一个仅包含了业务规则的黑盒。这样，无论服务和模块再多，也没有影响。业务的重用性也很高。

总而言之，搭建好了微服务的必要设施以后，剩下的就要根据实际状况和项目经验来继续调整了。好比，咱们可能会选择把不少功能合并到一层，以免过分分层所带来的没必要要的性能损失，或者对整个基建进行一些细节微调。只要把控好“中心-自理”和“业务-非业务”之间的关系，这个基础设施就能健康地发展。

总结

微服务组件（按请求流中的出场顺序）：

• 配置管理：配置集中管理。
• API 网关：对外的 API 总目录；API 依赖关系；发起鉴权。
• 服务名册：服务的注册和发现。
• 鉴权服务：提供鉴权服务：认证身份，验证功能权限。
• 前置后端：按前端的需求拆解请求、调用服务，并汇总、转换结果。
• 消息中介：全局通知机制；异步调用机制。
• 回路熔断：隔离出问题的服务并等待其恢复；提供备用方案。
• 负载均衡：避免服务过载。

更多内容关注