导读：关于服务治理，业界的讨论比较多，但尚未一个统一的解释。从实践角度，不少从业者会把服务治理和Service Mesh绑定起来。而百度搜索引擎和推荐引擎的微服务治理，有着本身的特色和定义。Geek大咖说第二期，咱们再次邀请到MEG推荐技术架构部的传玉老师，跟你们聊聊咱们本身的微服务治理是怎么落地的，效果如何。后端
全文3864字，预计阅读时间7分钟。性能优化
嘉宾简介 ：传玉架构
推荐技术架构部技术专家。2012年起专一于搜索引擎与推荐引擎方向；2016年开始负责自有的资源调度和容器编排系统的研发工做；2019年开始负责部分通用基础组件的研发工做，并开始在MEG用户产品内部全面推动云原生架构改造。app
Q1：您怎么定义服务治理？框架
以前为了方便在内部去推服务治理，咱们给了一个比较明确的定义：咱们指望的服务治理是让咱们全部的微服务都保持在一个合理的运行状态。所谓合理的运行状态，就包括：less
-
全部托管服务的容量是合理的，冗余既不会过多，也不会过少；微服务
-
全部托管服务是健康的，可以容忍局部的短时间异常，同时不会有长时间的故障，在生命周期内能提供高质量的服务；性能
-
整个系统是可观测的，它的流量拓扑和主要的技术指标，都是透明、可观测、可监控的。优化
Q2：咱们从何时开始着手服务治理？搜索引擎
推荐系统是16年末17年初开始作的。起初跟其余业务起步阶段差很少，咱们搭了一个快餐系统就直接就上了。最开始的重点是支持业务的高速发展，对巨型服务、资源利用，可观测性这些方面的问题，只要不影响业务的发展，可能就没有那么关注。例若有些服务上线作了一些尝试，发现效果不理想，而后又下线后，但作这些尝试的资源可能就没有及时回收，浪费掉了，这种状态一直持续到2018年。
以后，业务发展到必定规模之后，就无法维持这种超高速的增加，进入精细优化的阶段了，这时候咱们就须要开始关注如何去让这些服务的资源利用更合理，该还“技术债”了。
可是，咱们不但愿仅仅经过人工去运动式地清理这些技术债，而是但愿经过一种可持续发展的模式，经过系统自动化的去解决这个问题，而后把“技术债务”的清理从“运动式”的操做变成一个常规操做，决定开始全面推行对微服务治理工做。
Q3：服务治理，治理的是什么？
随着服务愈来愈多，后端系统面临2个重点问题，意识如何合理分配各服务资源，二是如何保障服务高效、健康的运行。目前，咱们的微服务治理体系包括三个层面：容量治理，流量治理，稳定性工程。
容量治理，是但愿利用自动扩缩容机制保障线上服务对资源的合理利用。
这就须要监控线上服务的负载状态，对服务的资源进行自动化调整，来保证冗余不会太高或太低。更精细化的措施是对线上服务作实时压测，根据容忍上限来分配冗余，咱们不要求全部的服务都作到高标准，但会设置一个基线来避免浪费。
流量治理，有2个目标：一是流量要可观测、可监控、可控制，二是管理要自动化。
举个例子，以前咱们作机房迁移时，有不到5%的流量不知道来源，因此不敢妄动，由于不知道会不会形成没法挽回的损失。所以咱们须要找OP和RD一块儿去追这部分流量来源，时间可能会很长。这种状况带来的问题是，咱们整个线上的流量状态实际上是不透明的，各服务间须要可观测、可监控、可控制。
另外，微服务改造后线上的链接关系变得复杂，模块数成倍增长，之间的链接关系也没法靠人力维护，面临的最大的问题是一旦服务出现问题，就要临时作一些降级和屏蔽，咱们不知道这个影响范围有多大，有多少重要的服务把它看成必选依赖了。所以，这方面的管理要实现自动化。
稳定性工程，就是创建一个稳定性监控和预警机制。
微服务改造让咱们的迭代效率变快了，资源效率变高了，但同时也让系统总体架构变得更复杂，咱们对系统可靠性的掌控随之变弱了。你愈来愈不清楚哪里会出问题，出了问题会有什么影响，上次新增的预案此次还有没有用……
半年前咱们出现过这个问题，一次线上故障之后，新增了一个干预接口，作了一个预案，当模块出问题的时候调用这个接口止损，当时也演练过，这个问题算close了。但半年后一样的故障再出现时再执行预案调用这个接口，发现这接口在某次迭代之后已经失效了。
所以咱们须要一个更系统化的机制来检测和验证系统的稳定性风险和咱们的预案有效性。
Q4：服务是随着系统规模增加的，怎样的容量治理框架才能知足咱们的需求？
在容量治理方面，咱们引入了全自动化的应用层的管理系统ALM（Application Lifecycle Management），这个平台上有一套比较完整的软件生命周期管理模块。咱们经过压测来自动构建每个app的容量模型，依此肯定合理的资源利用冗余。
2020年，咱们经过这种方式回收再利用的机器数量大概有1万多台。今年，咱们联合INF让负载反馈更实时，进而提高容量调整的实时性，与Serverless更近了。
Q5：流量治理方面咱们也是经过Service Mesh来解决可观测的问题吗？
是，也不彻底是。
一方面，与业界类似，咱们尝试经过Service Mesh来解决流量的管理和可观测的问题。
咱们引入了开源产品lstio + envoy，而后作二次开发来适配厂内的生态，以及大量的性能优化来知足在线服务的延迟要求。此外，咱们还基于lstio+envoy作了统一的Load Balance策略以及流量干预能力，好比流量熔断、流量黑洞、流量复制等。
如此一来，不少稳定性的预案执行，就不须要每一个模块单独去开发，而是经过mesh的标准化接口来执行，能最大程度地避免预案退化等问题。
另外一方面，咱们正在构造一个线上服务的Service Graph，也就是全局流量拓扑。
缘由是搜索和推荐的后端服务对延迟很是敏感，致使Service Mesh在咱们内部的覆盖率很难作到百分之百。所以，咱们把全局的服务链接关系单独抽出来，从Service Mesh和brpc框架获取和汇总服务链接关系和一些流量指标，实现对架构的总体可观测性。
咱们在brpc框架和数据代理层都按统一的标准格式存储了大量的、通用的“黄金指标”，包括延迟、负载状况等，用于观察整个系统全链路的流量健康状态。此外，咱们也在尝试应用Service Mesh的proxyless模式，把流量熔断、流量黑洞、流量复制等基础能力嵌入到brpc框架中，经过Service Mesh的控制指令下发渠道去控制。
如此一来，不管服务是否把流量托管到mesh中，在干预能力上的baseline都是一致的，这就是用一种标准化的方式去应对线上的异常，避免由于服务迭代致使的局部退化。
Service Graph 的一个直接的价值，就是提高了机房建设效率。
机房建设一般比较复杂，每一个服务都须要管理本身的下游链接关系，没有全局视图。所以在搭建新机房过程当中很难从几百个服务里发现个别配置错误，debug也须要好久。但有了Service Graph后，咱们对流量和链接关系就有了一个全局视图，发现问题就变得简单了。
Q6：稳定性主要是防患于未然，咱们怎么提早找到系统的“隐患”？
咱们在稳定性工程方面的建设，主要是自动化管理和混动工程。
稳定性工做一般都须要颇有经验的工程师来负责，但这在以前倒是一件隐性工做，缺乏度量机制，工做作得好时得不到正反馈，一旦出现问题就是你们都知道的事故，也没办法事前规避。咱们引入混沌工程主要解决两个问题，一是经过在线上注入随机故障的方式来发现系统中的稳定性隐患，二是尝试用混用工程的方法来量化稳定性工做。
在故障注入方面，咱们有从容器到整机、交换机、IDC、从局部到全局的故障注入能力，并联合OP开发外网故障和针对一些通用的复杂系统的定制化的故障。在线上，咱们有计划地随机注入故障，经过观察系统的表现，就能发现一些潜在的问题。
在度量机制上，咱们设置了“韧性指数”，来衡量线上系统对于稳定性问题的容忍能力。
好比对单机故障的容忍能力，能够经过混沌工程实验在线上挂掉一台机器，若是你的系统挂了，就说明不能容忍单机故障，这一项实验就是0分。
混沌工程的实验一轮作十几个或几十个，完成后打分，分值越高就能推断该系统越稳定。在分数设置上，越是常见的故障，分值越高，疑难复杂的故障反而分数较低。这是为了鼓励你们，重视常见故障而非剑走偏锋，把精力放在不常见却疑难复杂的问题上。
Q7：在自动化方面，咱们面临着怎样的挑战呢？
我以为有三方面，第一是用于作决策的数据怎么获取，第二是标准化的操做接口怎么设计，第三个就是如何基于数据去作操做决策。
在数据方面，咱们制定的黄金指标以及一些通用的负载相关的指标已经有了积累，在不断推动覆盖面。但一些相似服务等级、服务质量方面的指标，不一样业务可能有不一样的标准，若是须要业务以标准化的方式提供，就比较复杂了。如何制定统一的规范，是一个比较大的挑战。
标准化接口如今有两个：一个是云上实例的控制接口，也就是容量接口，能够经过ALM与底层PaaS系统对接；流量接口是经过Service Mesh控制面板来解决，目前还在推动覆盖。
一旦有了标准化的数据，和标准化的操做接口，中间的策略就不是一个特别难以实现问题。一般用简单的规则就能覆盖绝大多数场景。但这里的挑战可能更可能是在策略自身的决策灵敏度和准确率的平衡，可能在一些场景下，自动化操做的灵敏度太高，准确率就会降低，引发系统抖动。但灵敏度太低又会让问题得不到及时的解决，须要根据不一样的场景来设定不一样的策略。
Q8：聊聊对您感触最大的、思惟上的重塑
我以为不能只靠流程和规范来解决问题，要重视系统化，把流程、规范、经验沉淀到代码里，经过强化系统的可观测性，经过自动化的机制来控制和管理系统，去解决一些原来须要人工才能解决的问题。一方面，只有流程规范，人员的经验会随着我的的流失而丢失，咱们会反复犯一些历史上犯过的错误；另外一方面若是要开发新产品，还要再从头培养一批很是专业的维护者，成本过高了。
之前有个老的说法，是把OP作进架构里，其实干的就是这件事。
招聘信息
若是你对微服务感兴趣，请你联系我，咱们当面聊聊将来的N种可能性，另外，若是你想加入咱们，关注同名公众号百度Geek说，输入内推便可，期待你的加入！
推荐阅读
---------- END ----------
百度Geek说
百度官方技术公众号上线啦！
技术干货 · 行业资讯 · 线上沙龙 · 行业大会
招聘信息 · 内推信息 · 技术书籍 · 百度周边
欢迎各位同窗关注