满帮稳定性保障技术体系实践

前段时间在网上看到新闻，2 月 18 日南京市《关于优化疫情防控措施加快复工达产的通告》发布，全市 54 家规模化货运企业全面复工，为复工复业提供全方位的物流保障服务。这其中，就包括借助“满帮 App”无车承运人平台，开通网上定制货运，满足复工企业个性化货运服务需求。

借此机会，我向满帮信息平台技术部高级总监耿直了解了满帮信息平台的基础架构组成部分，了解是什么样的技术团队在支撑庞大的货运网络的。这里将具体的内容分享给大家。

耿直目前负责满帮 App 发货到找货整个链路中所有技术团队以及中间件团队的管理，涵盖 App、Web 前端、货源中心、车货匹配平台、用户中心、服务框架、监控、稳定性保障能力等非常关键的系统部门，总体在 160 人+。

满帮信息平台技术团队重大调整

2017 年加入满帮，耿直还记得当时整个信息平台分为客户端、服务端和基础平台。客户端承接整个公司所有 App 研发需求；服务端负责包含发货、搜货、运营三大领域；基础平台包含中间件、用户中心、短信、PUSH 等基础服务。

总体来说每个团队都很臃肿，没有自己的核心方向和目标，这对于团队的发展规划以及团队成员的成长非常不利。所以当时将整个信息平台架构进行了目标重组，拆分为货源、车货匹配、用户、中间件、基础服务和大前端六个团队。每个团队聚焦具体的目标，事实证明，这对后续的组织发展非常有利。

在系统架构层面，满帮信息平台到目前经历过两个阶段：单体应用和服务化，目前正在进入第三个阶段：平台化改造。

创业初期，因为业务简单，团队规模较小，满帮选择了经典的单体应用模式，随着业务体量、用户体量逐渐膨胀到快要爆发，单体应用从研发效率与稳定性上体现出各种不足，因此启动服务化建设。

据分析，当时业务体量最大的领域是车货匹配，包括系统并发量与迭代需求，如果将该领域独立为一组服务，那么 95%以上的稳定性问题和迭代效率问题将被解决。所以第一个服务化项目是车货匹配。在 2017 年初上线，并牵动各个系统做服务化改造，直到 2018 年 1 月，满帮第一个单体应用 logistics 服务流量掉 0 标志着服务化工作的全面完成。在这个过程中，技术团队同步建设了满帮的服务框架，监控等降低分布式服务复杂度的中间件和工具。

在业务快速发展过程中，信息平台架构是如何满足“可进化”需求的？

耿直说，做工程，不变的两个目标就是效率和稳定。伴随业务高速发展，因为人力有限，每个阶段都有不同的侧重点。这就需要在初期制定清晰的架构分层和领域边界，这样技术团队可以根据不同时期的需求分而治之。过程中每一个新的技术组件，新的业务服务建立，耿直都会带核心架构师参与，打下一个坚实的根基是至关重要的。

另外就是架构防腐，事实上大家也很清楚，很多起初优秀的架构在迭代 1-2 年后变得惨不忍睹，而这项工作是个苦活，需要不断的紧跟需求，阶段性代码 Review，抓出坏味道，一波波消灭。

制度和职业素养是保障稳定性的关键

稳定性是做工程的核心目标之一，在这方面满帮投入比较大，整体包括管理机制，管理工具，保障设施三大部分。

可回滚方案：确保所有线上变更是有后路，在出现问题时按照回滚方案执行后系统可退回到变更前的状态，这一点很重要，也是基本操作。

代码 Review：每次迭代上线前，各小团队 review 代码，主要看本次发布都改了什么，有哪些实现存在缺陷，可能在什么情况下导致什么问题，计划什么时间解决，如果因 review 疏漏造成的线上故障，第一责任人是代码 review 负责人。

设定代码质量指标：包含代码格式，基本逻辑质量，周度统计，责任到人，同样是基本职业素养。标准还在逐步提升，例如代码重复率等。

准入 Case 与通过率指标：每个迭代 QA 团队会产出一份准入 Case，这个 Case 目标就是保障整个测试流程畅通，不会因提测的代码 Bug 导致测试流程阻塞，影响测试效率。因为有明确的 Case 给到研发自测，所以指标要求是 100%。测试 Case 覆盖度，无论如何要保证测试 Case 覆盖 P1，P2 级故障。

稳定性负责人与虚拟团队：一位公司级稳定性负责人，虚线管理每个研发与 QA 团队的稳定性负责人，设立阶段性的稳定性与性能指标 KPI，包含可用性、响应时间、关键异常数量、告警数量、告警响应时长等等，每周稳定性会议上对上周数据进行 Review。

高峰期值班制度：因业务特点，每天早上 7 点到 10 点这三个小时是业务高峰期，所有核心系统在这个时间段内需要有人紧盯。所以制定了值班制度，与客服客诉在群里保持信息互通，确保任何系统问题可以经客服快速给予用户准确的答复，任何客诉问题值班同学可以快速上报到组织来解决。

例行压测制度：因业务需求迭代速度非常快，密集期每天都会有核心系统发布。所以每天晚上 8 点开始压测，在 2019 年全年，通过每日压测避免了 3 次 P1 级故障。

例行演练制度：在业务持续发展的过程中，系统微观架构每天都在发生着变化，如何做到核心链路稳定性不受影响是非常关键的，因为物理层的可用性是无法做到 100%的优秀，例如网络闪断，间歇性延迟上升是无法绝对避免的。业务也有可能在迭代过程中产生一些慢查询，那么持续的弱依赖、持久层灾难切换演练保障这些能力在故障发生时真的可用，所有人员具备快速响应高效执行的能力就变得非常重要，目前每个月都会围绕核心链路做一次故障演练。

标准操作流程与红线：主要针对运维与 DBA 团队，他们每天都要协助研发团队执行大大小小的线上变更操作，从部署架构到每一个线上变更操作的标准化可以避免因对环境与工具的特性不了解造成的故障。因此，研发团队非常重视线上变更的标准化与手册，并将其作为红线严格执行，避免操作失误引发的问题也能在团队内部传承。

以上属于管理机制范畴，接下来耿直介绍了管理工具和保障设施，下图是保障设施的整体架构：

（能力标准化与看护体系）

首先整体介绍下满帮系统的“看/护”体系：

“看”：包含告警，监控，诊断能力，用于从宏观到微观看住系统每一个点，出问题的时候可以快速的感知。

“护”：包含发布，压测 / 演练能力，用于保护系统尽可能不出问题。

这些能力的快速发展得益于对于稳定性核心模型与运维管控能力的标准化。下边我们分别看这些能力的细节。

全链路蓝绿发布机制：自动化灰度放量，秒级切流回滚，保证 RPC、MQ、JOB、Config 等全场景覆盖，尽可能缩小故障影响面与止损时长，核心原理不复杂，把每次项目发布涉及的系统纳入到一个发布组，在一个组内的灰度应用节点都会被贴上相同的标签。例如 G1，在网关层来读取灰度发布配置，将流量按配置也做相应的打标操作，在中间件层基于节点标和流量标路由，发布时首先发布涉及应用的一个对等新版本集群，网关只需要按配置给流量打标即可。将容器调度，镜像同步，应用启动这样比较重的回滚过程轻量化为打标逻辑，做到秒级回滚，任意粒度的流量管控，如下图：

（系统流量与灰度控制）

（流量调度机制）

（云平台灰度发布界面）

这个机制目前很多公司还是不具备的，后续满帮 App 团队会有专门的一篇文章公布技术细节。

全网变更事件流：在系统发生故障时，可以通过监控体现的故障开始时间，迅速定位当时对生产环境做出的线上变更，包含发布、配置、DB、网络、机器资源、乃至线上活动的变化，实践证明 80%左右的故障都可以通过历史事件记录找到问题根源。

（全局线上变更事件流）

上图可以看到各个时间点线上系统的状态变更记录，一旦有告警发生，工程师会在第一时间关注这里，可以很清晰的体现问题。

（监控全网异常大盘）

我们看到在每分钟的区块内，按应用聚合了这一分钟异常数量，区块右上角可以直接进入事件流系统查看临近这个时间点的事件记录，太多次线上变更导致的问题基于该能力得以快速止损。

线上压测机制：线下环境性能和线上有较大差异，线下压测体现出的问题需要经过架构师经验转化才能确保线上不出问题，这样做效率是较低的。单纯的线上压测并不难，难在如何避免给正常用户造成困扰。随后发现，满帮 App 业务只有货源搜索是对用户公开的数据，基于这个特性，给用于压测的用户打了测试用户标，并在搜索系统中实现了用户标与货源标的亲和，这样一来，用于测试的司机与货主在一套生产环境上就形成了两个内部业务闭环的用户群。基于这个核心特性，丰富了自动化工具集，以便高效的执行例如施压集群扩容，压测数据清理等工作。

在未来，QA 团队也计划将压测 case 移植到基于自然流量的录制与重放能力上，免除人工编写压测脚本的复杂度。

故障演练平台：业务的弱依赖与降级对系统容灾能力来讲是非常重要的，如何保障核心链路的容灾有效性与覆盖度是重中之重。

（弱依赖演练快照）

如上图，试一次系统弱依赖演练快照，我们可以看到该次演练的接口依赖 10 几个外部系统提供的 API 完成自己的业务，这些外部依赖有部分是弱依赖，持续高效的检验它们的有效性就由该系统完成。

满帮利用混沌工程概念来实现这一点。这也得益于阿里巴巴开源的用于混沌测试的工具 Chaosblade，满帮研发团队在其基础上二次封装命名为 Venom，适配满帮中间件体系，解决了故障注入过程慢的问题，以及一些必要的可视化管理工具与混沌工程 AB 对比工具用于提升演练效率，该平台 2020 年投入研发，目前仅支持系统弱依赖覆盖度演练，在未来的迭代计划中它还将支持演练计划自动生成工具，演练报告等功能。

运行时元数据平台：在稳定性能力的持续建设过程中发现，无论是监控溯源还是故障演练，工程师都需要清晰的知道系统每一分钟的运行状态，一个应用运行了几个 JVM？这些 JVM 在哪些容器里？这些容器运行在哪些物理机上？他们实时在和哪些远程主机通信？因此在物理层，容器层，JVM 层都做了实时信息采集 Agent，并将这些信息上报到运行时元数据平台，它就像一张地图，在故障发生时告诉工程师是哪出了问题，在故障演练时告诉工程师在哪注入故障。

除此之外还包括一个较为重量级的产品，满帮监控治理平台 Hubble，提供 APP、微服务、中间件、物理资源一站式监控、追踪、诊断能力。

稳定性的原则与目标导向

首先是要有敬畏心，制定较严格的故障定级标准，满帮技术团队认为，超过 15%的用户就是大部分用户，大部分用户超过 5 分钟不可用就视为 P1 故障。端上涉及核心链路的卡顿都有严格的分类指标，过慢的相应即视为不可用。

其次是可靠，所有稳定性预案建设必须配合压测演练，用于论证有效性以及执行难度，过于复杂的预案都会通过工具来降低复杂度，例如降级一个场景需要操作很多个开关，过程中还要保证顺序，不是任何一个人 1 分钟都可以做到的，可靠性较低。即增加了预案管理工具，会按照预定的顺序执行一组开关将一个业务场景降级。

然后是高效解决问题，线上一旦出现告警，则要求 1 分钟内响应，5 分钟内止损。

最后是所有事情要闭环，所有线上故障事后务必有复盘，包括故障发生过程、问题总结、后续 Action、责任人、时间点。并且由稳定性负责人跟进。

光说不练假把式，所以团队也会做很多演练，每周一次全链路压测中会针对发货搜和货场景的大多数预案进行演练，比如 MySQL 单点故障，Redis 单点故障，会员服务故障等，确保需求高速迭代过程中所有预案的可靠性。

高峰时期如何实现容灾？

从货运业务情况来看，每天早晨 7 点到 10 点都有一个相对的早高峰，流量相对平缓，不像电商搞大促那样激进，因为这个期间司机和货主都在紧张工作，系统出问题会给他们的工作造成很大的麻烦。所以耿直说，技术团队对于高峰期的稳定性也同样非常重视，这个期间务必保证系统核心场景（注册，登陆，发货，搜货，隐私电话，成交）可用。

大多数情况考虑在应用、中间件、基础设施三个层面做容灾即可解决绝大多数问题。其中应用层做了系统依赖关系梳理，在弱依赖系统发生问题的时候，做到一键降级，保证核心链路可用。

中间件方面主要考虑了 RPC 框架和配置中心的高可用，其中 RPC 框架注册表有本地容灾机制，当注册中心不可用的时候，本地缓存还可以持续提供服务。

对于 RPC 协议和框架当初选择了点评的 Pigeon，经受住大规模生产环境考验，而且整个监控体系有开源的 CAT 也比较完善，这一点在当时比起 Dubbo 要强很多，技术团队不用费多大力气就可以使用非常全面的功能。因为设立了专门的团队维护，在实际使用过程中遇到的各种问题也可以很好的解决。耿直说，这里很感谢点评可以开源这些开箱即用的基础设施，研发团队也在持续强化这些中间件的功能与体验，使其具备更优的使用体验更满足云原生架构要求，这些内容后续也会通过文章等形式与大家分享。

配置中心目前采用 Zookeeper 搭建，为规避它的短板而建设了本地容灾能力，避免配置中心宕机服务无法启动的问题。MySQL 和 Redis 都采用了高可用架构，避免单点故障影响核心业务不可用。基础设施方面，目前阿里云提供了同城多异地容灾机制，不过满帮认为这是不够的，今年打算开始考虑多机房容灾以及单元化架构。

通过规则制度帮助技术团队找到工作快感

大部分技术人非常渴望成长，享受解决各种难题所带来的快感。

对于 Tech Lead 来讲，除了指对方向，设有吸引力的目标，传递方法之外，更需要造一个场。这个场要给大家带来工作的兴趣，且结果能让人愉悦，从而转化为成长的动力，这是非常重要的。要做到这一点，满帮技术团队每周回顾工作，Review 周报，关键项目需求，各团队的配合度，迅速组织闭环解决一线研发的痛点，卸除包袱。

每个季度的开始，会对上一个季度的 OKR 执行情况进行复盘，重点关注非常精彩的以及没有完成的部分，对于超出预期的结果，一定要让当事人有站在舞台众人瞩目的感觉，并且向团队传达标杆的属性，引导更多的人向其学习。对于没有完成的部分，挖掘问题的本质，做出相应的调整。半年度会进行实际的绩效考核行为，例如人员优化，职位调整等，这是组织优化必须的动作。

在 OKR 设定中，业务支撑是及格线，更关注架构升级带来的稳定性与效率提升或者业务指标的拉升，这是研发人员希望去做的事情，有自上而下的也有自下而上的，都会迅速调度资源帮助其落地。

另外每个季度结束后会举办一个开放日，会邀请核心业务方一起对上一个季度的业务、产品、技术 OKR 做一个回顾。加深业务、产品、技术间的了解。让所有人看到满帮 App 技术团队都做了哪些改变，达成了什么目标，以及下一个季度的展望。