余额宝自 2013 年上线之后，目前存量已经突破万亿，用户规模达到 5 亿以上，为了支持这样的用户体量，余额宝不断地对现有 IT 架构进行优化和治理，

余额宝负责服务治理的核心团队是服务治理委员会，该委员会的成员大约为 8 人，包含了架构师、服务开发团队的 TeamLeader、运维等。据李鑫介绍，治理委员会每两周有固定会议，集中分析这段时间内相关的服务度量指标分析报表，包括线上服务集群的性能趋势、容量趋势、健康度趋势，整体调用关系质量变化趋势、服务运维质量，以及线下的研发开发效率趋势、研发协同配合度等等报表报告，并在此基础上讨论相应的管控措施、管理改进决策及落地计划。

在治理能力构建方面，余额宝没有设置专职人员，而是由开发团队统筹负责，架构师牵头进行相应的治理能力方案设计，把治理能力的开发工作作为架构优化统一排入迭代开发中，然后再安排相关开发人员来实现。

余额宝服务治理的方法论  

与其它行业相比，金融行业在服务治理方面有哪些特有的挑战呢？

首先，由于金融行业，尤其是互联网金融行业，属于国家强监管行业，涉及到巨额资金流动，因此安全合规是系统开发设计的首要考虑因素。

其次，服务化的根本目标之一是让应用更“轻”，提高研发效率，让线上应用开发和部署更快。如何平衡安全和合规监管的“重”与服务化的“轻、快”之间的矛盾，也是金融行业服务化的一大挑战。

第三，互联网金融领域普遍秉持的是“谋定而后动”的原则，上线一个功能需要经过缜密的设计和重重审核，很难像其它互联网应用领域那样进行频繁的“试错”，服务治理也不例外。

李鑫表示：“余额宝在服务度量方面，利用收集到的线上线下各个维度的指标来进行部分安全及合规的分析，例如，基于服务访问日志做用户行为异常分析，基于研发过程指标生成流程规范性分析报告，这也算是服务治理能力的一种‘扩展’。此外，支撑我们服务化的研发 CI/CD 流水线会比一般公司更复杂，因为额外增加了一些发布检查及审核的环节，并且有一些本来可以是全自动化的运维管控流程也增加了人工审核环节。”

余额宝的服务治理没有非常具象化的系统或者平台，而是分散在包含监控、线上运维、数仓等多个平台之中。

“但这并不意味着治理能力的分散，相反，我们有一套很完整的服务治理方法论及策略。”李鑫表示：“我们对服务的治理覆盖线上和线下两大领域，并按服务的度量、管控、管理这三个层次来划分及组织服务治理能力。”

在这三个层次中，服务度量是最核心和最基础的，它解决的是服务可观察性的问题。只有解决了“看”的问题，才能在此基础上进行服务的管控和管理。服务度量主要是采集线上的访问日志、系统日志、调用量、访问延时、异常、调用关系及线下的服务开发、测试、运维等各个维度的指标，汇总后再进行统一的度量和分析。为了度量方便，专门开发了度量大盘，为各种服务度量分析和相对应的管控举措提供统一的入口门户。

针对线上线下的指标，余额宝也有不同的获取方式。如果是在线上，可以通过服务注册中心获取到服务的注册信息及服务的管控指令信息，通过各个微服务主机节点上的主机日志、应用及服务日志、APM 监控的调用链日志，获取到相关的性能及异常指标信息；如果是线下指标，可以通过需求管理系统采集到服务相关 UserStory 及各类需求的基本信息，通过项目管理系统采集到开发人员、开发团队、开发任务的基础信息，通过测试相关的管理系统采集到测试用例及测试 bug 的相关定义信息及过程指标信息，通过源码仓库及软件版本仓库采集到最终研发产出物的基本信息等等。

另外，还有一类治理度量指标——从各种协作模式的相关过程管理系统中抽取出的的过程指标事件。常用的协作模式包括针对开发和测试之间配合的持续集成（CI），针对产品、开发、测试的敏捷协作模式，针对 DevOps 的 Pipeline 等。常见的过程指标事件包括任务何时完成设计，何时进入开发，何时完成开发等等。

这些线上线下指标会被统一汇总到数据仓库进行进一步的深度度量和分析。

其中一部分的线上性能及异常指标会被转化为运维事件，一旦触发预先设置的阈值，就会更进一步被转化成“管控指令”，通过调度中心下发，进行服务的弹性伸缩、扩容缩容操作，或者进行服务的限流、降级、容错、路由调整等管控操作。

而另一部分度量指标，包括线上的性能、异常，以及线下的架构、开发、测试、运维、过程协作效率等会通过层层的维度汇总，最终生成服务的性能趋势分析、容量趋势分析、健康度分析、架构合理性分析、开发及协同效率分析等分析报告。服务治理委员会会定期对这些分析报告进行人为的深入分析，并制定出治理决策，这些治理决策会通过相关的管理措施进行落地。

通过服务的度量、管控、管理这三大举措，余额宝构建起了一个三位一体、围绕服务治理的闭环体系。

在服务治理工具的选型方面，李鑫表示服务度量以自研为主，包括线上线下指标的采集、传输、存储、分析等，服务管控能力主要是依托蚂蚁金融云的现有能力来实现。服务度量选择自研的主要原因，一是业界没有现成的一体化产品可供开箱即用，即使有，也要解决与服务框架适配性的问题；二是因为自研可以根据自身的需要，灵活开发指标的采集粒度及分析粒度。

余额宝的服务拆分与整合  

服务化的本质就是一个“拆”字，原来的单体应用被拆成了大大小小的应用集群和服务集群，并被分散到网络的各个节点，由不同团队负责。这个时候，传统意义上的架构师的职责实际上是被弱化了，对应用及服务的规划、架构、设计能力更多的被下沉到一线团队，由开发人员直接承担。但是每个团队的整体能力及风格各不相同，服务切分及设计的尺度很难做到完全统一。这种情况下，如果对架构完全放任不管的话，往往会导致随意创建服务、服务滥用、服务能力冗余等一系列问题。

因此，李鑫认为在分布式环境下做服务化拆分，更要加强对服务集群整体架构的掌控，防止架构“劣化”。要做到这一点，最重要的就是对线上服务进行有效的梳理。在服务数量比较少的时候，架构师还勉强能将服务之间的调用关系梳理清楚，一旦服务数量膨胀，服务之间的调用将构成一张非常庞大和密集的“网”。这时候，依靠人工来梳理服务调用关系是不现实的，需要借助一些自动化的手段。

据了解，余额宝在服务梳理方面主要采用了两条“链”，动态调用链和静态调用链。

很早之前，余额宝就在服务框架的基础上构建了 APM 能力，动态调用链跟踪是它的核心功能，基本上是参考 Google 的 Dapper 论文来实现的。调用关系发现是动态调用链跟踪的一个基本能力，只要经过足够长时间的调用日志积累，它就能勾画出足够详细的线上服务和服务之间、服务和资源之间的调用关系。

不过，动态调用链成于“动态”，也受限于“动态”，它只能在运行状态下生效，而且，必须是有埋点并实际发生的调用才能被监控和采集数据，不管这个埋点是手工埋点还是自动埋点。而线上的很多服务往往存在大量的冗余分支和异常处理逻辑，这些分支及逻辑，需要在特定场景下才会被触发，甚至有的可能永远都不会被触发。因此，动态调用链勾画出的只是系统全貌的一部分。

为了弥补动态调用链在服务梳理上的不足，余额宝团队决定基于源码来梳理服务之间完整的调用关系，并开发了一套对源码仓库中所有工程源码进行统一扫描的工具。该工具的核心是 eclipse 中负责源码解析的 AST 组件（Abstract Syntax Tree，中文为抽象语法树）。通过 AST，可以获取到源码工程中任何一个 Java 源码文件中所调用的外部类、继承或者实现的接口（父类）、类变量集合、类方法集合、方法逻辑块（多层嵌套）、注释等等基本信息，有了这些基本信息之后，通过对代码的逐行扫描，并基于一系列的正则及其它匹配，就可以获取到一个方法对其它方法的调用关系，汇总之后，最终构建出一个跨工程、方法一级的庞大的调用关系矩阵。微服务之间的调用关系是这个调用矩阵的一个子集。由于这个调用关系矩阵和基于动态调用链路跟踪所获取到的调用链路非常类似，因此，李鑫把它称之为静态调用链路。

基于动态调用链和静态调用链可以做很多服务集群整体宏观架构及微观架构上的梳理及优化工作，如服务的回环调用检测、调用深度检测、集中调用检测、对外依赖度检测等等。此外，将动态调用链和静态调用链叠加，还可以梳理服务的冗余代码，为其“瘦身”。

服务拆分与整合  

实现服务化必须要做的就是拆分和整合服务，在李鑫看来，服务拆分与整合本质上可以分解为两个问题，即服务的判定问题和服务的切分粒度问题。

判断一个功能是否要封装为服务的原则其实很朴素，就是看这个功能在业务或者技术上是否具有通用性，如果有，就把它从具体应用中拆出来，封装成服务，比如余额宝的申购、赎回，会在直销和代销等很多业务场景下被调用，就可以把它以独立服务的形式进行封装和部署。另外，对短信网关这类基础资源的调用，由于要做一些鉴权及流控，也可以将对资源的访问封装成服务，供各个业务系统统一调用，以降低调用的难度。

而服务的切分粒度是一个“仁者见仁，智者见智”的尺度问题，不同的开发人员来划分，结果也不尽相同。据李鑫介绍，余额宝虽然在这方面没有强制的规范，但是大家会遵循几个基本原则：

• 首先服务要完整体现一个单元能力，不管是业务能力还是技术能力；

• 其次，除了聚合层服务外，服务能力要尽量自洽，也就是说，服务调用其它服务的数量尽量控制在一个合适的范围，建议不要超过 10 个。

• 第三，服务粒度不是一成不变的，随着功能不断演进，服务的粒度也会膨胀，因此需要定期审核服务，如果粒度膨胀的太厉害，就要进一步拆分。我们也可以利用自动化的代码扫描手段来辅助进行服务的粒度判断。

余额宝系统的能力拆成大大小小的服务之后，根据这些服务所承载的能力及调用关系，可以划分成 4 个层次，从底至上依次为 PaaS 服务层，基础业务服务层，应用业务服务层、聚合服务层。

• PaaS 服务层主要承载针对底层资源的能力调用，包括存储、缓存、消息队列、短信网关等资源。由于余额宝整体能力构建在蚂蚁金融云上，所以除了自身开发的部分能力外，大部分能力是由蚂蚁金融云提供的。

• 基础业务服务层包含了基金销售的一些通用基础业务能力。根据服务所属业务领域不同，余额宝又把这一层的服务分为八大类，包括账户服务、资产服务、交易服务、支付服务、智投服务、配置服务、结算服务、卡券服务。每一类服务都独立打包及部署，所以余额宝内部也称其为 8 大服务中心。

• 应用业务服务层更多是按产品线来划分，包括直销业务服务和代销业务服务。这一层的服务主要面向产品业务，一方面基于基础业务服务层的 8 大中心服务来构建直代销的基金销售业务，另一方面，也构建适合自身业务特点的业务服务，比如活动拉新、客户营销等等。应用业务服务层的存在对后台基础业务服务起到了有效的封装和适配作用，可以让前台应用不用写太多的封装代码就能快速的构建出新的能力，从而保持前端应用的“轻”和“快”。可以说它实际上承载了业务中台的职责。

• 聚合服务层，顾名思义，主要对服务做聚合。它并不承载太多的业务逻辑，主要是将应用业务服务层及基础业务服务层的服务根据前台需要做简单的能力聚合，并以 API 服务的形式暴露给前端调用，所以也可以称其为网关层。针对这一层服务的调用，余额宝会在框架层上添加很多安全校验。另外，限流及降级操作也是主要在这一层上进行。

余额宝服务治理的经验分享  

目前余额宝的服务治理体系的整体框架已经搭建起来了，治理指标体系也相对完整的覆盖了线上和线下。在李鑫看来，现在余额宝的服务治理体系可以打 70 分，不过，服务治理是个持续迭代的过程，在不同时期总会遇到新问题，这些问题可能是服务自身的规模、容量的变化带来的，也可能是新技术的引入带来的，比如运维引入容器技术后，直接改变了服务的生命周期管理手段，服务治理的相应管控手段也要随之调整，等等。

除了应对当下的治理需求之外，据李鑫介绍，余额宝也有一些长期治理能力建设的规划，例如针对线上服务的故障定位定界，做智能根因分析的探索，主要通过梳理服务调用关系和在 CMDB 的资源依赖关系基础上，再结合关系网络算法，构建了相应的故障传导模型；针对服务集群的性能及容量规划做更长周期的趋势预测，提升资源利用效率等等。

针对其它想要做服务治理的团队和技术人员，李鑫给了以下 3 条建议：

1、建议优先构建服务的度量监控能力，只有先解决了“看”的问题，才能解决“管”的问题。

2、服务治理能力有一个积累的过程，在资源有限的情况下，不要一开始就追求大而全的治理平台。余额宝在构建治理能力的早期，很多度量报表的指标采集和报表生成都是直接写个小工具和小脚本，并配合系统定时器定时调用来实现的。等到能力成熟之后，可以慢慢的优化改造成系统。

3、不要限制自己的想象力。服务治理本质上是为服务化保驾护航的，只要能达到这个效果的手段都是好的治理手段，例如基于代码扫描获取服务的静态调用链路就是余额宝团队拍脑门想出的点子，在服务治理能力构建上，敢想敢干很重要。