本系列为网上收集转载分布式相关知识点系列文章,并非原创。如果侵权,请联系我删除!!!

服务网格(ServiceMesh)这两年异常之火,号称是下一代微服务架构,互联网公司经常使用的是微服务分层架构。但是网上真正讲清楚这玩意儿是咋回事的文章非常少。

随着数据量不断增大,吞吐量不断增加,业务越来越复杂,服务的个数会越来越多,分层会越来越细,除了数据服务层,还会衍生出业务服务层,前后端分离等各种层次结构。不断发现主要矛盾,抽离主要矛盾,解决主要矛盾,架构自然演进了,微服务架构,潜在的主要矛盾会是什么呢?

引入微服务架构,一般会引入一个RPC框架,来完成整个RPC的调用过程。

               分布式系统知识点十五:到底servermesh是咋样的,解决啥问题(转载)

如上图粉色部分所示,RPC分为:

  • RPC-client,它嵌在调用方进程里

  • RPC-server,是服务进程的基础

不只是微服务,MQ也是类似的架构:

                分布式系统知识点十五:到底servermesh是咋样的,解决啥问题(转载)

如上图粉色部分所示,MQ分为:

  • MQ-send-client

  • MQ-server

  • MQ-recv-client

框架只是第一步,越来越多和RPC,和微服务相关的功能,会被加入进来。

例如:负载均衡

              分布式系统知识点十五:到底servermesh是咋样的,解决啥问题(转载)

如果要扩展多种负载均衡方案,例如:

  • 轮询

  • 随机

  • 取模

  • 一致性哈希

RPC-client需要进行升级。

例如:数据收集

              分布式系统知识点十五:到底servermesh是咋样的,解决啥问题(转载)

如果要对RPC接口处理时间进行收集,来实施统一监控与告警,也需要对RPC-client进行升级。

画外音,处理时间分为:

  • 客户端视角处理时间

  • 服务端视角处理时间

如果要收集后者,RPC-server也要修改与上报。

又例如:服务发现

               分布式系统知识点十五:到底servermesh是咋样的,解决啥问题(转载)

服务新增一个实例,通知配置中心,配置中心通知已注册的RPC-client,将流量打到新启动的服务实例上去,迅猛完成扩容。

再例如:调用链跟踪

               分布式系统知识点十五:到底servermesh是咋样的,解决啥问题(转载)

如果要做全链路调用链跟踪,RPC-client和RPC-server都需要进行升级。

下面这些功能:

  • 负载均衡

  • 数据收集

  • 服务发现

  • 调用链跟踪

其实都不是业务功能,所以互联网公司一般会有一个类似于“架构部”的技术部门去研发和升级相关功能,而业务线的技术部门直接使用相关框架、工具与平台,享受各种“黑科技”带来的便利。

完美!!!

理想很丰满,现实却很骨感,由于:

  • RPC-client,它嵌在调用方进程里

  • RPC-server,是服务进程的基础

往往会面临以下一些问题:

  • 业务技术团队,仍需要花时间去学习、使用基础框架与各类工具,而不是全心全意将精力花在业务和产品上

  • client要维护m个版本, server要维护n个版本,兼容性要测试m*n个版本

  • 如果要支持不同语言,往往要开发C-client,Python-client,go-client,Java-client多语言版本

  • 每次“黑科技”的升级,都需要推动上下游进行升级,这个周期往往是以季度、半年、又甚至更久,整体效率极低

这些耦合,这些通用的痛点,有没有办法解决呢?

一个思路是,将服务拆分成两个进程,解耦。

              分布式系统知识点十五:到底servermesh是咋样的,解决啥问题(转载)

  • 一个进程实现业务逻辑(不管是调用方,还是服务提供方),biz,即上图白色方块

  • 一个进程实现底层技术体系,proxy,即上图蓝色方块

画外音:负载均衡、监控告警、服务发现与治理、调用链…等诸多基础设施,都放到这一层实现。

  • biz和proxy共同诞生,共同消亡,互为本地部署,即上图虚线方框

  • biz和proxy之间,为本地通讯,即上图黑色箭头

  • 所有biz之间的通讯,都通过proxy之间完成,proxy之间才存在远端连接,即上图红色箭头

这样就实现了“业务的归业务,技术的归技术”,实现了充分解耦,如果所有节点都实现了解耦,整个架构会演变为:

             分布式系统知识点十五:到底servermesh是咋样的,解决啥问题(转载)

  • 绿色为biz

  • 蓝色为proxy

整个服务集群变成了网格状,这就是Service Mesh服务网格的由来。

架构演进,永无穷尽,痛点多了,自然要分层解耦。希望大家有收获,后续再细聊SM的设计与架构细节。

 

转载自。https://www.cnblogs.com/rinack/p/10754100.html

 

 

上面部分是转载的网友文字。相信有上面内容对server mesh到底是怎么玩的心里有个比较清的了解了

下面是我通过各种沟通了解到的已在用的servermesh实现的关键细节:

biz和proxy是怎么通信的呢,最佳方式是:两个进程走回环网卡。这样效率最高

另外 proxy和biz底层,应该把 网络io,数据队列框架都做好,业务此时只需要接个回调,收到消息处理即可,最简单也最高效。

 

另外,server mesh应该跟docker高度绑定,高度定制化(推荐用k8s),这样框架管理和部署,啥IO,磁盘,内存,CPU这些的负载均衡可以完美的动态调整,性能可以达到最佳,可维护性最好。

 

分类:

技术点:

相关文章: