【导读】服务网格（Service Mesh）的概念自2017年初提出之后，受到了业界的宽泛关注，作为微服务的下一代倒退架构在社区迅速发酵，并且孵化出了诸如Istio等广受业界关注的面向于云原生(Cloud Native)的微服务架构。
那么，服务网格在百度的落地状况又如何呢？
近日，在百度技术沙龙上，百度服务网格技术负责人乔元才发表了『服务网格在百度外围业务大规模落地实际』的主题演讲。
1. 从微服务到服务网格
何谓微服务？据维基百科的定义：微服务是一种软件架构格调，它是以专一于繁多责任与性能的小型性能区块为根底，利用模块化的形式组合出简单的大型应用程序，各性能区块应用与语言无关的API集互相通信。
Service Mesh 最早在2016年9月29日由开发 Linkerd 的 Buoyant 公司首次提出，Service Mesh 是用于解决服务间通信的基础设施层，它负责通过形成古代云原生应用程序的简单拓扑构造来牢靠地传递申请。
因而 Service Mesh 也被称为微服务时代的TCP协定。
第一代微服务的常见架构如下图所示：
在黄色的容器内有服务A、服务B。A和B都蕴含本人的业务逻辑，如果想要A调用B，同时试图对这个服务进行治理，通常会在业务的外部集成一个SDK，来实现服务发现、负载平衡、服务路由、重试、熔断限流等性能。
然而，这个架构存在三个次要问题：
第一，开发成本。因为A和B的服务曾经是微服务了，它们可能是由不同语言开发的而且各自的框架可能也不同，如果心愿把绿色的局部进行降级或者提供新的性能，就须要反复的迭代和开发。
第二，降级老本。因为SDK的局部跟业务耦合在一起，在新增一些能力时须要重新部署业务的模块。
第三，部署老本。因为相干治理的性能须要耦合在业务的配置外面，所以很难做到实时的下发配置，服务间拓扑关系和治理配置无奈对立治理。
Service Mesh 是如何解决这些问题的?
如下图左侧所示，它通过将SDK 、开发框架提供的服务治理能力下沉到一个和业务过程独立的轻量级网络代理中，由这个网络代理作为微服务通信的基础设施层，它能够提供业务无关、语言无关、独立演进，通明降级的个性。这个轻量级的网络过程被称作Sidecar代理，是服务网格的数据面。
同时如右侧所示，通过一个对 Sidecar 进行对立管制和治理的服务管制立体，来提供对微服务治理和运维的对立入口。
这种架构实现了服务治理技术和业务逻辑的解耦，是云原生时代微服务治理技术的倒退方向，也失去了越来越多的公司的关注。
2. 百度微服务治理的现状和痛点
百度在服务网格以及微服务相干的摸索大略能够追溯到2013年，过后在外部独立部署了流量转发零碎，同时在一些业务有所推广施行；2016年 Service Mesh 这个概念被首次提出，因为百度自身有相干需要，便尝试引入Mesh的概念，于是外部自研了一套遵循社区 Mesh 概念的通过 Golang 开发的蕴含管制面和数据面的 BMesh 零碎，在搜寻服务前端服务上线，不过没有在特地多业务推广；直到2019年，百度外部做了拥抱开源的决定，心愿基于社区计划：Istio + Envoy 进行深度定制开发。
目前，百度外围业务线已全面完成了微服务架构革新，基于微服务构建了包含百度信息流、百度App、百度地图、百度小程序等外围业务的利用架构；微服务模块大量采纳C++、Golang、PHP、Java等语言来开发和疾速迭代；而且百度长期积淀了许多自研和二次开发的开源微服务框架：bRPC、GDP、ODP、SpringCloud等， 这些微服务间通信除了规范的HTTP、GRPC协定外，宽泛地采纳了大量的公有协定，比方baidu-std、Nshead等。
所以百度的外围业务线造成了多开发语言、多开发框架和多通信协议形成的简单的异构零碎，传统的基于入侵的微服务框架曾经不能满足这种简单零碎的服务治理要求——降级Mesh火烧眉毛！
在降级之前，有一些重点问题须要综合思考：
- 革新老本
- 各种各样的微服务框架网格化革新和适配
- 各种各样的通信协议反对
- 性能问题和资源问题
- 因为Sidecar的引入，微服务间的通信链路变长，业务提早减少，甚至某些敏感业务无奈承受Sidecar带来的额定损耗。
- Sidecar本身会耗费资源，减少业务的老本。
- 规模问题
随着Sidecar规模的增长，开源的管制立体计算开销变大，导致Mesh配置下发工夫变长，甚至无奈工作。
3. 百度服务网格整体计划
如何解决这些问题？
在服务网格的技术选型问题上，百度抉择了开源的 Istio + Envoy 作为网格管制面和数据面，在其上进行深度的定制和开发。
然而 Istio + Envoy 的社区计划和K8S的技术生态进行了深度绑定。而在百度外部有自研的根底技术平台，包含对标 K8S 的 PaaS部署零碎、Trace零碎、监控零碎和Naming零碎等，这些都是业务模块包含 Istio + Envoy 部署运行的依赖零碎。所以，将 Istio + Envoy 和外部依赖零碎进行了深度的技术交融，买通了公司根底技术平台，升高了业务接入老本。
在数据面和管制面之上，又建设了 Mesh 控制中心，即微服务的配置管理核心，提供服务治理和运维的对立入口；基于底层架构的建设，向上提供了流量复制、负载平衡、过载爱护、流量镜像等零碎能力。
这些零碎能力在外围业务的服务治理、运维止损、容量治理、混沌工程和服务可观测等场景中失去了利用，并且获得了不错的业务收益和应用成果。
那么，实现这样一套零碎，咱们须要解决哪些问题呢？
3.1 网格接入优化计划
首先是流量劫持计划的问题，在社区计划中，个别是通过Naming Service（如：DNS服务）获取到指标 Server 的实在地址。同时，通过配置 iptables 进行流量劫持，将客户端的申请间接转发给 Sidecar。然而，当 iptables 配置有大量匹配规定时有性能的问题，而且无奈动静批改客户端拜访服务端的行为，如：重试、超时等，且没有方法平滑的在 Mesh 和非Mesh 模式切换。
在百度外部采纳了另外一种劫持的计划，首先 Sidecar 启动的时候会将本人注册给Naming Service（在百度外部叫BNS），在框架通过 Naming Service 查问的时候，框架的外部集成了一个和 Naming Service 对接的小模块，这个小模块从 Naming Service 拿到的就是 Sidecar 的地址，动静的扭转了指标服务器的地址，间接将指标的IP变成 Sidecar 的地址（loopbackIp），同时，还会笼罩客户端的重试、超时等参数，这所有对业务来说都是无感的。
这样就能够很便捷的调整客户端服务治理参数、切换Mesh和非Mesh模式。因为如果Sidecar挂掉了，会在Naming零碎里把本人解除注册，这样上游的框架会自然而然的拜访上游服务的实在地址了。
第二，对自有协定的反对的问题。在社区外面是反对不同的协定，比方HTTP、Thrift、Dubbo，但会波及反复的开发。如果要反对一个新协定，可能须要从新实现超时管制、重试、申请路由、流量镜像等。百度外部将这通用的局部独自剥离进去：于是反对一个新的协定变得简略起来，咱们只须要将下图中绿色的部实现简略的Codec，即：将这个协定进行编解码就能够，大大降低开发反对新协定的老本。
最初是对多框架和协定的反对问题。Mesh 对协定的要求包含具备申请特色信息扩大的能力，能够实现申请特色路由；具备元信息扩大能力：可能在框架和 Sidecar 间传递信息（如：一致性哈希的Code），在上下游服务模块间传递信息（如：TraceID，SpanID)
外部传统的老协定如何接入 Mesh？通过框架实现协定降级，用可扩大的 baidu-std 协定封装老协定进行传输，达到上游服务之后再由框架拆解开报文。
3.2 服务网格性能优化
针对代理架构如下图所示，社区计划是从APP1进入 Sidecar 再到上游服务的 Sidecar再到APP2，这外面通过了两次 Sidecar，会有两倍提早或者两倍资源开销，在百度外部可能并没有这么简单，没有对这个很高要求的场景，少数状况下只通过 Sidecar一次。比方，APP1通过Sidecar后间接达到了APP2，并没有再次通过 Sidecar。
另外一种模式，外部很敏感的业务并不心愿通过 Sidecar。比方，APP2通过框架间接拜访到APP3，并没有通过任何的 Sidecar。下图左是通过一次 Sidecar 的模式（在百度外部称为一跳）这是通过 NamingService 注册再拜访本地IP。而下图右 Proxyless 模式 Sidecar 会将本人服务的参数以及指标服务的IP通过 NamingService 下发给框架，框架领有上游服务的IP以及服务治理的全副参数，能够间接实现拜访。
针对数据面性能方面的优化，社区的 Envoy 在性能方面并不是特地优越，所以。百度整合了一个 bRPC 开源框架作为内核去转发流量，在下层 bRPC 框架仍然兼容了xDS协定（服务治理参数的协定），便于同步社区的新设计、新变动，做到了鱼和熊掌都能够兼得的成果，通过降级内核的版本当前，在各个延时、长尾以及CPU使用率上都有很好的优化。
最初是管制面性能优化，管制面在没有配置 Sidecar CRD 的状况下，会下发所有的服务列表，咱们通过外部的要害门路优化，实际上只会下发 Sidecar 关注的上游，大大减少管制面对配置计算以及下发的性能优化。
通过上述革新后，最初就实现了百度外部对 Mesh 的整体优化和批改。
4. 业务收益及案例启发
通过上图所展现的高级服务治理策略，在 SLA 以及故障复原工夫上都有很高的优化。在此基础上还有全局的智能容灾零碎，能够优化高级服务策略参数。
服务可观测性方面，能够通过框架传递 TraceID、SpanID 等，再通过 Sidecar 再采集到外部的 Trace平台和监控平台，能够在外部的监控平台上展现 Trace，不便监控以及进行故障的排查和追踪。
主动止损方面，整个零碎联合外部的监控平台，监控平台将这些指标存储在本人的平台上，稳定性预案平台依据监控平台的指标异样进行实时调参，执行流量降级、切机房、切流等。同时这个成果会实时反馈给监控平台，包含稳定性预案平台继续的对系统进行调参，造成闭环。
混沌工程方面，会通过管制立体下发给故障工作，而后管制立体将命令下发给Sidecar，Sidecar 通过这个命令注入一些提早，这样去影响外部的零碎，外部零碎同样会产生监控的指标，这些指标再上报给监控平台，而后混沌平台再通过这些指标评估零碎的弹性以及容错等。
零碎容量评估方面，容量平台能够发动压测工作，这个工作对接到管制立体。如：由管制立体下发切20%的流量到某上游服务，对它进行压测，实时产生的指标上报给监控平台，容量平台对监控平台的指标进行实时评估。
百度外部业务接入状况：
- 百度App、信息流、百度地图、智能小程序、难看视频等产品线
- 接入实例十万级
- 每天解决申请数千亿次
业务接入收益：
- 大幅晋升外围链路的可用性和零碎整体容灾、防雪崩能力
- 大大降低治理迭代老本、服务治理迭代周期从数月缩短到天级别
- 解锁服务可观测，主动止损，容量探测等高级场景能力
最初，乔元才总结了通过接入Mesh服务网格失去的一些启发：
- 服务网格不是微服务治理的银弹
- 齐全无入侵的，反对所有协定，所有框架和所有治理策略的 Mesh 计划是不存在的
- 大规模工业化落地的平滑、稳固可控接入计划，波及到大量对已有服务治理组件的兼容降级和革新
- 服务网格的确实现了业务逻辑和服务治理架构的解耦，解锁了很多新能力
- 服务网格联合可观测、故障止损、混沌工程，容量治理等场景化，能力施展出最大价值
点击进入理解更多技术资讯~~