微服务模式系列之四：客户端服务实现

译者自序：

熟悉我的朋友都知道，我很不喜欢翻译东西，因为在两种语言的思维方式之间做频繁切换对我来说是件很痛苦的事情。但是这次不一样，公司和同事的大力支持降低了我的痛苦指数，让我能够坚持把Chris Richardson的微服务模式系列文章翻译完，今天发布第四篇——《客户端服务实现》。

背景

不同服务之间通常需要相互调用。在单体应用程序当中，服务间通过语言层级的方法或者过程实现相互调用。在传统的分布式系统部署下，服务在固定并且已知的位置（主机与端口）运行，从而确保各服务可利用HTTP/REST或者某种RPC机制进行相互调用。然而，现代化微服务应用程序中通常在虚拟化或者容器化环境中运行，在这样的环境中服务的实例数量和位置是动态变化的。

因此，要想实现客户端向动态变化的一组服务端实例发送请求，我们必须采用新的机制。

问题

服务的客户端——包括API网关或者其它服务——如何才能获取服务端实例的位置？

需求

• 每一服务实例都会在特定位置（主机与端口）通过HTTP/REST或者Thrift等方式发布一个远程API。
• 服务端实例的具体数量及位置会发生动态变化。
• 虚拟机与容器通常会被分配动态IP地址。
• 服务实例的数量会发生动态变化。例如，EC自动伸缩组会根据负载情况随时调整实例数量。

方案

在向某一服务发送请求时，客户端会通过查询 Service Registry，即服务注册表，以获取该服务实例的位置。该注册表中包含全部服务的位置。

以下示意图展现了这种模式的结构。

而这正是微服务底盘框架的典型处理方式。

举例

Netflix OSS正是客户端发现机制的典型代表：

• Eureka1 充当其中的Service Registry2
• Ribbon Client3是一套HTTP客户端，负责向Eureka发出查询任务并将HTTP请求路由至可用的服务实例。

结果

客户端发现机制拥有以下优势：

• 相较于服务器端发现4 ，其活动部件与网络中转数量更少。

客户端发现机制亦存在着以下弊端：

• 这一模式使客户端与 Service Registry5相耦合。
• 需要为应用程序中使用的每种编程语言/框架建立客户端服务发现逻辑，例如Java/Scala以及JavaScript/Node JS。举例来说，Netflix Prana就为非JVM客户端提供了一套基于HTTP代理的服务发现方案。

相关模式

• Service Registry 6-服务发现机制中的重要部分
• 微服务底盘 7-客户端服务发现机制作为微服务底盘框架
• 服务器端发现 8-是解决此类问题的备选方案。

文中关键词链接地址：

1.Eureka：https://github.com/Netflix/eureka/wiki/Eureka-at-a-glance

2.Service Registry：http://microservices.io/patterns/service-registry.html

3.Ribbon Client：https://github.com/Netflix/ribbon

4.服务器端发现：http://microservices.io/patterns/server-side-discovery.html

5.Service Registry：http://microservices.io/patterns/service-registry.html

6.Service Registry：http://microservices.io/patterns/service-registry.html

7.微服务底盘：http://microservices.io/patterns/microservice-chassis.html

8.服务器端发现：http://microservices.io/patterns/server-side-discovery.html

原文链接：http://microservices.io/patterns/client-side-discovery.html

关于译者：

宋潇男

EAII-企业架构创新研究院 专家委员

现任普元云计算架构师，曾任华为云计算产品技术总监。曾负责国家电网第一代云资源管理平台以及中国银联基于OpenStack的金融云的技术方案、架构设计和技术原型工作。

原著作者

Chris Richardson

世界十大软件架构师之一，《POJOS IN ACTION》一书的作者。他的研究领域包括Spring、Scala、微服务架构设计、NoSQL数据库、分布式数据库、分布式数据管理、事件驱动的应用编程等。