在 GTLC 台北站上，前美图技术 VP、AfterShip CTO & TGO 鲲鹏会会员洪小军带来了「我的移动互联网十年成长经历」的主题分享。从 2008 年开始，洪小军历经中国移动飞信、新浪微博和美图三个中国内地很典型的亿级用户规模的移动互联网公司的关键发展阶段，历任工程师、架构师、技术经理、技术总监和技术副总裁。

TGO 鲲鹏会公众将分为 4 篇分享洪小军在过去十年对于行业、技术、管理等方面进行的思考，本篇内容着重讲述着重讲述洪小军在新浪微博时期的收获和成长。

作者 | 洪小军

编辑 | Rainie Liu

新浪微博时期

2011 年初，我加入了新浪微博平台研发部门。从业务的角度来看，平台研发部门主要职责是为 Weibo.com、移动端和开放平台等提供 API 服务。当时，微博平台面临着很大的技术性挑战，承担着整体最大的访问量级，服务需要有最高的可用性保证。在平台端，因为保存着微博几乎所有的数据，所以也会面临着海量数据存储和处理的各项挑战。

我把在新浪微博的工作主要分为了 3 个阶段：

互联网小常识：将主机（A）资源记录手动添加到正向查找区域时，使用“创建相关的指针（PTR）记录”选项，可以将指针记录自动添加到反向查找区域中。

1、业务架构师阶段

在新浪微博时，我常常思考自己未来的定位和发展问题，但是无论是如何，我认为最重要的是，需要提升自己对于业务的理解能力，从业务开发和业务架构师入手，思考如何更好帮助产品和团队发展。

2011 年，在加入新浪微博之后，我基本上参与了绝大部分的业务系统研发和优化工作，从消息总线、移动端 Push，到好友关系服务、计数器服务、短链服务、未读数服务，再到微博的 Feed 服务、评论点赞服务等，其中涉及到重写、优化、功能开发等方面。

在此阶段，我深刻体会到跟时间赛跑的含义。因为业务发展很快，所以我们需要争分夺秒的解决性能和可用性的问题，比如微博未读数服务——用户在刷微博时，会看到还有几条未读的新微博；当出现新微博时，我们需要提醒用户未读微博信息。这是一个看起来很小的业务功能，但是当你深入分析实现方案时，你会发现它没有想象中那么简单，尤其是在访问量级很大、响应时间和成本要求很高的情况下。

2011 年时，微博的平台部门不到 20 人，我们需要承担微博绝大部分业务服务的 API 开发，所以整个团队的节奏非常快。

我依稀记得入职第一天，原本我计划晚上给朋友送东西，想着入职第一天应该加班也不会太晚，所以约了晚上 11 点，结果发现到了晚上 10 点，团队一个人都没离开，团队老大 TimYang（TimYang，新浪微博研发部副总经理，TGO 鲲鹏会第一任北京分会会长）都在。最后到了快 12 点，我才发现终于有人离开了。虽然当时团队节奏非常快，但是大家的状态都很好，也非常有激情。

还有一件让我有深刻体会的事情是，时间挤挤总是能出来的。当时 TimYang 组织了一系列编程比赛，其中有一次是限定用 Scala 语言，看谁能让 CPU Load 跑最高。

那时，距离比赛仅剩 4 天时间，我们基本都是在满负荷工作，基本每天工作到 11 点才回家，还有半夜上线的情况，而且团队中多数人都没有接触过 Scala。但是，大家仍然利用 4 天时间，挤牙膏似的在乘坐地铁的过程中、睡前、午休等剩余时间学习相关的知识和做好各种 case study，最后大家基本上都完成了比赛。因此，我一直都用时间挤挤总是有的来鼓励自己。

在微博的第一年时间里，我基本上围绕着业务系统工作，其中有几件事让我特别有感触：

第一件事是，我到公司做的第一个系统是统一消息总线系统（内部称为 firehose）。从后来的业务演化角度来看，消息总线系统对于内部组织协作和业务发展起了很大的帮助。

在此期间，微博核心业务系统在不断演进，同时公司围绕着微博在做很多新的扩展业务尝试，消息总线系统成为了一种很好的系统间接耦方式，也能很方便、快速的为微博生态提供各种产品和服务。

通过一段时间，我们发现这也是一种比较好的实践方式，很多公司都很需要这样的一套机制，尤其是在公司需要围绕其中 1-2 款核心产品做各种延伸和创新的情况下。

第二件事是，2011 年中旬，我负责新版本微博未读数服务的开发工作，这个业务看似简单，但是对于如何实现高并发、高性能和低成本有不小的挑战。

当时的问题场景是，百万以上级 QPS，每个人平均关注百级别好友数（基于敏感数据考虑只是列大概值），每天千万以上级微博发送量，Latency 需要保证 99% 的情况在 10 毫秒以下，可以接受数据最终一致性，我们需要显示具体的数字，而不仅仅是有新消息（当然，后续有些场景会有所权衡）。为了解决这个问题，大家都在进行头脑风暴，最终方案采用的是由微博平台的田琪大师提出的参考 Git 的 Snapshot 的机制。

这件事情给我很大的启发，在日常工作生活中，往往已经出现了很多很好的实践方式，如果我们对于这些事情进行延伸思考、观察和进一步总结，往往能帮助我们解决很多新问题。在今年的 GTLC 上海站中，七牛老许（许式伟，七牛云创始人 & CEO）提到，计算机学科是一个非常年轻的学科，与人类社会几千年的发展相比，计算机科学还只能算是一个幼童，所以很需要从人类发展的几千年中进行更多学习。

第三件事是，当时微博有两个数据源，一个是从 2009 年微博网页版发布时，一直维护的主站数据库；另一个是 2010 年，微博做开放平台重新建设的平台数据库。虽然都是全量的数据，但是由于各种历史原因，主站数据库早期的数据更全，平台数据库后期的数据更全，并且两个数据库从设计上差异很大，导致出现数据一致性和完整性的问题。尤其是在不同的数据源中，大家各自使用不同的 ID，这给团队带来了很大的困扰。

于是在 2011 年国庆节前一周，我们讨论要不要重新设计一套新的数据库，包括从整体架构上进行综合梳理，同时把历史的两个数据库里所有的 Feed、转发、评论和赞等微博核心数据都导入新的数据库，解决掉历史的各种包袱问题。最后，我们 4 个人说干就干，立刻梳理了原先所有的架构，设计新的系统架构，开始写导数据的工具，计划在国庆期间让工具运行起来。

原本这是一个预计快速突破的项目，但是最后成为了持续近半年的项目，其中的关键原因是这个项目的目标在持续扩大，扩大为重构微博整体核心业务系统和实现微博异地多 IDC 部署。

我们在梳理整体新系统架构之后，项目最大的挑战是，如何在多个数据源的情况下，保持万亿级数据的一致性；如何让新老系统同时稳定的运行；如何实现跨越中国南北实现异地多 IDC 部署。同时，由于数据库的改变，导致基本上所有微博的业务系统都需要进行调整。可想而知，这个工作量有多大，我们不仅需要深入了解所有涉及的业务系统，而且还需要做逐步的调整。

通过这件事，让我对微博整体的业务和架构以及国内外相关公司的架构有了更深入的了解，同时拥有与公司内部各个团队深入沟通、建立互信的机会。尽管在这半年非常辛苦，基本上很少凌晨两点前回家，但是这对我个人的成长还是非常大的。同时，因为经历了这件事情，让我与参加过全程的项目组成员建立了非常深厚的革命感情。后来，我们还一起去了沙漠、草原和丽江。（天知道当时三个单身男子在丽江酒吧里呆呆看着旁边小哥各种撩妹是什么心情，但是这也算是我们三个人的共同回忆了 。）

通过这段经历，让我更深刻体会到架构需要有权衡全局的能力。比如，在系统快速迭代的同时，我们需要完成新需求、保证新老系统运行，平衡系统等等，这极大程度的锻炼了我们的全局视野和能力。当然也让我体会到在快速发展的阶段，拥有强执行力和组织管理能力的重要性。

2012 年初，微博做了不少业务创新和尝试，尽管大家本职工作已经很多，然而大家还是都凝聚在一起，齐心协力在短时间内快速开发上线新的业务系统，尽管很多不是原本计划内的工作。在这个过程中，我也能更深入的体会到，大家如何站在业务角度思考去帮助公司，而不是陷入到技术里。虽然技术很重要，但是我们还是要做到能综合考虑。

开发完新版本微博服务后，我们马上面临的最大挑战是，如何平滑的上线。

类似微博的系统都是构建在缓存体系之上，可以说缓存是其中最核心、最重要的基础设施。因此我们除了需要保证缓存的高可用和高可扩展之外，还需要严格保证缓存的高命中率以及控制尽量低的成本等等。一旦缓存出现问题，那么就可能带来致命的雪崩——整体性大量故障，并且在短时间内不能马上修复，国内外有不少大公司也出现过这种血的经历。

互联网小常识：构成超网的CIDR技术的两个特点：（1）采用网络前缀代替网络号+主机号的结构，形成新的二级网络地址结构，即IP地址可表示<网络前缀>+<主机号>（2）CIDR可以将网络前缀相同的连续IP地址组成一个CIDR地址块。CIDR地址的一个重要特点是地址汇聚与路由汇聚的能力。

而这次新系统上线调整就包括微博最核心的 Feed 服务， Feed 服务的缓存命中率长期保持在 99.9% 以上，因为它承担着最大的访问量，同时也是微博最核心的业务（如果出现问题将直接导致微博首页出问题）。

在调整过程中，我们需要使用新的数据库和缓存系统。经历过 10 多个日夜颠倒的日子之后，我与微博 Feed 业务负责人道儒终于一起把整体平滑的切换上线。通过这件事，让我对于缓存有了更深入、更体系的认识。除此之外，也让我对于缓存有了更加深刻的敬畏心，对于涉及缓存的调整，我们需要有非常严谨的 checklist 以及需要梳理清楚所有异常场景，并有提前准备和演练，哪怕漏掉一个微小的细节可能都会导致致命的故障。墨菲定律（意为如果事情有变坏的可能，不管这种可能性有多小，它总会发生。）真的非常灵验，所以我们不要具有侥幸心理。

通过这件事，让我学会了做事要保持一颗敬畏心。无论是在熟悉的领域，还是在不熟悉的领域里，都需要保持一颗敬畏心。这能让你更好地与大家沟通配合，同时也能真正收获和学习很多知识。

在新版本微博服务上线后，我们马上做的事情是，实现异地多 IDC 部署上线。

微博平台在比较早期就实现了同城多 IDC 部署，而异地 IDC 部署又面临不少新的挑战。在这个过程中，我们从实现多机房读取单机房写入、核心业务和需要做多 IDC 的业务做起，一步步达到目标，最终实现让南方用户和海外用户的使用体验得到进一步的提升。

2012 年 5 月，新版本的微博、评论、点赞等系统上线了，微博的异地多 IDC 也正式上线了。当时，我松了很大一口气，这口气我憋了有半年，一直是忙到根本都没有时间去想自己有多忙。

2、技术架构师阶段

微博是行业里比较早真正实践在线容错和压测演练的公司，也就现在所说的混沌工程。当然这个诉求也是来自于业务，随着微博系统复杂度越来越高，出问题的概率肯定是会越来越大，因为从理论的角度看，每个环节都可能出现问题。如果没有预判当问题出现时整体的系统反应情况，那么我们就会变得很被动。

而在很多场景下，我们没有办法完全复现测试环境中出现的所有问题。因此最好的情况是，我们在线上直接去模拟，或者演练真实的问题，看系统的表现，防范于未然。

微博的容错演练系统是 TouchStone，我们希望它可以通过在线容灾演练，尽早发现线上的问题，并提前解决。同时，当真正出现故障时，也有机制能尽快处理。

这时，我们需要与业务团队进行配合，搭建更体系化的系统，比如高可用体系的建设。对于微博这类时事热点事件非常敏感的系统来说，高可用的体系建设的重要程度不言而喻。

同时在这个阶段，我开始更多地参与到一些分享、交流的活动当中，包括内部的新兵训练营、微博平台技术开放日、新浪技术交流大会以及外部的技术沙龙活动和跨公司专项交流会。从 2008 年开始，我基本上每年都去参加几场在北京的大型技术大会。通过这些活动，不仅让我提高了视野，而且学会了用辩证性的角度看待各类事物，看到了更多千疮百孔和不完美，也逐步接纳了不完美的世界、不完美的项目和不完美的自己。

3、架构平台团队阶段

2013 年，我开始负责微博平台架构团队。当时，微博平台架构团队是由几个核心业务团队中比较核心的同学以及平台基础研发的同学组成，期望通过基础设施的建设和部分核心业务的研发，帮助业务发展和团队的成长。

这是一个可能最不需要管理的团队，因为一方面他们很了解业务，另一方面他们拥有很强的基础研发能力，同时每个人还拥有很强的自律性和自驱力，在团队中也十分受人尊敬，因为当平台中任何业务线出现了问题，总能看到他们的身影。

此时，我重点思考两个问题：

1、从业务的角度看，公司和平台需要什么，业务需要什么，这些人怎么做才能帮助到业务团队，帮助产品做得更好；

2、我该如何帮助团队和团队成员获得更快、更好的成长。

在我的理解里，只有能帮助业务和个人共同成长的组织才是可持续的。因此，我花了大量的时间在思考这两个问题，做的事情很多也围绕着这些方面。

我认为，首先我们需要从业务入手，梳理从业务角度需要的基础设施，包括未来的微博需要什么样的技术和业务支撑；最后再统一朝着更加体系化的方向演进。

基于业务场景角度的考虑，微博 Feed 服务采用推拉结合的方案。对于普通类型的微博采用拉的方案，获取所有好友的 TopN 微博 ID 进行堆排，而特殊的微博采用推的方案。

但是随着每个人发布的微博量越来越多、好友关注数量越来越多，大家对于微博的使用体验也越来越高时，我们迫切地需要对当时的架构做进一步的优化。一方面我们在推动做一些更前沿更理想化、一步到位的存储靠近计算方案和集存储、计算为一体的定制性服务，另外一方面还需要思考如何基于现有架构更加极致的优化。

2014 年 3 月，我们启动了基于现有架构进行极致优化的方案，期望通过 1 个月的封闭开发完成系统的上线。这让我不禁回想起 2 年前同一时期，我们针对微博 Feed 服务进行的整体优化和调整，因为有了上一次的经验，同时我们拥有了更好的条件，比如健全的稳定性保障体系、在线容灾和压测演练体系、多 IDC 容灾体系、高可用的缓存服务等等，所以我们当时的整体改造得很顺利。

最终，我们的项目在 1 个月内顺利上线。上线后，Feed 极致优化方案减少了 Feed 服务 1/3 的缓存容量，降低了 1/3 的带宽消耗，同时接口服务 Latency 也降低了 1/3 以上，达到了全方位优化的效果。

这是一个比较典型的基于数据驱动优化项目，在优化之前，我们需要针对用户访问行为等做了多维度数据分析，建立访问模型，整个过程都需要基于数据驱动的方式推行。因此通过这个项目，让我明白了我们需要在日常做更深入的思考和积累，一旦逐步从量变到质变，那么能给我们带来的能力是很大的，当我们能做到有规划和方向前进时，那么认真做好每一件事就变得非常重要了。

此时，我们也常常在思考，如何进一步的帮助团队提升整体技术氛围和技术影响力。因为我在 TimYang 组织和建立起来的很好技术氛围中受益良多，所以我也很期望能尽量多帮助大家。

后来，我逐渐开始在微博平台技术开放日做分享，推动大家更多地参与到行业里的技术沙龙和技术大会，同时通过微博夜校等方式让大家拥有更好的学习氛围，从中也去挖掘潜在人才并给予更多的空间。

在微博工作期间，我也感受到了新浪微博很强的执行力，会在多个团队协作的重点项目中设立项目评审小组，整合跨团队的公司所有资源，让不同团队有统一的目标和执行计划，然后快速执行。

总的来说，在新浪微博时期是我个人技术成长最大和最快的阶段，虽然也是最忙最累的阶段，但是我很感谢这段经历。在微博平台研发部的经历，让我很深刻的感受到团队家庭的概念。在工作中，大家互帮互助，尽管后面有些人相见于江湖，但是大家都很感谢和珍惜一起在微博的经历，都还是像在微博时那样互帮互助。

在此之前，我曾在飞信也感受到很多团队带来的感动，感谢架构团队负责人 CC 和部门负责人攀哥（杨攀，融云联合创始人兼 CTO & TGO 鲲鹏会会员），感谢小伙伴们。一直都很感激大家，感激大家在当时给予我很多的帮助和支持，也很感谢组织和 TimYang 给大家营造良好的工作氛围，大家都在跟着业务快速成长，让我更加深刻感受到业务发展和个人发展是可以双赢的。后来，我的职业发展生涯里很多团队建设的思考也是借鉴于此。