视频访谈： 赵磊：从Facebook到Uber，打破传统

1. 大家好，我在ArchSummit深圳大会的现场，今天非常高兴邀请到了Uber高级工程师赵磊接受我们的专访。刚才您在台上进行主题演讲的时候非常火爆，我们也是费了不少功夫才把您请过来，我们这边所了解的是您曾经在Facebook负责消息的后端服务，这个系统在支撑Facebook全球5亿人同时在线。您去年加入Uber以来，负责整个消息系统的架构，在高可用性方面做了很多的工作，那么我首先想问您一下，去年离开Facebook到Uber这方面能介绍下您去年所完成的大概工作情况吗？

赵磊： 第一个做的是Real-Time Message Network（实时消息网络），刚才在会议中也提到了。我们叫Ramen，其实就是Real-Time Message Network中间拿了几个字母出来，我们觉得比较好玩这名字。这东西将来不光是check message（消息检查），而且我们还有很多的就是client state可以通过server push到client。除了这之外呢，还有一个比较有意思的事，因为我们以前整个stack都是基于HTTP和JSON，很多service都是Node.js写的。他们用PHP和JS非常简单，而且整个公司还有很多service是用Python写的，可能还有其他语言Go或Java。为了互相间协同，Thrift是非常好的方法。我们看了些Open Source的实现，Facebook也做了很多工作。但是我们发现Facebook主要是C++和Python的实现，但是我们用的Node，而Node的实现包得没那么好，而且很多人在Node上没有用server，所以我当时做一个事情就是把整个Thrift-stack用JS重新写了一遍，这个已经Open Source了，叫做thriftify。在Uber，应该是所有的Node.js Server都迁移到了Thrift。另外，我们的transportation已经不是基于HTTP，而是一个我们自己的Protocol，所以基本上我们是用自己的Protocol再加上Thrift。

2. 哦，那您所说的这个事情，其实相当于打破一些传统的做法对不对。你想其他的一些service的driver系统里直接去push一些消息了，将来可以避免丢掉的消息或者是拿不到的消息对不对？

赵磊： 我们的想法主要是，server和server之间，可能是不同team做的，但documentation还是需要一个strong type的一个IDL，就是你可以定义这个service只能管理这几个function API。每个API有input和response，要有它的full documentation。Thrift这方面做得非常简单。我们很多service这在往这上面迁移。

3. 这块的工作量都是过去你们这边要做的事情吗？

赵磊： 这个Thrift library呢，基本上已经完成，而且已经Open Source了。另外一个是新的事情是service-discovery，以前很多都是通过HAProxy和configuration management。我们将来会有我们自己新的service-discovery的service。我们现在就是一步一步将旧的service迁移到这上面来，而新的service直接可以在上面工作了。

4. 就相当于你们在同时在做两件事情，对吧。刚才您在主题演讲里面所提到的Ramen，现在是已经Open Source了吗？

赵磊： 现在还没有Open Source，因为这里面有很多业务逻辑，但是我刚才提到整个protocol非常简单，你如果想自己实现这个protocol其实非常快，而且它最重要的几个component是已经Open Source的，而且整个公司很多很多其他service现在都在用这个。

5. 我对您演讲里的45秒比较感兴趣，这个为什么会定义45秒？是有故事吗？

赵磊： 是这样，因为client可能会通过一个HTTP Proxy连到server，time-out可能不是client自己去控制，而是中间一个Proxy，他有时候不会让你有太长时间的response time，所以他会time-out，但是一般的Proxy都会比这个45秒长，所以我们只要在45秒之内return response，那Proxy看起来就不会time-out。另外一个原因是，所有client到server的traffic都是通过HTTP request过去的，如果很长都没有send response 给client，那client就不会send下一个request。这是server就不知道client现在的情况，client是否还在线，是否还在等待。如果每隔45秒就send response给client，站在server的角度，等45秒就可能收到下个client request；如果没有收到，就表明client已经下线。

6. 这个数据是根据你们的一个经验值，你们认为这个时间差是最合理的。这是非常好的一个经验。下面我想问，在过去的一年里，你在Uber最大的挑战是什么？

赵磊： 我觉得我到Uber最大的挑战是，之前我一直在做自己的service和其他几个和它相关的component，很难有机会知道整个流量有多少。Ramen其实没有多复杂，但在deploy时，全世界的client都会connect到Ramen上，既不能break client，也不能break任何中间的load balancer以及各种各样的component。我之前从来没有碰过nginx和load balancer，因为原来Facebook有专门的工程师去管理。你只要告诉他，我的service需要多少load balancer的traffic，他就会满足你。但是，Uber的工程师比较少，不知道整个flow是多少。所以当时改了nginx config，加了很多monitor，知道了service或nginx down掉了是什么样子。如果client非常多，是什么样子。还遇到很多问题，我们的整个架构是用HAProxy将各个service连起来，TCP上有fd limit，如果collection point做得不好，QPS/RPS（request pre second）上去之后，server port就会受到限制。

7. 听您的阐述，感觉您从后端过度到了整个架构，不光你自己的service，其他所有打交道都要去接触。

赵磊： 是的，而且包括iOS和Android client的管理。比如client crash可能是server 给了它一个unexpected result。所以我要去看client crash的情况。这和我预想的完全不一样，因为client上没有log，需要external service 把 crash report上传再进行分析。这对我来说是个挑战。你没法去看client的情况，只能看到一个stack trace，只能通过很多clinet对比，才能知道发生了什么问题。这就需要看很多很多的crash report。

8. 你们自己内部有没有做APM这种东西，还是用第三方的？

赵磊： 我们用了第三方的一个service，crash report 是upload他们的server上，我们到上面去看分析结果。

9. 那么你是做个很多改造和转换对吧，面对如此众多的service，你今年的工作重心或目标是什么？

赵磊： 增加了如此多的service，不过对我自己，对整个公司来说都是很大的变化。我们慢慢朝着Microservices的方向发展，但是Microservices带来了很多挑战。比如，Service Discovery就非常难，还要在此基础上保证high availability。之前使用的HAProxy目前看来已经不能适应Microservices的环境。所以我们需要做自己的Service Discovery。

10. 国内的企业会有很多个服务产品线，我们会提供一个公共组件，因为他是基于底层，我们通常会给它做一个平台，这个平台会提供多个接口和规范。如果应用需要使用的话只需要给相应的授权，就可以使用它。国内有很多这种平台，相当于将前后端做了一个分离。Ramen相当于中间一层，前后耦合得非常紧密，我觉得这是一个很大的问题。

赵磊： 我的感想是，当我做一个底层的platform时，，而这个platform可以帮我做push，会有越来越多的service迁移到这个platform上，user增多后，带来的挑战就是interface非常难改。当break interface时，发现cost非常大。要和每个service的team确认是不是要修改。而且break时候可能当时不知道，而是在某些情况service才会break。所以对我的挑战是，我在增加feature的同时能不能保证interface或API的兼容性。这就需要在design的时候花很多时间，不光是给自己design一个protocol，还要考虑到customer的需求。把所有的需求汇总，砍掉一些不重要的10%的需要，满足90%的需求，将它们公共的部分做一个interface。如果再有新的customer需求，可能就要回绝，解释这个新feature会带来的复杂性以及对现有interface的影响。

11. 这也一种策略性的调整，要有大局观。接下来聊聊Uber在业务发展的情况。在出租车上应该是顶尖了，费用还很便宜。你们还会扩展其他的业务吗？比如快递就是一个很大的挑战，如果采用Uber模式，我上个班就可以送个快递。但这回给业务逻辑带来更大的复杂性，这对背后的架构和数据处理有些什么变化。

赵磊： 我们修改了以前的一个dispatch system（一个乘客一个司机），现在整个公司都在用新的dispatch system（不再是一个乘客一个司机）。我们在纽约的UberRUSH，可以通过叫Uber，把咖啡店的咖啡送给某一个顾客，而不用自己雇佣送外卖的人。送咖啡的人不一定要开车，他也可以骑自行车送给客户。这个和UberTAXI有个不一样的地方，送货员不一定只拿一个东西，可以一次拿很多东西一起儿送。以前的算法就遇到了问题。为了这个新的需求，就要重新抽象一个service来满足它。这个系统不仅能满足原来的要求，还可以满足UberPool的需求，UberPool就是拼车服务。新系统可以满足一个车上有很多人或很多东西的逻辑。

12. 所以这个算法的改造有利于后续产品线的发展。这对Ramen系统有什么底层改造吗？

赵磊： 是的，新的dispatch system是为未来很多年服务的。至于对Ramen的架构改造这里不方面谈。

13. 那我们最后谈谈Uber的企业文化和团队建设吧。你对开源软件有什么想法？Uber现在用了Node.js和最近流行的IO.js，对于前沿技术，你有什么看法？

赵磊： 我所在的team大部分service都用Node写的。Node对我来说其实很新，因为我原来是写C++的。我到Uber之前从来没碰过JavaScript。我觉得Node是很有意思的一种语言，有人喜欢有人不喜欢。对我来说语言本身不是很重要，语言是就是一个工具，它有好的地方有不好的地方或者说不适应的地方。语言其实更多的是culture的问题，你的同事是否能适应这个culture。在Node上，大家非常喜欢用Open Source的component，很容易就能在Github上找到合适的library。我们有一个比较复杂的service，大概用了400多个package，当然有些是internal package，其中绝大部分是Github上Open Source的。这时会有很多dependence，带来的挑战是，当时直接拿来用的package，如果对它理解不到位，出现break时可能无所适从。

14. 是的，底层的维护会是很大的问题，你们会去重构吗？

赵磊： 刚开始当load和traffic很小时，只要work就可以用了。后面发现问题了，我们再慢慢去改，这也是敏捷的做法。

15. 那么你们团队有没有限制，最好用Node语言，还是说可以用其他的，比如Go或Python？

赵磊： 我觉得这是Mircoservice带来的好处，以前很多人own一个service，现在一个人或几个人own一个service。只要大家都认为新的东西无论是Go或其他的，能给我们带来好处，大家都想去用它，那就可以用。公司不会规定说能用这个不能用那个，只有一个大概的原则，在design一个service时，可用性是第一位的，要考虑各种各样的情况。如果所有情况都可以应对，那就OK。

16. 这是一种非常极客的文化，不管东西是如何实现的，只要所有的点都考虑到就那么事情就是OK的。这样的公司文化对你有什么影响？

赵磊： 我可以说下在旧金山遇到的事情。有很多年轻刚毕业就到旧金山来创业，他们没有什么钱，就是对技术非常执着，我非常佩服他们这一点。

17. 这也表明你们在招聘人才时更关注的是对技术的热情。您对人才培养这块有什么心得？最后问下您对新技术持有的态度。

赵磊： 我到Uber后，发现周围的同事都非常年轻，但我从他们身上能学到很多东西。新技术我都是自己业余时间做，我会问自己问什么做这个，做过几个月后我会回过头总结，看看当时的决定是不是还是成立的。对于创业公司来讲，人比较少，资金也不多，在尝试新技术时，我会问自己它能带来的好处多少，比现在多5倍还是10倍增长？比如performance问题，service不够快，不是慢慢去改，而是去找到那个瓶颈，修复80%的问题，其他20%的问题留着其他时候解决。我会花很多时间去找到这些关键问题，看看做的工作可不可解决它们。我是一个看数字说话的人，我会在做事情前先估算好是50%还是70%，事情做完后会回过来看是否完成了。

18. 参加ArchSummit你有什么感受？

赵磊： 我虽然在国外，但还是关注了很多国内大牛的微博，这让我受益匪浅。国内大型互联网公司的技术非常强。非常感谢InfoQ让我有机会到这来交流。对我来说，一个很大的收获是能认识很多朋友。Uber很多重要的data都是存在POSTGRES这个开源的数据库里，我有很多问题不知道问谁，昨天正好认识一个华为的同事，他是这方面的专家，我就问了他很多很多问题。