背景
Uber（优步）是一家美国硅谷的科技公司。Uber 在2009年，由加利福尼亚大学洛杉矶分校辍学生特拉维斯·卡兰尼克和好友加雷特·坎普创立。因旗下同名打车 APP 而名声大噪。Uber 目前已经进入中国大陆的60余座城市，并在全球范围内覆盖了70多个国家的400余座城市。
Uber 的资深工程师 Matt Ranney 在 gotoConference 大会上分享了 Uber 从巨石应用到拆分为1000个微服务架构的历程。
2014年，Uber 的员工仅有200人，两年之后，Uber 的员工达到6000人，发展的速度非常迅速，于是 Uber 开始了微服务的实践。。。
实现微服务之前你需要知道的事情
微服务的好处
微服务的好处很明显：
团队独立运行，独立发布软件。
团对自行维护线上环境，肩负研发，上线运维的责任。
有权利挑选适合自己团队的工具链。
Uber 的工具链演进：
最初版本的 Uber 是外包公司开发的。据说滴滴最初也是几个大学生搞出来的原型，当然是为了快速试错，快速测试市场反馈。随后 Uber 的核心开发语言从 Python 转向了 Go，地图和数据处理模块使用 Java 开发。
坑1：多语言
语言种类多了之后，代码难以共享，同样的功能不同的团队难以重用。程序猿会根据语言划分群体，产生隔阂。
坑2：所有调用都是 RPC
当所有的通信都变成 RPC 之后，随着团队的扩张，问题会尤为突出。
这个 HTTP 请求的返回值是什么意思？
JSON 没有固定的 schema，导致解析 JSON 的工具变得混乱。
RPC 请求的速度比 Function 调用慢。
坑3：运维困难
如果像 Uber 一样，每周都有15个新服务要上线，作为整个平台的运维负责人会非常痛苦，因为这意味着线上服务很有可能被新部署的服务破坏。出了问题，研发团队需要对线上整体环境有深入的认识。
坑4：性能
性能问题取决于语言和工具。如何查看不同语言的性能问题？Go 语言有 pprof 工具来将 Go 程序运行时的 Profiling 可视化展示出来。
Uber 实现了自己的跨语言的性能分析工具，为内部的服务使用，内部一旦有新的服务上线，不需要进行开发，就能够实现服务性能的实时监控。
坑5：定位问题
当一请求横跨了10个微服务，其中某一个调用很慢，其他都正常，你如何快速定位这个慢服务？
Uber 提供了内部可视化的服务调用的追踪功能。这个功能大大缩减了微服务里问题定位的问题。
坑6：日志
每个人记录日志的方式千奇百怪，存储的地点，方式都不同，难以统一。在多语言的环境里问题尤为突出。如果你用 ELK 或 Storm 来统一处理这些日志，新的问题又会出现，由于记录日志是免费的，开发者会滥用这个功能，导致日志记录了大量的数据，从而泛滥。
坑7：压力测试
压力测试需要在线上环境执行，并且不能够破坏用户体验。因为一些延时的 Bug 只会出现在系统压力达到瓶颈时才能重现，所以压力测试要将系统压到一个合适的程度。
坑8：破坏测试
在线上执行破坏测试，例如使用 Netflix 的 ChaosMonkey 随机破坏线上的环境进行服务可靠性测试。你的开发团队开始会拒绝，但如此演练多次之后，开发团队面对线上突发问题时会更加的自信。
总结
微服务看起来很美，实现起来确遇到很多隐藏的坑，如果在实现微服务之前，预先知道这些问题，就能帮助你在关键时刻做出正确的决策。看看 Uber 趟过了的这些坑，也许你明天就少踩一点坑。
