app和网站开发,网站制作替我们购买域名,个人网站设计与制作源代码,出口非洲的外贸公司摘要#xff1a; 小蚂蚁说#xff1a; 蚂蚁金服在服务化上面已经经过多年的沉淀#xff0c;支撑了每年双十一的高峰峰值。Service Mesh 作为微服务的一个新方向#xff0c;在最近两年成为领域的一个大热点#xff0c;但是如何从经典服务化架构往 Service Mesh 的方向上演进…摘要 小蚂蚁说 蚂蚁金服在服务化上面已经经过多年的沉淀支撑了每年双十一的高峰峰值。Service Mesh 作为微服务的一个新方向在最近两年成为领域的一个大热点但是如何从经典服务化架构往 Service Mesh 的方向上演进中间可能会遇到什么样的问题几乎没有可以借鉴的经验。
小蚂蚁说蚂蚁金服在服务化上面已经经过多年的沉淀支撑了每年双十一的高峰峰值。Service Mesh 作为微服务的一个新方向在最近两年成为领域的一个大热点但是如何从经典服务化架构往 Service Mesh 的方向上演进中间可能会遇到什么样的问题几乎没有可以借鉴的经验。本文会给大家分享 Service Mesh 在蚂蚁金服的演进历程和在2018年6月举办的 GIAC 全球互联网架构大会中蚂蚁金服高级技术专家与现场人员关于Service Mesh的热门QA互动。蚂蚁金服高级技术专家蚂蚁金服分布式架构SOFA 的开源负责人黄挺前言在过去的一段时间中蚂蚁金服已经开始采用 Service Mesh 来帮助解决一些架构上的问题并且在 Service Mesh 如何更好地与经典的服务化架构结合上有一定的经验希望借此分享和大家交流我们这部分的实践。使大家对蚂蚁金服当前的服务化架构有更多了解并对 Service Mesh 如何解决经典服务化架构中的问题以及蚂蚁金服实际在落地Service Mesh 中的时候的一些设计考虑和未来展望有更进一步的了解也希望能与行业分享蚂蚁金服服务化架构现状。蚂蚁金服从单体应用转移到服务化的架构下已经经过了差不多 10 年的时间在整个过程中为了满足蚂蚁金服金融级的要求我们也构建了一整套地面向金融级的分布式架构的解决方案也就是 SOFA。SOFA 其实包含了金融级分布式中间件CICD 以及 PAAS 平台。SOFA中间件部分包含的内容包括 SOFABoot 研发框架、SOFA微服务相关的框架RPC服务注册中心批处理框架动态配置等等、消息中间件、分布式事务和分布式数据访问等等中间件。干货蚂蚁金服如何实现经典服务化架构往 Service Mesh 方向以上的这些中间件都是基于 Java 技术栈的目前 SOFA 在蚂蚁金服内部大概超过 90% 的系统在使用除了这些系统之外还有剩下的 10% 的系统采用 NodeJSCPython 等等技术栈研发的。这剩下的 10% 的系统想要融入到 SOFA 的整个体系中一种办法是用对应的语言再去写一遍 SOFA 中间件的各个部分对应的客户端。事实上之前我们正是这么干的蚂蚁金服内部之前就有一套用 NodeJS 搞的 SOFA 各个组件的客户端但是最近几年随着 AI 等领域的兴起C 也在蚂蚁金服内部也在被应用到越来越多的地方那么我们是否也要用 C 再来写一遍 SOFA 中间件的各个客户端如果我们继续采用这种方式去支持 C 的系统首先会遇到成本上的问题每个语言一套中间件的客户端这些中间件的客户端就像一个个烟囱都需要独立地去维护去升级。另一方面从稳定性上来讲之前 Java 的客户端踩过的一些坑可能其他的语言又得重新再踩一遍坑。对于多语言的问题来说Service Mesh 其实就很好地解决了这部分的问题通过 Service Mesh的方案我们可以尽量把最多的功能从中间件的客户端中移到 Sidecar 中这样就可以做到一次实现就搞定掉所有语言这个对于基础设施团队来说在成本和稳定性上都是一个提升。干货蚂蚁金服如何实现经典服务化架构往 Service Mesh 方向另外的一个问题其实是所有在往云原生架构中转型的公司都会遇到的问题云原生看起来非常美好但是我们怎么渐进式的演进到云原生的架构下特别是对于遗留系统到底怎么做比较好。当然一种简单粗暴的方式就是直接用云原生的设施和架构重新写一套但是这样投入的成本就非常高而且重写就意味着可能会引入 Bug导致线上的稳定性的问题。那么有没有一种方式可以让这些遗留系统非常便捷地享受到云原生带来的好处呢Service Mesh 其实为我们指明了一个方向通过 Service Mesh我们为遗留系统安上一个 Sidecar少量地修改遗留系统的配置甚至不用修改遗留系统的配置就可以让遗留系统享受到服务发现限流熔断故障注入等等能力。干货蚂蚁金服如何实现经典服务化架构往 Service Mesh 方向最后我们在蚂蚁金服的服务化的过程中遇到的问题是中间件升级的问题蚂蚁金融从单体应用演进到服务化的架构再演进到单元化的架构再演进到弹性架构其实伴随了大量中间件升级每次升级中间件不用说要出新的版本去提供新的能力业务系统也需要升级依赖的中间件这中间再出个 Bug又得重新升级一遍不光是中间件研发同学痛苦应用的研发同学也非常痛苦。我们从单体应用演进到了服务化的架构从原来好几个团队维护同一个应用到各个团队去维护各自领域的应用团队之间通过接口去沟通已经将各个业务团队之间做到了最大程度的解耦但是对于基础设施团队来说还是和每一个业务团队耦合在一起。我们中间尝试过用各种方法去解决升级过程中的耦合的问题一种是通过我们自己研发的应用服务器 CloudEngine 来管理所有的基础类库尽量地去减少给用户带来的升级成本不用让用户一个个升级依赖一次升级就可以。但是随着蚂蚁的业务的不断发展规模地不断扩大团队的数量业务的规模和我们交付的效率已经成为了主要的矛盾所以我们期望以更高的效率去研发基础设施而不希望基础设施的迭代受制于这个规模。后来蚂蚁自己研发的数据库 OceanBase 也在用一个 Proxy 的方式来屏蔽掉 OceanBase 本身的集群负载FailOver切换等方面的逻辑而刚好 Service Mesh 的这种 Sidecar 的模式也是这样的一个思路这让我们看到将基础设施的能力从应用中下移到 Sidecar 这件事情是一个业界的整体的趋势和方向通过这种方式应用和中间件的基础设施从此成了两个进程我们可以针对中间件的基础设施进行单独的升级而不用和应用的发布升级绑定在一起这不仅解放了应用研发和基础设施团队也让基础设施团队的交付能力变地更强以前可能需要通过半年或者一年甚至更长时间的折腾才能够将基础设施团队提供的新的能力铺到所有的业务系统中去现在我们通过一个月的时间就可以将新能力让所有的业务系统享受到。这也让基础设施团队的中台能力变得更强了。这样我们就可以把我们还是把一些架构当中非常关键的支撑点以及一些逻辑下沉到 Sidecar上面去因为整个蚂蚁金服的整体架构有非常多的逻辑和能力承载在这一套架构上面的。这些东西我们有一个最大的职责是要支撑它快速向前演进和灵活。干货蚂蚁金服如何实现经典服务化架构往 Service Mesh 方向Service Mesh 的选型前面讲到了蚂蚁金服当前服务化架构下遇到的问题以及我们希望能够通过 Service Mesh 能够去解决的一些问题接下来就面临一个很现实的问题Service Mesh 的框架我们到底应该怎么选我们应该用什么样的标准去衡量那接下来我就给大家分享一下蚂蚁金服在Service Mesh 的框架上的选型上的一些思考。首先所有的架构的演进都不是一蹴而就的都是一个渐进式地演进的一个过程越大的公司在架构演进的过程中其实越需要考虑这一点。所以我们在选型的时候就需要去考虑这一点考虑目标框架能否很好地和当前的架构融合在一起。另一个点作为一个和钱打交道的公司我们需要特别地去关注目标框架是否在生产环境经过大规模的验证在场景上是否经过了各类场景的验证。目前业界主流的 Service Mesh 相关的框架有三个分别是 GoogleIBMLyft都参与其中的 Istio以及 Bouyant 公司下的两个开源的 Service Mesh 的框架 Linkerd 以及 Conduit。首先我们来看下 IstioIstio 应该是目前被关注最高的一个 ServiceMesh 框架本身又有顶尖公司的光环加持比如 GoogleIBM 等等他也完整地包含了一个 Data Plane 以及 Control Plane但是Istio 一直以来被挑战的地方其实在于他的 Control Plane 的 Mixer 的部分Istio 的 Mixer 承担了服务鉴权Quota 控制TracingMetrics等等能力它是一个中央的节点如果不开启缓存的情况下所有的调用都需要从 Mixer 中去过即使开启了缓存的情况也不可避免的有请求一定要从 Mixer 中去过而在全蚂蚁有20000 多的服务服务之间的调用是非常频繁的如果都需要过 Mixer那 Mixer 就成了一个单点这个单点的运维和高可用又成了一个问题。另外Istio 的性能是我们一直以来比较担心的问题虽然 Istio 每个版本的发布性能都有了一定程度的提升。但是我们来看下 Istio 的性能数据0.5.1 的时候是 700 的 TPS0.6.0 的时候是 1000 个 TPS0.7.1 的时候是 1700 个 TPS相对于一般的RPC 通信框架最低最低都是万级别的 TPSIstio 的这个性能数据的确是有点儿惨淡完全无法满足蚂蚁这边的性能要求。接下来我们来看 LinkerdLinkerd 算是业界几个 Service Mesh的框架里面最成熟的一个了但是他也有一个问题首先就是他脱胎于 Twitter 的 Finagle架构上其实不够开放没法很好的适配到蚂蚁的环境里面去另外Linkerd 也没有 Control Plane 这一层只有 Sidecar再者 Linkerd 的路由规则 DTab 其实是挺难理解的。最后其实也是我们当时选型的时候最关心的一个问题Linkerd是用 Scala 写的跑在 JVM 上面我从 Linkerd 的一篇博客上摘录出了一张图片这篇博客主要讲的是如何优化 JVM 的内存使用这种文章一般上是的确有这个问题才会去写这样的文章从这张图片中我们可以看到 Linkerd 所需要的内存至少都需要 100M这也是 Bouyant 官方不推荐 Linkerd 和应用做一对一的部署而是采用 DaemonSet 的方式进行部署。而我们期望的一个部署方式是和应用做一对一的部署这样的内存占用对于我们来说成本太过我们期望将 Sidecar 的内存占用控制在 10M 左右。最后我们来看下 Conduit首先 Conduit 也是 Linkerd 不久之前推出的一个Service Mesh 的框架其实不太成熟其次Conduit 选择的语言是 Rust我们来看下 Rust 在 Tiebo 上的排名Java 长时间高居第一位C在第三位Golang 经过这几年云基础设施的蓬勃发展到了 14 位而 Rust和一众语言的占用率没有太大的差别排在了 50 位往后。所以我们最后选择了自研 Service Mesh一方面当然是我们基于前面的两个准则去衡量目前业界流行的Service Mesh 框架没有能够完全满足我们的要求的另一方面蚂蚁金服服务化上有长期以及深厚的积累这部分的一些经验也可以支持我们能够更好地去自研我们自己的Service Mesh 的框架。当然我们也不是说完全从零开始搞 Service Mesh 框架对于业界的Service Mesh 的框架中的优秀理念我们是希望能够吸收过来的另一方面我们也希望能够尽量地去 Follow Service Mesh 目前社区中的一些规范。SOFA Mesh 的设计首先SOFA Mesh 其实直接采用了 Istio 的 Control Plane 的Pilot 和 Auth因为我们觉得 Istio 在这块上没有太大的问题甚至里面也有一些非常不错的设计比如Pilot 这部分的 Universal Data API 就是非常不错的设计。Istio 的 Auth 这部分也充分地利用了 Kubernetes 的安全机制。而Mixer 这部分其实我之前就提到我们是觉得有设计上问题的所以我们的想法是直接把 Mixer 搬到 Sidecar 中实现。再者大家都知道 Istio 的 Sidecar 是 Envoy它是一个用 C 写的那么我们怎么把Mixer 移入到 Sidecar 中去呢其实我们的 SOFA Mesh 的 Sidecar 是采用了 Golang 来写的所以才给把 Mixer 移入Sidecar 提供了可能性当然我们选择用 Golang 来研发 Sidecar 不仅仅是为了把 Mixer 移入到 Sidecar 而已其实也有其他的考虑一方面在云计算的时代Golang以及成为构建基础设施的首选语言我们看到大量的基础设施都是用 Golang 写的包括 DockerKubernetes 等等选择 Golang其实也是希望能够更好地和云原生时代的这些基础设施贴合。另外相比于 Envoy 采用的 CGolang 显然更加容易上手也更加容易找到这方面的人才另外Golang相对于 JVM 来说Memory Footprint 低了非常多我们用 Golang 写的 Sidecar目前的峰值 TPS 下的内存在用在 11M虽然还有一定的优化空间但是相比于 JVM 来说已经降低了10 倍。另外虽然我们采用了 Istio 的 Pilot但是在内部使用的时候直接使用Pilot 并不能满足我们的诉求。首先Pilot 在 Kubernetes 上是直接对接到 Kubernetes 的服务发现机制上的无论是 SOFARPC还是微博的Motan 等等国内的服务框架其实都是单个应用多个服务这样的模型而 Kubernetes 的服务发现机制实际上针对的是单个应用单个服务的模型在模型上就不太一致。另外SOFA的服务注册中心 SOFARegistry 在蚂蚁金服内部经过了多年的实践面对内部大规模的服务化的场景SOFARegistry 的扩展能力以及可靠性已经经过了大量的实践证明这里说一下SOFARegistry 上的一些数据上面大约注册了 2W 多个服务一个机房里面的 Pub 和 Sub 的加起来在千万级别。基于以上的考虑我们选择了用Pilot 上增加 SOFARegistry 的 Adapter使之能够拿到 SOFARegistry 上的服务注册信息。然后Pilot 还有一个问题就是原来 Pilot 会把所有的服务注册相关的数据都同步到Pilot 上这个对于 Pilot 的集群的压力是非常大的所以我们选择了只同步必要的数据到一个 Pilot 的节点上介绍 Pilot 本身的内存压力。最后我再分享一个蚂蚁金服的场景在蚂蚁金服因为事业部众多以及监管的问题不用的事业部之间的一些机器可能是网络不通的那么他们要做服务访问就必须有一个角色来做跨环境之间的服务访问所以我们基于 Sidecar 的概念提出了 EdgeSidecar 的角色他在技术的实现细节上其实和和应用部署在一起的 Sidecar 是非常类似的只是这个 Sidecar 作为一个“边缘”的角色来负责跨环境的服务通信问题。所以SOFA Mesh 在整体的大图上大概是这样的我们自研了一个 Golang 的Sidecar并且把 Mixer 纳入到 Sidecar 中来防止出现类似于 Istio 那样的性能问题在 Pilot 和 Auth 这两个角色了我们选择直接使用Istio 的然后在上面做一定程度的适配适配到蚂蚁内部的环境中然后我们在整个部署上新增了一个 EdgeSidecar 的角色来解决跨环境的服务调用的问题。干货蚂蚁金服如何实现经典服务化架构往 Service Mesh 方向我知道大家一定对 SOFA Mesh 在蚂蚁内部的落地情况非常感兴趣目前我们已经落地的场景主要是多语言的场景解决其他的语言和 SOFA 的通信问题大约上了二三十个系统。然后我们正在尝试用 SOFA Mesh 去更好地解决服务间调用的安全以及蓝绿发布的问题在异构系统通信的这件事情上我们也在不久的将来会尝试用 SOFA Mesh 去解决。当然SOFA Mesh 在蚂蚁内部的落地其实离不开开源社区所以在未来的两三个月内我们也会将 SOFA Mesh 开源出来将蚂蚁内部实践 Service Mesh 的成果开源出来给大家更多在这方面的参考。对于未来其实我觉得中间件作为基础设施未来和云平台融合是一个不可阻挡地趋势除了 Service Mesh未来还可能会出现 Message MeshDB Mesh 等等产品我知道业界有些同学已经开始做这方面的努力了。最后总结一下我今天演讲的内容一个是 Service Mesh 给蚂蚁金服解决的问题包括多语言遗留系统以及基础设施团队和业务团队耦合的问题。在 ServiceMesh 的选型上我们主要考量和当前架构的可融合性以及框架的高可用稳定性。未来除了 ServiceMesh可能还会出现其他的 Mesh中间件和底层云平台进一步融合的趋势不可挡。多谢大家下面带来的是GIAC大会中蚂蚁金服高级技术专家与现场参会人员进行关于Service Mesh的问答互动我们精选了几个比较热门的问答分享给大家。干货蚂蚁金服如何实现经典服务化架构往 Service Mesh 方向一、Mesh的高可用和安全能否详细说明一下答我们最近正在做安全这件事情安全涉及到两个方面一个方面是 RPC 的整个服务调用健全的问题这个是可以直接在 Mesh 中去做的可以直接利用 Istio 的 RBAC 来实现另外是 Mesh 和 Mesh 之间的 TLS双向认证的事情。这个其实 Istio 里面会有一些现成的方案它与 K8S 融合的也非常好这些东西是可以直接拿过来去用的。二、如何解决服务的多版本路由和数据单元的多版本路由的问题答ServiceMesh 主要关注的是服务调用这一块我来解释一下多版本的路由其实我们在内部的话服务版本这件事情用得会比较少用得更多的是同一服务不同的实现。但是其实多版本路由这一块如果说大家知道 K8S 的 Label 的话可以把它的这种设计来借鉴到整个Mesh当中然后通过不同的标签来做区分后面也会有一些这方面的分享出来。三、Service Mesh 主要是解决了请求的可靠传输和服务治理的问题吗答应该是说Service Mesh提出了更好的方式去解决请求的可靠传输和服务治理的问题。其实想像一下如果说你要上一整套的服务治理的架构的话在原来的方式下可能需要你们所有的上层业务系统都接入你们对应的服务治理的组件现在的话只要有一个Service Mesh在这个 Sidecar 当中就可以把服务治理的这件事情做掉。它没有去解决新的问题只是把一些老的问题用更好的方式去解决。四、为什么Control Plane对于Mesh来说很重要答其实这个就涉及到整个云平台和我们整个服务化体系的融合的问题。其实目前大家可以看到Pilot 这部分的东西在原来 Istio 设计当中是非常强的和 K8S 这个东西融合在一起的如果说你没有这套东西存在的话对于 Mesh 来说还是一个非常上层的中间件这样的东西。当然你可以说不用 Control Plane 这一层只有 Sidecar对接到原来的一整套的服务治理体系当中去这样做也是可以的没有太大的问题。但是有了 Control Plane 这一层东西它定义了非常通用的 API本身这个架构又是和云平台整个架构是绑定得比较紧的有更好的融合度。所以我们觉得整个Control Plane这一层是非常重要的。另外Istio 提出 Control Plane其实是在往微服务标准化方面迈进了很大一层。它里面有非常多的服务发现的标准治理的标准虽然说他大胆提出了这样的概念和假设我们也看到了它的一些不足所以我们希望和社区一起推进这一层的标准化。就像我一开始分享的基础设施一层一层的向上包。像我们觉得越来越多的中间件的部分其实是会被沉淀到基础设施当中的。现在也有云原生语言我们编译了一下发现很慢问题也很多但是我们觉得这是一个方向。大家在写的时候可能就用这样的语言去写很多能力就提升上去了。我们希望把基础设施向上再推一下去扮演这样一个角色。这也是我们认为 Control Plane 的最大的价值。原文链接本文为云栖社区原创内容未经允许不得转载。
