共计 4181 个字符，预计需要花费 11 分钟才能阅读完成。
导读 ：对于服务治理，业界的探讨比拟多，但还没有一个对立的解释。从实际角度，很多从业者会把服务治理和 Service Mesh 绑定起来。而百度搜索引擎和举荐引擎的微服务治理，有着本人的特点和定义。Geek 大咖说第二期，咱们再次邀请到 MEG 举荐技术架构部的传玉老师，跟大家聊聊咱们本人的微服务治理是怎么落地的，成果如何。
全文 3864 字，预计浏览工夫 7 分钟。
嘉宾简介： 传玉
举荐技术架构部技术专家。2012 年起专一于搜索引擎与举荐引擎方向；2016 年开始负责自有的资源调度和容器编排零碎的研发工作；2019 年开始负责局部通用根底组件的研发工作，并开始在 MEG 用户产品外部全面推动云原生架构革新。
Q1：您怎么定义服务治理？
之前为了不便在外部去推服务治理，咱们给了一个比拟明确的定义：咱们冀望的服务治理是让咱们所有的微服务都放弃在一个正当的运行状态。所谓正当的运行状态，就包含：
- 所有托管服务的容量是正当的，冗余既不会过多，也不会过少；
- 所有托管服务是衰弱的，可能容忍部分的短期异样，同时不会有长时间的故障，在生命周期内能提供高质量的服务；
- 整个零碎是可观测的，它的流量拓扑和次要的技术指标，都是通明、可观测、可监控的。
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 说，输出内推即可，期待你的退出！
举荐浏览
| 百度搜寻与举荐引擎的云原生革新 | Geek 大咖说第一期
———- END ———-
百度 Geek 说
百度官网技术公众号上线啦！
技术干货 · 行业资讯 · 线上沙龙 · 行业大会
招聘信息 · 内推信息 · 技术书籍 · 百度周边
欢送各位同学关注
