本文原始内容由作者“阳振坤”整理发布于Oceanbase技术公众号。
Oceanbase 是蚂蚁金服自研的分布式数据库，在其 9 年的发展历程里，从艰难上线到找不到业务场景濒临解散，最后在双十一的流量考验下浴火重生，成为蚂蚁金服全部核心系统的承载数据库。这一路走来的艰辛和故事，蚂蚁金服高级研究员、Oceanbase 团队负责人阳振坤将为你娓娓道来。
什么是Oceanbase数据库？
是阿里巴巴集团自主研发的分布式关系型数据库，融合传统关系型数据库强大功能与分布式系统的特点，具备持续可用、高度可扩展、高性能等优势。广泛应用于蚂蚁金服、网商银行等金融级核心系统。 在2015年双11承载了蚂蚁核心链路100%的流量，创下了交易、支付每秒支付峰值的新纪录，在功能、稳定性、可扩展性、性能方面都经历过严格的检验。
（本文同步发布于：http://www.52im.net/thread-2072-1-1.html）
阳振坤：博士、YOCSEF荣誉委员。
1984年进入北京大学，先后获得数学学士、硕士以及计算机博士学位后留校，1997年破格晋升为教授，1999年成为北京大学首批“长江学者奖励计划”特聘教授之一；
先后获得北京市科学技术进步奖一等奖、国家科学技术进步奖一等奖（排名第四）、第六届中国青年科技奖、北京市五四青年奖等；
曾先后担任方正研究院副院长、北大计算机研究所副所长、联想研究院首席研究员、微软亚洲研究院主任研究员、百度高级科学家等；
现担任淘宝研究员，主持淘宝海量数据库系统的研究和开发。
《阿里技术分享：深度揭秘阿里数据库技术方案的10年变迁史》
《微信后台基于时间序的海量数据冷热分级架构设计实践》
《现代IM系统中聊天消息的同步和存储方案探讨》
《腾讯资深架构师干货总结：一文读懂大型分布式系统设计的方方面面》
《新手入门：零基础理解大型分布式架构的演进历史、技术原理、最佳实践》
《一套高可用、易伸缩、高并发的IM群聊架构方案设计实践》
数据库在每个人的生活里无处不在，不管是通讯、交通、金融行业，抑或是每天大家都在接触的互联网，所有这些业务的背后都是数据库在支撑。
▲ 蚂蚁金服 Oceanbase 团队负责人阳振坤
数据库经历了近半个世纪的发展，在理论上很成熟，在技术应用上也已经非常成熟了。
但是数据库偏偏有一个特别高的门槛，原因是数据库有三条特别苛刻的要求：
1）事务须并发处理： 数据库要支持事务，所有人都希望用最小的处理资源，做到最大价值的事情。所以事务持续要做大量的并发处理；
2）数据一条不能错： 一个数据库如果数据错了，就永远没有机会了。对于使用者而言，如果你会错一条，你就有可能会错一千、一万条，这是没有公司愿意承担的风险；
3）服务片刻不能停： 通讯系统、列车系统，甚至飞机航行系统的背后都是数据库在支撑，这些系统一旦启动，一分一秒都是不能终止的。
上面提到的这三条要求，任何两个其实都好满足。但是大家仔细想一想，这三个要求如果要同时满足，就会变得极其困难。
同时，数据库又是一个巨大的市场，对国家、对整个社会都非常重要。这就导致很多国家、很多企业都想做也正在做这件事，但是结果大家都做到了同一个思路上。后来者都成了先行者的模仿者，那么这个模仿的代价就会变得很大。
今天作为一个后来者，你再去做这么一套数据库系统的时候，就真的很难说清楚你与先行者相比有多大的优势。这也就造成了强者恒强、寡头垄断的局面，后来者很难居上。
数据库同样也有开源这条路径，比如大家都了解的 MySQL。开源是免费的，对于很多对成本敏感的公司而言开源数据库成为了替代商业数据库的另一种选择。
那么在面对数据库的“死亡之谷”这样的困境下，为什么我们还去花这么多钱，投入这么多设备，花这么多年时间和人力再去做一个数据库，究竟它的意义在哪儿？它又能够产生多大的经济价值？
既然有了开源的数据库，阿里巴巴和蚂蚁金服还要做这么一个商业数据库产品，其实这里面是有本质原因的。很多人知道阿里巴巴今天已经 全面去 IOE：去掉了 Oracle 数据库、IBM 小型机、 EMC 存储。那么很多人就在想，能不能在其他的行业，在铁路、交通，电信、政府这些行业推而广之，全部完成去 O 的进程呢？这个答案是否定的。
因为像阿里巴巴发展的这一套系统是基于 MySQL 的开源数据库，跟商业数据库在功能和性能上其实是有很大差距的。阿里巴巴当时在用它的时候，有很多事情数据库是做不了的，那么这些做不了的事情当时就放在应用软件里做。所以阿里巴巴在数据库和应用软件上都投入了很大的技术力量。这套系统拿到外部业务去用是不能彻底解决问题的。本质上这套系统是服务于阿里巴巴的专用系统，而不是一个通用的系统。
那么有人会问，在我的企业里，如果真的想去掉 IOE，该怎么办？你同样要投入两拨人，一拨人要去做数据库，针对你的企业的需求来做相应的修改；还有一拨人要去做应用系统。但是问题是并不是所有的企业都像阿里巴巴有这么多优秀的技术人员，这套东西其实很难去直接推广应用。
所以，从一开始我们做 Oceanbase 的目标就是——我们不想只做一个专用的系统，要做就一定要做一个通用的系统。我们希望今后 Oceanbase 能够服务于各行各业，再也不需要企业投入几十几百甚至几千个人去改造、去重新做一套业务系统。
当时做 Oceanbase 数据库一个最根本性的原因就是需求的变化。因为这么一套基础系统，如果背后没有需求的变化，从 0 到 1 自己做出来基本是不可能的。
2010 年春夏之际，我来到了阿里巴巴。去了之后发现当时有两个因素影响了阿里巴巴关系数据库的应用。
一个因素是并发，数据库它是按照并发量来卖钱的。说直接点，就是按照处理器来卖钱。之所以要买这么多处理器就是因为业务有这么大的需求。那么传统的业务比如商场，一个商场就那么几个收银台，它是一个相对稳定而且比较小的并发量，大多数情况就是几十几百的并发量。
▲ 阳振坤分享经验心得
随着互联网的高速发展，阿里巴巴天猫双 11 几乎完全改变了过去行业内相对稳定的并发量，突破了几百万人甚至是千万人的同时在线购买。这个并发量跟过去的传统业务场景相比是几个数量级的增长，按照这个数量级去买商业数据库，没有一家企业买得起。
还有一个因素，当时我们叫它建站，其实就是搭建一个数据库。过去建一个商场，建一个银行的分店，这个周期是非常长的，有足够的时间来规划 IT 业务系统。互联网业务是等不了的，就像当时 Oceanbase 接的第一个业务给到我们的时间就是最多一个星期。现实是一个星期的时间根本连小型机的安装调试都完不成。
原来的模式已经完全无法支撑互联网快速发展的业务。所以这两个需求的变化，是催生我们自己来做数据库的很关键的因素。
当时我找了几个同事商量这个事情，我跟大家说，我们是天时地利人和都赶上，这件事情除非是被拍死掉，否则我们是肯定要把它做成的。这个过程真的非常艰辛，我们花了差不多五年的时间，才真正让 Oceanbase 有了关键的应用。
过去做数据库的公司，不管是国内还是国外，大家都是为了做数据库而做数据库，那么最后结果就是所有做传统数据库的厂商，大家的方案都很像。
因为数据库有很成熟的理论和工程的方法，那么如果我们按照以往的原则做过去，结果肯定也是一样的。所以，其实我们走了另外一条路——做分布式。最早做这个东西可能都不叫数据库，它更像是一个分布式系统，但是支持了事务的特性。这条路后来被证明确实是具有特别大的价值和意义。
当时我们在做 Oceanbase 的时候，首先确定了几件事情。第一件事就是我们要做分布式，因为我们的业务要建站，不做分布式靠大型机和小型机是不可能做得到的。
另外一件事是成本，什么东西最便宜，量最大最主流的东西最便宜，它就是 PC 服务器。小型机少则几十万，多则几百万，PC 服务器顶多就是几千几万块的成本。
第三个要解决的就是可靠性问题。大家对数据库的期望是永不宕机，永远不出问题。可是 PC 服务器到处都有，性价比也非常好，但是不容忽视的是它的故障率高。普通 PC 服务器它远远达不到数据库所要求的年可靠性五个九的要求。对普通 PC 服务器而言，差的可能是两个或者三个数量级，所以我们得首先把这个问题解决掉。我们用的就是分布式的办法来解决。
我们运用的是分布式的一致性协议，直白一点就是一个多数派的选举和投票协议。同时，我们把修改的增量直接放在内存里，每次要查询的时候，把内存硬盘的数据做一个 merge，那么每天在业务相对的低谷期，再把内存中的数据整理回硬盘去。
做到了这几件事情，这个系统就有了很好的性价比，我们的成本比传统的数据库至少低一个数量级，你只需要用普通的 PC 机，不需要用昂贵的硬件设施。同时，扩展能力会也变得很好。
理想看起来很美好，但是现实特别骨感。这个项目刚启动的时候，我们好不容易才找到了几个人，人手是严重不足的。另外一个更大的挑战是时间：在做 Oceanbase 数据库之前，我去找我的老板，他说给你 两年时间 如果能把一个数据库做出来就可以。当时我心里想两年虽然对于做数据库来说时间确实太短，但是这两年对于那时候的我们而言已经足够支撑起最初的想法了。
技术最终还是需要通过业务落实下去，所以我找了一批业务方，花了很长时间跟对方沟通，最后终于有一个业务愿意用我们的数据库。当时他给我的时间期限是——两个星期。
当时我就傻了，两个星期要做个数据库，这可怎么办？后来跟业务的同学反复讨论，最后他们同意说，你们先做个 demo 出来。于是我们就花了两个月吭哧吭哧的做了一个 demo 出来。他们看了以后觉得比较满意，后来这个事情就一直坚持做下去了。
最后，我记得是到了第八个月的时候，系统上线了。这个业务就是现在大家都在用的——淘宝收藏夹，这是 Oceanbase 的第一个业务。如果没有这个业务，我们现在也活不下来。
▲ 淘宝收藏夹业务
那么这个业务到底有什么特殊的地方？每个人都用过淘宝收藏夹，每次你打开收藏夹的时候，数据库在背后其实做了很多事情：我们以单个商品为例，它需要到一个叫商品库的地方，逐条纪录核对，看看商品有没有下架，有没有参与促销，有没有参加其他的返点活动等等。
假如你收藏了 100 多件商品，它就要进去一条条的取出来看。本质上来讲，这就意味着一百多次的随机 IO。那么当很多人同时来看的时候，其实一个 IO 就被放大了几百倍，这时候有多少个硬盘都不够用。
当时他们已经用了几十台服务器了，按照业务的预估，第二年他们要买 400 台机器，第三年的数量都不敢想象。当时我们想了一个办法——我们做了一个 宽表，确切的讲应该称为 物化视图。
▲ 淘宝收藏夹的宽表
首先我们把每个用户收藏的信息聚集起来，这样可以减少 IO，然后把收藏的商品放在这个列表里。但是我们怎么避免去访问一百多次 IO 呢？我们的办法就是找到一个时间点，当时是设定在每天晚上凌晨两点。在这之前，我们就把这些信息全部 merge 到硬盘，然后从两点开始，我们把新的修改都放在内存里面。
所以每到两点的时候，我们把两点之前所有的信息都合到这张表里，那么这张表里的信息在两点整的时候是准确的，这时候我们不需要去访问商品库。两点之后的修改，包括商品库的修改是在内存里进行的，这时候如果要看这些商品有哪些修改，商品只需访问内存中的更新即可。
所以其实我们就是通过这样一个手段，把每次收藏夹的展示，由原来的一百多次 IO 变成了一次。我们一下子就把淘宝收藏夹业务的整个 IO 降下来了。当时 Oceanbase 确实是帮助业务实际解决了他们的问题，使得业务能够更好的快速的发展。业务是一定要发展的，所以只有我们真正能够解决他们的问题，我们这些做基础系统做底层的人，才能活下去。
▲ 淘宝收藏夹架构图
这是当时给淘宝收藏夹做的一个架构，中间是一个做修改的服务器，所有的修改都在这一台机器上进行。旁边的机器是基线数据，就是分片切片以后，放到周围这一圈进行。所以当时我们就用这个看上去很简陋的一个方案来真正解决了淘宝收藏夹的问题。
当时收藏夹用了这个方案之后，服务器的数量从原来预计的第二年要用几百台，最后其实只用了差不多二十几台服务器，就把整个问题解决掉了。
从淘宝收藏夹项目之后，我们陆陆续续也做了不少项目，但是没有一个项目能像淘宝收藏夹这样对业务有明显的价值和贡献。
从那之后的整整两年，我们找不到对 Oceanbase 数据库而言特别有价值的业务。那两年对于我们而言特别特别困难，甚至整个团队随时面临着解散。
2012 年底，公司把我们从淘宝调到支付宝，当时预估到支付宝在数据库方面所面对的挑战更大，后来证明确实如此。即使是这样，当时仍然还处在一个非常困难的时期。到了支付宝一年多的时间，我们仍然很难找到新的业务，或者说价值比较大的业务来证明我们的价值。
2013 年的夏天，支付宝希望全面去掉 IOE——去掉 IBM 的小型机，Oracle 的数据库和 EMC 的存储。当时面临了一个问题，就是去掉之后是可以用 MySQL 来代替 Oracle，但是 MySQL 的主备镜像其实是做不到主备完全一致的。
这个时候我们意识到：Oceanbase 的机会来了。因为我们可以通过分布式的选举跟投票来做，哪怕硬件本身不可靠，我们也能保证数据的不丢失。传统数据库本质上是借助硬件的可靠性，也就是硬件需要达到五个九的可靠性来实现高可用的。就算出了故障，它的数据也能救得回来。但是这种手段需要非常高的成本，同时没有足够的扩展能力。
银行虽然有很高的可用性，但是它的高可用性是用很高的硬件成本换来的。我们建议一定要淘汰这些高可靠的硬件，因为他们的成本实在太高了。一旦真的使用了高性能，高性价比的 PC 服务器，那么你就不可能再花那么多钱去买高端的硬件。
所以我当时心里很明白，如果这件事情我们做不成，这个项目就只有死路一条。
那么，Oceanbase 到底如何做到主备完全一致的呢？理论上我们也没有办法说完全做到主库备库的一致。我们用了另外一个办法：主库还是主库，还是需要它快速的做事务，但同时主库还要把事务的日志同步给至少两个备库。两个备库中至少有一个收到了，那么加上它自己就超过了半数，或者我们叫多数派。当多数的节点收到了这个事务，并且把它持久化到硬盘了，我们就认为这个事务是成功的。
所以这时候任何一台机器坏掉，每笔事务在剩下两台机器里面至少一台存在。所以说即使主库突然坏掉，另外两台机器经过握手，它们再选举出一个新的主库，那么肯定可以继续工作下去，同时可以保证数据是没有损失的。
2014 年的时候，我们在会议室里讨论 支付宝交易库的上线，当时吵得面红耳赤，争论了很久别人就是不愿意上 OB。他们原来的交易、支付系统全都在 Oracle 上，当时的 Oracle 无论是在稳定性、可靠性还是性能方面，肯定比 Oceanbase 要好得多。所以没有人愿意用。
最后，在 鲁肃（蚂蚁金服 CTO） 的力挺下决定切给 Oceanbase 1% 的流量试试。因为那几年业务发展的太快，当时 Oracle 的共享存储已经扛不住这个流量，按照当时的业务流量去做压测的时候，几分钟就要坏一块盘。最后发现，把业务切掉 10%，才能勉强扛得住。所以那一年的双 11 就把 10% 的流量切到了 Oceanbase。Oceanbase 也成功扛过去了那一年的双 11。
但是其实在 0.5 这个版本上线的时候，我们心里非常清楚，这个版本是临时的。我们当时选择做多数派协议的时候，还是用了原来的想法，每个集群还是中间有一个中心节点。这个事情一定不会是长久持续下去的，我们知道这个一定会遇到问题。所以当时其实交易库还没有完全上线，我们就已经启动了 1.0 版本的开发。
2014 年到 2016 年，整整两年的时间，我们投入了 40 多个人，全部投在 Oceanbase 1.0 版本的开发上。整整两年，这 40 多个人没干任何别的事情。所有的线上问题，版本修改、升级都是我们调出来的五个同学全部扛下来的。
有人会问什么样的因素让这么多人做了两年才能把这个版本做出来？这个版本里面我们主要做的一件事就是分布式。
如果你问分布式事务有这么难吗？我可以自豪地回答你：今天的商业数据库里有且只有一个是能够支持分布式事务的，它就是 Oceanbase。
Oceanbase 通过分布式的一致性协议做到了系统的高可用性，就是说哪怕我们今天用的是比较廉价的，可靠性比较低的 PC 服务器，但是我们的可用性其实会变得更高。因为单机的故障我们完全能够自动的容忍掉，而且我们做到了现在的数据做不到的一件事情——哪怕主库出故障，我们能够保证数据没有任何损失。
今天的银行每年国家都要求他们至少做一次消防演习，银行要到最前端的网关把交易纪录捞出来核对，把这些账对平了，备库才能继续服务。我们今天根本没有这个问题，主库出故障了，也就是几十秒以后，新的主库就会被选出来。因为只要剩下的机器超过半数，他们互相之间会通过握手把数据补齐，很快就能工作。其实这 30 秒大部分还是消耗在确定主库是否真的有故障。
所以，我们用不可靠的硬件反而做到了更高的可用性，而且做到了数据真正的一致。
传统的数据库因为涉及到共享存储，共享存储是一个单一的设备，你只能放在一个机房。所以一旦那个机房出现了故障，你就只能靠备库容灾把系统恢复起来。
Oceanbase 通过“三地五中心”部署实现城市级故障自动无损容灾。比方说相当于你一共写了五份日志，放在三个不同的城市里。任何一个城市哪怕出故障，比方说杭州断网了，那么剩下的依然超过半数，这个系统还是可以恢复工作的。这也是原来的传统数据库，不管想什么办法，都做不到的事情。
▲ 2018年 9 月 20 日云栖大会 ATEC 主论坛现场剪光缆实况
前段时间，大家可能也看到了云栖大会的新闻。蚂蚁金服副 CTO 胡喜在 ATEC 主论坛现场模拟挖断支付宝近一半服务器的光缆。结果只过了 26 秒，模拟环境中的支付宝就完全恢复了正常。而这场 26 秒自断服务器现场演示的技术核心其实正是基于 Oceanbase 的三地五中心架构方案。
2017 年，天猫双 11 中蚂蚁金服的全部核心系统，包括很多业务系统都放在了 Oceanbase 上。去年我们创造了 25.6 万笔 / 秒 支付峰值的世界纪录，这下面还有一个数据，就是说我们为了要执行这 25.6 万笔的支付，执行了 4200 万条 SQL。
所以从今天来看，Oceanbase 在过去的历史进程中面临了一个个新的机遇，无论是处理器、操作系统还是数据库，这些都是非常大的挑战。
从 2016 年底，我们就开始做准备，Oceanbase 一定要走出去。从我们成立的第一天起，团队里的每个成员的目标都是一致的：我们不是想做一个数据库只是给自己用，我们要做一个数据库真的去推动整个社会的进步，能够让整个社会的生产力发生变化。
所以，2017 年我们正式开始服务于外部，最早的两家客户是 浙商银行 和 南京银行，我们现在的客户要多很多。从内部的应用到真正走出去服务于外部，真的是一个很大的挑战，是一件很困难的事情。
回想这八年多来，Oceanbase 走过的路：开始的头两三年，我们真的每天都在挣扎，每分每秒都在想着怎么能让自己活下来。到了 2013、2014 年，我们终于找到了一个真正的立足点，就是支付宝的交易库。然后我们接着花了整整两年的时间，真正在 Oceanbase 1.0 版本把分布式做出来。在接下来的一到两年时间里，我们把支付宝的核心业务全部搬到 Oceanbase 上。
关系数据库确实是个门槛很高的东西，但是凡事有利有弊。门槛高意味着我们进来很难，别人进来一样难。我们集中精力在做事务处理这一块，它的门槛是很高，很不容易进去，但我们恰恰有这个机会能进去。我们费了很大的力气跨进来了，别人可能费了全部力气也进不来。
现在回想起来，能够把最早的一些想法一些创新变成产品，真的是非常辛苦或者说非常痛苦的一条道路。但是我们做的所有事情其实还是从业务、从客户中出发，只有技术真的能够落到生产中去，落到用户中去才是真正有价值的，否则你做得再好也是一个空中楼阁。
到了今天，当我们走出阿里巴巴，走出蚂蚁金服再来看，发现当你做的事情能够提供十倍性价比的时候，其实真的有机会去颠覆一个产业，重新塑造一个行业。
[1] 有关大型互联网系统架构设计的文章：
《浅谈IM系统的架构设计》
《简述移动端IM开发的那些坑：架构设计、通信协议和客户端》
《一套海量在线用户的移动端IM架构设计实践分享(含详细图文)》
《一套原创分布式即时通讯(IM)系统理论架构方案》
《从零到卓越：京东客服即时通讯系统的技术架构演进历程》
《蘑菇街即时通讯/IM服务器开发之架构选择》
《腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT》
《微信后台基于时间序的海量数据冷热分级架构设计实践》
《微信技术总监谈架构：微信之道——大道至简(演讲全文)》
《如何解读《微信技术总监谈架构：微信之道——大道至简》》
《快速裂变：见证微信强大后台架构从0到1的演进历程（一）》
《17年的实践：腾讯海量产品的技术方法论》
《移动端IM中大规模群消息的推送如何保证效率、实时性？》
《现代IM系统中聊天消息的同步和存储方案探讨》
《IM开发基础知识补课(二)：如何设计大量图片文件的服务端存储架构？》
《IM开发基础知识补课(三)：快速理解服务端数据库读写分离原理及实践建议》
《IM开发基础知识补课(四)：正确理解HTTP短连接中的cookie、Session和Token》
《WhatsApp技术实践分享：32人工程团队创造的技术神话》
《微信朋友圈千亿访问量背后的技术挑战和实践总结》
《王者荣耀2亿用户量的背后：产品定位、技术架构、网络方案等》
《IM系统的MQ消息中间件选型：Kafka还是RabbitMQ？》
《腾讯资深架构师干货总结：一文读懂大型分布式系统设计的方方面面》
《以微博类应用场景为例，总结海量社交系统的架构设计步骤》
《快速理解高性能HTTP服务端的负载均衡技术原理》
《子弹短信光鲜的背后：网易云信首席架构师分享亿级IM平台的技术实践》
《知乎技术分享：从单机到2000万QPS并发的Redis高性能缓存实践之路》
《IM开发基础知识补课(五)：通俗易懂，正确理解并用好MQ消息队列》
《微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）》
《微信技术分享：微信的海量IM聊天消息序列号生成实践（容灾方案篇）》
《新手入门：零基础理解大型分布式架构的演进历史、技术原理、最佳实践》
《一套高可用、易伸缩、高并发的IM群聊架构方案设计实践》
《阿里技术分享：深度揭秘阿里数据库技术方案的10年变迁史》
《阿里技术分享：阿里自研金融级数据库Oceanbase的艰辛成长之路》
>> 更多同类文章 ……
[2] 更多感悟和思考
《一个微信实习生自述：我眼中的微信开发团队》
《微信程序员创业总结：如何提高Android开发效率》
《如何做一个合格的 iOS Team Leader》
《程序员中年危机：拿什么拯救你，我的三十五岁》
《一个魔都程序员的3年：从程序员到CTO的历练》
《为什么说即时通讯社交APP创业就是一个坑？》
《致我们再也回不去的 Github ...》
《一名90后二流大学程序员的自述：我是如何从“菜鸟”到“辣鸡”的》
《一个魔都程序员的3年：从程序员到CTO的历练》
《选择比努力更重要：我是如何从流水线工人到程序员的？》
《程序员的抉择：必须离开帝都——因为除了工作机会，还有什么值得留恋？》
《即时通讯创业必读：解密微信的产品定位、创新思维、设计法则等》
《干了这碗鸡汤：从理发店小弟到阿里P10技术大牛》
《程序员神级跳槽攻略：什么时候该跳？做什么准备？到哪里找工作？》
《感悟分享：在腾讯的八年，我的成长之路和职业思考》
《调皮的程序员：Linux之父雕刻在Linux内核中的故事》
《老罗最新发布了“子弹短信”这款IM，主打熟人社交能否对标微信？》
《迷茫中前行：一个专科渣渣菜鸟的编程入门感悟》
《盘点和反思在微信的阴影下艰难求生的移动端IM应用》
《QQ现状深度剖析：你还认为QQ已经被微信打败了吗？
《机会不给无准备的人：一个Android程序员屡战屡败的悲惨校招经历》
《笑中带泪的码农往事：入职三天被开，公司给100块叫我走人，有我惨？》
>> 更多同类文章 ……
[3] 互联网大厂的技术故事：
《技术往事：微信估值已超5千亿，雷军曾有机会收编张小龙及其Foxmail》
《QQ和微信凶猛成长的背后：腾讯网络基础架构的这些年》
《闲话即时通讯：腾讯的成长史本质就是一部QQ成长史》
《2017微信数据报告：日活跃用户达9亿、日发消息380亿条》
《腾讯开发微信花了多少钱？技术难度真这么大？难在哪？》
《技术往事：创业初期的腾讯——16年前的冬天，谁动了马化腾的代码》
《技术往事：史上最全QQ图标变迁过程，追寻IM巨人的演进历史》
《技术往事：“QQ群”和“微信红包”是怎么来的？》
《开发往事：深度讲述2010到2015，微信一路风雨的背后》
《开发往事：微信千年不变的那张闪屏图片的由来》
《开发往事：记录微信3.0版背后的故事（距微信1.0发布9个月时）》
《一个微信实习生自述：我眼中的微信开发团队》
《首次揭秘：QQ实时视频聊天背后的神秘组织》
《为什么说即时通讯社交APP创业就是一个坑？》
《微信七年回顾：历经多少质疑和差评，才配拥有今天的强大》
《前创始团队成员分享：盘点微信的前世今生——微信成功的必然和偶然》
《即时通讯创业必读：解密微信的产品定位、创新思维、设计法则等》
《QQ的成功，远没有你想象的那么顺利和轻松》
《QQ现状深度剖析：你还认为QQ已经被微信打败了吗？》
《[技术脑洞] 如果把14亿中国人拉到一个微信群里技术上能实现吗？》
《QQ和微信止步不前，意味着即时通讯社交应用创业的第2春已来？ 》
>> 更多同类文章 ……