蚂蚁金服OceanBase,让客户越过山丘,抵达云和山的彼端

SamYux 2018-04-13

本文作者介绍

冯柯:2014年加入蚂蚁金服,入职前在数据库厂商神舟通用任CTO,浙江大学计算机应用专业博士,十五年数据库研发和产业化经验。目前在基础数据部(OceanBase团队)任架构师,参与OB1.0的设计和研发工作,主要研究领域分布式关系数据库、数据存储、性能诊断优化。

蚂蚁金服OceanBase,让客户越过山丘,抵达云和山的彼端

前言

作为一个干了十二年数据库的行业老兵,当我刚加入蚂蚁金服的时候,觉得从零开始做超过百万行代码的数据库,其实是很不可思议的。因为阿里巴巴蚂蚁金服和其他互联网公司一样,技术上推崇开源文化,为什么用一行一行写代码的“笨法子”,去做一个分布式关系数据库?直到今天,我们团队做的这件事,在整个行业看也是少数派,可以说是非常奇妙的。

但是现在回过头去看,当时的OceanBase在我眼里,就如同一件还略显粗糙的艺术品,但我希望能够和同事们、客户们一同把它打造得更加完美,因为我的技术信仰是较为完美主义的。正因为期待完美,所以我们会去趟一条在旁人看来最艰难、最不合情理的荆棘路。在大方向上,我和OceanBase创始人阳振坤老师一样,既有同样的技术洁癖,也有相同的抱负和情怀。

OceanBase就是数据库领域的高铁,概念不新但重要

过去这几年和同行、客户们交流的时候,很多人都会问,OceanBase为什么要这么发展,开源的MySQL价格便宜量又足,你们为什么不走寻常路?打个比方来说,基于开源做就像是开吉普车,灵活且方便,尤其擅长越野、户外,只要你驾驶技术好,想怎么开就怎么开,但对许多行业客户来说,他们更像是后排乘客,而不是老司机;做自研产品就像造高铁,基础技术门槛高,控制系统、供电系统、轨道、车厢、车轮都要从零开始,投入巨大,高铁的重量很大,起步过程会很长,可是一旦速度起来了,重量就变成了它的优势,速度越快就越势不可挡,而且还是全自动驾驶,司机轻松、乘客放心。这也是走自研路线的OceanBase,和行业里常见的走开源研发路线的差别。

作为一个在软件和互联网行业干了十五年的老兵,知道“造高铁”有多么难。

1998年,中国软件企业5000家,市场规模325亿;到了2017年底,中国软件企业3.6万家,收入规模达到5.5万亿元,营收增长了169.23倍,仅次于美国。可在最核心的CPU、操作系统和数据库这基础设施三大件上,过去我们并未取得商用意义上的重大突破。

二十年前我们还有自己的一些自研软件产品在发展,但早期被盗版商用软件掠夺了一把之后,在开源生态开始爆发之后,又再次被套路。如今的大多数基础类软件自研产品,几乎都是在开源基础之上研发。当然,开源是好事,让我们的技术水平能快速提升,但完全依赖开源的代价之一,就是让行业丧失了一些做基础原创性技术创新的动力,大家变成了在别人做出来的基础框架上进行小创新、微创新。这样的现象,在数据库、中间件、操作系统等各个关键领域,非常普遍。

自己造高铁的另一个好处,是可以实现差异化价值。对标下老牌数据库公司,它们通过几十年的技术积累,打造出专业的技术、产品、市场、销售、实施、咨询、服务团队,有完整的生态系统,这是巨大优势。

而蚂蚁金服是一个金融科技公司,OceanBase团队不是以数据库产品为盈利目的而创建的,能发展起来的基本前提是,能够为业务部门不断创造价值,这是跟国内传统数据库企业一个非常大的差别,过去国内专业数据库公司往往发展的不好,就是因为没有行业属性,没有真正找到成熟发展的商用场景。

但老牌数据库厂商的大优势,同时也是大包袱。正如阳振坤老师在上一篇文章里提到的,数据库的天时地利人和都变了,从集中式数据库技术形态,到分布式技术形态,技术思路上的转变很重要。巨头们当年做数据库的时候,PC服务器的可靠性非常差,也没有最近这十几年才发展起来的高可用、高可靠的分布式架构,所以传统IOE方案,本质上是通过硬件的高可靠来解决整个系统的高可靠。

而今天OceanBase的分布式系统是通过系统架构和软件实现系统高可靠,这是完全两种不同的思路。还有个极大的差异是,原来是满足线下和PC端等一些固定业务场景的需求,如今是要满足基于移动互联网业务场景的需求,需求角度、数量级、响应时间都不一样。

我们做了七年多基础原创性技术研发,跟业务部门绑在一块,相当于走完了从特定业务需求抽象成有一定普适性的技术定义,再去做产品化、商业化。我觉得技术并不是最大的挑战,更大的挑战是要解决客户可能遇到的具体问题。遇到的问题越多,能包容的越多,产品的兼容性越高,多样性越好。

就像微软说了几十年的,多样性和包容性是核心竞争力——一般人理解不了什么叫多样性和包容性,比如从技术角度看,Linux比Windows更简洁、更高效、更美,但是胖大肿的Windows把190多个国家、十几亿个人和企业用户的需求都包容到产品中了,Linux一直没做到,这就是多样性和包容性。

所以我们对“OceanBase高铁”的优势很有信心。首先蚂蚁金服有非常好的业务场景,我们能接触到真正影响几亿人的核心业务,从架构到功能都能看到跟传统商业数据库的差异化亮点。这一点非常重要,做产品一定要做差异化,而不是一味追随、模仿,因为数据库到今天已经不新鲜,没有差异化的价值,客户就没有兴趣来了解和尝试。

其次,OceanBase一直高度关注如何降低客户的使用门槛,不要让每个客户都成为吉普车老司机,而是让他们去享受下坐高铁的体验。如果我们跟客户离得很远,就会产生非常大的间隙,这个间隙在传统商业数据库厂商看来挑战并不大,但是在客户看来往往是很重要的。

踢走石子 越过山丘 望向云和山的彼端

OceanBase早期是一个纯技术团队,如今已经有相对完整的市场、咨询和服务团队,也包括整个工具链和平台团队,一开始我们把高铁开出蚂蚁金服的站台,觉得在内部做得这么成功,到了外部那还不得“振臂一呼,应者云集”?

但市场很快就给了我们最好的教育。

首先是我们学会了厘清服务内外部客户的成功,是完全不同的。今天OceanBase在内部是很重要的成功,比如承担了“双十一”、上线了账务,背后是因为内部客户和DBA团队都是一体,除了业务本身,所有人都是乙方,所以很多成功本质上不只是OceanBase独自成功,而是整个项目组的成功。而在外部客户那里,信任的建立、能力的认可、工作流程和业务流程的熟悉,都是需要重新建立的,这是比较大的挑战。

其二,了解到内外部需求有较大差异。蚂蚁金服的核心业务特别关注高可靠、稳定性和一些非常极限场景的性能,可是外部需求不完全是这样的,哪怕是一些大型客户,整体业务量也没有那么大,技术能力、基础设施、运维能力,也是参差不齐,所以外部客户对产品功能、产品体验的要求是非常高的。

其三,学会了怎么去理解客户需求。因为上一点,外部客户会提出许多小需求,比如说迁移工具的体验不太好,是不是可以优化一下。而这类问题在内部通常是不会优先解决的,因为内部我们总是习惯先解决架构、容量的问题。有一段时间,我们在外部客户的环境中部署时,总是被产品在各种细节上设计的不合理而磕磕绊绊,后来有位客户对我说 “我们知道OceanBase很牛很厉害,可三地五中心也好、高可用、性价比远远强于IOE这些优点,我们一般的业务不一定用得上。

“你们在内部解决的是云和远山,可往往挡住我们的是脚下的石子和不远处的山丘”。这句话对我触动很大,从那天开始,我把自己在公司内网的签名改成了这句话,“挡住客户脚步的,不是远处的高山,而是脚下的石子”。我希望我的团队中的每个人都能看到这句话,之后的一段时间,我们开始学习怎么去服务外部客户,不再单纯以技术导向来判定一个客户需求的优先级,而是真正去解决客户的每一个具体而微小的痛点。

以蚂蚁金服为始发站 开向下一站金融行业

经过一年多的积累,我们决定将OceanBase开向下一站的时候,选择的是先满足金融行业,尤其是专有云的场景需求。

首先,金融业更关注整个系统的可靠性、扩展性,OceanBase最重要的几个核心特性与金融行业的需求高度契合。

其次,目前OceanBase具备的应用场景优势,是在蚂蚁内部积累的核心金融业务场景的经验,映射到金融行业显然是最容易被客户接受的,目前已经实施的几个银行客户案例也证明了这一逻辑。

第三,我们会在合适的时间选择上公有云。相对来说公有云的客户众多,对产品的广度要求远远高于深度,这并非我们当前最擅长的领域,团队需要继续成长,如果现在直接上公有云,会拖慢OceanBase团队在核心技术创新方面的脚步。

对于蚂蚁金服来说,不是只有OceanBase在考虑怎么去做商业化的问题,而是整个蚂蚁金服都在加速将内部技术创新赋能给金融行业。在这个大背景下,OceanBase跟着集团军一起作战显然是更好的选择。从客户角度看,通常也不会只关注一个单独的数据库产品,而不去考虑整体架构、研发效能、服务治理,不去考虑金融场景、产品营运、甚至是组织文化的创新。这时蚂蚁金服的整体解决方案价值就格外重要,整个金融业正在逐步形成一个共识——金融科技是未来,分布式架构是未来。

一眨眼,OceanBase也到了七年之痒的时间点,需要一些变化。对蚂蚁金服来说,OceanBase的商业化进程非常重要,我们需要通过更好地理解外部客户的业务场景、具体需求,帮助客户的新业务能稳定运行,让更多的业务能够跑在OceanBase上,逐步建立起品牌和声誉。让蚂蚁金服的金融科技输出战略因为有了OceanBase而不同。当然,一切的前提是把产品和生态做好,才有能力越过OceanBase的下一个山丘。

只希望我们那时候,不要白了头。

相关推荐