本文作者介绍
冯柯：2014年加入蚂蚁金服，入职前在数据库厂商神舟通用任CTO，浙江大学计算机应用专业博士，十五年数据库研发和产业化经验。目前在基础数据部（OceanBase团队）任架构师，参与OB1.0的设计和研发工作，主要研究领域分布式关系数据库、数据存储、性能诊断优化。
前言
作为一个干了十二年数据库的行业老兵，当我刚加入蚂蚁金服的时候，觉得从零开始做超过百万行代码的数据库，其实是很不可思议的。因为阿里巴巴蚂蚁金服和其他互联网公司一样，技术上推崇开源文化，为什么用一行一行写代码的“笨法子”，去做一个分布式关系数据库？直到今天，我们团队做的这件事，在整个行业看也是少数派，可以说是非常奇妙的。
但是现在回过头去看，当时的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的下一个山丘。
只希望我们那时候，不要白了头。
— END —
