概述这篇文档,着重解决一个问题:Spring Cloud 融合于 Rainbond 原生 Service Mesh 的正确姿势是什么样子的。Rainbond 原生支持 Service Mesh 微服务架构。也就是说,无论原来是什么,只要部署在 Rainbond 上,那么就天然的成为了 Service Mesh 微服务。这也是 Service Mesh 微服务架构的一大特点:对原应用无侵入。Spring Cloud 部署在 Rainbond 上后,整套业务即是完整的 Spring Cloud 微服务,又是一套 Service Mesh 微服务。那么如何使业务系统即保留了原有 Spring Cloud 微服务架构的特点,又能享受到 Service Mesh 带来的种种好处呢?这就涉及到了Spring Cloud 微服务与 Service Mesh 的融合。融合的核心思想,就是 Spring Cloud 框架维护的功能,保持不变; Spring Cloud 框架无法维护的功能,交给 Service Mesh 和 Rainbond。Spring Cloud 不维护什么我不会去深入讨论 Spring Cloud 微服务框架都维护了什么,这样的帖子网上有很多。在这里,我想说明的是,当读者选择将自己原有的 Spring Cloud 微服务部署在 Rainbond 时,有哪些工作应该由 Rainbond 来完成。向 eureka 的注册eureka 注册中心,是 Spring Cloud 微服务框架中,标准的注册中心解决方案。微服务框架中的 Service provider(服务提供者) 将自己的服务地址注册于 eureka 中,供 Service consumer(服务消费者) 远程调用。这种服务注册与发现的机制,是微服务架构中为了将原来的一站式服务拆解为若干个独立的服务并相互解耦,却又能相互交互所设计的。基于这种机制,所有的 Spring Cloud 微服务组件,可以动态的获悉自己需要的 Service Provider 的服务地址;也可以摇身一变,将自己注册为 Service Provider 对其他组件提供服务。然而,就是这么一种灵活的服务注册/发现机制,却不会维护其它服务组件向 eureka 自身注册这一动作。向 eureka 注册的地址,往往是在配置文件里配置的,例如码云6K+星Spring Cloud项目 PIG后台管理框架 中,设定的 eureka 注册方式如下:https://gitee.com/log4j/pig/b…# 注册中心配置eureka: instance: prefer-ip-address: true client: service-url: defaultZone: http://pig:pig@pig-eureka:8761/eureka/
Spring Cloud 微服务与 Service Mesh 的融合
ℹ️ Info
Rainbond 中会将无法解析的域名,如 pig-eureka 解析为 127.0.0.1
ℹ️ Info
必须指出的是,在这个启动控制链条中,pig-gateway 指向 pig-auth 的依赖关系,其意义只作为启动顺序控制策略,不作为正常的依赖关系使用。
ℹ️ Info
上述配置适用于于测试场景以及调试场景。如果服务已经趋于稳定,并决定应用于生产环境,则建议自行设置合适的配置方案。