背景
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 趟过了的这些坑,也许你明天就少踩一点坑。
下载JFrog Artifactory 开源版(代替 Nexus):
http://www.jfrogchina.com/open-source/
下载JFrog Artifactory 企业版(免费试用):
https://www.jfrog.com/artifactory/free-trial/?lang=zh-hans#High-Availability
关于JFrog
世界领先DevOps平台
公司成立于2008年,在美国、以色列、法国、西班牙,以及中国北京市拥有超过200名员工。JFrog 拥有4000多个付费客户,其中知名公司包括如腾讯、谷歌、思科、Netflix、亚马逊、苹果等。关注 JFrog,感受原汁原叶的硅谷技术!我们不仅仅提供最优秀的产品,也提供最优秀的持续交付平台的解决方案,详情请洽info@jfrogchina.com