《微服务没有银弹.docx》由会员分享，可在线阅读，更多相关《微服务没有银弹.docx（14页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、微服务没有银弹2017年度4月25日Buoyant公司的CEOWilliamMorgan给ServiceMesh下了个完好的定义简言之“ServiceMesh是一个专用的根底设施层用于使效劳到效劳的通信平安、快速以及可靠其实更确切的讲ServiceMesh应该诞生于2016年度因为回看很多ServiceMesh方案早在2016年度就已经开场探索前行。随后的几年度如雨后春笋般出现了很多实现逐渐形成了其根本事实标准负责效劳间通信的数据面和控制整体流量在体系内流转的控制面。ServiceMesh可谓是当下微效劳领域最火的形式。被认为是下一代的微效劳。甚至2018年度被称为ServiceMesh元年度
2、。本文我试图从自己理论ServiceMesh经过中的一些感悟出发去探寻ServiceMesh的本质祈望能给正在关注ServiceMesh或方案理论、落地ServiceMesh的你带来一些我的理解毕竟大众已经观望2年度多也该考虑落地了。ServiceMesh到底是什么为什么要讨论“ServiceMesh到底是什么这样一个话题因为我发现一个有趣的现象如今大众议论ServiceMesh时几乎就把它与istio画了等号尤其是越往后关注这个技术方向的人这种情况越明显。从另一个角度来看这也算一种技术垄断大公司背书的istio经过这两年度的开展与其专业的开源运营几乎掩盖了所有其它方案的声音让新进的开发者误以
3、为ServiceMesh就是istio。这会带来一个直接的问题:istio并不一定适应所有的场景。我觉得Mesh社区一个同学讲的一句话十分有道理“垄断使得包括其在内的竞品并未通过足够长时间的竞争到达相对的成熟就过早形成了某种心理意义上的垄断预期。导致当下可能很多团队可能在自己的场景强推istio无视了自己真正的痛点或假装自己有istio预设那样的痛点如此复杂的istio体系假如方向选不对折腾到最后可能吃力不讨好。图一ServiceMesh!istio那么ServiceMesh终究是什么ServiceMesh并不是什么新的技术它所关注的问题域比方恳求的高效、可靠传输效劳发现以及治理等有效劳化的一
4、天就已经存在。成体系的效劳治理方案我们早前很多SOA、API网关等就早有深化并已形成标准方法论以及行业标准。社区也不乏这方面的最正确理论。那为什么到如今才催生出如此火爆的ServiceMesh这一切的发生我认为关键点在于两个方面首先微效劳架构形式成为大规模分布式应用的主流架构被大众所熟知与认可其次云计算、容器化技术的规模化落地。越来越多的团队以及组织开场理论微效劳。这个时机很重要。大众很清楚微效劳架构的核心在于基于分而治之理念的效劳拆解而拆解往往使原先可能一次内部方法调用就获取的结果转换为一次或者屡次网络调用我们都知道网络本身是不可靠的这也正是为何ServiceMesh解决的核心问题域中始终将
5、恳求的可靠传输放在至关重要位置的原因下面我们简单梳理效劳的拆解给我们带来的挑战拆解后效劳间依赖不可靠的网络进展通信缺少一套整体的方案来解决所谓东西向横向效劳连通性的问题怎样保证拆解后整体业务的稳定性一次业务处理可能依赖数目不定的微效劳调用怎样来治理这些拆解后的效劳甚至是异构的微效劳体系怎样规模化、标准化更高效的施行、运维整个微效劳体系图二单体效劳到微效劳架构转变引发的调用方式的改变依赖网络过去通常使用微效劳治理框架、API网关等方案来解决上面的问题。比方微博早在2021年度就开场基于MotanRPC框架来解决效劳治理的问题而更早的API网关方案也具备相应的效劳发现以及治理才能甚至比微效劳框架出
6、现的还要早。传统微效劳框架通过胖客户端的方式提供了客户端实现的效劳发现与治理才能。但是这种方式有众多弊端与业务无关的效劳治理逻辑与业务代码强耦合框架、SDK的晋级与业务代码强绑定多语言的胖客户端支持起来性价比极地各种语言的效劳治理才能天差地别效劳质量体系难以统一图三传统SOA方案效劳治理框架与API网关而API网关通常部署在集群的边缘作为业务接入层虽具备一些通用的效劳治理才能然而其本身的实现相对更重、且往往性能低下因为它专注于API管理流经API网关的流量都会经过很多通用逻辑比方鉴权、验证、路由等在传统的API网关场景长达几十甚至过百毫秒的延迟对南北向的流量来讲根本可以承受但这在处理微效劳体系
7、内东西向流量时这样的性能是不能容忍的而且效劳的拆分势必导致整个体系内东西向流量随着微效劳规模的扩大而剧增。所以API网关并不能胜任微效劳场景下的流量管理任务它也不是为此而生的。再补充一点很多人对ServiceMesh以及API网关分不清楚因为正好这两种方案我都经历过其实很简单它们关注的点不一样Mesh关注内部效劳间的互联互通核心在于Sidecar构建的那张网格和对应流量及效劳的治理而API网关关注的是API的管理固然它们都有效劳治理的才能但彼此专注的点不一样。所以本质上ServiceMesh的出现就是为解析决大规模微效劳架构下恳求的高效可靠传输与效劳治理的问题。它将原先实如今微效劳框架胖客户端
8、或API网关接入层的效劳治理功能下沉到一个统一的Sidecar代理以一个独立进程的方式部署在业务进程旁边通过控制面来保障效劳间通信的横向流量按照业务的真实需求在整个微效劳体系内高效流转因此ServiceMesh不是效劳治理框架不是API网关更不是istio。它是一种新兴的微效劳施行形式。一种微效劳治理的标准标准。它有很多种实现istio是目前最为大众所熟知的实现。不过下面我们要看的是微博自研的实现WeiboMesh。图四ServiceMesh的方案其实是效劳通信及治理功能的下沉与解耦WeiboMesh的理想与现实解析过WeiboMesh的同学可能知道它基于微博早期效劳治理RPC框架Motan演
9、变而来没解析过的同学可以Google“微博ServiceMesh这里不再赘述。微博平台的微效劳体系建立做得比拟早平台内部技术主要是Java栈基于效劳治理框架以及混合云有一整套效劳化体系。同时平台还给其它兄弟团队提供底层数据与存储资源支撑。数据通过Restful接口提供。是一个典型的异构体系效劳化整合的场景。随着平台微效劳规模的增大和业务复杂度的进步我们必须面对以下三个难题热点、突发事件所引发流量洪峰u001c几倍、十多倍的突增的应对要求高效、完备的效劳治理体系混合云微效劳架构下的复杂拓扑带来的冗长的调用链路、低效的恳求长尾与及其复杂的故障排查各语言效劳治理才能差异性引入的异构系统效劳治理体系建
10、立难题为了应对这些难题我们探索了一套ServiceMesh实现方案。这里我先对整个方案的几个核心点做个简单描绘祈望大众能从微博的场景中体会这种方案选取的出发点将以往在MotanRPC胖客户端实现的效劳发现以及治理功能下沉到Motan-Agent这个Sidecar代理上通过对效劳的订阅以及发现来建立效劳间依赖的逻辑网络作为WeiboMesh的数据面。复用MotanRPC的Filter机制在Cluster效劳集群以及Endpoint节点两个维度实现了ServiceMesh的控制面逻辑完成对效劳间通信流量的管控作为WeiboMesh的控制面。效劳注册以及发现依赖微博故有的自研Vintage命名以及配
11、置效劳。WeiboMesh不与任何平台耦合可运行在裸机、公/私有云、混合云的场景。实现全新语言无关的通信协议Motan2以及跨语言友好的数据序列化协议Simple来应对跨语言。通过为所支持的语言开发标准的Motan2客户端完成与Mesh的通信对业务较低的侵入性带来平台才能的整体输出比方我们提供的各种数据效劳化、存储资源效劳化才能。这个方案的性价比极高保证整体架构向前演进而非推倒重来这在微博大体量的业务需求下显得格外重要而且我们跨语言的SDK只保存极薄的一层仅保证使用Simple序列化在Motan2协议上传输恳求而已这很好的控制了整体维护本钱。图五WeiboMesh方案理想的终极方案这是我们探究
12、了各种跨语言效劳化方式后最终第一版上线时的方案之前的文章有对此详尽的描绘请自行Google同样不再赘述也是一个迄今为止我们仍然认为比拟理想符合微博现状的ServiceMesh方案。最大程度上复用了我们多年度来在Java体系和混合云架构下积累的效劳化经历。最大化的保证了平台技术体系的稳固、高效同时兼顾了极低的接入、晋级、维护本钱。为什么讲理想很饱满现实很骨感。整个WeiboMesh工程组最初由效劳框架组与Feed组主导协同多个业务方共建立项时叫跨语言效劳化小组介入方涉及五、六个团队且介入各方都对跨语言效劳化有重度需求一点不夸大的讲已经是痛不欲生苦不堪言才逼到这条路上来经常为排查一个线上问题要追踪
13、无数跳的链路打日志加监控费时费力效果还不理想四七层的转发也增大了恳求时延因为恳求双方效劳池的不一致导致跨云转发恳求长尾严重等。所以最初介入的各方状态以及心境都非常积极大众很主动的推进整个方案演进、调研、试错。效劳端改造过GRPC方案、Yar方案、Servlet转Motan2的方案等等客户端也改造过很多方案比方效劳在Client端的描绘、Client的构造方式、恳求的组织形式、各种兜底方案等等。所以第一版上线时我们其实已经经历了很多尝试与磨合。算是比拟成功的我们原型版早在16年度底就初步线上试水17年度已经直接抵御春晚的顶峰。但是往下想把这种理想的方案铺开来时现实开场向我们展现出它的骨感。可谓一
14、步一坎怎样讲服工程组外其他各方在新业务上应用Mesh方案怎样将老业务接入Mesh体系现有方案Server、Client两端都没做到完全零侵入Agent引入的运维复杂度以及权责划分我们除了需要消除大众对Mesh性能以及稳定性的顾虑还要保证方案足够简单防止对已有的运维体系效劳开发、部署形式造成太大的冲击同时要让大众认可Mesh改造的收益用数据以及效果讲话。图六Mesh接入的一个典型收益例如双发带来延时的削峰填谷固然有搜索、微博主站Page、热门、话题这样的一些重量级典型业务方给我们的方案背书从以往的Restful方案接入Mesh后享受到性能提升的同时也收获了平台效劳治理体系的红利因为有些业务方专注
15、于自己的业务领域很正常在效劳治理及相关体系建立方面会相对薄弱。对于业务方接入我们的方案已经足够简单只需要多部署一个Sidecar代理将以往的Restful调用迁移到我们的跨语言SDK上即可业务方不需要关注Sidecar的任何事情因为当Sidecar出问题时我们可以退化为Restful调用并立即报警。同时我们Mesh体系提供了缓存、队列等效劳化资源通过SDK既可以轻松访问业务方可以由此对自己依赖的效劳以及资源都有整体治理的才能。对于SDK接入这样的改造显然性价比是极高的。然而现实情况是很多时候可能因为业务开发压力等原因他们并没有过多的精力来完成这样的改造。而另一方面平台内部已有的大量老业务怎样接
16、入Mesh体系现今平台业务已经处于一个相对稳定的阶段老业务才是改造的重中之重我们必须在Mesh体系为业务方准备好他们依赖的效劳。但是Mesh方案能为平台效劳方提供的唯一好处可能就是接入后他们不再需要同时维护RPC以及Restful两套效劳但是对于本来就已经历经风雨稳定运行的平台效劳来讲已有的Restful效劳没什么不好为什么要去改造显然大众是不乐意的固然我们已经在MotanRPC框架层面做了众多努力甚至做到只需修改一行配置多导出一个Motan2效劳即可哪有怎样效劳端的变更要求非常严谨一行配置同样需要经过整个上线流程。婉拒的话术通常是诸如“目前业务比拟忙往后有空再详细规划此类。这迫使我们一直在考
17、虑一个问题“假如要让xxx接入Mesh需要xxx做什么我们需要支持什么这也促使WeiboMesh迎来了全新的一次演进HTTPMesh。HTTPMesh的目的在于不需要修改任何一行代码真正零侵入接入详细做法将现有Restful接口自动导入Mesh体系通过HTTP_PROXY将客户端流量指向Sidrcax我们通过解析平台Restful效劳对应的Nginx配置将Restful接口自动对应到Mesh体系的RPC效劳上Nginx的upstream与RPC的Service对应Restful效劳池与PRC效劳分组对应这样一来原来的Restful效劳在Mesh体系就有了相应的表示。图七HTTPMesh方案新增
18、业务只需提供一套Motan2效劳而非以往的RPC以及Restful两套。老业务的场景效劳端Agent充当反向HTTP代理将进入的RPC恳求转换为HTTP恳求转发到之前的Restful接口客户端我们在Sidecar代理上提供了HTTP的正向代理支持通过HTTP_PROXY将本地出口的HTTP恳求都指向Sidecar这样假如Sidecar发现恳求已经导入Mesh体系那么会将代理的HTTP恳求转换为RPC恳求转发进入Mesh网格否那么将HTTP恳求透传发出而新开发的采用了SDK方案的效劳可以同时享有平台所有资源、效劳及治理体系。这样双方接入都不需要做任何改动。解决了双方改造本钱的大问题接下来就是引入
19、Sidecar对运维流程的影响以及权责划分的问题。在业务进程旁运行Sidecar来处理进出流量需要在固有的运维流程中添加对Sidecar的运维这看似简单的操作实那么涉及多方面的问题Mesh进程与业务进程的启停时序、优雅停机Mesh进程的晋级维护Mesh进程的监控、报警故障处理与恢复运维方面可能各公司情况不一包括我们内部不同团队可能姿势都不完全一样不具有通用性所以这里不展开过多只想讲明一点我们为了应对各种场景以及姿势我们在Mesh上提供了管理端口、后端探测等功能比方运维可以通过向Mesh管理端口提议上下线恳求来触发Mesh自动上下线效劳可以以通过配置探测地址及状态来对业务进程进展安康检查指导该节
20、点上下线或者告警另外我们提供了多种发布方式镜像、RPM包等一应俱全便于运维挑选合适自己消费的部署方式我们还将Mesh配置做了统一的管理因为以往接入的经历来看80%场景使用通用配置即可只有很少的20%甚至更少的场景需要个性化配置那样也减少大众理解以及我们作为方案提供方的指导本钱。所有Mesh相关的包、库以及配置都由我们提供这样也有了明晰的权责划分我们为Mesh负责降低业务方的心智负担。就这样我们在WeiboMesh的路上继续前行。因为我们深知微效劳、云计算才是稳定效劳的正道。确实给我们带来了很多现实收益而且我们相信这些收益仍在不断放大。怎样落地ServiceMesh前面我们讨论了ServiceM
21、esh的本质共享了一些WeiboMesh理论经过中的经历下面我们来讨论下怎样落地ServiceMesh。ServiceMesh很好的解决了规模化微效劳架构下效劳通信以及治理的问题给我们带来了很多确确实实的好处网络上相关的解读很多了我就不再次啰嗦。这里我只想根据自己的理论以及理解梳理出一些我认为很合适引入ServiceMesh的场景祈望能帮助大众更好的做出判断还未进展任何形式效劳化有的初创团队可能先期并没有过多精力来进展技术建立但是技术的稳定性是业务增长的基石ServiceMesh的整套的微效劳治理方案正好是个不错的选择先期可能不需要对效劳做太细粒度的拆分可以基于Mesh体系来构建逐步接入、分解
22、有跨语言互通的需求这不用多讲前面共享的WeiboMesh就是这方面的理论的好例子内部效劳依赖重东西向流量有些业务可能同时依赖很多效劳一次恳求对应数次Restful恳求有繁重的网络I/O需要处理可以引入ServiceMesh来保障这些恳求的可靠性依赖传统的效劳化框架做效劳治理这里主要指效劳治理与业务逻辑强耦合的场景前面也讨论过这种方案的各种弊端引入ServiceMesh将效劳治理逻辑与业务逻辑解耦应用开发的同学只需专注自己的业务这是最好的选择技术建立与前瞻性云计算与微效劳为进步效劳构建效率、降低投入本钱提供了可能性这里面的想象空间是宏大的从大厂在此方面的投入可见一斑俗话讲的好钱在哪儿方向就在哪儿
23、。具有前瞻性的技术储藏将为组织迎接各种挑战提供坚实后盾想清楚我们确实需要落地ServiceMesh认可其带来的宏大收益剩下的就是ServiceMesh方案的选择了。我们需要制定一个可执行的ServiceMesh施行方案。还是那个老生常谈的话题“选择自研、开源还是基于开源微创新。在这方面u0008我只有一条建议“因地制宜不盲目跟风。选择的经过中头脑一定要明晰仔细分析自己的场景以及业务痛点调研与自己场景最贴合的开源方案经过中掂量自己可支配的资源和工程周期同时关注方案复杂度。尽量防止重复造轮子。不过事实上开源方案一般考虑比拟通用的场景很难有能与自己场景完全吻合。这时候为了控制本钱更多会选择基于开源进
24、展改造。这就引入了一个与开源共建的问题。应该防止独立fork导致后期分开源越走越远。ServiceMesh从出现到如今两年度多的时间里可谓开展迅猛这离不开社区大众的热情抛开大厂在前面带风向不讲技术本身确实有很多先进性不管是否入坑ServiceMesh作为一个工程师我觉得都应该深化解析学习这种Mesh考虑形式以及工程化、标准化思路。祈望本文能给你带来一些考虑。简介周晶新浪微博平台研发技术专家负责微博跨语言微服化框架开发和ServiceMesh技术落地等OpenResty社区委员会成员高性能OpenResty开发框架Vanilla开源爱好者关注微效劳、云原生等技术。此外周晶将在QCon广州站为大众共享微博ServiceMesh理论。大会目前8折报名福利立减1360元咨询可致电鱼丸13269078023微信同号。