第三方服务支持原理

第三方服务分类

第三方服务的最关键的是用户提供的服务通信地址，因此我们根据用户提供服务通信地址的方式将第三方服务分为两类：

• 静态注册第三方服务

顾名思义此类第三方服务是用户在创建时提供一个或多个固定的服务通信地址，我们称其为 Endpoints。通信请求流量将固定的被负载到这些目标上去。

• 动态注册第三方服务

相对于静态注册，通常我们的服务还可能是一个动态的通信地址，因此我们支持基于第三方服务注册中心(etcd、zookeeper、consul)或 Rainbond 提供的 API，让用户能够动态的更改服务的通信地址。这一类我们称为动态注册第三方服务。

工作原理

第三方服务在 Rainbond 创建完成后，Rainbond 应用运行时服务将自动开始维护服务的 Endpoints, 通过上述两种方式 Rainbond 获取到服务的通信地址列表后，将会为每个服务创建一个模型来存储服务的 Endpoints 信息。此模型工作后将根据用户配置的健康检查策略来对服务进行健康检查，从而呈现服务 Endpoints 的健康状态。

• 健康检查

健康检查的方式分为 TCP 检查和 HTTP 检查，分别对应不同的服务类型。若实例处于不健康状态将会有两种处理方式：下线或不处理，当前默认设置为不处理，当用户设置为下线时，实例处于不健康将从集群中下线，从而网关或其他服务将不会访问到不健康的实例。

• Rainbond 的服务访问安全控制

Rainbond 服务通过设置端口的对内、对外开启属性来进行内部服务注册，这其实也类似于防火墙的概念。参考文档 ，对于第三方服务一样，通过设置端口的对内、对外开启属性来管控当前服务是否向网关或其他服务开启访问权限。

• 第三方服务端口设置

与内置服务一样，第三方服务也需要设置端口，不同的是第三方服务更加灵活。当前版本中我们规定第三方服务只能添加一个端口，那么这个端口与服务实际监听的端口有什么关系呢？

通常情况下我们推荐设置端口与监听端口一致，便于理解。用户添加服务 Endpoints 时只需要提供服务的 IP 地址，服务多个实例就填写多个 IP 地址。对于这些服务我们默认为监听端口一致，因此 Rainbond 在与这些服务通信时将采用 Endpoint 定义的 IP 和服务定义的端口组成通信地址。

• 对接服务网关

第三方服务配置完端口后，开启对外服务对于 HTTP 类型即会与内置服务一样生成默认访问域名，应用网关接收到服务请求后将负载均衡到服务的 Endpoints 端点。此原理与内置服务一致。

• 其他服务访问

与内置服务一样，其他服务需要访问第三方服务时需要依赖第三方服务，此时 Rainbond ServiceMesh 机制将会工作，根据用户配置的服务端口在访问端服务网络空间内建立本地监听，对服务的 Endpoints 进行负载均衡和其他服务治理。