Uber将整体式API拆分为微服务

Uber工程师Emily Reinhold最近介绍了他们是如何将整体式API拆分为灵活的模块化微服务体系结构的。她重点介绍了在Uber的迁移工作中,设计和体系结构方面几个最重要的考虑。

\\

根据 Reinhold的介绍,迁移至微服务的主要目标在于在三个指标方面实现更好的缩放性:应对流量的激增,更轻松地增添新功能,以及转为使用一种在组织迅速增长的情况下能轻松适应规模变化的体系结构。

\\

为了降低微服务之间的耦合,Uber工程师在常规设计方面做出了一些决策:

\\
  • MVCS,对众所周知的模型-视图-控制器(Model-View-Controller)方法进行的扩展,可明确包含服务层并承载应用程序逻辑。这样Uber就可以在业务逻辑和持久层之间实现解耦,借此更容易地修改持久层。 \\
  • UDR,Uber的全球复制数据存储,该技术取代了PostgreSQL,使得Uber可以通过多个数据中心同时为用户提供乘车服务。\

此外为了应对大量服务所造成的后续问题,Uber工程师还对体系结构进行了一些重大更改:

\\
  • 异步网络:为了处理数量日益增加的服务请求,Uber工程师通过一种基于Python事件环路(Event-loop)的异步网络库Tornado实现了同时缩放至数万个开放连接的能力。使用Tornado的优势之一在于该技术可与Uber现有的Python网络代码集成,借此构建结构化的异步范式。 \\
  • 服务的发现和弹性:面对数量激增的服务,关键在于要能发现服务并找出故障点。例如需要收集故障率和SLA违背等指标,检测运行状况不正常的主机,通过短路(Circuit breaking)防止连锁故障。Uber通过Hyperbahn使用TChannel解决了这一问题,这是一种他们自行开发并已开源的,适用于RPC的网络多工(Multiplexing)和帧通讯协议。 \\
  • 严格的接口定义:Uber选择使用Thrift通过IDL定义服务接口,并借此生成不同语言的客户端源文件。Thrift使得他们能够检测出客户发起的,与接口定义规范不符的调用。\

最后Reinhold还提到Uber会通过下列基本原则确保生产环境正常运行:

\\
  • 通过负载测试发现瓶颈和断点。 \\
  • 通过容器实现更高的硬件利用率。 \\
  • 通过模拟服务中断确保系统能够顺利恢复并发现可能存在的弱点。\

Emily Reinhold也曾在上一次纽约QCon活动中讨论过这些话题。

\\

查看英文原文Breaking a Monolithic API into Microservices at Uber

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值