第三方服务定义

运行于 Rainbond 集群之外，运行生命周期不受 Rainbond 管理，且在网络上能够与 Rainbond 集群通信的服务称为第三方服务。例如单独运行的 Oracle 服务，或运行于 Windows 服务器的.net 服务等。

Rainbond 支持第三方服务管理的初衷

Rainbond 作为一款云应用操作系统开源产品，在众多的企业中落地使用的过程中出现了两类共同的问题：

• 循序渐进的迁移策略，已经上 Rainbond 的服务如何与遗留服务通信和统一管理。

​ Rainbond 以应用为核心，应用的关键是服务，Rainbond 提供了一套成体系的服务注册和发现机制来维护服务之间的配置共享和通信。但是过去的版本中对于未迁移到 Rainbond 的服务却鞭长莫及。用户不管是在传统应用架构向微服务架构转化过程，还是从传统运维向 Rainbond 迁移的过程，我们都非常推荐用户循序渐进的进行。那么在这个过程必然出现集群内外服务共存的现象，举个例子：我有一个传统服务化架构，都使用同一个 Oracle 数据库，Oracle 数据库运行于一台特定的服务器中，第一阶段我们不改变它。首先将部分服务迁移到了 Rainbond 平台，这些服务即需要访问 Oracle 服务，还需要访问其他未迁移的服务。在 Rainbond 中我们推荐使用环境变量的方式定义配置，过去我们就需要重复的为每个服务定义相同的变量信息，如果后期有变化，又得全部重新改一遍。另外，服务需要访问其他服务，过去只能直接定义服务的 IP 地址，无法使用 Rainbond 提供的服务通信治理功能。再者在 Rainbond 平台可以可视化的观察服务拓扑关系和通信状态，然而对于处于集群外的服务无法在 Rainbond 中统一管理。

• Rainbond 应用网关很好用，但是遗留的服务没办法与 Rainbond 上的服务共享外网端口或域名。

​ Rainbond 提供了让应用和服务向外网提供服务的能力，越来越多的用户希望 Rainbond 应用网关可以直接面向外网，即外网 IP 绑定到 Rainbond 网关节点，服务网关占用了 80 和 443 端口。但是这里马上就带来了问题，企业中可能还存在其他的服务需要被同一个域名访问到，因此过去我们没有办法，只能在 Rainbond 网关的前面继续添加一层 nginx 服务，这样带来的就是配置的巨大复杂性。同时未迁移到 Rainbond 的服务也没办法使用 Rainbond 网关提供的众多开箱即用的功能，比如域名访问监控。

根据上述的用户诉求，我们根据 Rainbond 的服务抽象定义，提出了支持第三方服务集成管理的新思路。

第三方服务与内置服务的区别