近年来，API网关是微服务架构的一个组成部分。API网关为我们所有的应用程序提供了一个单一的入口点，并提供了一个接口来访问后端微服务的数据、逻辑或功能。它还提供了一个集中的地方来实现许多高层次的责任，包括路由、协议转换、速率限制、负载削减、头的丰富和传播、数据中心亲和力的执行、安全审计、用户访问阻止、移动客户端的生成，以及其他。

在上一篇文章中，我们回顾了Uber的API网关的多代演变，以及我们在每个阶段的设计选择。在这篇文章中，我们将更深入地探讨自助式API网关系统的技术组件。

Golang是Uber数千个后端服务的命脉，在数百万个CPU核心上运行。了解我们的CPU瓶颈是至关重要的，这既是为了减少服务延迟，也是为了使我们的计算机群高效。Uber运营的规模需要对代码和微架构的影响有深入的了解。

虽然与其他几种语言相比，内置的Go剖析器比没有剖析器要好，但Go中事实上的CPU剖析器在基于Linux的系统上（也可能在其他操作系统上）有严重的局限性，并且缺乏许多[1, 2, 3, 4]充分理解CPU瓶颈所需的细节。

在Uber，运营的实时监控和自动化对于维护市场健康、保持可靠性和获得市场效率至关重要。根据 "实时 "一词的含义，这种监控需要显示现在正在发生的事情，及时获取新鲜数据，并能够根据这些数据建议适当的行动。Uber的数据平台提供自我服务工具，使运营团队能够建立自己的实时监控工具，并通过建立丰富的解决方案来支持他们的区域团队。

在这个项目中，我们的要求是提供商户层面的监控，并处理复杂的内部市场管理工具所不能解决的边缘情况。我们使用了Uber的各种实时数据平台组件，建立了一个名为Charon的工具，以减少市场可靠性差对商户的影响。

在2020年初推出的Charon最终非常有效，它使在COVID-19封锁期间关闭的餐馆和其他商户只需提供送货服务。在这篇文章中，我们以Charon COVID-19的用例来说明Uber的数据平台是如何赋予团队更快建立和适应的。

假设你拥有一个已经运行得相当好的生产型ML模型。你知道在你的模型中添加相关的和不同的信号源是提高性能的一个可靠方法，但是找到能够真正提高性能的新功能可能是一个缓慢而乏味的试验和错误过程。

在搜索之初，你可能会寻求重新使用为其他项目开发的功能，或者你可能会选择你怀疑会对你的模型有益的新功能的原型。无论哪种情况，都可能有成百上千个潜在的新功能需要探索，其中许多是常见主题的轻微变化。根本的问题是，不清楚这些功能中的哪一个（如果有的话）会真正改善你的模型的性能。绝大多数的新功能将与已有的功能部分重叠（如果不是完全重叠的话）。

你可以尝试一次加入一个或一小组，以评估个别的影响，但这需要时间，而且这种方式很难发现不同功能之间的协同作用。

Uber Freight于2017年推出，旨在彻底改变巨大而低效的货运卡车行业中托运人和承运人的匹配业务（在美国每年花费约8000亿美元）。我们相信，并且已经证明，一个以技术为先的货运经纪人和市场可以为承运人提供更好的机会，并为托运人和社区提供卓越的结果。

我们希望通过技术消除的一个浪费过程是，传统的货运经纪人和承运人之间为货物（货运术语）的价格进行冗长的砍价。这种做法源于运费价格和承运人支付意愿的不透明。受到定价创新在Uber大规模增长中发挥的作用的启发，我们决定成为第一个提供透明的动态承运人定价的货运经纪人，通过先进的算法 "清理市场"，而不是用老式的讨价还价，浪费了时间并从市场上吸引了流动性。

在这篇文章中，我们描述了我们的框架，以产生每天数以万计的货物的最佳前期价格序列。

Uber的许多软件系统每天都需要进行大量的变更。由于我们系统的规模和复杂性，如何在不产生意外后果的情况下实施这些变更是一个巨大的挑战，最终拖慢了开发人员的工作效率。Flipr是Uber解决这一问题的重要组成部分。Flipr是我们为动态配置管理而创建的工具，如功能标志、允许列表、增量推出和其他高级用例。在这篇文章中，我们将介绍Flipr的架构和功能，并将展示我们如何使用它来快速、轻松地进行大量的更改，而不牺牲可靠性。

最近，人们对面向服务的系统架构和微服务系统架构的缺点进行了大量的讨论。尽管仅仅在几年前，由于微服务体系架构提供了许多好处，如独立部署的灵活性、明确的所有权、提高系统稳定性以及更好地分离关注点等，但近年来，人们开始谴责微服务的倾向极大地增加了复杂性，有时甚至使微小的特性也难以构建。

随着 Uber 已经发展到大约 2200 个关键微服务，我们亲身体验了这些折衷。在过去两年里，Uber 试图降低微服务的复杂性，同时仍然保持微服务架构的优势。通过这篇博文，我们希望介绍我们对微服务体系结构的通用方法，我们称之为“面向领域的微服务体系架构”（Domain Oriented microservice Architecture，DOMA）。

由于这些缺点，近年来批评微服务架构变的很流行，但很少有人主张彻底拒绝微服务架构。系统的运营效益（可维护性）太重要了，而且似乎没有或极其有限的替代方案。我们使用 DOMA 的目标是为那些希望在保持与微服务体系结构相关的灵活性的同时降低总体系统复杂性的组织提供一条前进的道路。

这篇文章解释了 DOMA，导致 Uber 采用这种架构的原因，它对平台和产品团队的好处，最后，为希望采用这种架构的团队提供了一些建议。

对于人们熟知的平台服务而言，看似更严酷和集中的算法控制，有时候反而让零工有了统一的斗争矛头，这在针对亚洲平台经济的考察中都有所体现。研究者发现，直接隶属于平台的中国骑手相比隶属于配送站的全职工人更有抗争意识，而印尼的线下交通平台化后也出现了更多的劳工抗议。相比之下，更隐形的零工平台多依赖零散和不统一的人工控制，容易消解掉平台劳工集体维权的动力。

Uber通过推动数十亿次的乘车和送货，将数百万乘客、企业、餐馆、司机和快递员连接起来，彻底改变了世界的移动方式。这个庞大的交通平台的核心是大数据和数据科学，它为Uber所做的一切提供了动力，例如更好的定价和匹配、欺诈检测、降低ETA和实验。每天都会收集和处理PB级的数据，成千上万的用户从这些数据中获得洞察力并做出决策，从而建立/改进这些产品。

随着机器学习的不断发展，改变了它所涉及的各个行业，它才开始为审计世界提供信息。作为一名数据科学家和前CPA审计师，我可以理解为什么会出现这种情况。从本质上讲，审计是一个专注于细枝末节并调查任何例外情况的领域，而机器学习通常寻求推断广泛的模式。审计专注于分析历史事件，而机器学习解决方案则倾向于预测未来事件。最后，大多数审计人员缺乏必要的教育或编码技能，无法在工作中熟练地尝试使用机器学习。下面我将展示我们如何使用机器学习来解决Uber的一个特殊审计问题，并延伸出我们的方法论和架构如何被利用来解决更大的审计行业的其他数据问题。

Uber的骑手、司机、吃货的iOS移动应用规模较大。选择Swift作为我们的主要编程语言，我们的快节奏开发环境和功能添加，分层软件及其依赖性，以及静态链接的平台库，都导致了大型应用二进制文件。减少应用大小对我们的客户体验至关重要。此外，苹果的应用下载大小限制禁止大型应用使用流量下载。

应用下载大小限制意味着首次使用的用户无法在最需要的时候下载应用，当现有用户不在Wi-Fi上时，Uber也无法向他们提供功能、促销或安全更新。我们建立了Uber Rider应用大小与客户参与度之间的关联性--当应用大小超过下载大小限制时，并导致应用安装量减少10%，注册量减少12%，首次预订量减少20%，造成收入损失。在过去的三年里，Uber Rider应用的规模经常接近App Store的空中下载限制，而保持在该限制之下显然是当务之急。

在下面的文章中，我们将介绍我们如何使用先进的编译器技术将Uber的iOS Rider应用的代码大小减少了23%。本文讨论的想法也分别转化为Uber Driver和Uber Eats iOS应用的代码大小节省了17%和19%。

2016年，我们发表了关于Schemaless--Uber Engineering的可扩展数据存储的文章（一、二）。我们介绍了Schemaless的设计以及解释了开发它的原因。今天这篇文章我们要讲的是Schemaless如何演进成一个通用的事务性数据库Docstore。

在过去的几年里，日志流量的增长导致平台部署规模巨大，用户需求也发生了显著的变化。这两方面都给基于ELK的平台提出了很多挑战，为了从根本上提高可靠性、可扩展性、性能，我们决定构建下一代日志平台。

实时数据（乘车请求数、可用司机数、天气、游戏）使运营团队能够做出明智的决策，如激增定价、最大调度ETA计算以及关于我们服务的需求/供应预测，从而改善Uber平台上的用户体验。虽然分批数据可以通过识别中期和长期趋势提供强大的洞察力，但Uber服务可以将流式数据与实时处理相结合，以逐分钟的方式创建可操作的洞察力。

uber 使用数据指标来指导业务决策，但经常因为业务统计口径不一致，造成决策失误，为此uber统一的内部度量平台 uMetric。

Uber has one of the largest deployments of Apache Kafka in the world, processing trillions of messages and multiple petabytes of data per day. As Figure 1 shows, today we position Apache Kafka as a cornerstone to Uber’s technology stack and build a complex ecosystem on top of it to empower a large number of different workflows.