两年前Service Mesh（服务网格）一进去就受到追捧，很多人认为它是微服务架构的最终状态，因为它能够让业务代码和微服务架构解耦，也就是说业务代码不须要批改就能实现微服务架构，但解耦还不够彻底，应用还是不不便，尽管架构解耦了，但部署还没有解耦。
- 无奈依据不同环境或客户须要抉择适合的Service Mesh框架。
- 无奈做到在开发环境不必学习和应用Service Mesh，生产环境按需开启。
插件式 Service Mesh架构实现思路
目前成熟的ServiceMesh框架也有许多，然而对于用户而言。并不存在万能的ServiceMesh框架，能够解决各种场景的问题。因而咱们心愿对于用户而言，他只须要关怀本人的业务代码。而利用的治理能力，则能够通过不同的ServiceMesh框架进行拓展。用户的业务代码与ServiceMesh框架齐全解耦。如下图所示。用户能够随时替换某个利用所应用的ServiceMesh架构。抉择与业务最匹配的解决方案。
基于以上思路，咱们能够将istio、linkerd、dapr等微服务架构做成插件，开发过程中齐全不须要晓得Service Mesh框架的存在，只须要解决好业务的依赖关系，当交付到生产环境或客户环境，有些须要性能高、有些须要性能全、有些客户曾经指定等各种差异化需要，依据环境和客户须要按需开启不同类型的插件即可，当Service Mesh框架有问题，随时切换。这样Service Mesh框架就变成赋能的工具，老的业务零碎重新部署马上就能开启服务治理能力。
Rainbond就是基于上述思路实现的，以后版本曾经实现了三个服务治理插件。
- kubernetes 原生Service 模式
- 基于envoy的Service Mesh模式
- Istio服务治理模式
前面咱们具体解说Istio服务治理模式的应用过程。
应用Istio治理模式的实际
有了以上概念，咱们能够来看看Rainbond如何与Istio联合。在Rainbond中，用户能够对不同的利用设置不同的治理模式，即用户能够通过切换利用的治理模式，来按需治理利用。这样带来的益处便是用户能够不被某一个ServiceMesh框架所绑定，且能够疾速试错，能疾速找到最适宜以后业务的ServiceMesh框架。
装置Istio 管制面（control plane）
首先在切换到Istio治理模式时，如果未装置Istio的管制面，则会提醒须要装置对应的管制面。因而咱们须要装置Istio的管制面，管制面在一个集群中只需装置一次，它提供了对立的治理入口，用来管理工作在Istio治理模式下的服务。实现配置下发等性能。联合Rainbond现有的helm装置形式，咱们能够便捷的装置好对应的组件。
1. 创立团队
在5.5.0版本中，咱们反对了用户在创立团队时指定命名空间。因为默认helm装置的命名空间为 istio-system ，所以为了缩小用户配置。咱们首先须要创立出对应的团队。如下图所示。团队英文名对应的则是该团队在集群中的命名空间。此处填写 istio-system 。
2. 对接商店
Rainbond反对基于helm间接部署利用，所以接下来对接Rainbond官网helm仓库，后续基于Helm商店部署Istio即可， 在利用市场页面，点击增加商店，抉择helm商店，输出相干信息即可实现对接。
商店地址：https://openchart.goodrain.co...
3. 装置 Istio 管制面
商店创立实现后，即可看到对应的 helm 利用，目前Rainbond提供了 istio 1.11.4 版本的helm包，依据 Istio官网文档，该版本对Kubernetes集群的版本反对为 1.19, 1.20, 1.21, 1.22。
装置 base 利用
抉择helm商店中的base利用进行部署，团队抉择之前创立的命名空间为 istio-system 的团队。该利用包次要部署了Istio相干的集群资源和 CRD 资源。
装置 istio-discovery 利用**
同上述base利用一样，抉择正确的团队。装置 istio-discovery 利用。有了这两个利用，就能够领有 Istio 根底的治理能力了。
示例利用开启Istio治理模式
1. 切换治理模式
咱们以SpringBoot后盾管理系统 若依 为例，如下图所示，用户能够先从开源利用商店装置一个 若依SpringBoot 利用，版本抉择3.6.0，点击治理模式切换，抉择Istio治理模式。
在点击切换为Istio治理模式后，会须要用户手动设置外部域名，此处的外部域名将会是该组件在Kubernetes集群中的service名称，在同一个团队下惟一。这里咱们批改为可读性较高的外部域名。
2. 批改配置文件
在这一步实现后，咱们还须要进入 ruoyi-ui 挂载一个新的配置文件。这次要是因为默认状况下，ruoyi-ui 的配置文件 web.conf 中后端服务地址为 127.0.0.1，在之前应用 Rainbond 内置 ServiceMesh 模式时，因为 Rainbond 会获取到后端服务的地址，注入到 ruoyi-ui 外部, 赋予 ruoyi-ui 一个本地拜访地址（127.0.0.1）拜访后端服务。所以无需批改就能应用。
但应用 Istio 治理模式时，组件间通过外部域名进行通信，因而须要通过挂载配置文件的形式批改对应的代理地址，ruoyi-ui 的配置文件能够通过右上方的 Web终端 拜访到容器中，复制 /app/nginx/conf.d/web.conf 这个文件的内容。批改代理地址后保留，如下图所示。之前咱们设置了控制台的外部域名为 ruoyi-admin，所以这里替换为 ruoyi-admin。
3. 重启利用
在实现以上两步后，咱们须要重启整个利用。在启动利用后，进入组件页面查看，应该能够看到每个组件都有一个相似的 Sidecar 容器，这就是Istio的数据面 (data plane)，在利用切换为Istio治理模式当前，该利用下的所有组件都会主动注入对应的 Sidecar 容器，不须要用户额定设置。
至此，该利用已纳入Istio治理范畴。用户如果须要对该利用有更多的配置，则能够参考 Istio官网文档 进行扩大。
通过Kiali监控和治理Istio
在之前的步骤中，咱们应用 Istio 治理模式纳管了 若依 。接下来则带大家一起看看如何应用 Kiali 观测利用间的通信链路。在这一步中，用户须要有 kubectl 命令。
1. 装置 prometheus
在Istio中，各个组件通过裸露HTTP接口的形式让Prometheus定时抓取数据（采纳了Exporters的形式）。所以Istio管制立体装置实现后，须要在istio-system的命名空间中部署Prometheus，将Istio组件的各相干指标的数据源默认配置在Prometheus中。
同上述base利用一样，抉择正确的团队，装置 Prometheus利用。
2. 装置kiali
kiali提供可视化界面监控和治理Istio，可能展现服务拓扑关系，进行服务配置。
装置 kiali-operator 利用，同上述base利用一样，抉择正确的团队。
装置过程将主动创立Service，通过Rainbond平台第三方组件的模式可将 kiali 的拜访端口裸露进去。如下图所示：
在端口界面增加拜访端口，增加当前关上对外服务应用生成的网关策略即可进行拜访。
kiali登录时须要身份认证token，应用以下命令获取token：
kubectl describe secret $(kubectl get secret -n istio-system | grep istiod-token |awk '{print $1}') -n istio-system拜访到kiali当前，在Applications一栏，选中利用所在的命名空间，就能够看到咱们刚刚创立的利用。点击进入，能够看到如下的流量路线。
在 Graph 一栏，也能够看到对应的利用内的流量申请。更多的配置及相干性能参考 Kiali官网文档
总结
本文简略介绍了在Rainbond中应用Istio治理模式的操作。以及Rainbond与Istio治理模式的联合。Rainbond为用户提供了一个可选的插件体系，使用户能够依据本人的需要抉择不同的Service Mesh框架。在与Istio的联合上，咱们次要为用户实现了指定利用数据立体的注入。用户也能够通过该机制扩大本人所需的ServiceMesh框架。后续文章咱们将具体解说如何制作插件，尽请关注。
Rainbond是一个开源的云原生利用治理平台，应用简略，不须要懂容器和Kubernetes，反对治理多个Kubernetes集群，提供企业级利用的全生命周期治理，性能包含利用开发环境、利用市场、微服务架构、利用继续交付、利用运维、利用级多云治理等。
Github：https://github.com/goodrain/r...
官网：https://www.rainbond.com?chan...
微信群：请搜寻增加群助手微信号 wylhzmyj
钉钉群：请搜寻群号 31096419