今天我想和大家聊聊蚂蚁金服和自研技术。说到蚂蚁金服，大家很容易联想到中国新四大发明之一的支付宝，从支付宝的担保交易到风险识别、智能客服，再到更加基础的数据库、中间件以及大数据平台，这些技术实际上是蚂蚁金服在完成自身业务挑战的基础上进行的大量创新和发展。

如今，很多行业中的企业都开始考虑发展自研技术，不仅仅是互联网行业。我希望能够借此次机会将蚂蚁金服多年来在发展自研技术方面的实践与思考分享给大家，希望能够带给行业一些启发。

1995 年，我第一次加入高校的实验室，当时选择的是数据库方向。之后八年，我一直在做工程数据库方面研究的工作。2003 年，当时国家给了我们一个很好的机会，我们就在思考是否可以借此将目前的技术商业化，之后就做了 11 年，直到 2014 年，我加入蚂蚁金服。作为国内早期的自研数据库团队，我们起初发展得并不是很好。虽然技术一直在发展，但我们始终没有找到一个真正成熟的商业应用场景。当时国内的市场环境也并没有给技术迭代足够的时间与空间。但就是在那几年，我们共同见证了商用技术在整个中国的快速兴起，直到今天，它们依旧是绝大多数行业的主流。今天数据库领域常说的 IOE 其实就是商用技术产品的代表，IOE 本质是基于单机视角的集中式架构，在该架构中，硬件主要解决系统可靠性和扩展性问题，而软件用来提供功能集成。

站在业务视角，这种架构是近乎完美的，最好的产品和最好的服务结合，当然价格也比较昂贵。大概在十年以前，整个互联网行业进入快速发展期，集中式架构在扩展性和成本方面的问题越来越严重，特别是在经历了双 11 大促这样的场景之后，所有人都可看出集中式模式在互联网行业基本走到了尽头。因此，系统从数据和业务两个层面开始去中心化的过程，高端硬件被普通 PC 服务器取代，系统的扩展性和可靠性问题交由架构和软件解决，分布式中间件在这个时期得到快速发展，并迅速成为互联网企业的架构核心。

开源技术由于其灵活和可快速定制等能力很快在互联网行业得到普及。此外，文化也是一个重要影响因素。在多数互联网企业中，IT 技术人员的比例早已超过 50%，在这样一个崇尚自由创新的企业文化的影响下，只要技术可被替代，商用技术就再也没有生存和发展的土壤。

近几年，以蚂蚁金服为代表，自研技术开始兴起。一方面，自研的分布式中间件经过数年场景沉淀已经完成整个企业从研发到生产的全面覆盖，进而演化成了具备行业属性的企业级分布式架构。另一方面，更加基础的自研技术，比如分布式数据库，也开始诞生并发展。那么，为什么会出现这样的趋势呢?

首先，经过不断业务场景挑战之后，我们已经越来越多地触碰到已有商用技术和开源技术的天花板，我们需要通过发展自研技术解决这些问题。同时，当企业的产品和服务同数亿个体的日常生活紧密关联时，从企业内部开始诞生对核心技术自主可控的诉求。

今天，我们看到越来越多的平台型和生态型企业出现，这些企业从过去的关注自身开始更多的关注整个生态，开始思考如何对生态赋能。商业赋能的本质是技术赋能，这就要求技术最终可以变为产品，无论是基于开源技术进行深度定制，还是完全从头开始的自主研发，在我看来殊途同归，重要的是自研才是技术走向产品的必经之路。

回顾蚂蚁金服整个自研技术多年的发展历程，我们发现有三个问题是非常重要的，换句话说，今天的企业想要发展自研技术需要先思考这三个问题：

第一个问题是技术的主场在哪里?

过去的实践证明技术不只是被研发出来更是被应用出来的，我们需要找到一个相对可控的市场为自研技术的迭代创造足够的时间与空间，帮助技术团队渡过早期的产品脆弱期，这一点非常重要。如果没有这样的主场，那就意味着技术团队不得不在技术尚未得到充分验证之前，就投放到竞争性的市场之中，这样做的后果只有两个，要么你把客户玩死，要么你被客户玩死。最终，技术团队只能在一些企业的边缘化应用中不断试用。国内早期的许多技术团队都在发展过程中面临过这样的问题，只能投入大量的技术力量满足客户在边缘化应用中无休止的功能细节，整个团队无法从这样的市场活动中有效获取资源，无法进行大规模的技术创新，也无法保证核心团队的稳定。

第二个问题——技术的核心价值是什么?

十年以前，我们觉得做技术尤其是数据库这样的基础技术，必须要由专业的公司来做。如今，这个边界变得越来越模糊。因为，在一个商业生态非常成熟、竞争已经非常充分、以存量为主的市场中，所有新进的技术必须有自己的核心价值，必须有差异化的地方，所以，技术创新非常重要。技术创新从哪里来? 只可能从行业实践中来。今天，我们发展自研技术不能只是为了满足自主可控，如果只是一味的追逐模仿商用技术，或者简单的基于开源技术的拿来主义，技术团队本身很难从这样的研发过程中持续获得正向价值激励，企业也很难基于这样的技术和产品打造良性健康的生态模式。

第三个问题——技术如何变为产品?

企业发展自研技术的目的是什么? 只是为了解决自己的问题? 还是将来有可能解决更多人的问题? 在整个自研技术发展早期，技术团队通常没有太多精力思考这类问题，但是技术团队的领导者需要在一开始就想清楚这些问题并制订相应的技术路线。首先是自己要坚信不疑，该技术路线会在今后很长一段时间给技术团队带来持续影响。即便是像数据库这样已经高度标准化的技术，在过去几年的发展中，我们也经常面临过在如何支持业务快速上线和如何保持技术的通用性之间的选择。如今，我们很难说过去做的每一个选择都是正确的，但是，不管如何选择，技术团队要有一颗产品的心。

如何找到自研技术的主场? 当然是企业的自有业务，这是一个非常自然的逻辑。如果我们发展的自研技术连自己都不敢用，我们很难说服其他人使用。但是，企业光有自有业务是不够的，企业发展自研技术需要考虑三个方面条件：

一是有想法，发展自研技术，企业是主体，企业自己有这样的诉求是自研技术长期发展的根本动力。一方面，对于发展自研技术要解决的问题必须要有明确定义，要有现实存在的业务痛点，否则，技术团队很难获得足够的动力和压力; 另一方面，对于要解决的问题必须要有明确的技术路径。如果只有问题，没有路径，那就变成了单纯的提需求。

二是有能力，我们既需要具备足够的技术力量保证技术从路径到实现，又必须有完整的技术保障体系控制自研技术在应用过程中的风险。自研技术的应用始终是一项高危工作，自研技术的最终的目的是应用到生产环境，风险控制是自研技术发展过程中非常关键的问题。如果无法控制风险，就会最先甚至导致企业生产运营面临风险严重威胁，那么，企业发展自研技术就是一个伪命题。

三是有担当，决策者的担当 (决策担当)。即使当技术能力具备，风险也可有效控制时，我们就需要决策担当能力。即便风险可控，我们也仍然无法知道真正把自研技术用于核心生产的一刹那究竟会发生什么，我们的团队在过去几年碰到过这种困境，一步天堂、一步地狱，决策者的担当此时将发挥关键性作用。因此，我们建议，企业发展自研技术必须要有决策担当是一把手工程。

如果只有决策者没有足够的担当并无法对可能的结果负责，单单依靠系统支撑技术团队自己，最后的结果很可能是技术团队由于无法创造足够的业务价值而逐渐消亡。

近几年，OceanBase 这几年在蚂蚁金服的发展过程是一个非常典型的自研技术在企业内部落地的过程。OceanBase 最早于 2010 年诞生于当时的淘宝，整个团队发展的头几年，我们一直处于寻找稳定应用场景的过程。虽然，我们支持了类似收藏夹这样的项目，但当时整个团队很多情况下实际上是处于一个边缘化的生存状态。

之后，我们加入蚂蚁金服，也就是当时的支付宝。加入蚂蚁金服之后，我们很快遇到了一个很好的机会。当时，蚂蚁金服的核心业务大量使用商业数据库，技术团队面临的最大需要回答的问题就是当商业数据库许可到期以后，应该怎么办? 是购买更多的许可? 还是寻找合适的替代品? 基于这个大背景此时，由决策者出面，将蚂蚁金服 10% 的交易流量数据切换到 OceanBase，这也是我们团队第一次有机会承接蚂蚁金服的核心业务。

此时，当时蚂蚁金服的分布式峰值架构已相对成熟，我们有一整套完整的产品风控灰度发布体系，能够控制住新产品上线的风险，甚至在业务层面进行了大量改造来保证对整个系统的顺利运行进行托底。即便如此，依然没有人可以保证，当双 11 时、流量迅速攀升时，OceanBase 可以顶住。与此同时，内部质疑从未停止。当时的蚂蚁金服已经使用了大量开源数据库，既然有了可靠的开源数据库，为什么还要冒险使用 OceanBase 呢? 此时，想法和能力都不管用，决策和者的担当再一次发挥了关键作用。了解 OceanBase 发展史的朋友应该都知道，我们团队在技术历史上几次面临危险关键时刻都得到了贵人相助，而这些贵人就是当时在关键点位置上的决策者。如果没人没有决策者的担当，那么蚂蚁金服的自研数据库团队早就不复存在。

2014 年，OceanBase 支持了蚂蚁金服 10% 的交易流量，整个自研团队迈出了重要一步。2015 年，OceanBase 支持了 100% 的交易和 50% 的支付，交易成为第一个完整支持的核心业务。2016 年，OceanBase 支持了 100% 的交易、支付，甚至以及包括上层的账务、会员在内的更多的核心业务。

在支持账务层面这件事情上，团队再一次面临关键考验。熟悉金融系统的嘉宾应该知道，账务是一个状态性型业务，同比流水型的交易、支付相比，的数据模型处理逻辑要复杂得多，容灾逻辑也要复杂得多。

实际上，业务团队已没有太多工作可做经不能托底了，剩下的事情必须靠数据库完成自己去解决。此时，业务团队选择相信 OceanBase 我们，然而我们团队的压力空前巨大，如果双 11 当天数据库中的数据出现问题，这会对蚂蚁金服产生很严重的后果。幸运的是，我们最后扛过来了。

2017 年，OceanBase 终于迎来了重要的里程碑事件，完成了我们把蚂蚁金服全部所有核心业务部门中的商业数据库的都去掉了替换。也就是说，蚂蚁金服通过发展自研技术，用了将近 4 年的时间，通过自研技术把核心业务中的商业数据库全部换成了自研数据库实现了对于核心数据库的自主可控。开句玩笑，在今天的中国，即便商业数据库被禁售，和开源数据库都不可用被闭源，蚂蚁金服我们也不怕。

自研技术在企业内部的落地，尤其是实现对在核心业务的支撑落地，是一件长期而艰难的工作。尽管如此，我们还是要回答一个问题——如何打造自研技术的核心价值。蚂蚁金服对这个问题的答案非常简单，就是用业务场景驱动，持续给技术团队巨大压力，跟得上就继续发展，跟不上就被淘汰。蚂蚁金服本身从不缺这样的业务场景，今天我们遇到的很多技术挑战，在整个行业乃至世界范围内都是前所未有的。这里，我可只列举三点，：

一是极致的扩展能力，在过去八年的双 11 大促中，蚂蚁金服支撑的交易峰值提高了 500 多位倍，数据库处理峰值已超过每秒 4000 万次。但是，没有人可以预测最高这个峰值未来会涨到什么程度。对蚂蚁金服的所有技术团队来说，重要的是不让技术和产品成为阻碍业务发展的瓶颈。

二是极致的容灾能力。我的手机经常会收到一些推送消息，比如，系统将在今晚 11 点到明早 8 点之间进行维护升级，在此期间，某某服务将暂停使用。我相信大家和我一样经常收到这样的消息。试想一下，如果支付宝暂停服务几小时会怎么样，以蚂蚁金服今天所承载的交易量来看，不要说几小时就是几分钟都会迅速演变成巨大的社会性问题。因此，保持业务极致得的可连续性的要求是悬在所有技术团队头顶的一把剑。

三是极致低的成本。我们今天所面临的线下支付场景，比如共享单车、地铁公交，如果不能把单笔交易的成本控制在极低的水平，那么普惠金融对我们来说就永远只能是个梦想。对蚂蚁金服而言，所有的使命和愿景最终都会转化为技术能力。

如何应对这些金融级的技术挑战，架构是非常关键的。目前，我们在业内可以参考到的业务方案只有两地三中心。两地三中心是在一个城市部署两个活跃的数据中心，在另一个城市部署一个灾备中心，这是目前决绝大多数金融机构广泛使用的跨数据中心的扩展性和跨城市的容灾方案。

如果仔细分析观察就会发现，该方案存在一些问题。首先，从扩展能力看，由于核心业务只能被部署在活跃的数据中心，所以该方案无法解决核心业务跨城市扩展问题。换句话说，从业务角度来看，两地三中心的本质是同城双活; 其次，从成本来看，由于灾备中心只在极端容灾场景下被启用，所以整个系统的资源利用率较低，相对应的成本就会升高; 最后，从容灾影响能力来看，整个系统正常运作时，灾备中心始终处于冷备模式，所以系统容灾时可用性较低，容灾切换风险较高。因此，在两地三中心的架构下，如果真的发生城市级故障，我们通常也不敢把业务切到灾备中心，只能等待故障的数据中心恢复，在这个过程中，系统是无法恢复提供服务的。

两地三中心的本质是同一城市内跨数据中心的扩展性和可用容性方案。对蚂蚁金服来说，支撑亿级的交易规模和保证 99.99% 的可用率都需要对现有架构进行升级，从同城双活变为异地多活，从跨数据中心变为跨城市。由此，蚂蚁金服开始了对单元化架构的技术探索。

单元化最初是支付宝用来解决业务和数据拆分后数据库连接数过多的问题，通过更多的场景沉淀，单元化架构今天已经成为蚂蚁金服异地多活和容灾架构的基础。，单元化架构也是蚂蚁金服自研的金融级分布式金融级架构 SOFA 的核心能力。，单元化架构的本质是将系统进行水平拆分或数据后的逻辑隔离，单元化中的每一个单元都具备更小的规模，但拥有完整的功能，从金融接入网关到应用服务器再到数据库，每个单元依据规则支撑一定的流量和数据。

单元具备四个重要特性，一是自包含性，比如账户充值交易所涉及的所有计算和数据都会被封闭在一个单元; 二是松耦合性，单元之间只允许进行服务调用，不允许直接访问数据库或其他存储，对于必须跨单元的操作，比如位于两个不同单元之间的用户转账交易，服务调用需尽可能少，同时在不影响客户体验的情况下，尽可能异步化。这样，即便两个单元相距较远，整个系统的响应也不会受单元间距离访问延迟的影响; 三是故障独立性，一个单元的故障不会影响其他单元; 四是容灾性，单元之间相互备份，每个单元都保证在发生同城或异地故障时有可切接管的单元，单元之间的备份方式是使用自研数据库提供的多地多中心的一致性方案。

通过单元化架构，首先实现，系统的伸缩问题变成了单元的增减问题，而在此过程中，整个单元的规模和系统内部复杂性是相对稳定的，这就降低了系统整体伸缩的复杂度; 其次，单元之间的故障独立性使得我们能够降低故障控制软硬件故障的影响面; 最后，单元之间可快速切换，这就使得我们处理同城和异地容灾时可以更加简单高效。

单元化解决了业务和服务层面的扩展性和灾备性容灾问题，但数据层面的容灾问题并没有得到解决。如果发生程序城市级故障，我们仍然不敢把核心业务流量切换到另一城市，那我们实际上仍然停留在原地。但这个问题不管是商业数据库还是开源数据库都是无解的，我们可以通过各种技术手段尽可能降低故障切换时间，减少故障影响的客户范围，但无法避免资损的问题发生。这个问题，但是，在我们有了自己的自研数据库 OceanBase 之后，被彻底可以解决这个问题了。

OceanBase 的核心是基于 Paxos 协议的多数派分布式选举协议，Paxos 协议的价值已被业内广泛认可。该协议保证只要多数成员依然存活，任何少数成员的故障不会影响系统的整体可用性和数据一致性。所以，如果把一个数据集群部署到三个或三个以上城市时，我们就可以保证任何一个城市的故障，系统都可以实现无损容灾，也就是 RPO=0 都不会对系统造成损坏。此外同时，系统可在 30 秒以内把数据故障切换到另一城市，故障切换过程在数据库层面自动完成，对上层业务没有影响。另一方面，当我们把一个数据库集群部署到三个城市时，为了避免任何单机故障导致的业务跨城市访问问题，可以我们把数据库集群中的副本数量从 3 个增加到 5 个，这就是我们今天所说的三地五中心，或者严格一点，三地五副本五多中心。

从两地三中心到三地五中心，我们解决了一个基础又非常重要的问题，即便发生城市级故障，整个城市都不可用，但数据库层面仍然可以做到，系统不丢数据，不停服务。

蚂蚁金服花了数年时间来演进基于单元化和三地五中心的异地多活和容灾架构。今天，蚂蚁金服已在多个城市部署了多个数据中心，我们所有的核心交易流量量部署在所有数据中心并可随时切换调备和调配，通过异地多活，我们实现了流量在全国范围内的均衡任意扩展，极大地提高了资源利用率。最重要的是，我们提升了系统面对城市级故障的能力。蚂蚁金服在如此大规模的金融交易系统中实现了这样的容灾能力，这在世界上属于首创

现在，今天的蚂蚁金服已经成长为是一家成熟的生态型企业，作为全球金融科技创新的领导者，蚂蚁金服已经开始面对面向生态中所有的合作伙伴全面开放和赋能，这种开放赋能是全方位的，从涉及数据、技术、产品、数据、平台、业务、运营以及业务等多个维度，这与过去单一的 IT 赋能存在本质不同。在过去几年，技术和产品如何匹配业务和生态发展速度，对于的这个问题的思考，一直是激励我们团队前进的动力。，未来，仍然如是仍将如此。我们希望，有蚂蚁的地方就有蚂蚁金服，有蚂蚁的地方就有我们的自研技术。

从上个世纪末开始，我们从商业数据库崇拜、开源数据库崇拜到今天一路走来，到了今天，我们发现自研技术已经在许多企业扎根。虽然还存在许多不确定性，但是，既然时代发生了转变已经发展到了今天，那么总会有一两颗种子，会破土而出，努力地向上生长并最终成为参天大树。我们相信，下一个十年，自研技术特别是核心自研技术将会迎来真正的黄金发展期，这背后将存在深刻的行业背景和成熟的技术企业实践。

原文发布时间为：2018-05-23

本文作者：冯柯

本文来自云栖社区合作伙伴“数据和云”，了解相关信息可以关注“数据和云”。