写点什么

我在蚂蚁金服做后端:那些坚持在一个岗位做八年的人,后来怎么样了?

  • 2019-08-26
  • 本文字数:5488 字

    阅读完需:约 18 分钟

我在蚂蚁金服做后端:那些坚持在一个岗位做八年的人,后来怎么样了?

1985 年出生的他,在 OB 团队里绝对算是一个“老人”,从研究生毕业加入 OB 至今已经迈入第八个年头了。

有人觉得花这么长时间做同一件事会变得“螺丝钉”,用他的话说,做底层的同学需要比一般人更多一份耐心。除了耐心以外,驱使他一直“做下去”并且“往深了做下去”的原动力还是基于“兴趣”。

从 P5 到 P8 他完成了职业生涯的三级跳,也完成了三个阶段的成长和蜕变。机会从来都是留给有准备的人,当然,也总是留给那些耐得住寂寞的人。



元启,蚂蚁金服高级技术专家

有时候离成功就差一次机会

「当时自己就憋着一股劲,就是非常想来 OB,觉得自己说什么也要再试一次。」


1985 年出生的席华锋(花名:元启)出生于湖北襄阳。


“我接触计算机算比较晚的,高中的时候有计算机课程,不过那个时候完全没有概念,每次进机房都要套上鞋套,所有设备都被保护的很好。”


说到报考计算机专业,元启说那个时候想法特别简单,当时他连计算机跟软件工程两个专业都分不清楚,但是他始终坚持的一点就是自己以后是要做研究的。当时他觉得计算机对于搞研究很有帮助,计算机可以用来处理大数据,可以帮助人们去做更深入的研究。


2004 年,元启顺利考入了华中科技大学,华科是湖北省最好的理工院校。大学期间,他对数据库并没产生特别大的兴趣。大学的数据库课教的都是关系代数、范式之类的内容,觉得特别枯燥。


后来顺其自然选择了读研,在研究生期间,实验室做的方向是大数据,当时主要做的项目是大数据的 benchmark。相当于是在做一件定标准的事,虽然导师的想法很好,但是由于国内之前没有类似的先例,做起来困难重重。虽然过程很艰难,但是元启对最后的结果还是挺满意的,研究生毕业的时候他拿到了优秀毕业论文。


就这样顺利的毕业了,找工作的经历却远不如求学顺利。


“我其实并不是特别自信的那种人。但是当时我有一点特别明确,就是一定要去一家互联网公司。”


2011 年的时候,外企风头正猛。当时外企的薪资和待遇比互联网公司还要高不少。但是元启相信互联网行业的前景,相信互联网一定是下一个趋势。


当年基本上所有的互联网公司巨头:BAT、网易、搜狐他都投了简历。有一些过程很顺利,比如腾讯的 offer 就拿的非常快;也有一些没那么顺利的,比如最后拿到阿里的 offer 就经历了不少挫折。


“第一次投递阿里是因为一个关系不错的同学一毕业就来到了 OceanBase,他特别喜欢这个团队的氛围,就一直鼓励我来 OB 积极帮我内推。但是第一次面试不太顺利,没有过。当时自己就憋着一股劲,就是非常想来 OB,觉得自己说什么也要再试一次。后面自己就花了很多时间做准备,这个同学也特别好后来又帮我内推了一次,让我获得了宝贵的第二次机会,这一次终于拿下了 offer。”


让元启印象深刻的是,当时最后一面的面试官是时任阿里云 CTO 的章文嵩。虽然元启在研究生期间做的项目更多是偏实验性质,章文嵩觉得通过一个点就能够体现出一个人做事的深度。过五关斩六将,最后元启终于来到了阿里巴巴,来到了 OB 团队。

跟 OB 一路狂奔的这八年

「那个时候确实是下了狠劲,基本上 9 点下了班以后,回家继续自学,每天学习到 12 点以后。」


2011 年,OceanBase 0.3 版本刚开始开发。刚来 OceanBase 的时候人比较少,基本上不论职位高低所有人都在写代码。当时元启进来后,主要做的事情就是跟事务和日志相关。这部分工作虽然不是最难的,但是却很关键。


2011 到 2012 年间,对于整个 OceanBase 团队而言特别特别困难。当时找不到对 OceanBase 而言特别有价值的业务,甚至整个团队随时面临着解散,活下来成了整个团队的唯一目标。


2012 年底,OceanBase 从淘宝调到支付宝,当时预估到支付宝在数据库方面所面对的挑战更大,后来证明确实如此。


这一年多时间对于元启来说,是真的下了狠劲。因为研究生阶段花了很多时间做实验,项目经验比较少,编程基础比较薄弱。当时的主管非常关注他的个人成长,让他每天写一份日报总结除了工作以外自学到的知识。基本上是 9 点下了班以后,回家继续自学,每天学习到 12 点以后。



2013 年 5 月,支付宝下线了最后一台 IBM 小型机,完成了去 IOE 进程中的一次重要尝试。如何取代最要命的“O”成了横亘在支付宝面前的一道大山。


OceanBase 0.5 版本应运而生,在次年双十一,0.5 版本就取代 Oracle 支持了支付宝当天 10% 的流量。


对于整个 OB 团队,或者说对于蚂蚁来说,0.5 版本的上线都是一个里程碑式的存在。它最大的意义在于真正帮助蚂蚁完成了去“O”,也真正让高可用在蚂蚁落地。


0.5 版本在蚂蚁金服核心交易系统的上线让 OceanBase 真正活了下来,甚至 OceanBase 还有了不少“拥趸”。在当时整个阿里巴巴还没有一款数据库产品能够真正解决高可用的问题,OceanBase 一下子被捧到了一个前从未有的高度。


对于元启个人而言,他除了持续负责日志部分的工作,另外很大一部分工作就是跟性能相关。那段时间基本上把所有精力都完全扑在 0.5 版本的研发上,整个团队是一种全力以赴的状态。


这之后,2014 年到 2016 年,整整两年的时间,元启和其他 40 多个 OB 同学一起,再一次投入战斗,全身心投在 OceanBase 1.0 版本的开发上。


1.0 版本的诞生主要是解决扩展性的问题。“1.0 版本放在当时并不是为了马上解决业务的实际问题研发出来的,而完全是一套面向未来的架构。”


阳振坤(OceanBase 创始人)曾经提到,其实在交易库还没有完全上线的时候,就已经启动了 1.0 版本的开发。1.0 版本的设计初衷就是希望做出一套没有任何限制,完全可扩展,高可用的系统架构。


1.0 版本的里程碑事件就是 OceanBase 在 2016 年的双十一上线了蚂蚁的账务系统。对于银行系统有一定了解的朋友可能知道,对于银行来说最最核心的其实是账务系统。


对于元启来说,他的感受更直接更具体。突然觉得那一年数据库的数量飞速增长,同时 OceanBase 上了非常多的业务。这对运维提出了更高的要求。OceanBase 1.0 版本的质量比 0.5 版本提升了整整一个层级,每一个版本发布前都要经过一轮又一轮严密的测试,发布周期也变得长了很多。正因为有质量的保障,才有了 OceanBase 1.0 版本在规模上几何倍数的扩大。


OceanBase 2.0 版本在 2018 年 9 月正式发布。2.0 版本的重要意义在于真正将 OceanBase 打造成一款通用型的商业数据库产品。2.0 版本在 1.0 版本的质量标准上又提升了一个量级,除了对 MySQL 的兼容,2.0 版本更多的是打磨对 Oracle 的兼容性。


当时做 Oracle 兼容是有争议的,团队内部都觉得 MySQL 已经做到了 90% 的兼容,为什么还要花这么多时间再去做一套 Oracle 兼容。


但是元启心里明白,这件事不得不做。OceanBase 正在走向商业化,然而很多金融机构里的核心业务大多还是基于 Oracle。如果不做 Oracle 兼容,就意味着业务改造的工作量变得非常大,更换数据库的成本非常之高。


“我们在做在 OceanBase 0.5 版本的时候,当时做的系统已经可以算得上是业界领先了。到了 2.0 版本的时候,这个感觉就更明显了,我们遇到的问题都是现有的系统从来没有遇到过的,所有问题都是全新的,充满挑战的。”


在 OceanBase 2.0 版本的开发中有两个非常大的难点:一个是资源的紧缺,人力不足。Oracle 对外宣称要招聘 1000 个人来做内核开发,实际上 OceanBase 的系统远远比 Oracle 复杂,如果按照他们的标准 OceanBase 可能要招 1000 人还不够。


另外,还有一点就是技术实现上的困难,也就是如何保证分布式系统中数据的一致性。在事务执行的时候如何让它们看起来好像是独立执行,同时又能完成并发。这些问题在单机环境下已经很难解了,在分布式的环境下实现更是举步维艰。

三个阶段的蜕变

「你可以不去考虑自己所处的位置,勇敢的提出来,并且放手去做。做成了以后团队里所有人都能看得到。」


与 OB 一起狂奔的这八年,他完成了职业生涯的三级跳,也完成了三个阶段的成长和蜕变。

第一阶段:从自我视角到客户视角

刚进入团队的时候,最开始主要就是在做技术深度的积累和技术广度的扩展。除了一直在事务层面做更深入的研究外,后面元启也接触了像测试、运维相关的知识。用他的话说,“当你了解的越多,你会发现自己看问题想问题的视角也在变化。”


当接触的东西越来越多,慢慢的自己会从狭隘的技术上的自我视角转向客户视角,去开始理解客户的痛点,感悟到技术是为了服务业务而存在的。

第二阶段:往高看,往远看

在进入团队前面几年的时候,经常有一些技术方案的做法自己不是完全认可。还在第一阶段的自己,一般第一反应就是觉得它不对,会去跟主管辩论。当你接触的越多,思考的越多的时候,其实观念也在变得越来越开放,自己会深入去想主管为什么想这么做,部门老大为什么会这样想,慢慢你就会发现所有选择都是有原因的。


“你现在如果还是一个 P6。可能没办法去理解 P10,P11 的想法,因为你还没看到他们看到的东西。但是你要开放的去接纳别人的想法,从更高的层面去思考,可能到了未来某一个时刻,你突然就顿悟了。”


当时 OceanBase 选择走上自研这条路来说,很多人都不认可也不理解。尤其对于刚毕业的同学来说,可能心理会有障碍,他会认为现在已经有一套开源的 MySQL,做一套自研的数据库有什么用,不理解做这件事的价值。


出现这种认知的偏差可能有两方面的原因,一方面是这个同学可能了解的信息比较少,眼界还不够开放,很多东西他看不到。另外一方面是他了解的不够细致,还认识不到这件事情背后的难度,可能是因为他觉得这件事情太简单,不知道从里面能够玩出什么花样来,所以会变得很浮躁。


在总结招聘经验的时候,OB 团队里曾经有人总结出这样一句话:“如果一个人在一个看似很无聊的岗位上都能够玩出一些花样儿,这种人就很值得要。”说明这个人能够沉得下心,愿意也能够去发现一些别人看不到的东西。做数据库的人天然需要这样的特质,或者说也只有具备这种特质的人才愿意投入这个行业。

第三阶段:扩展你的边界

阳老师说过一句话让元启感触特别深,“企业里的组织架构大多是人带人的模式,并不代表这就是你做事情的边界。如果你愿意做一件事,并且觉得是对团队真正有价值的。你可以不去考虑现在自己所处的位置,勇敢的提出来,并且放手去做。做成了以后团队里所有人都能看得到。”


元启说特别喜欢 OceanBase 团队开放的氛围。刚进 OB 团队的时候,很多事情都是领导安排你去做。慢慢进入到现在这个阶段,自己会更多的主动去想应该去做哪些事,做哪些事才能发挥自己最大的价值。


在 OceanBase 的这八年,元启最明显的感觉就是自己做的越多,懂得越少。早期的时候会觉得自己特别牛,越往后越觉得自己身边的人特别牛。这一路还有很多东西要学习,还有很多事情值得去探索。

一个特别正确的决定

「如果你选择了这个行业,最重要的就是一定要有耐心,一定要相信自己的选择。」


谈到选择数据库行业,元启说这是一个特别正确的决定,也是值得选择的一条路。


首先,数据库离业务最近,不管是在功能上的增强,还是在性能上的提升,数据库的价值都会被放大。比如你写了一段代码,如果这段代码是一个具体的业务逻辑,可能只有几十或者几百个人去访问,它的价值就比较有限。如果你写了一段代码放进数据库,因为数据库拥有海量用户,它的价值就会被放大,给更多的人带来影响。


另外一点就是数据库行业的技术壁垒很高。技术壁垒一方面指的是技术的门槛高,所以一旦你在这个行业站稳脚跟,就拥有了非常强的核心竞争力。另外一方面是指从工程上来说数据库是一个超大型项目,代码行数在几百万行都算是规模小的,这就使得这个行业必须长期投入,在这一行也必须要沉下心来耐得住寂寞。技术壁垒越高,也就意味着一旦做成了,价值也会越大。


“如果你选择了这个行业,最重要的就是一定要有耐心,一定要相信自己的选择。还有一点就是保持好奇心,多了解当下和未来,比如现在整个行业有了哪些新硬件或者新业务产生,了解的越多,你就越容易找到自己的突破点。”

数据库发展的这八年

「数据库的价值在于它的开放性。」


元启与 OceanBase 的这八年其实也是数据库行业变迁的一个缩影。对于元启来说,这八年时间感触最直接的变化就是单机的性能和性价比越来越高。SSD 越来越便宜也越来越快,内存变得越来越大,CPU 核数也在变多。而 OceanBase 在最开始其实就是基于 SSD 大内存多核来设计的,这也是 OceanBase 的一个后发优势。


然后就是从集中式转向分布式的这样一个大浪潮。其实互联网最开始是基于 KV 或者文件系统来做分布式。数据库的分布式主要依赖于业务配合中间件来做,但是 OceanBase 是真正开创了一套在工业上可用的分布式数据库。


亚马逊的 Aurora 做的是数据库的云服务,也可以叫做云原生的数据库。可以说是数据库方向的另外一个趋势,也有很多公司在效仿这个思路。Aurora 它的思路是首先保证数据库功能的完善,然后再去解决它的扩展性。OceanBase 相当于是走了完全不同的一条路,我们一开始的设计就是无限可扩展的,然后再开始持续不断完善功能。虽然过程会难很多,但是 Aurora 最终的扩展性是有限的,OceanBase 却是无限可扩展的。


谈到数据库未来的发展,元启一直强调“数据库的价值在于它的开放性”。


提到数据库,大家首先想到的就是 MySQL、Oracle。数据库之所以这么有价值,某种意义上是因为数据库开放的定义。关于什么是数据库其实这个概念一直在发生变化,比如时序数据库、空间信息数据库等等全新的概念层出不穷。


人工智能的普及化也给数据库带来了新的机会点。现在的人工智能更类似于用数据去训练,得到的更像是一套算法,最后能够进行识别和反馈。未来人工智能跟数据库有更紧密的结合,才能够发挥更大的价值。


数据库的边界在不断扩展,随着新技术的兴起未来数据库的机会点还会有更多。


本文转载自公众号蚂蚁金服科技(ID:Ant-Techfin)。


原文链接:


https://mp.weixin.qq.com/s/veol0Uez9Q_Aszy7O0cw5Q


2019-08-26 16:029170

评论

发布
暂无评论
发现更多内容

10年码农生涯经验总结,聊聊工作中18种接口优化方案!

Java全栈架构师

Java 数据库 程序员 程序人生 性能优化

TiDB常用SQL

TiDB 社区干货传送门

性能调优 集群管理

《关键信息基础设施安全保护要求》于明年五月正式实施

行云管家

网络安全

React中常见的TypeScript定义实战

xiaofeng

React

技术分享 | 多测试环境的动态伸缩实践

LigaAI

云原生 自动化测试框架 测试环境 测试自动化 kubenetes

使用Docker踩坑,排查完问题之后,又涨知识了

程序员小毕

Java Docker 程序员 程序人生 后端

低代码实现探索(五十三)后台逻辑的控制

零道云-混合式低代码平台

教你一招,安全的从 MySQL 切换到 TiDB

TiDB 社区干货传送门

迁移 实践案例

TiFlash 源码阅读(八)TiFlash 表达式的实现与设计

TiDB 社区干货传送门

AntDB入选《2022爱分析·信创厂商全景报告》

亚信AntDB数据库

AntDB 信创 国产数据库 aisware antdb AntDB数据库

技术分享 | TiUP工具 - TiDB集群滚动升级核心流程解析

TiDB 社区干货传送门

React性能优化的8种方式

xiaofeng

React

详解Native Memory Tracking之追踪区域分析

华为云开发者联盟

开发 内存 华为云

TiFlash 源码阅读(七)TiFlash Proxy 模块

TiDB 社区干货传送门

安防厂商在企业数字化转型中的机遇和挑战

慕枫技术笔记

AIOT 11月月更

老板拍脑袋决策,团队群魔乱舞

填空时光

决策 团队内耗 企业敏捷

# 分布式数据库新秀TIDB初探

TiDB 社区干货传送门

TiDB 底层架构 TiDB 源码解读

TiFlash 源码阅读(六) DeltaTree Index 的设计和实现分析

TiDB 社区干货传送门

react源码中的fiber架构

flyzz177

React

Go类型转换和类型断言可别搞混了

王中阳Go

golang 高效工作 学习方法 面试题 11月月更

CQRS与Event Sourcing

胖子笑西风

架构 DDD CQRS Event Sourcing #java

GaussDB CN服务异常实例分析

华为云开发者联盟

数据库 华为云 GaussDB

React生命周期深度完全解读

夏天的味道123

React

诚迈科技深耕汽车操作系统领域,获评优质供应商

科技热闻

React的5种高级模式

夏天的味道123

React

将业务从mysql迁移至TIDB,有哪些需要注意的?

TiDB 社区干货传送门

管理与运维 应用适配 大数据场景实践

《全国一体化政务大数据体系建设指南》发布,隐私计算将如何发挥作用?

洞见科技

react源码中的协调与调度

flyzz177

React

react源码中的hooks

flyzz177

React

React源码中的dom-diff

夏天的味道123

React

React-hooks+TypeScript最佳实战

xiaofeng

React

我在蚂蚁金服做后端:那些坚持在一个岗位做八年的人,后来怎么样了?_数据库_荔子_InfoQ精选文章