微服务架构设计-7服务注册与调用

在前几节我们确定了服务的划分、通讯协议的选择及接口的设计等，那接下我们考虑这样一个问题：我们将车贷系统拆分成了20个左右的服务，这些服务怎么调用呢？

最简单的方法是使用类似Nginx的反向代理服务来作为轻量级的ESB，负责编排服务调用和处理服务路由。这是一个不错的选择，尤其适用于小型系统。然而，在中大型系统中，这种方案存在一些不足之处，例如：

1. 性能问题： 由于所有调用都经过ESB的调用链路，可能导致链路变得较长，影响系统性能。ESB本身也可能承受较大的压力，限制系统的横向扩展。
2. 服务注册发现： 这种方案对服务注册发现的支持相对较差。在Nginx等反向代理服务中，服务路由通常需要静态配置，难以实现对服务动态变化的感知和支持。
3. 动态服务管理： 对于服务的动态增加、删除和存活性的感知支持有限。在使用Nginx等工具时，服务的管理通常需要手动的配置和操作，而无法实现自动化的服务治理。

要有效地管理各个服务我们需要一个带有服务注册与监控、智能负载调用、高性能的注册与调度服务，而这也正是微服务最核心的技术之一。
要实现服务注册监控最简单的做法是让注册与调度服务定时ping各个服务进程是否存活，但这过于粗放，有很多情况是服务进程还在但服务僵死，所以真正有效的做法是要求各服务提供服务状态API，由各服务定时主动上报或注册调度服务定时采集的方式来确定服务是否正常。
注册与调度服务常见的几种形式如下：
中心化的注册与调度服务

image.png
服务的注册与调度完全交由中心化的注册调度中心完成，这其实就是上面Nginx的版本，它的优点是对各个服务本身没有侵入性，方便做服务Orchestration，问题上文也提到，每次调用都要走ESB，对性能一定影响

对等网络，嵌入式注册与负载

image.png
各个服务内嵌了服务注册与负载调度功能，使得各服务实例具有对等性。这样的设计优势在于服务自治、无需额外支撑服务、直连调用速度快。然而，这也导致服务对注册调度逻辑的侵入，不够纯粹，而且需要为不同语言编写完整的注册调度实现，不够通用。此外，随着服务数量增多，统一的管理和管控变得复杂。 Vertx 是一个支持这种模式的知名微服务框架。

独立注册服务，嵌入式负载

image.png
这一模式综合了前两个模式的优点。它采用了独立的、中心化的注册中心，服务调用直接下放到各服务侧，实现了点对点的通信。所有服务在启动后会定期同步其状态到注册中心，使注册中心拥有最新的全量路由表。各服务也会定期拉取与自身相关的路由表，可以通过注册中心事件触发并推送的方式来实现。这样，在服务调用时，系统首先在本地进行寻址，实施本地化的负载策略，并直接与目标服务进行通信。

这种模式既保留了独立注册中心的优势，便于管理和监控，同时也让服务调用可以直接连接，以保证性能。因此，像Spring Cloud、Dubbo等主流的微服务框架都采用这一模式。

在服务调用时，需要考虑负载均衡的策略，以确定在多实例情况下调用哪一个实例。一些常见的负载均衡策略包括：

• 随机选择： 随机选择一个服务实例。这种方式相对简单，但一般不推荐使用，因为过于粗暴。

• 轮询： 将所有服务实例组成一个环，每次调用上次调用节点的下一个节点。

• 加权策略： 比较智能的策略，可以根据不同的加权项组合出多种策略。例如：

  1. 响应时间权重： 统计每次请求后对应实例的响应时间，下次请求时优先分配给响应时间较快的实例。
  2. 区域权重： 考虑服务可能分布在不同的机架、机房甚至国家和地区，这个策略会优先分配请求给相邻节点的实例。

说到这，有读者会想到我们即要注册中心以方便管控又要避免嵌入式的调用负载对服务的侵入，那么是否可以实现类似下图的注册调用方式：

image.png

在这种模式下，我们将调用负载从服务中独立出来，每个服务实例外挂一个相应的调用负载组件。所有与注册和调度相关的功能都由这个调用负载组件来实现，使得服务本身更为清晰简洁。同时，服务的实例与调用负载部署在同一节点中，减少了网络开销，有利于维护性能。

如果你曾经考虑过这样的方案，那么恭喜你！你的想法正是当前讨论最为热门的 Service Mesh 的核心思想。Service Mesh 试图构建一种对服务最小化侵入的服务治理体系，被广泛认为是微服务未来发展的方向。

注册中心有很多开源实现，比如主流的有：
Zookeeper: 它是一个高可用的分布式服务协调器，本质上它维护了一颗分布式的节点树，节点有永久、临时、顺序三类，临时节点在客户端连接时创建，宕机或正常下线时删除，注册功能的核心正是基于此特性实现
Consul: 与Zookeeper不同，Consul是专门为服务注册发现而生，不需要像Zookeeper需要定制开发，它开箱即用，同时有友好的UI，支持多数据中心等高级特性，它对Service Mesh提供了很好的支持。
Etcd: 是一个分布式的K-V结构数据存储器，与Zookeeper类似，用它做注册发现需要定制开发。
Eureka: 这是Spring Cloud默认的注册中心，与Spring Cloud深度集成，功能与Consul类似，但通用性欠缺。

如果我们项目是Spring Cloud构架，那么Eureka应该是首选，否则如无特性情况Consul会是很不错的选择。

在绝大多数情况下，使用特定框架提供的解决方案通常足以满足需求，无需过多的架构设计。然而，在一些特殊情况下，可能需要自定义调用和负载策略，特别是在金融、电商等行业面临的“薅羊毛”行为问题上。

这类问题常见的解决方法包括加强验证，采用各种手机、图形、滑块等验证方案。此外，通过获取黑产库（包括黑卡、IP、设备等信息）建立自己的黑白灰名单库。对于白名单用户，可以直接放行；对于黑名单用户，则可直接过滤。然而，对于标记为可疑的灰名单用户，不能百分之百确定是否为羊毛党。在这种情况下，可以通过活用调用负载，采用自定义负载策略来处理。

一种可能的方式是将灰名单用户路由到专用实例中，或者建立两套相对独立的集群，用于分流正常请求和可疑请求。这样可以确保在像秒杀场景这样的高压力环境下，系统不会受到过多的负载影响，同时保障正常用户的访问不受到不必要的干扰。

只要存在足够大的利益，总会有人动起歪脑筋。在“攻”与“防”的较量中，双方不断升级，做安全架构时必须深刻认识到：不存在攻不破的系统，我们唯一能做的就是让攻击的成本超过其收益。这正是比特币以PoW（工作量证明）机制为基础能够风靡全球且未受致命攻击的原因。
前文提到，为解决“薅羊毛”问题而加入各种验证功能，在实际生产中都发现存在不同程度的渗透。即使使用国内某知名验证产品，面对足够的利益，这些验证措施也可能变得形同虚设。

服务注册与调用是微服务组织管理与通信的关键，对这一概念大家要所有了解，灵活地应用以优雅的方式解决特定的问题