www.hj8828.com 6

蚂蚁金服缘何自行研制瑟维斯 Mesh?

“应用研发有时候无法很好的理解基础设施的东西,升级容易出现问题。基础设施团队有时候也无法很好地去了解应用研发。应用研发和基础设施团队耦合在一起发布、变更、升级,非常容易出现问题”,黄挺说。

我们从单体应用演进到了服务化的架构,从原来好几个团队维护同一个应用,到各个团队去维护各自领域的应用,团队之间通过接口去沟通,已经将各个业务团队之间做到了最大程度的解耦,但是对于基础设施团队来说,还是和每一个业务团队耦合在一起。

接着这个话题,鲁直讲了他对云计算的理解:“一方面云计算肯定要为整个业务的发展提供更加方便的基础资源,可以不用去关心底层的基础设施。Serverless字面的意思就是说‘无服务器’——我不用关心服务器怎么来的,不用关心基础设施,只要关心业务代码就可以了。那反过来对于云服务商来说,经过了这一层抽象,其资源利用率会更高,可以有更多的利润空间,这是一个双赢的局面。对于用户来讲,这种好处是实实在在的,可以更少关注基础设施,只关心代码就可以了。”

其二,解决遗留系统融入问题,让一些遗留系统更好的融入到云原生体系。

www.hj8828.com 1

Service Mesh 的部署模型,有两种情况:

那么,Service
Mesh到底是什么?自2016年被提出,为何不到两年就获得了如此高的人气?Service
Mesh又能为企业解决哪些问题?在近日召开的GIAC全球架构大会上,蚂蚁金服高级技术专家黄挺以蚂蚁金服的自身实践为例,深入解读了Service
Mesh。

首先,SOFA Mesh 其实直接采用了 Istio 的 Control Plane 的Pilot 和
Auth,因为我们觉得 Istio
在这块上没有太大的问题甚至里面也有一些非常不错的设计,比如Pilot 这部分的
Universal Data API 就是非常不错的设计。Istio 的 Auth
这部分也充分地利用了 Kubernetes 的安全机制。

说到开源模式,鲁直表示:“做开源,我觉得首先肯定要做一个心理准备,就是说你要有一个核心部分,再在这个基础上做扩展,在维护的成本上肯定有一定的上升,但是你要接受这样的成本——我觉得这种成本是可以接受的。……项目本身要设计好,具备一定分拆的可能性。如果不具备分拆可能性,那没法做了。像微内核这样的设计方式就会比较适合——就是开源一个核心模块,然后再去扩展,各种模块是可插拔的。”

2018年,微服务方兴未艾,Service
Mesh又快速崛起。有观点认为,2018年可被称之为“Service
Mesh元年”,在未来两年中,Service
Mesh将迎来爆发式增长,成为下一代的微服务架构。

另外,Istio 提出 Control
Plane,其实是在往微服务标准化方面迈进了很大一层。它里面有非常多的服务发现的标准,治理的标准,虽然说他大胆提出了这样的概念和假设,我们也看到了它的一些不足,所以我们希望和社区一起推进这一层的标准化。就像我一开始分享的,基础设施一层一层的向上包。像我们觉得越来越多的中间件的部分,其实是会被沉淀到基础设施当中的。现在也有云原生语言,我们编译了一下,发现很慢,问题也很多,但是我们觉得这是一个方向。大家在写的时候,可能就用这样的语言去写,很多能力就提升上去了。我们希望把基础设施向上再推一下,去扮演这样一个角色。这也是我们认为
Control Plane 的最大的价值。

“我觉得做技术管理,跟普通的管理不太一样,因为技术管理最重要的一个点是除了管理之外,还要保持一定的技术判断力和敏锐度。对一些新技术,包括团队中遇到一些重大的技术问题,你都要有一些方向性的判断。虽然最后不一定是你具体解决的,但是在整个团队的技术攻坚和技术选型上,要一起确立方向。”

如今SOFA包含丰富的组件,如SOFABoot、微服务、访问代理、分布式事物、消息队列、分布式链路跟踪等,基本上包含了分布式架构所需的各种中间件。

另外,虽然我们采用了 Istio 的 Pilot,但是在内部使用的时候,直接使用Pilot
并不能满足我们的诉求。首先,Pilot 在 Kubernetes 上是直接对接到
Kubernetes 的服务发现机制上的,无论是 SOFARPC,还是微博的Motan
等等国内的服务框架,其实都是单个应用多个服务这样的模型,而 Kubernetes
的服务发现机制实际上针对的是单个应用单个服务的模型,在模型上就不太一致。另外,SOFA的服务注册中心
SOFARegistry
在蚂蚁金服内部经过了多年的实践,面对内部大规模的服务化的场景,SOFARegistry
的扩展能力以及可靠性已经经过了大量的实践证明,这里说一下SOFARegistry
上的一些数据,上面大约注册了 2W 多个服务,一个机房里面的 Pub 和 Sub
的加起来在千万级别。基于以上的考虑,我们选择了用Pilot 上增加
SOFARegistry 的 Adapter,使之能够拿到 SOFARegistry 上的服务注册信息。

目前鲁直在SOFA的团队主要负责的工作包括几个部分。其中一个主要部分就是
SOFA 开源相关的工作。SOFA
的产品体系非常广,包括已经对外开源的部分、内部整个微服务体系,以及 SOFA
框架等等——而这些开源相关的工作主要是由鲁直负责推动的。

其一,解决多语言通信的问题,用同一套基础设施解决不同的语言的通信问题。

本文会给大家分享 Service Mesh 在蚂蚁金服的演进历程和在2018年6月举办的
GIAC 全球互联网架构大会中蚂蚁金服高级技术专家与现场人员关于Service
Mesh的热门QA互动。

2007 开始,蚂蚁金服自主研发了分布式事务中间件
XTS,在内部广泛应用并解决金融核心场景下的跨数据库、跨服务数据一致性问题,最终以
DTX 的云产品化展现并对外开放。

Service Mesh让蚂蚁金服找到了解决问题的方法,通过Service
Mesh,应用研发和基础设施团队能够最大程度地解耦,做厚技术中台,让中间件可以更快的交付业务需要的能力。

答:其实这个就涉及到整个云平台和我们整个服务化体系的融合的问题。其实目前大家可以看到,Pilot
这部分的东西,在原来 Istio 设计当中是非常强的和 K8S
这个东西融合在一起的,如果说你没有这套东西存在的话,对于 Mesh
来说还是一个非常上层的中间件这样的东西。当然你可以说不用 Control Plane
这一层,只有
Sidecar,对接到原来的一整套的服务治理体系当中去,这样做也是可以的,没有太大的问题。但是有了
Control Plane 这一层东西,它定义了非常通用的
API,本身这个架构又是和云平台整个架构是绑定得比较紧的,有更好的融合度。所以我们觉得整个Control
Plane这一层是非常重要的。

www.hj8828.com 2

很多传统企业,包括金融机构往往有着大量的遗留系统,随着传统企业云化的深入,这些遗留系统也需要转变为云原生应用。“一种方式是直接把系统代码重新做一遍,直接用云原生的方式再写一遍”,黄挺认为,这种方式虽然比较直接,但是也比较粗暴,有可能在迁移过程当中出现非常多的Bug。

再者,大家都知道 Istio 的 Sidecar 是 Envoy,它是一个用 C++
写的,那么我们怎么把Mixer 移入到 Sidecar 中去呢,其实我们的 SOFA Mesh 的
Sidecar 是采用了 Golang 来写的,所以才给把 Mixer 移入Sidecar
提供了可能性,当然,我们选择用 Golang 来研发 Sidecar 不仅仅是为了把
Mixer 移入到 Sidecar
而已,其实也有其他的考虑,一方面,在云计算的时代,Golang以及成为构建基础设施的首选语言,我们看到大量的基础设施都是用
Golang 写的,包括 Docker,Kubernetes 等等,选择
Golang,其实也是希望能够更好地和云原生时代的这些基础设施贴合。

“我们希望在 SOFA5
的方向上,在这个新的迭代中,去让业务——包括让未来我们开源出来各种功能、各样服务模式——都更多地去关心自己的业务代码,而不用再过多地关心基础设施。”鲁直说,

“服务网格是一个基础设施层,用于处理服务间通信。云原生应用有着复杂的服务拓扑,服务网格负责在这些拓扑中实现请求的可靠传输。在实践中,服务网格通常实现为一组轻量级代理,它们与应用程序部署在一起,而对应用程序透明。”

www.hj8828.com 3

鲁直说:“分布式事务是蚂蚁金服在 2007 年做的创新,是基于TCC
原理,我们在内部实现了这个模式。TCC
理论相对还是比较简单的,但是它要落地,需要花费比较长的工程实现上的打磨才行。分布式事务这个技术在蚂蚁金服已经走过了12年的时间了。在蚂蚁金服最核心一些业务上,包括支付、交易、账务等等系统都在使用这套分布式事务框架解决和孵化的。”

“然而有一个问题是,这些中间件都是用Java写的”,黄挺指出,当前蚂蚁金服技术栈大部分基于Java语言,包含2000+应用和20000+服务;但还有一部分应用是基于NodeJS、C++、Golang和Python语言,要把这些应用融入到SOFA体系,按照传统的方式,各种语言的客户端都需要再实现一遍,带来巨大的工作量,同时要承担大量风险。

蚂蚁金服在服务化上面已经经过多年的沉淀,支撑了每年双十一的高峰峰值。Service
Mesh
作为微服务的一个新方向,在最近两年成为领域的一个大热点,但是如何从经典服务化架构往
Service Mesh
的方向上演进,中间可能会遇到什么样的问题,几乎没有可以借鉴的经验。

多个服务调用的情况,Service Mesh
出现在所有的服务的下面,这一层被称之为服务间通讯专用基础设施层。Service
Mesh
会接管整个网络,把所有的请求在服务之间做转发。在这种情况下,上面的服务不再负责传递请求的具体逻辑,只负责完成业务处理。服务间通讯的环节就从应用里面剥离出来,呈现出一个抽象层。

而有了Service
Mesh之后,通过Sidecar,遗留系统不经改造,或是只需要很少的改造,可以非常方便的和云原生体系融合到一起。

对于多语言的问题来说,Service Mesh 其实就很好地解决了这部分的问题,通过
Service Mesh的方案,我们可以尽量把最多的功能从中间件的客户端中移到
Sidecar
中,这样就可以做到一次实现,就搞定掉所有语言,这个对于基础设施团队来说,在成本和稳定性上都是一个提升。

具体来说,“阿里巴巴的 Seata 提供是 AT
模式,对业务来说,不用有太多感知,但是它覆盖的场景有限,如果可以接受这样的情况,用
AT 模式更好。而蚂蚁金服因为有更强的金融方面的要求,就需要采用 TCC
模式,业务接入成本更高,但是它能做到非常好的分布式执行。未来还会提供像
XA
这样的模式,去适应更宽泛业务场景,这在这一块上,蚂蚁金服和阿里巴巴会结合在一起提供一个融合的框架。”

解决蚂蚁金服三大难题

www.hj8828.com,最后,我再分享一个蚂蚁金服的场景,在蚂蚁金服,因为事业部众多以及监管的问题,不用的事业部之间的一些机器可能是网络不通的,那么他们要做服务访问,就必须有一个角色来做跨环境之间的服务访问,所以我们基于
Sidecar 的概念,提出了 EdgeSidecar
的角色,他在技术的实现细节上其实和和应用部署在一起的 Sidecar
是非常类似的,只是这个 Sidecar
作为一个“边缘”的角色,来负责跨环境的服务通信问题。

“首先,最基础的肯定是代码,并提供对应的示例,然后我们会提供贡献者指南这样的指引文档,因为本质上我们希望打造成一个开源社区,社区的参与度对我们来说是非常重要的东西,有人会上来提issue,也有人来解答,有人提功能需求,有人提
PR 等等”,鲁直说。

而通过Service
Mesh中的Sidecar,服务注册中心、限流熔断、动态配置、故障注入等客户端可以和NodeJS、C++、Golang、Python等具体语言解绑,让基础中间件和具体的应用脱离关联,即“一次实现,搞定所有语言的客户端”,用一套基础设施解决不同语言的通信问题,大大节省了工作量。

答:应该是说Service
Mesh提出了更好的方式去解决请求的可靠传输和服务治理的问题。其实想像一下,如果说你要上一整套的服务治理的架构的话,在原来的方式下可能需要你们所有的上层业务系统都接入你们对应的服务治理的组件,现在的话,只要有一个Service
Mesh,在这个 Sidecar
当中就可以把服务治理的这件事情做掉。它没有去解决新的问题,只是把一些老的问题用更好的方式去解决。

鲁直指出,“我觉得Serverless想要成功,还是要从覆盖业务的整个广度上打开,否则可能还是停留在
FaaS 上,那场景就比较受限。”

其三,解耦基础设施团队和应用研发团队,增强基础设施团队的交付能力和交付速度。

www.hj8828.com 4

最后,鲁直希望致语开源社区,“其实蚂蚁金服开源的东西,也不只是 SOFA
中间件框架,未来会开源更多的东西,包括 AI
方面的一些技术,也希望整个社区能够多关注蚂蚁金服在开源上面未来的举措。”

www.hj8828.com 5

SOFA 其实包含了金融级分布式中间件,CICD 以及 PAAS
平台
。SOFA中间件部分包含的内容包括 SOFABoot
研发框架、SOFA微服务相关的框架(RPC,服务注册中心,批处理框架,动态配置等等)、消息中间件、分布式事务和分布式数据访问等等中间件。

“我们将以Service
Mesh为跳板再往前走。”鲁直表示,“Serverless更多的还是应该聚焦在其字面本身,其含义就是‘无服务器’,后面的技术都是为了让无服务器承载具体的业务。”

众所周知,SOFA中间件(Scalable Open Financial
Architecture)是蚂蚁金服自主研发的金融级分布式中间件,被蚂蚁金服广泛应用于支付、借贷、信用、基金、保险等全金融场景,支撑蚂蚁金服平稳度过历次“双11”、“双12”、“新春红包”等苛刻考验。

www.hj8828.com 6

虽然我和鲁直在微信上已经联系很久了,但这还是第一次见面。交谈中,我了解到鲁直是2009
年加入阿里巴巴工作,已经有十年了。刚开始是在1688.COM
做业务系统,对中间件技术非常感兴趣,也会经常研究各种中间件的实现和功能。后来在
2013年时,为了更深入地学习研究中间件框架,转到了蚂蚁金服中间件团队,从那个时候开始就一直在做
SOFA。

“Service
Mesh”最早由开发Linkerd的Buoyant公司提出,2016年9月第一次公开使用该名词。对于什么是Service
Mesh,Linkerd首席执行官William Morgan曾经给出这样的解释:

最后我们在蚂蚁金服的服务化的过程中遇到的问题是中间件升级的问题,蚂蚁金融从单体应用演进到服务化的架构,再演进到单元化的架构,再演进到弹性架构,其实伴随了大量中间件升级,每次升级,中间件不用说要出新的版本去提供新的能力,业务系统也需要升级依赖的中间件,这中间再出个
Bug,又得重新升级一遍,不光是中间件研发同学痛苦,应用的研发同学也非常痛苦。

鲁直:“我们希望能够在我们进行了生产验证之后,再慎重地推送给开源社区。这也是蚂蚁做开源贡献的一贯理念——我们希望一个东西经过了内部一段时间的成熟之后,再去开源。经过了大规模的内部验证之后,它的稳定性上有了一定的保障,就贡献给外部社区使用,再去拓展更多一些使用场景,包括完善和解决一些之前没有遇到一些问题。”

首页<上一页12下一页>尾页

以上的这些中间件都是基于 Java 技术栈的,目前 SOFA 在蚂蚁金服内部大概超过
90% 的系统在使用,除了这些系统之外,还有剩下的 10% 的系统,采用
NodeJS,C++,Python 等等技术栈研发的。这剩下的 10% 的系统想要融入到 SOFA
的整个体系中,一种办法是用对应的语言再去写一遍 SOFA
中间件的各个部分对应的客户端。

SOFA 5 落子 Service Mesh