Matt是Uber的主系统架构师，他经历了Uber流量10倍的快速增长，在此过程中，Uber技术团队犯了很多错误，他在GOTO大会2016的分享主题是WIWIK－What I wish I Had Known（我当初要是知道这些就好了），总结了他在此过程中学到的经验和教训。
Uber有2000名工程师，8000个代码仓库，部署了1000多个微服务。这看起来非常混乱，但是为了在全球的市场竞争中确立领先的位置，Uber必须快速成长，拥抱混乱无序的状态。而微服务的架构用于应对Uber快速扩张是完美的解决方案，这并不是完全出于技术的原因，更多是技术团队快速增长、功能快速上线带来的压力。当公司快速增加大量工程师，以很高的频率上线新功能的时候，要让开发人员快速进入角色，微服务架构大概是唯一可行的方式。微服务归根结底是用API通信代替人的交流，人类的交流中会出现信息不对称，会涉及团队政治，与此相比写代码要简单高效得多。
在考虑扩展性的时候，往往并不存在一个正确的方案，因此这篇分享提到的很多设计决策都是权衡的结果。
Uber的统计数据（2016年4月）
-
70个国家
-
400多个城市
-
6000多名员工，其中2000多名是工程师（一年前只有200人）
-
线上共有1000多个服务
-
代码分别维护在8000余个不同的仓库中
微服务
把庞大的单个服务分解成多个微服务有很多好处，但是也有弊端。当微服务发生改动的时候，整个系统都很脆弱，Uber在周末的时候非常稳定，因为那时工程师没有更改代码。
微服务的好处在于，允许我们快速组建小团队独立运作。在开发人员快速增加的时候，我们需要团队能够快速成型并开始步入研发正轨，所以有一个清晰的问题边界很重要。微服务提供了一个小团队可以理解的边界。这个团队不但开发服务，而且要负责这个服务的正常运行，在这个服务出现问题的时候，他们需要及时响应。
微服务的代价：分布式系统比单个程序更难处理的问题在于，大部分调用都是RPC，所以需要考虑各种失败模式，以及在发生问题时怎样定位、处理。还有一些隐性的代价，比如，每个小团队都有自己喜好的语言和技术选型，在微服务的架构下，每个小团队都可以自由地纵容自己的喜好，而这对于整个项目来说并不一定是最优的选择。Uber的子项目中使用了各种不同语言：
-
分发服务一开始用NodeJS开发，后来迁移到Go语言
-
核心服务使用Python后来迁移到Go语言
-
地图服务使用Python和Java
-
数据团队使用Python和Java
-
内部统计系统使用Go
不同语言的服务之间可以正常通信，但是也存在很多问题：
-
无法共享代码
-
开发人员无法轻易转换团队，有一定的学习成本
-
支持多种语言可能造成工程师分裂的文化阵营
RPC
使用HTTP处理服务间通信并不合适，对于状态码、头部、查询字符串、方法类型等等的解读的不同，会给各个团队带来很大的沟通成本；JSON在可读性方面很棒，但是类型定义（schema）的缺乏会使数据在各个服务间传递的过程中带来混乱。使用带有类型定义的RPC可以避免这些问题。
代码库
多少个代码库是最优的？
一个统一代码库有其优点。在做出改动的时候，很容易同时同时处理所有需要改变的代码，浏览代码也更容易。缺点在于，构建系统需要非常复杂的配置和特殊的工具，Google用一个虚拟文件系统来实现统一的repo。
多个代码库是业界的趋势－更多更小的模块，意味着易于开源、易于替换。缺点在于不易浏览代码，而且很难正确做出影响全局的改动（cross cutting change）。
Uber当前有8000个代码库，一个月之前还只有7000多个。
性能问题
因为微服务相互依赖的特性，性能问题迟早会出现。由于不同语言有不同的性能工具，使用统一的性能度量格式就非常必要（比如火焰图、统一格式的dashboard）。
Fanout问题与追踪
微服务之间的调用的Fanout会给性能代码来灾难。比如一个普通服务99%情况下的响应时间是1ms，1%情况下是1秒。但是如果有很多fanout，响应时间慢的可能性就大大提高，如果有100个调用，就会有63％的响应时间超过1秒（1.0 – 0.99100 = 63.4%）。应对这个问题的方案是分布式追踪系统。Uber遵循OpenTracing协议，开发了Jaeger系统。
当然，传统的log也可以定位性能问题，但是每个log条目都应该有一个跨服务的公用ID，才能把不同服务的log串起来。
追踪本身是有很大代价的。我们只能追踪一部分请求，Uber在统计上追踪1%的请求。追踪系统必须在服务间传递上下文信息，即使服务本身不理解这个信息的含义。
日志
提供一种公用的日志工具，保证它易理解易使用，以致于开发人员不会自找麻烦用其他的方法记录日志，这样就可以保持日志格式的统一性。
记录太多日志会给故障中的系统带来更多压力，所以必须在日志系统中添加反向压力，当log过多时，丢弃一些条目。甚至有必要引入向开发人员log“收费”的机制，以免开发人员打印过多log。
Uber开源了一个log工具zap来实现结构化的log：
测试
压力测试系统有时候无法模拟真实的在线流量，也无法模拟各个不同系统所产生的测试数据。此时只能在非高峰时段在生产环境中完成测试。这样做可能会打乱度量系统，因此度量系统必须能通过上下文判断是否测试流量。
失败测试：必须引入失败测试（chaos monkey），以保证生产环境正常工作。各个服务必须经得起停止、变慢和各种操作的干扰。
自研还是购买
任何基础设施类型的服务，任何看起来属于平台而不是产品的部分，早晚都会变成无差别的商业化产品，Amazon或者其他公司会提供这个服务，他们的成本更低、做得更好。是自研还是采用现成的方案（第三方／开源项目）是一个问题，因为可能伤害开发人员的感情：）
