基于Predix平台开发微服务应用需要服务发现框架么？

微服务架构能将单一、庞大的应用拆分为一套小且互相关联的服务，从而解决大型应用程序复杂性的问题，因此备受开发人员的青睐。越来越多的开发团队在Predix平台开发基于微服务架构的分布式应用。同时，对于基于云端的、现代化的微服务应用而言，微服务应用间通过轻量级的HTTP API进行沟通却是一大难题。因为在微服务场景下，所有服务实例的网络位置，包括IP和端口都是动态分配的。由于扩容、失败和升级，服务实例会经常动态改变，微服务的调用方必须使用更加复杂的服务发现机制。

因此，不少开发人员认为基于Predix平台开发的微服务应用也需要使用服务发现框架。

为了解答这个问题，我们先来了解目前典型的服务发现模型：

1. 客户端服务发现模型
2. 服务器端服务发现模型

客户端服务发现模型

客户端服务发现模型是指，当发起一个请求时，客户端直接从服务注册表中获取相应微服务实例的网络位置。如果有多个微服务实例提供相同的服务能力，客户端则根据自身的负载均衡算法决定将请求发送到哪个具体的微服务实例。例如，为保证高可用性，系统提供多个用户认证微服务实例，用户登录客户端自行决定将登录请求发送到某一个具体的微服务实例。

服务器端服务发现模型

服务器端服务发现模型是指，当发起一个请求时，客户端通过负载均衡器向相应的微服务实例提出请求。负载均衡器根据预定义的负载均衡算法从服务注册表中获取相应微服务实例的网络位置，再将请求转发过去。和客户端服务发现模型不同的是，客户端已经不用关心服务注册表的地址、负载均衡的算法和具体的微服务实例的网络位置，只需要将请求发送给负载均衡器，其他事情都由负载均衡器去完成。

服务注册表

从上面两种服务发现模型我们可以了解到，服务注册表是服务发现的核心组件。它存储了所有微服务实例的网络位置，而且需要根据微服务实例的状态实时更新。

服务发现的三大核心功能

因此，为了能够成功定位一个具体的微服务实例，一个服务发现框架需要完成如下三个的核心功能：

1. 服务注册：将微服务实例的网络地址保存到服务注册表
2. 服务发现：允许从服务注册表中读取相应微服务实例所注册的网络地址
3. 服务状态更新：实时更新微服务实例的状态到服务注册表

现在我们了解了服务发现框架的三大核心功能，再来审视Predix平台有没有相应的组件提供相应的能力，答案就是Router。

Router简介

Cloud Foundry核心架构如下图所示，

从架构图中，我们可以了解到，

1. Router是Predix平台所有流量的入口，包括了发送给Cloud Controller的控制流和发送给托管在Predix平台应用程序的数据流。
2. Router定期会从应用程序的运行平台查询每个应用程序实例运行在哪个主机的哪个容器环境中。Router通过这些信息来构建自己的路由表，记录每个应用程序实例的网络地址，完成服务注册的功能。
3. 当Router收到访问应用程序的请求时，它会根据自身路由表的记录，采用轮转算法或者最少连接算法，将请求转发到具体的应用程序实例，完成服务器端服务发现功能。
4. Router同时还监听消息管道推送来的消息，实时更新应用程序实例的网络地址，完成服务状态更新的功能。

使用基于Router的服务发现

Router已经完美的实现了服务发现的核心功能，因此使用基于Router的服务发现服务是非常方便，甚至我们都对服务发现没有特别的感知。例如，我们开发一个微服务架构的分布式应用由多个微服务应用程序构成，并且它们之间有如下的调用依赖关系。

我们只需要在微服务应用程序F（以下简称，微服务F）的配置文件中指定微服务B和微服务E的接入点信息即可。

// microServiceF.confmicroServiceB = https://microServiceB/api/microServiceE = wss://microServiceE/msg/

当微服务F请求微服务B或者微服务E时，Router就会通过自身的路由表信息，将请求转发到微服务B或E的具体实例，完成服务发现的功能。而当微服务B或E进行横向扩容或者缩容时，Router也会更新自身的路由信息，使得微服务F始终能通过Router将请求转发到合适的微服务实例，而不必关系具体微服务实例的网络地址。

Health Manager检测应用程序状态

Predix平台中的Health Manager组件能定期检测平台中应用程序实例的状态，如果发现失败的应用程序实例，则会发送消息到router.unregister主题。Router就会根据推送来的消息，实时更新应用程序实例的网络地址，完成服务状态更新。

因此，通过Predix平台内置组件的相互配合，Router完全能够满足Predix平台上的服务发现功能，使得开发人员能更加专注在业务相关的微服务应用的开发，而不需要关系与业务无关的服务发现功能，更高效的完成自身业务程序的开发。

小结

通过本文我们了解到，

1. 服务发现框架的三大核心能力为，服务注册，服务发现和服务状态更新。
2. Router是Predix平台所有流量的入口。
3. 通过Predix平台内置组件的相互配合，Router完全能够满足Predix平台上的服务发现功能，使得开发人员更高效的完成自身业务程序的开发。

作者：谢品，上海创新坊首席架构师，GE数字集团

专注于工业互联网，云计算，大数据，高性能分布式存储领域，对Cloud Foundry和传统应用向云端，特别是向Predix迁移有丰富的经验，曾供职于VMware，EMC，Autodesk等知名软件公司云计算部门。