Service Mesh 治理模式

    • 内置 ServiceMesh 模式（默认）

    内置ServiceMesh模式需要用户显示的配置组件间的依赖关系，平台会在下游组件中自动注入 sidecar 容器组成 ServiceMesh 微服务架构，业务间通信地址统一为localhost（127.0.0.1）模式。作为 Rainbond 中默认的应用治理模式，通过 sidecar 实现了服务组件间 A/B 测试、智能路由、限流、熔断等治理功能。了解更多请参考 、 基于 Rainbond 实现组件A/B测试

    • Kubernetes 原生 Service 模式

    该模式组件间使用 Kubernetes Service 名称域名进行通信，用户需要配置每个组件端口注册的 Service 名称，治理能力有限。

    • Istio 治理模式

    Rainbond 将 Istio 作为插件方式引入 Rainbond 应用治理模式体系，组件间的治理均由 Istio 提供。

    对于用户而言，切换到不同的应用治理模式，最需要注意的，是组件之间相互访问方式的变化。新增的 Kubernetes 原生 Service 模式，意味着用户可以使用原生 Kubernetes 中的 Service name 的方式访问对应的服务组件了。

    如果从内置 ServiceMesh 模式切换到 Kubernetes 原生 Service 模式，那么需要用户定义当前应用下，所有开启对内服务的端口的 内部域名。

    定义内部域名

    内部域名 即作为该端口全局可解析访问的地址。

    如果你不了解何为通信变量，请先阅读 通信变量注入。

    对比于默认的内置 ServiceMesh 模式，Kubernetes 原生 Service 模式中依然存在通信变量。不一样的是，通信变量的值，不再是固定为 127.0.0.1 这一本地回环地址，而是变为了上文提及的内部域名。这一改动，是为了方便使用通信变量来确定依赖关系的用户，在不改动配置的情况下，依然可以正常的使用通信变量完成组件间的调用。

    即使 Kubernetes 原生 Service 模式不再需要依赖关系提供 sidecar 插件来实现组件之间的通信，但是依赖关系依然有其存在的价值。

    • 依赖关系呈现的应用拓扑图非常直观好看。