infra FB海归国内高管：谈谈infra、代码管理、微服务、测试系统，以及技术人员海归能做什么。

总有关注一亩三分地的朋友，他们对作者alexwy也不陌生！他已经在“海归版”里和大家分享过了，这次他带着超强的技术干货来了！！感谢作者一直以来的更新和分享。

技术栈有很多方面，先说下文。文章很长，不喜欢技术的要慎重。

我只在国外FB工作过。infra类似于G，与中国相比应该是两个极端。硅谷其他公司，个人理解多多少少介于两者之间，了解的欢迎补充。

做技术比较，有助于了解人才的背景和发展历史。硅谷的技术圈是一个联合国，聚集了各国顶尖人才，但美国本土人是少数。虽然中国人口多，数学物理基础好，但毕竟只是个国家。然后，中国的互联网公司比美国多很多倍。不管美国有没有，中国不止一个版本。所以有限的资源是分散的。

现在很多人说，互联网的寒冬应该和之前人口红利时期的疯狂扩张相比较。当时我们公司把研发从一年100个扩大到1000个。滴滴优步大战期间，几百人从零开始进入各个部门，没有海归被授予管理岗位。半年时间500人进入智慧城市。这种例子比比皆是。相比之下，FB的增速已经很久没有超过每年30%了。

在这个市场的带动下，国内的技师大多不是985或者计算机专业的。国内没有好的转专业或者选修课的机制，课程的水平大家都知道。那为什么感觉中国的app功能比美国多无数倍，不用一直死机或者长得太硬直接看？这不得不佩服中国人的智慧，进化出一个框架，让任何小白都可以通过阅读Java初级读本开始贡献产品级代码。

正是因为这种架构，程序员才成为劳动密集型的工种，使得996家喻户晓，程序员单位时间的生产力与美国相差甚远。

代码管理

代码管理的重要区别是FG是代码库加骨干开发。在国内，除了个人围棋选手，通常至少有一个项目，很容易达到四位数的水平。回购的数量有很多争议。单个回购骨干的开发确实影响迭代速度。我在FB升级了numpy，花了一个多月的时间尝试解决各种依赖。最后，有两个构建无法解决，所以我强迫他们升级，让他们的团队自己完成。国内也缺乏git/hg高手，签到的冲突可能无法解决。开源gitlab也不是规模化的。老板着急的话，管不了那么多。

多重回购在国外也很常见。而在中国，合作意识本来就不足，回购的增加更是雪上加霜。如果回来做经理，最容易处理的问题就是下属抱怨因为其他部门不配合，事情无法推进。有时候你甚至故意不给代码库权限，让你无法估计工作量。我的一个朋友，infra，想把int改成long，但是业务研发一直拖着，几次报警CTO都没用。生意至上你能做什么？国内没听说过跨部门提交代码。

这种情况下，各部门再造车轮的情况很常见。自己做轮子可以加强团队，但是谈合作只会得罪人。你选哪个？就算CTO级别，手掌手背都是肉，你也经常睁一只眼闭一只眼。

多回购除了不合作的软问题外，还存在技术缺陷。首先是公共图书馆的管理。一个公司有几十个JSON lib。不兼容往往导致生产事故。即使有相同的库，跨回购的变化也不能保证原子性。或者int换成long，四位数回购换了三个月，因为RPC类型不匹配发生了两次严重的停机事故。在FB中，codemod自动生成一个大diff，分配到不同的部门，大家审核后再批准。

要解决这个问题，不仅要有回购技术，还要有意识。否则代码合并了，每个项目都有一个目录，没有人维护lib、RPC等常见的东西，没有任何意义。

微服务

微服务主要是指业务逻辑层的架构，即这个模块承担各种前端请求，根据业务逻辑分解成各种底层数据访问或其他网络请求。

FB的这一部分，从一开始到现在，都是由一个叫做www的单一php代码库完成的。只有编译系统从最早的php原生解释器到hiphop编译器，再到即时hhvm编译器。FB桌面和app的所有业务逻辑都集中在一个代码库中。不可否认，学习周期还是比较长的。而且经常重构，基本一年不碰，可能不知道怎么写，写出来也不符合新规范的要求。

国内大部分公司都经历了业务逻辑层从单一到微服务的转变。当初是因为单服领全身，没人确定。后来服务越来越细致。据统计，拥有数千个R&D团队的8家公司，除了新浪，其余都是四位数的微服务。五家公司的微服务比R&D的人员还多。有一家公司仅用7000台服务器就运行了3000项微服务。

每个微服务具体在做什么？比如我们要做一个社交用户管理系统，首先要有一个用户数据库来存储用户的基本信息。为了保证服务的稳定性和数据隔离，会有一个专门访问用户数据库的微服务，所有应用都必须通过这个微服务访问用户数据库。为了保证性能，会增加一个缓存，通常是Redis，然后会有一个微服务专门访问这个缓存。在这两个数据底层服务之上，业务层有一个微服务，负责添加、修改和删除前端请求，比如用户。如果需要批量修改数据，会有批量修改的微服。批量修改通常是异步服务，它会添加一个队列和专门访问这个队列的微服务。这是五个微服务。用户需要交朋友，所以需要一个用户关系数据库和与刚才列出的这个新数据对应的五个微服务。然后在删除老用户时，需要异步批量删除好友，因此需要一个新的微服务来处理删除老用户的请求。再加上状态更新、聊天、推荐等系统，很容易得到三位数。

服务好，门槛就低，会写字的人就多了。现在Spring Boot/Cloud发展的非常快，加上Java中各种强大的注释，虽然用户系统中可能有10+的微服务，但是自己写的代码有100多行。相比之下，现在恐怕很少有人能完全理解FB的用户系统。

但问题来了。微服务比工程师多。出了问题怎么办？事故定位是个大问题，经常有事故根本不知道原因，只是碰巧重启或者回滚。配置管理和依赖分析也非常困难。即使服务写的很完美，运维团队超级强，执行上也没有错，资源浪费也无法解决。每个服务都只敢按照高峰流量分配资源，平均CPU利用率低于1%的情况很常见。下面的多租户服务将进一步讨论资源利用问题。

测试系统

几乎所有的国内公司都有测试团队，不像硅谷的工程师，自测是主流。这不是问题的关键。FB给新人的很多任务就是为系统写测试用例。说白了就是测试工作。

其中一个主要问题是缺乏自动测试框架，这将在下面的CI/CD中进一步讨论。另一个更致命。没有一个方便的测试环境，开发人员无法单独运行集成测试。FB的所有业务逻辑都在一个www代码库中，hhvm十几G，一台机器就能运行。每个人都有自己的服务器来测试所有功能。如果有几千个微服务，几千个JVM，需要运行多少台机器？

因此，有一个独立的测试环境专门进行集成测试是很常见的，有几十万台机器。开发环境、测试环境和生产环境的同步又是一个大问题。如果同步太频繁，那么就必须频繁中断，太不频繁地测试环境是没有意义的。此外，代码库数量众多且不断增加，因此很难实现自动化同步。各种配置以手动为主。因此，没有人知道生产环境和测试环境之间的区别。然后直接产生很多变化，不需要集成测试，所以回滚是常有的事。有些人在述职时提到的业绩是从“回滚每一次发布”到回滚到一定比例。

另一个有趣的现象是，Hackthon不能做demo，因为开发没有自己的测试环境。每个哈克顿团队都不能运行数百台机器的演示。所以Hackthon最后往往会变成算法问题，与公司业务无关。

持续集成和持续发布

持续集成和持续发布是3-4年前中国非常流行的概念。如果我们现在在会上再讨论这个问题，它可能会被考虑出来。大多数做红外线的人会说他们公司有CI/CD。不知道CI/CD的确切定义。每个公司都不一样。这里主要说一下FB系统。

FB是单一回购加骨干开发，所以任何变化都是直接集成的，全球可见。为了保证主干的稳定性，在每次提交diff之前都会强制运行局部测试，所有案例都要通过后才能提交。提交后，集成测试将在后台自动运行，如果有任何错误，审查者将被突出显示。如果是前端diff，它会自动在各种设备上运行测试。对于光盘，www以前每周自动发布一次，每天两次，修复程序需要手动批准。出版过程是所有的灰度级，直到完全生产。现在是全自动连续释放。后端服务也有自动配置项/光盘工具，但它们不是强制性的。

在中国做CI很难，因为上面说没有简单的方法来建立微服务架构的测试环境。在发布方面，很多公司都可以实现灰度化，但是手动触发是主要方法，因为回滚是常见的。释放仍然是一个严重的事件。由于测试环境问题，往往无法在发布前集成高保真测试。你可能经常听到国货上线，几乎所有人都要通宵到场协调，这就是原因。

单一与多租户服务

本文主要讨论一些常见的后端服务，如数据存储和检索。阿里的对口部门叫科技中站。这些服务的一个重要区别是，FG是一个自行开发的单实例服务，但是在国内，往往是直接使用开源或者在一定程度上封装开源，然后为每个应用部署一个实例来运行。如果你熟悉SaaS的术语，那就是多租户和单租户的区别

单租户模式下的服务故障不会相互影响。缺点是管理成本高，资源利用率低。多租户对服务质量本身要求很高。如果有问题，它将在全球范围内不可用。如果没有问题，应该提供QoS等机制，保证每个租户的服务质量。但是管理成本和资源利用率要高得多。

之前在FB写过一个与LBS相关的多租户服务，大概十几个应用。上线后，我也没在意。几个月后往上走，看到QPS达到了几千万，峰值CPU利用率达到了70%。Ads知道怕出问题想单独部署一个实例，但我反正不同意，说没有运维。有一次，一家企业不小心解码了iOS地址，访问量翻了三倍，炸了苹果的服务。我的服务是多租户。偶尔一个应用的流量会增加几倍，影响不大。从来没有任何问题。后来广告也没要。

下面讨论几个重要服务的多租户实现。

数据库、缓存、队列服务

数据库是一大痛点。国内几乎所有的工程师都熟悉并讨厌“SQL慢查询”这个概念。生产事故诱因中，至少排前三。FB和www代码中没有SQL语句。因为FB对数据进行了抽象，根据社交网络的特点，只有点和边两个表。比如用户是点，朋友是边。对于新业务，只需申请新的点边类型即可。然后有专门的API读写数据，不用管数据存储在哪个机器上，也不用提前申请数据库资源。

其实FB的DB系统经历了很多大的转变，从单个数据中心到分布式从到分布式主，引擎也从InnoDB到RocksDB，其他MySQL不断升级。这些东西，因为点和边的抽象，产品R&D团队完全没有意识到，从来不影响生产。我以前甚至不知道数据库管理员的职位存在于infra中。在国内，每次DB调整都是大招，所以集中全公司的精英R&D实力，计划一年以上是很正常的。

Redis在国内一般用于缓存。这个东西有很多高级功能，每一组都有不同的玩法，使得运维压力很大。在FB的情况下，由于数据库是抽象的，缓存很好的统一了。我写了一个叫TAO的直写缓存，我开发并使用了TAO的API。完全不需要考虑数据一致性，也不需要知道后台存储的方式。

如果队列服务是开源的，那么卡夫卡和RabbitMQ都不是主流语言，可以控制的运维也不多。当事故发生时，原因找不到。FB的异步服务，程序只需要声明异步执行的代码，不需要管理队列。

写高并发多租户服务或者只写C++。C++11以上很多特性可以大大降低代码复杂度，特别是智能点是必须的。国内很少有人知道C++和这些特性。看看CSDN和知乎讨论C++的帖子就知道了。

海归能做什么

了解了这些问题之后，回来面试的时候不妨和面试官讨论一下。我相信会有很多共鸣，因为这些事情发生在每个家庭。许多FB回到中国在基础设施领域开展业务，其中许多是为了提高工程效率。

但是，实事求是地说，这么多年过去了，与日新月异的商业变化相比，国内基础设施的变化非常小。在我看来，关键问题不一定是技术能力。我曾经带领三个人，C++，复制了半年FB的水肺系统。任何对单个表的SQL查询，甚至数十亿条记录，只需要几秒钟。主要问题是管理，越早介入越好。

所以我更愿意做中小公司的技术总监，甚至不是大公司的副总。改变总是从小公司开始。我在硅谷以技术面试+文化的形式招人，先来个网上笔试。比leetcode简单的题可以淘汰一半左右。目前猎头推了50份简历，只录了一份。很多知名大公司的人发现不了解基本的数据结构。坦率地说，我不知道这能走多远，但我比每天发展我自己快乐得多。

原帖子问答

yhfyhf

感谢楼主，果然，作为fb的早期员工，我对很多系统都有非常精辟的见解。

此外，吹facebook的CI/CD-fb www repo早在16/17就成了来自master的推送:

https://engineering . FB . com/web/rapid-release-at-massive-scale/.

很多17年或者更晚加入fb的小伙伴可能会觉得这很自然，但实际上在这种规模和规模下达到这种水平的CI/CD是远远领先于整个行业的。

丹丹22

感谢fb前辈们分享经验，受益匪浅！不知道能不能再和G家A家比一比。有何异同，取舍？

既然大家都知道infra的这些痛点，为什么业务日新月异，而infra却变化缓慢？是因为不重视，还是觉得不重要？还是觉得重要，但是觉得技术上太难实现？

楼主

一家人都不知道。g家感觉比f更多元化，FB很同质化。万事万物只有一个体系。再差，其他组都没有机会再造轮子。另外，我个人感觉F是极度追求自动化的。如果一个机械作业手动完成两次以上，没有自动解决方案将解决各种diss…

基础设施改革绝对不能忽视。即使CTO不重视，CEO也不能忽视人和机器的开销。之前CFO开始问我，因为机房成本高，CPU利用率多少？这就是为什么我说我们可以轻松地交谈，不要担心。老板不在乎。

问题是怎么做。我之前说过，中国的海龟很少，BAT TMD VP以上几乎没有海龟，至少FG infra没有混杂海龟。而且不是每个回来的人都熟悉infra 0-1的流程，经常做99.9%到99.99%甚至更高的工作。这些东西，不是听几堂课，看几篇论文就能效仿的，太多细节了。另外，如果一个几千人的团队不知道排序的复杂性，那么谈工程效率就有点可笑了。所以我现在特别害怕大团队空的工作。刚回来熟悉落地，每天都累得不行。

阿里在FB之前有两个E8，一个是以前的hiphop工作者，不想负责拿P10，另一个应该是AI infra的副总裁。阿里科技中台负责人毕宣是老阿里，在行业内口碑很好。

BryanBai

我又看了一遍这个技术干货。太有共鸣了。事实上，硅谷的许多红外和测试自动化原型在15-20年前被国内外公司使用，但同一批工程师离开外国公司去了私营企业，所有这些东西都被扔掉了。技术上没有错，只是水土不服。我是一个软件工程专业的学生，我知道软件工程是一个完美的武器，就是规模化。为了降低成本，大公司不用讲，独角兽要讲。我们要用愿景在早期设计和构建端到端自动化，以便将来变得更大更敏捷。但是国内大部分公司都在应用创新，成败不在技术。这种一次性销售让人们忽略了这些与基础设施相关的东西。等它真正上市了再说。

另外DevOps也属于万金油，从硬件网络到应用都要纵向理解，从R&D和测试到客服销售都要横向理解。各种建筑语言拿起来都要用。大公司一般都是自己培养的，小公司不重视，需要找货。

我是DevOps CI/CD的建筑师。国内外公司，十年北美经验。现在是硅谷。这种背景下有国内市场吗？

楼主

非常想！尤其是如果你能处理整个系统而不是某个模块。不过得找个便宜货，大公司都找毕玄这个级别的。对于中小企业来说，如果你对其他基础设施略知一二，那就找一个懂做生意的CTO或者CEO，至少找一个基础设施副总裁。我个人认为中小型公司很有前途，因为整套基础设施是密切相关的。比如Java微服务不改造，就解决不了测试环境问题。