vlambda博客
学习文章列表

导读：关于服务治理，业界的讨论比较多，但还没有一个统一的解释。从实践角度，很多从业者会把服务治理和Service Mesh绑定起来。而百度搜索引擎和推荐引擎的微服务治理，有着自己的特点和定义。Geek大咖说第二期，我们再次邀请到MEG推荐技术架构部的传玉老师，跟大家聊聊我们自己的微服务治理是怎么落地的，效果如何。

之前为了方便在内部去推服务治理，我们给了一个比较明确的定义：我们期望的服务治理是让我们所有的微服务都保持在一个合理的运行状态。所谓合理的运行状态，就包括：

• 所有托管服务的容量是合理的，冗余既不会过多，也不会过少；

• 所有托管服务是健康的，能够容忍局部的短期异常，同时不会有长时间的故障，在生命周期内能提供高质量的服务；

• 整个系统是可观测的，它的流量拓扑和主要的技术指标，都是透明、可观测、可监控的。

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做进架构里，其实干的就是这件事。

推荐阅读

｜

----------  END  ----------