如何应对企业级微服务开发？最优解在这里...

导语：近期，国外HashiCorp在官网宣布，不允许中国境内使用、部署和安装该企业旗下的企业版产品和软件，其中包括Consul。那么国内企业有没有类似的服务可以提供呢？答案是有！我们一起来看看华为云ServiceStage。

近年来越来越多的企业开始实践微服务，而微服务在企业应用落地的过程，面临着微服务开发框架的选型，无论是自研还是选择第三方框架都不得不考虑的问题包括：微服务框架是否具备高可靠性，任何时间不能中断业务；微服务框架是否能够实现高速通信性能，保证业务从单体架构向微服务架构切换时，性能下降不会太多。本文从服务管理中心、通信处理两个模块来介绍华为开源微服务框架 SeviceComb 如何帮助企业应用快速具备高性能的通信能力以及高可靠的服务管理能力。上篇先介绍微服务的服务管理中心。

ServiceCenter 整体介绍

图 1 ServiceCenter 整体介绍

ServiceCenter 是一个具有微服务实例注册 / 发现能力的微服务组件，提供一套标准的 RESTful API 对微服务元数据进行管理。ServiceComb 的微服务注册及动态发现能力也是依赖其实现的。

除了以上描述的微服务动态发现外，ServiceCenter 帮助应用具备以下能力：

• 实例缓存机制

基于 SDK 开发的微服务，会在第一次消费 Provider 微服务时，会进行一次实例发现操作，此时内部会请求 ServiceCenter 拉取 Provider 当前存活的实例集合，并保存到内存缓存当中，后续消费请求就依据该缓存实例集合，按照自定义的路由逻辑发送到 Provider 的一个实例服务中。

这样处理的好处是，已经运行态的 SDK 进程，始终保留一份实例缓存；虽然暂时无法感知实例变化及时刷新缓存，但当重新连上 ServiceCenter 后会触发一缓存刷新，保证实例缓存是最终有效的；在此过程中 SDK 保证了业务始终可用。

图 4 微服务实例缓存机制

• 异步缓存机制

在 ServiceCenter 内部，因为本身不存储数据，如果设计上单纯的仅作为一个 Proxy 服务转发外部请求到 etcd，这样的设计可以说是不可靠的，原因是因为一旦后端服务出现故障或网络访问故障，必将导致 ServiceCenter 服务不可用，从而引起客户端实例信息无法正确拉取和刷新的问题。所以在设计之初，ServiceCenter 引入了缓存机制。

图 6 异步缓存机制

1.    启动之初，ServiceCenter 会与 etcd 建立长连接（watch），并实时监听资源的变化。

2.    每次 watch 前，为防止建立连接时间窗内发生资源变化，ServiceCenter 无法监听到这些事件，会进行一次全量 list 查询资源操作。

3.    运行过程中，List & watch 所得到的资源变化会与本地缓存比对，并刷新本地缓存。

4.    微服务的实例发现或静态数据查询均使用本地缓存优先的机制。

异步刷新缓存机制，可以让 ServiceCenter 与 etcd 的缓存同步是异步的，微服务与 ServiceCenter 间的读请求，基本上是不会因为 etcd 不可用而阻塞的；虽然在资源刷新到 ServiceCenter watch 到事件这段时间内，会存在一定的对外呈现资源数据更新延时，但这是可容忍范围内的，且最终呈现数据一致；这样的设计即大大提升了 ServiceCenter 的吞吐量，同时保证了自身高可用。

• 自我保护机制

前面提到的缓存机制，保证了 ServiceCenter 在 etcd 出现网络分区故障时依然保持可读状态，ServiceCenter 的自我保护 (Self-preservation) 机制保证了 Provider 端与 ServiceCenter 在出现网络分区故障时依然保持业务可用。

现在可以假设这样的场景：全网大部分的 Provider 与 ServiceCenter 之间网络由于某种原因出现分区，Provider 心跳无法成功上报心跳。这样的情况下，在 ServiceCenter 中会出现大量的 Provider 实例信息老化下线消息，ServiceCenter 将 Provider 实例下线事件推送到全网大部分的 Consumer 端，最终导致一个结果，用户业务瘫痪。可想而知对于 ServiceCenter 乃至于整个微服务框架是灾难性的。

为了解决这一问题，ServiceCenter 需要有一个自我保护机制（Self-preservation）：

图 8 ServiceCenter 的自我保护机制

1.    ServiceCenter 在一个时间窗内监听到 etcd 有 80% 的实例下线事件，会立即启动自我保护机制。

2.    保护期间内，所有下线事件均保存在待通知队列中。

3.    保护期间内，ServiceCenter 收到队列中实例上报注册信息则将其从队列中移除，否则当实例租期到期，则推送实例下线通知事件到 consumer 服务。

4.    队列为空，则关闭自我保护机制。

有了自我保护机制后，即使 etcd 存储的数据全部丢失，这种极端场景下，SDK 与 ServiceCenter 之间可在不影响业务的前提下，做到数据自动恢复。虽然这个恢复是有损的，但在这种灾难场景下还能保持业务基本可用。

以上就是 ServiceComb 的服务管理中心在分布式系统下的高可靠架构设计，在进行大规模、高并发的企业应用开发时，可靠的服务管理中心能够使得分布式系统运行更加稳定，同时高性能的通信也使得分布式系统更高效地处理密集的业务。