标签：服务 Consul 网格 边车 OpenResty ServiceMesh 节点 客户端

之前的方案

《基于OpenResty与Consul实现服务网格ServiceMesh》 一文是2019年对服务网络架构的一个实践，里边有一些不完美的地方，比如每个服务节点上要装OpenResty + Consul client两个组件来做代理，OpenResty上要装微博开源的upsync插件来更新上游服务的upstream配置，且只能更新现有upstream的节点横向扩缩容，如果新增或者删除stream的话，需要使用远程的shell脚本执行来改OpenResty里的nginx.conf文件再执行reload操作。
2021年初笔者基于Ribbon + Spring Cloud Config，修改了Ribbon源码做自定义开发，做了一个客户端负载均衡组件：Ribbon向Config来获取服务列表，通过Pinger机制来对各个服务节点做健康检查，Config管理端修改了服务配置之后通过Spring Bus（kafka）来通知节点上的Config客户端库来重新获取配置。
做了这个项目之后，熟悉了负载均衡的玩法。后面笔者又做了OpenResty + Redis + RocketMQ的一个秒杀架构。又看了一些关于蚂蚁金服ServiceMesh架构的一些文章。又想起了自己曾经做了的这个ServiceMesh小Demo，决定重新优化一下架构。

新方案

下面说下新的优化思路：

• Consul分Server和Client端，Server端3节点高可用集群、客户端装在每个业务服务器节点上，共同组成了一个服务配置共享的网络。
• 去掉OpenResty，把代理程序缩到每个业务服务进程里边，以SpringBoot Starter作为一个Lib让每个业务应用引用，这个库作为Proxy。
• Consul client作为边车，Proxy负责为所在业务应用连接边车，从边车获取可用服务列表，然后直连调用服务端。

1、跟之前的边车不同，这次边车只负责给客户端提供服务列表，并没有负责转发客户端的请求。客户端与服务端是直连调用的。
2、客户端进程内的Proxy库，可以基于spring-cloud-starter-consul-discovery来做封装和定制化二次开发。

优缺点：

• 与原来的OpenResty + Consul的方案相比，业务应用里边要引入1个封装的依赖，然后服务调用使用封装过的带负载均衡功能的HttpClient工具。但是好处是服务调用是直连调用了，不需要像原来一样用OpenResty做中间代理了。也就绕开了前文提到的这块不完美的几个地方。
• 与Ribbon + Config的方案相比，业务应用引入封装Jar包、服务调用工具用新客户端类这点是一样的。搭建Config变为搭建Consul，前者之前使用的是JDBC模式存储服务节点信息，用Consul后更为方便。另外不需要搭建Kafka来做Spring Bus通知服务节点变化，Consul网络会通过Gossip协议扩散到各个服务节点里的边车中、客户端去边车定时查就可以了，相比原来架构简单了不少。（节点配置变化通知及时应该确实是原来的更及时，变化后立即通过kafka通知客户端，客户端收到通知立刻调用rest接口到Config查询。通过Consul的Gossip扩散到客户端旁边的Consul Client边车本身就会有一定的延迟，然后客户端又是定时轮询边车的。但考虑到延迟个最多10几秒应该可以接受）

标签：服务,Consul,网格,边车,OpenResty,ServiceMesh,节点,客户端
来源： https://www.cnblogs.com/lyhero11/p/15775426.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。