过去十年，随着云计算带来的变革，传统IOE架构对企业运营成本的影响以及未来业务发展的制约因素逐渐加剧。尤其是互联网的大规模、高并发、实时在线、大规模网络优化等新兴需求，使得针对传统IT环境设计的Oracle数据库越来越难以应对互联网日益庞大的数据量公司。于是，为超大规模互联网公司的分布式计算环境重新开发的关系型数据库OceanBase应运而生。OceanBase作为蚂蚁金服自研的分布式关系型数据库，自2008年阿里提出“去IOE”的理念以来，经历了很多难以想象的尝试，也取得了很多成绩，蚂蚁金服在2018年全面实现了“去IOE”。2017.影响国内外成就。本文将深入OceanBase，回顾其研发过程和研发方法论。研发故事：软件、硬件、业务融合这里仅举几个典型案例进行说明：业务结合，软硬件整体优化基础数据部（OceanBase）负责SQL相关开发工作的陈萌萌蚂蚁金服团队）表示，以往数据库技术更偏向于软件层，硬件层有专业人员、专业技术、专业公司来解决硬件本身的稳定性或容灾等问题。但是，蚂蚁金服更多的是软件和硬件的结合。OceanBase软件从设计之初就考虑到了硬件不稳定和分布式系统的特点，做了以前数据库不会做的优化工作。过去，数据库优化没有考虑到底层硬件损坏、机器宕机、网络断开、天灾人祸等问题，但今天OceanBase无时无刻不在考虑这些问题。“以前做软件开发时，我们首先假设底层硬件没有问题，只需要做好上层的软件逻辑即可。现在我们考虑的是软硬件整体。”在数据库查询优化技术方面，比如传统的银行柜台，通过人工窗口提供服务，用户大部分时间都在和人工窗口打交道等，对数据库的速度不是那么敏感。但是蚂蚁金服是一个互联网应用，任何时候数据库抖动或者查询执行速度变慢，用户都能第一时间感受到。这与传统的应用场景有很大的不同。如果对数据库的一次查询从一毫秒变为五毫秒，传统数据库不会认为这有什么大不了的。但是在互联网应用下，多出来的四毫秒可能会放大成几百毫秒，甚至一两秒。一旦出现这种延迟，用户体验会立即恶化。“我们每天都在做非常精细的事情，我们生怕一毫秒变成五毫秒，所以做了很多精准防御。”蚂蚁金服基础数据部（OceanBase团队）研究员杨传辉进一步解释：数据库查询优化器是一种近似解，基本上没有最优解，优化的目标是逼近最理想的情况。在传统应用场景中，优化结果允许有几毫秒甚至更多的差异，但在互联网场景中很难接受如此大的差异，所有的优化效果都必须精确到几毫秒以内。比如：你每次在支付宝支付，点击支付按钮，背后的数据库可能会对数据库执行一两百条SQL查询，优化器需要为每条查询生成一个优化后的执行计划。如果优化器在某个场景出现了错误，每次查询多花费了5毫秒，那么整个链接就多了500毫秒，用户在按下支付按钮的时候可能会发现交互速度可能变慢了。如果再加上可能不仅仅是支付——比如购买商品后下单后支付——这些环节可能慢了几百毫秒甚至几秒，这对用户来说已经是不可能的了。公认。还有地铁刷脸或者支付宝进站的场景。如果用户站在大门前，久久出不来，不仅是体验问题，还可能造成连锁问题，后面的人也会排长队。这些现实的挑战需要OceanBase能够精准快速的做出响应。杨传辉告诉我们，从关键业务系统的数据链路梳理来看，一两百条SQL是最常见的事务。如果支付渠道不同，SQL执行次数会更多。因为蚂蚁金服本身是一个分布式系统，一个很大的挑战就是对底层的基础组件，包括网络有非常高的要求。如果网络出现问题，将对整个服务产生影响。因此，OceanBase不仅要优化数据库层，还要对网络、磁盘、操作系统等软硬件层进行精准优化。那么OceanBase是如何解决的呢？OceanBase团队从业务开始就会参与到业务设计中：业务如何使用数据库，如何使用最合理等，从一开始就参与整体设计，并随着业务端和整个架构。蚂蚁金服基础数据部（OceanBase团队）SQL组组长蒋志勇，从事SQL引擎和优化器工作，从零开始为OceanBase搭建了自己的SQL引擎，特别是让原来的MySQL应用能够运行迁移过来。在数据库兼容性方面，OceanBase兼容MySQL。蚂蚁金服内部业务已经从MySQL数据库迁移到OceanBase，没有任何变化。在优化器方面，将涉及到的系统统计信息的采集结合蚂蚁金服的业务架构，设计了一个动静分离的架构：白天统计信息存放在内存中，统计信息存放在内存中。在生意低谷的每一天都在记忆中。从内存写入磁盘。它不像其他数据库那样直接写入磁盘，这导致系统统计信息收集缓慢且不完整；它不像内存数据库那样使用高成本的内存来存储统计信息。OceanBase的类内存数据库设计方式，不仅满足了SQL查询实时收集更全面的系统统计数据的需求，而且使得整体的信息收集成本没有额外的开销。OceanBase还微调了SQL语句搜索的优化。由于是完全自研的数据库，对于Join连接查询算法可以灵活适配多种算法，而在其他数据库中，由于可选范围有限，无法做到更精细的优化。“我们在搜索条件的改写上做了一个巧妙的设计，结果是选择范围更广，其他数据库只能在一个狭窄的范围内选择最优策略，所以OceanBase的搜索结果更好。”江志勇说.因为需要兼容MySQL，所以OceanBase团队也对MySQL进行了深入的研究，对MySQL做了大量的调优工作。在此过程中，OceanBase团队发现了数百个MySQL问题，并在向MySQL开源社区报告后得到确认。比如MySQL执行不同路径的结果不一样，MySQL的语义不是很完整等等，都是OceanBase团队在使用MySQL的过程中发现的问题。特别是随着阿里巴巴和蚂蚁金服的业务规模越来越大，他们经常踩到各种技术的极限门槛。OceanBase团队在开发MySQL接口驱动的时候，通过业务排查，发现某笔交易回滚了，但是数据还在提交到数据库，导致转账取消了，但是钱还在还是转移了团队排查了很久，最终发现是因为MySQL客户端的一个变量设置有问题，但这种问题只有在极端情况下才会出现，属于小概率事件。OceanBase团队就这样将小概率事件一一排除，最终走向了通用产品的道路。通用型产品和场景化产品最大的区别在于，通用型产品可以适配大部分场景，而场景化产品只能适配单一场景。蚂蚁金服基础数据部（OceanBase团队）架构师冯柯表示，这是商用数据库最强的地方——可以匹配绝大部分场景。或许商业数据库的技术不是最强的，但价格这么贵，用户还是可以买的，这意味着商业数据库的总体拥有成本更低，一个产品可以适应大多数场景。能够适应绝大部分场景，意味着几乎所有能踩的坑都踩完了。今天OceanBase也在经历同样的过程。Linux碰了个bug，差点解散OceanBase的团队又踩了一个坑，同样是极端情况下才会出现的Linux系统bug。OceanBase本身是一个基于Linux和C语言开发的分布式数据库系统。2010-2011年，OceanBase团队在支持淘宝收藏夹业务。2011年双十一的时候，遇到了一个稳定性问题：当时的Linux有一个直接访问IO的特性，这个特性有一个bug，而且是极端情况下才会触发的bug。杨传辉回忆，2014年距离双十一不到一个月，是周五出现的问题，导致淘宝收藏夹一天下来3次，每次一个小时左右。恢复收藏夹的流量。一旦访问量超过一定数量，就会再次触发Linux内核的bug，导致再次宕机。直到周五晚上八九点多，淘宝的来访用户减少，才恢复营业。由于当时开发团队主要集中在北京，所有团队成员都在下周六一早从北京飞往杭州的第一班飞机解决了这个问题。“当时气氛很紧张，如果这个问题解决不了，OceanBase团队就要解散。”杨传辉回忆起当时的情景。而且解决问题的时候，负责写代码的程序员压力也很大，后面还有两三个人在盯着代码怎么写。“当时我并不确定这样做就一定能解决问题，但我认为有70%-80%的概率会解决问题，后来才真正解决了问题。”“阿里巴巴/蚂蚁金服的系统发展太快了，一直在变，OceanBase一直在开发新的特性和支持线上业务，双十一的爆发可能是平时流量的十倍。像linuxkernelbug这样的问题，如果只是平时流量的一两倍，根本不会触发，只有爆发十倍才会出现。所以我们很紧张，没有时间仔细分析，慢慢解决问题。问题来了，大家加班加点解决，就是这样。杨传惠说道。在挫折和失败中成长，冯柯回忆说，加入OceanBase后做的第一件事就是做诊断监控。认识到这一点很重要，但是没有人愿意去做，因为涉及所有模块，是一件吃力不讨好的事情。我当时之所以选择去做，是因为这对业务来说非常重要，是必须要做的事情。在这个过程中，遇到了很多挫折，也出现了很多问题。比如：OceanBase诊断监控功能刚上线的时候，N个人去看监控就会得出N个不同的结论。“大家都觉得这个功能完全不能用，我觉得做的不好，所以当时参与的同学都很沮丧，觉得自己没有被认可。”冯柯当时鼓励团队，“别人骂你最多的时候，其实是你进步最快的时候，你的产品能拿到更多的资源，得到更多人的认可，其实很好，真的是一个很大的进步。”触及当时。”OceanBase是一个在业务中“求生”的过程，同时寻找发展壮大自己的机会。在“造命”的过程中，OceanBase将无法妥协。杨传辉回忆说，2010年的OceanBase版本有一个比较大的缺陷就是设计了单点写入。那时，所有写入的数据都放在一台机器上。这个版本的可扩展性很差。本质上，它只能做纵向扩展，没办法做横向扩展。另外由于每次Writes都要经过那个节点，最后整体性能比较差，数据库的功能也受到限制。这是OceanBase的早期版本。那时候团队的数据库经验还没有那么丰富，也没有时间做长远的发展。直到2015年重新设计开发的1.0版本，才是真正面向云时代的分布式数据库。期间，OceanBase团队也从各种渠道引进数据库人才，最终实现了数据库的重构。OceanBase经历的失败还是很多的。杨传辉回忆说，OceanBase是2012年11月转到蚂蚁金服，2014年实现了交易系统，2013年其实是在做淘宝的库存项目，而不是交易系统。当时OceanBase团队看到库存的数据库问题也是一个很大的挑战，就像卖火车票系统的挑战本质上是一个减库存的问题——如果两个人同时减库存，那么就是弄乱。当时淘宝的MySQL团队也在做这件事。最终，业务部门选择了MySQL方案，因为业务团队使用MySQL感觉更安心。“不为别的，我们最后没有选择OceanBase，那一年我们白做了，整个团队白做了。但是因为有这个基础，我们下一个交易系统才真正做出来。”研发方法论：发现问题、定义问题、解决问题总结OceanBase的开发过程，总想找到一些研发方法论，就像微软的软件开发“三驾马车”方法论。但是我们其实更多的时候用运维、业务团队等来定义问题。我们将查看一些问题，找出真正的问题所在，并帮助用户定义该问题。在定义一个问题的时候，有时候我们会开会分析某个问题是数据库团队解决的还是业务团队解决的，但是在开会之前，大家可能并不知道最终的效果会是怎样。很多时候我们都在做这些不确定的事情。OceanBase本身就是一个分布式数据库，没有先例可以借鉴。团队骨干成员杨振坤在百度带领分布式技术团队积累了丰富的经验，也吸取了谷歌大量的分布式技术思想。但是后面尝试把分布式架构和关系型数据库结合起来的时候，没有之前的经验，团队只能自己想。虽然OceanBase至今没有发表论文，还在做生意，但杨传辉回忆说，OceanBase里面有很多其他人没有想到的方法。制定新的计划可能需要很长时间，需要半年到一年的时间才能做出决定。做吧。在具体开发的实施过程中，测试是非常重要的工作。分布式系统中的异常处理很容易出错。通常机器是不会出故障的，但是线上业务突然出现故障，就可能是大故障了。但是，很难测试这种异常处理。OceanBase有一个容灾模拟框架，就是随时干掉一台机器，随时都在运行这样的容灾测试。另外，对于并发处理的测试，即某个条件的达成可能会突然触发两个线程的顺序或某个变量的访问顺序出错。OceanBase也在随时模拟这样的场景，让这种小概率事件尽快出现。在开发过程中，OceanBase通常是一个人编写的代码，需要另外一个人阅读审核，然后提交通过的代码。团队也写了很多自动化测试的框架。开发人员要自己做单元测试和一些功能测试，集成测试有专门的人做。OceanBase的测试人员很少，大部分测试都是自动完成的。因为OceanBase是一个整合了软件、硬件、业务的整体优化，而当软件、硬件、业务相遇的时候，往往会出现各种碎片化的小场景问题，那么如何解决呢？陈萌萌说，遇到这样的场景，会提前把大家拉进一个群，把需求丢到群里。技术团队会根据需求进行反馈和建议，业务团队也会对实验中遇到的问题进行反馈。问题。这些碎片化的场景和问题，很难区分是软件问题、硬件问题还是业务问题。因此，组内有运维、开发、业务，甚至还有负责业务开发的BD和负责产品的PD。任何人都可以加入该组。每个人都有一个负责的业务或技术方向，他们会在空闲时间了解小组的来龙去脉。一些团体按需寻找人。如果你在群里@，你一定会关注新闻的。如果不是@，不是特别紧急的时候会在群里找消息。虽然群很多，但真正发群消息的时候，把这几天的所有消息都翻一遍，也需要几分钟的时间。这样一来，总能分清哪些是需要立即响应的，哪些是可以跟进的。一般OceanBase团队的工作时间是上午9点到晚上9点12小时，但也有“双十一”、“6.18”、春节红包压力测试等突发事件。当然，随着OceanBase的发展，处理突发事件的需求在减少。陈萌萌回忆说，以前他都是跟着业务团队压测到凌晨，甚至说经常有半夜被人接走的情况。“我记得经历过很多戏剧性的失败。因为一旦出现一些问题，各行各业的人都会在半夜被拉上来，每个人都会被临时拉到一个群里。没人知道那时候发生了什么。”时间。但每次都有可能有一些信息，大家赶紧把自己的信息丢到群里，好让大家知道到底发生了什么。大家都有点害怕，生怕自己的所作所为会引起一些问题。陈萌萌回忆道：“我记得有个小故障。半夜11点，说有问题需要大家上网查看。包括supervisor在内的一行人，一直到凌晨四五点才上网查看问题。一开始大家都在，慢慢发现问题越来越集中，相关人员上来，一直到凌晨四五点才解决问题。中间大家在群里查看分析各种信息，提出各种建议。虽然他们没有坐在一起，但就像是被关在一个房间里，开了一个通宵的战斗会议。陈萌萌总结了阿里特有的技术讨论群的解题过程：“这是一个不断过滤和重新分析信息的过程。如果一开始你没有所有的信息，没有人可以总结。经过检查信息，有人发现某个地方需要关注，其他人就把相关的信息加进去，慢慢的连成一个逻辑。这种现象在群里回头看新闻的时候尤为明显，信息散落在开始，然后慢慢就能达成共识，最后再继续下去。”当然，群里也会有熟悉各种“疑难杂症”的“老中医”。他们一般都是有经验的人，见过的问题比较多。所以，当别人可能还在猜测的时候，“老中医”就会给出一个非常靠谱的可能性。如果你去看待这个可能性，你会发现，你确实可以从这个角度挖掘出解决问题的办法。但是，即使如果讨论可能的解决方案，"每个人仍然非常害怕。是的，打字命令是给运维人员打字的。这时候的关键是手不要抖，不要打错，因为如果打错了，会造成二次故障。所以，我们会找一个心理素质好的同事来操作，大家也不要说什么，静静的看着这个同事把订单打完。“因为无论通过群里的讨论，选择最安全可靠的操作方式，但直接在系统中输入命令可能会直接改变数据，输入错误的键可能会删除所有数据。不可逆，”大家不敢操作出气。”当然，每处理一次故障，也会进行回顾，寻找未来的解决方案，最后形成一个知识库，即应急预案，并固化到程序中，以防万一。下一个错误通过程序，整个OceanBase并没有一个统一的产品经理，因为OceanBase的功能列表是对标商业数据库的，比如某个版本必须在下一个双十一之前生产出来并稳定运行，然后通过双十一检查。“保持这样的节奏”，姜志勇补充道。未来前景：使用time用现实去体验和检验。姜志勇强调，数据库的产品化需要时间去体验，如果抱着投机的心态参与是很难实现的。蚂蚁金服最大的优势就是业务场景非常丰富，可以让OceanBase在服务外部客户之前在内部进行充分的培训，而这些培训是外部用户很难获得的。2017年开始，OceanBase跟随蚂蚁金服金融科技的开放，开始了赋能传统金融的实践历程。OceanBase对外业务负责人冯科表示：“分布式是OceanBase的重头戏，但最重要的是OceanBase是基于产品思维，而不是简单的解决业务问题，未来一定是对外发展。”如今，OceanBase已经从金融级分布式关系型数据库服务开始，向商用迈出了一小步。经过时间的历练和现实的考验，团队有信心将OceanBase从一个软件变成一个通用产品。作者：吴宁川简介：“云科技时代”创始人。职业生涯起步于《中国计算机报》，任副主编。专访甲骨文全球CEO、VMWare全球CEO、ARM全球CEO、亚马逊云全球CTO、微软全球研究院院长、华为CIO、京东CTO、IBM董事长大中华区、阿里云CEO。
