第三方服务定义

第三方服务定义

运行于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的服务抽象定义，提出了支持第三方服务集成管理的新思路。

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

对比项	内置服务	第三方服务
对接应用网关	支持	支持
被其他服务依赖	支持	支持
ServiceMesh治理	支持	支持上游通信治理
服务属性	全部属性	支持端口、连接信息、健康检查、权限 支持静态或动态添加Endpoint
服务生命周期管理	全部支持	仅支持健康检查
分享应用市场	支持	V5.2版本支持
备份、恢复	支持	V5.2版本支持