内容概要
本文主要分析 WeiboMesh 在运行阶段请求路由的实现,对比现有的通用 Service Mesh (比如 Istio )在这方面的不同。
前面我们对 WeiboMesh 的演化、实现以及 Service Mesh 规范等做了简要分析和解读,希望能帮助你基于 WeiboMesh 更好地理解 Service Mesh 的架构理念。
这里我们从实践的角度来体会下当前最受关注的 Service Mesh 实现 Istio 和 WeiboMesh 在服务调用和请求路由方面的一些异同,希望对你入坑 Service Mesh 有所帮助。
WeiboMesh 源自于 Weibo 内部对异构体系服务化的强烈需求以及对历史沉淀的取舍权衡,它没有把历史作为包袱而是巧妙地结合自身实际情况完成了对 Service Mesh 规范的实现,与同时期的其他 Service Mesh 实现相较而言,WeiboMesh 以最接地气的 Service Mesh 实现著称并不无道理。
如果你的团队拖着繁重的技术债务,又想尝试 Service Mesh 理念带来的诸多好处,那 WeiboMesh 应该能为你带来些许灵感。下面就让我们一起来体验一下。
WeiboMesh 的服务注册与发现
由微博开源 Motan RPC 框架演化而来的 WeiboMesh 服务注册与发现功能扩展自 Motan 相关功能,机制和用法基本不变,流程同样是服务启动的时候将自己的分组、服务名称、版本等等注册到注册中心。
稍微有点区别的可能在于扩展了具体执行注册和发现操作的角色,WeiboMesh 的服务由 Server Agent 完成注册,而通过 Client Agent 完成对依赖服务的订阅与发现。Mesh 层接管了服务进出的流量,那请求又是如何在 WeiboMesh 中流转的呢?
请求在 WeiboMesh 中的流转
作为服务提供方,HTTP 服务一侧的 Server Agent 将 HTTP 接口导出为 WeiboMesh 集群中的 HelloWorldService,并将其注册到 zookeeper,而依赖此服务的 Test 业务一侧的 Client Agent 订阅了这个 HelloWorldService 服务作为自己的一个 referer,并将服务的节点实时发现回来,Test 业务只需要对本地的 Client Agent 发起调用即可完成对 HelloWorldService 的依赖,而由 Client Agent 与对端的 Server Agent 发起点对点通信,下面我们通过抓包来演示请求的流转。
图中 z2.shared 为 Test 业务部署的节点,而所依赖的 HTTP 服务 http://10.211.55.3:9900/http_server 部署于 z.shared 节点,可以看出 Test 直接请求本机的 9981 Mesh 端口(Client Agent),Client Agent 又对远端的 Mesh 端口(Server Agent:9990)发起直连调用。 下面是将 HTTP 服务导出为 Motan RPC 服务,并暴露到 WeiboMesh 集群 的相关 Server Agent 配置,可以看到其将 HTTP 接口导出为 motan2 协议 的 Motan RPC 服务,并在 9990 端口提供服务。
http-mesh-example-helloworld:
path: com.weibo.motan.HelloWorldService
export: "motan2:9990"
provider: http
registry: "zk-registry" # registry id
HTTP_URL: http:
basicRefer: mesh-server-basicService
WeiboMesh 又是如何实现控制面板来对请求进行精细控制的呢?