每种架构风格,都会因各公司面临的情况不同而有不同的实现路线,Service Mesh也不例外,比如江南白衣描述的唯品会的服务化体系开放服务平台OSP(Open Service Platform)走的ServiceMesh之路就与流行的Istio不同。但它们要解决的核心问题是相似的,比如服务的注册发现、路由、熔断等如何实现,如何高效的传输与序列化、代理,甚至包括如何更方便的对原有的系统升级改造等。


一、标准服务化体系阶段

如果用两根手指将Local Proxy 和 Remote Proxy的框框按住,就是个标准的服务化框架。

传输与序列化层

当时还没有GRPC,自己拿Netty撸了一个TCP长连接,多路复用,异步IO的传输层,基于Thrift协议的序列化。

当然,这个组合从性能上现在看也不过时,自定义TCP不比HTTP2弱, Thrift 也比ProtocolBuffer略快,我们还支持基于Java类来定义Thrift接口,而不是原生Thrift,PB的有额外学习成本的中立语言,完美。

缺点嘛,就是跨语言时会略尴尬,虽然原生的Thrift也在某种程度上跨语言,但我们除了保留Thrift序列化协议外,其他从头到脚都重新实现了,也就不再能从它那借力。

服务注册中心

当时的大环境下,ZooKeeper也是比较流行的注册中心选择,不过最近在做去ZK化,改为自研的Http Api Server,数据用Redis或 Etcd存储。

API网关

当然要有入口网关,将外网的HTTP请求,经过认证,安全防刷, 再转换为OSP调用后端服务。

服务路由

服务的注册发现,负载均衡,路由定制,机房策略等路由策略,超时,重试,熔断等可用性策略,我们统称为路由逻辑。

我司的主力语言,前端是PHP 和 Java,后端是Java,在调用端有着硬性的跨语言需求。

SM第一步

上述的路由逻辑,如果在每种语言实现一次客户端,显然是不合算的。为了PHP,将这些逻辑抽取成独立的Proxy。

SM第二步

这个独立的Proxy,是部署成传统的集中式的Proxy集群,还是当时还不很著名的本地SideCar模式呢?

在公司的体量下,有着强烈的去中心化的愿望,所以我们选了SideCar模式。

SM第三步

PHP使用了Proxy,那Java呢,继续像dubbo一样在客户端里可以吗?

这个当时有比较大的争议,因为毕竟多经过了一层节点,虽然本地连接不经过网络,也很难说性能毫无影响。 为此我们还专门做了个基于Unix Domain Socket的版本,但后来觉得性能足够,一直没上线。

最后,老板力排众议,一是为了架构统一性,二是因为我们的Proxy功能还不成熟,而使用它的应用又特别多,如果不独立出来,很难推动快速升级。所以统一使用了Proxy模式。

SM第四步

SideCar模式虽好,但是存在单点的问题,如果SideCar在升级,或者挂掉了怎么办?

SideCar升级,可以联动同一台机上的应用先摘除流量。
SideCar挂掉,可以搞个脚本把它自动重新拉起。但重新拉起的间隔里还是会丢失的请求,如果重新拉起还是失败呢?

作为一个架构师,高可用的观念是深入到骨子里的,所以我们又在每个机房搭建了一个Remote Proxy集群,并在客户端里的SDK加入了如下的逻辑:

“如果本地Proxy不可用或宣称自己准备关闭,就将请求无损转发到Remote Proxy,再启动一个监视器观察本地Proxy什么时候重新可用。”

至此,一个封闭的服务化框架完备了,我们有了标准的服务化体系。能力上,也比当时久不更新的Dubbo,还有后来的Netflix,SpringCloud要强不少。

二,按不住的多语言的客户端接入

时间匆匆过, 一个公司里,总是按不住会有更多的语言出现,比如Node.js, C++, Go,像前面说的,再撸一次TCP/Thrift 感觉有点累了,这些也不是主流语言,花太多时间在上面不值得。 所以,我们在Proxy上额外支持了HTTP/JSON的传输层,再根据注册中心里的元数据,重新序列化成Thrift来调用后端服务就好了。

我们还发现,在PHP里用Thrift,还不如它内置的C写的HTTP/JSON库快。

不过,我们也不想在这些客户端再实现一次本地SideCar与Remote Proxy的切换逻辑了,反正这些非主流语言的客户端的调用量不会很大,就通通去调用Remote Proxy集群好了。哪天撑不住时,可能会改用前面说的不那么完美的方案。

至此,多语言的客户端完全咩有接入限制了。

三, 普通Web应用也想零成本变身服务化

时间又匆匆过,又有大量原来的Web应用,不想改造成OSP应用,又想作为一个服务,或者接入API网关,或者加入服务化大家庭,享受各种服务治理的能力。

为此,我们开发了一个很轻量的注册器,也是以sidecar的形式运行,不断的对Web应用的做健康检查,与注册中心进行注册,心跳,和反注册。

当然,免费的午餐肯定没那么好吃,比如没有了基于IDL生成SDK的与客户端的契约化编程,没有了高效的传输层序列化层,没有了限流,自动隔离线程池,ClassLoader预热,闲时主动GC等等细微的Runtime加强。

至此,多语言的服务端也完全咩有问题了。

四、容器化了,容器化了

为了容器化,sidecar跑在哪里,又成了问题。 如果跑在每一个Pod里,一来呢,身为Java应用,堆内堆外内存吃得有点多;二来呢,升级Proxy时,又要重新发布每一个应用;

所以,我们选择了DaemonSet的形式,每台宿主机上只运行一个Proxy,Proxy启动时把自己的IP写在一个共享文件里,这个文件也Mount进各个容器里面,各个客户端会监听这个文件。

为了隔离性,Proxy加了个来源IP的限流,效果就是单个容器的调用高于2万QPS时,第二万零一个请求开始就把它临时重定向到Remote Proxy集群。 十秒钟后再重试本地Proxy,如果还是高,又继续打发过去。

另一个改动,我们之前基于IP来定义路由规则( 比如把一些消耗较大的接口,都发送到隔离的三台机器上)。容器里IP不固定了怎么办?

我们引入了一个部署池的概念,比如一个应用有两个部署池,一个3台机器,另一个20台机器,这个部署池的名字,会注册为服务实例的元信息。在服务路由里就用这个池的名字来定义规则。

Istio 的区别

1. Server端无入口Agent

Server端前面也摆一个Agent,全部流量都流经它,有点重啊。当初在Client前摆一个Agent都争半天了,真的要再来一个?

如果已经是OSP应用,当然没必要摆这个Agent了。如果是一个希望零成本变身的Web应用,那我们回顾一下服务端要做的事情:

一是服务注册和心跳。 我们在应用旁边摆了个轻量级的注册与心跳器来实现。

二是分布式调用链记录。分布式调用链监控原本就支持Web应用呀,不需要额外的Agent。

三是服务端授权,服务端限流之类必须在服务端进行的服务治理,相对没那么重要与常用,真的需要要时同样以Servlet WebFilter 或多语言SDK包方式提供。

所以,这个偏重的Agent暂时没有太大必要。

2. Client端不基于IPTable劫持

为了客户端零改造成本,Istio里基于IPTable,将Client发出的所有请求劫持到Proxy上。但IPTable的性能一般,尤其是一个环境里有很多应用时,性能更加跌得很厉害。所以我们就不节约客户端的一点点改造成本了。

基于SDK的访问,支持Local Proxy与Remote Proxy的完美切换,比IPTable更加的高可用。而如果某种语不想写这种复杂SDK,那要么全部打到本地Proxy(等于IPTable),要么全部直接访问 Remote Proxy集群。

3. 没有画大饼用的Mixer

为了Proxy实现的可替换性,Istio里将与基础设施相关的部分都提取到中央的Mixer里,连分布式调用链跟踪都分离出来太那啥了,每个请求发生前发生后都可能要调用一下这个Mixer,一个是性能,一个是中央化的容量瓶颈。

虽然理解Google架构师们为了画大饼的无奈,但自用体系,不需要考虑Proxy的可替换性时,还是把该下沉到Proxy的基础设施埋点给下沉下去。

4. SideCar以DaemonSet形式运行

因为是Java,堆内堆外要3G左右,所以每台宿主机只运行一个Proxy。 当然也为了升级Proxy方便,不用每次升级Proxy将全部应用的容器重新发布一遍。

5. 不依赖K8S和容器技术

这么一路走来,当然不会依赖于K8S。目前Istio们为了节约开发精力而完全依赖K8S,其实也大大局限了它们的适用范围,起码一个公司里如果混合物理机与容器双向调用的就难搞了。

6. 路由和路由是不一样的,熔断和熔断是不一样的

一个词能涵盖完全不同级别的实现。大家都说路由,但我觉得比如Dubbo,比如OSP,才算是真正的规则路由。

其他负载均衡,熔断,重试等等,都一个名字也可以做得差别极大。

http://calvin1978.blogcn.com/?p=1779

唯品会的Service Mesh三年进化史的更多相关文章

  1. 唯品会的Service Mesh三年进化史 2018 年 Service Mesh 元年,被誉为是下一代微服务架构

    2018 年 Service Mesh 元年,被誉为是下一代微服务架构 https://www.sohu.com/a/225324586_465914 唯品会的Service Mesh三年进化史 - ...

  2. Qcon2017实录|Service Mesh:下一代微服务

    https://zhuanlan.zhihu.com/p/30292372 数人云11月Meetup报名开启,看中西方大神如何论道云原生与微服务!本文作者敖小剑老师将在本次Meetup上继续分享Ser ...

  3. Service Mesh服务网格新生代--Istio(转)

    万字解读:Service Mesh服务网格新生代--Istio  官网地址:https://preliminary.istio.io/zh/docs/concepts/security/ Servic ...

  4. 什么是 Service Mesh

    作者|敖小剑 微服务方兴未艾如火如荼之际,在 spring cloud 等经典框架之外,Service Mesh 技术正在悄然兴起.到底什么是 Service Mesh,它的出现能带来什么,又能改变什 ...

  5. 微服务架构基础之Service Mesh

    ServiceMesh(服务网格) 概念在社区里头非常火,有人提出 2018 年是 ServiceMesh 年,还有人提出 ServiceMesh 是下一代的微服务架构基础. 那么到底什么是 Serv ...

  6. 五分钟了解 Service Mesh

      1 背景   1.1 多语言   微服务理念是提倡不同业务使用最适合它的语言开发,现实情况也确实如此,尤其是AI的兴起,一般大型互联网公司存在 C/C++.Java.Golang.PHP.Pyth ...

  7. 【转帖】赤壁之战,曹操大败只因缺了Service Mesh

    赤壁之战,曹操大败只因缺了Service Mesh 本文作者把微服务向 Service Mesh 的进化融入到了三国故事中,妙趣横生.故事比较长,大家慢慢看,精彩的在后边. http://develo ...

  8. 解读2017之Service Mesh:群雄逐鹿烽烟起

    https://mp.weixin.qq.com/s/ur3PmLZ6VjP5L5FatIYYmg 在过去的2016年和2017年,微服务技术得以迅猛普及,和容器技术一起成为这两年中最吸引眼球的技术热 ...

  9. 深入解读Service Mesh的数据面Envoy

    在前面的一篇文章中,详细解读了Service Mesh中的技术细节,深入解读Service Mesh背后的技术细节. 但是对于数据面的关键组件Envoy没有详细解读,这篇文章补上. 一.Envoy的工 ...

随机推荐

  1. 裸眼 3D 技术是什么原理?

    https://www.zhihu.com/question/19553745 作者:杨英东链接:https://www.zhihu.com/question/19553745/answer/1227 ...

  2. 20145122 《Java程序设计》第4周学习总结

    教材学习内容总结 第六章 1.在java中,子类只能继承一个父类. 2.在java中,继承时使用extends关键字,private成员也会被继承. 3.检查多态语法逻辑是否正确,方式是从=号右边往左 ...

  3. 20145325张梓靖 实验四 "Andoid开发基础"

    20145325张梓靖 实验四 "Andoid开发基础" 实验内容 使用 Android Studio 设计"Hello" 设计过程 创建项目 选择.xml中的 ...

  4. luogu P1025 数的划分

    https://www.luogu.org/problem/show?pid=1025 n的k划分 且不出现划分成0的情况  可以 分为两种情况 所有划分的数 都大于1的情况 至少划分的数里面有1的情 ...

  5. shell 判断文件是否是可执行文件

    测试变量指定的文件是否存在且是可执行文件.如果存在且是可执行文件,则执行该文件,否则通过chmod命令赋予该文件可执行权限. //test.sh #!/bin/bash echo "ente ...

  6. HashMap put方法

    HashMap的put方法执行过程可以通过下图来理解,自己有兴趣可以去对比源码更清楚地研究学习. ①.判断键值对数组table[i]是否为空或为null,否则执行resize()进行扩容: ②.根据键 ...

  7. [翻译]PyMongo官方文档

    PyMongo官方文档翻译 周煦辰 2016-06-30 这是本人翻译的PyMongo官方文档.现在网上分(抄)享(袭)的PyMongo博客文章很多,一方面这些文章本就是抄袭的,谈不上什么格式美观,另 ...

  8. numpy.zeros(np.zeros)使用方法--python学习笔记31

    https://blog.csdn.net/qq_26948675/article/details/54318917

  9. snmpwalk-MIB of S5700-idc-stack

    IF-MIB:.iso.org.dod.internet.mgmt.mib-2.interfaces.ifTable.ifEntry.ifDescrOID:.1.3.6.1.2.1.2.2.1.2 针 ...

  10. Howto: 在ArcGIS10中将地图文档(mxd文档)批量保存到之前版本

     Howto: 在ArcGIS10中将地图文档(mxd文档)批量保存到之前版本 文章编号 : 38783 软件: ArcGIS - ArcEditor 10 ArcGIS - ArcInfo 10 A ...