我们如何重新设计支付数据读取流程以优化客户集成，同时实现高达150倍的性能提升？
简介
近年来，Airbnb将其大部分后端服务从单体迁移到面向服务的架构（SOA）。这种行业标准的架构给像Airbnb这样规模的公司带来了无数的好处；然而，它也并非没有挑战。由于数据分散在许多服务中，因此很难以简单和高性能的方式提供客户需要的所有信息，特别是对于支付等复杂领域。随着Airbnb的发展，这个问题开始出现在许多新举措中，如房东收入、税表生成和支付通知，所有这些都需要从支付系统中读取数据。
在这篇博文中，我们介绍了Airbnb的统一的支付数据读取层。这个读取层是定制的，以减少客户集成的摩擦和复杂性，同时大大改善查询性能和可靠性。通过这种重新架构，我们能够为我们的房东和客人社区，以及信任、合规和客户支持领域的内部团队提供一个大大优化的体验。
Airbnb的支付平台的演变
支付是Airbnb应用程序最早的功能之一。自从我们的联合创始人Nate第一次提交报告以来，支付平台已经有了巨大的发展和变化，而且鉴于我们在全球范围内的业务不断扩大，它还在以更快的速度发展着。
与其他公司类似，Airbnb以单体应用架构开始了它的旅程。由于最初的功能集是有限的，写和读的支付流程都 "相对 "简单。
Airbnb的老式单体架构的过度简化图。支付模式不是很复杂，而且功能集也很有限。
可以预见的是，这种架构无法随着我们公司的快速增长和扩张而很好地扩展。支付，连同技术栈的大多数其他部分，开始迁移到SOA架构。这给现有的架构带来了重大的改革，并提供了许多优势，包括。
- 我们在不同的服务之间有明确的界限，这使得我们能够更好地掌握领域的所有权并加快迭代。
- 数据以非常规范化的形式被分离到各个领域，从而获得更好的正确性和一致性。
在SOA迁移之后，每一个支付子域都有自己的服务和表，并且边界清晰，但更多的功能导致了更复杂和规范化的数据。
新的架构带来了新的挑战
支付SOA为我们提供了一个更有弹性、可扩展、可维护的支付系统。在这个漫长而复杂的迁移过程中，系统的正确性是我们的首要任务。数据被规范化，并根据每个团队的职责分散在许多支付领域。这种分工有一个重要的副作用：演示层现在经常需要与多个支付服务集成，以获取所有需要的数据。
SOA迁移后，支付数据的读取流程是怎样的。演示服务调用一个或多个支付服务，并在应用层汇总数据。
在Airbnb，我们相信对我们的房东和客人社区要透明。我们与支付和收益相关的表面显示了一系列的细节，包括费用、交易日期、货币、金额和总收益。在SOA迁移后，我们需要查看多个服务，并从比迁移前更多的表中读取，以获得所有要求的信息。当然，当我们想用支付数据添加新的表面，或者想扩展现有的表面以提供额外的细节时，这个基础带来了挑战。我们需要解决的主要挑战有三个。
第一个挑战是，客户现在需要充分了解支付领域， ，以选择正确的服务和API。对于来自其他团队的客户工程师来说，这需要投入大量的时间，并延缓了整体上市时间。在支付方面，工程师需要提供持续的咨询和指导，占据了他们很大一部分的工作时间。
第二个挑战是，在很多情况下，我们不得不同时改变多个支付API，以满足客户的要求。当有 太多的接触点时，就很难对请求进行优先排序，因为许多团队都必须参与。这个问题也对上市时间造成了很大的负面影响。当调整和优先级会议不能顺利进行时，我们不得不放慢或推后功能发布。同样，当支付团队不得不更新他们的API时，他们必须确保所有的演示服务都采用这些变化，这就拖慢了支付系统的进展。
最后但并非最不重要的是，复杂的读取流的技术质量没有达到我们希望的程度。对于一般的使用情况来说，应用层面的聚合工作得很好，但是当涉及到我们的大型主机，特别是我们的专业主机时，我们还有改进的余地，因为他们在我们的平台上每年可能有成千上万的预订量。为了对我们的系统有长期的信心，我们需要找到一个解决方案，提供内在的更好的性能、可靠性和可扩展性。
引入支付的统一数据读取层
为了实现我们雄心勃勃的支付目标，我们需要重新思考客户如何与我们的支付平台整合。
统一入口点
我们的首要任务是统一支付数据的读取入口。为了实现这一目标，我们利用了Viaduct，Airbnb的面向数据的服务网，客户查询 "实体"，而不是需要识别几十个服务和它们的API。这种新的架构要求我们的客户只担心必要的数据实体，而不是必须与个别支付服务进行沟通。
与其说是与单个支付服务进行沟通，不如说是演示服务只是使用读取层。
在这些入口点中，我们提供了尽可能多的过滤选项，因此每个API可以向其客户隐藏过滤和聚合的复杂性。这也大大减少了我们需要公开的API的数量。
统一的高层数据实体
有一个单一的入口点是一个好的开始，但它并不能解决所有的复杂性。在支付方面，我们有100多个数据模型，这需要相当多的领域知识来清楚地了解它们的职责。如果我们只是从一个单一的入口点暴露所有这些模型，对于客户工程师来说，仍然需要太多的背景。
与其让我们的客户处理这种复杂性，我们选择通过提出更高级别的领域实体来尽可能地隐藏支付的内部细节。通过这个过程，我们能够将核心支付数据减少到少于10个 高层实体，这大大减少了暴露的支付内部细节的数量。这些新的实体也使我们能够防范客户在支付平台上的变化。当我们内部更新业务逻辑时，我们保持实体模式不变，不需要在客户端进行任何迁移。我们对新架构的原则如下。
- 简单。为非支付工程师设计，并使用通用术语。
- 可扩展性。保持与存储模式的松散耦合，并对概念进行封装，以防止支付的内部变化，同时允许快速迭代。
- 里奇：把复杂的东西藏起来，但不要把数据藏起来。如果客户需要获取数据，他们应该能够在实体中找到它。 一的实体中找到。
暴露更干净的高层领域实体，以隐藏支付的内部细节，同时保护客户免受频繁的API迁移。
将非规范化的数据具体化
有了统一的入口点和实体，我们大大降低了客户入职的复杂性。然而，获取数据的""如何获取数据的""，再加上昂贵的应用层聚合，仍然是一个很大的挑战。虽然客户能够顺利地与支付系统整合是很重要的，但我们有价值的社区也应该享受我们平台上的体验。
我们发现的核心问题是 在客户查询过程中对许多表和服务的依赖性.其中一个有希望的解决方案是去规范化--基本上，将这些昂贵的操作从查询时间转移到摄取时间。我们探索了不同的方法来预先规范化支付数据，并以低于10秒的复制滞后可靠地将其具体化。我们非常幸运，我们在Homes Foundation团队的朋友正在试验一个读优化的存储框架，它采用事件驱动的lambda方法来实现二级索引。使用这个框架，团队能够通过数据库变化捕获机制获得近乎实时的数据，并利用我们存储在Hive中的日常数据库转储获得历史数据。此外，与其他现有的内部解决方案相比，这个框架的维护要求（例如，在线和离线摄入的单一代码，用Java编写）要低得多。
高层看一下支付所使用的读取优化的存储框架。它为离线和接近实时的数据提供摄取流，并在它们之间共享业务逻辑。
在结合上述所有的改进后，我们新的支付读取流程看起来如下。
支付数据读取架构的最终形态。客户不需要知道任何支付服务或内部结构。
我们通过反规范化的读取优化的存储索引，以可靠和高性能的方式提供数据。
结果
迁移和提升。交易历史
新的统一数据读取架构的第一个测试面是交易历史（TH）。我们平台上的主机使用交易历史页面来查看他们过去和未来的支付，以及顶级的盈利指标（例如，总支付金额）。
在技术方面，这是我们最复杂的支付流程之一。有许多不同的细节要求，而且数据来自10多个支付表。这在过去造成了一些问题，包括超时、缓慢的加载时间、由于硬依赖而造成的停机、以及由于复杂的实现而造成的缓慢的迭代速度。在为TH从Airbnb单体迁移到SOA做最初的技术设计时，我们采取了重新架构这一流程的艰难途径，而不是采用创可贴。这有助于确保长期的成功，并为我们的主人社区提供最好的体验。
交易历史页面和简化的高层架构。Airbnb单体应用的行为就像一个演示服务，从多个支付服务以及传统的数据库中获取数据。
这个用例非常适用于我们的统一读取层。以TH使用的数据为起点，我们想出了一个新的API和高层实体来服务于来自类似领域的所有数据读取用例。
在锁定了实体及其模式后，我们开始对数据进行规范化处理。多亏了读优化的存储框架，我们能够将10多个表中的所有数据去正规化为几个Elasticsearch索引。我们不仅大大减少了查询的接触点，而且通过利用存储层而不是在应用层做同样的操作，我们还能更有效地分页和聚合。经过近两年的工作，我们迁移了100%的流量，实现了高达 150x延迟的改善，同时将流量的可靠性从~96%提高到 99.9+%**.
在重新架构后，交易历史所需的支付数据由支付阅读优化的商店提供，并由客户在统一的数据阅读层上使用定义明确和可扩展的支付模式进行访问。
解锁新的体验。访客支付历史
我们的下一个用例，称为 "客人支付历史"，来自Airbnb的年度全公司黑客马拉松。这个黑客马拉松项目旨在为我们的客人社区提供一个详细而简单的方法来跟踪他们的付款和退款。与交易历史类似，这个方案也需要来自多个支付服务和数据库的信息，包括许多传统的数据库。
宾客付款历史（GPH）也有助于展示统一读取层带来的许多好处：一个新的统一实体为GPH和未来类似的用例服务，同时还有一个可扩展的API，支持许多不同的过滤器。我们使用读取优化的存储框架，将传统和SOA支付表的数据去正规化并存储到一个Elasticsearch索引中，这大大降低了查询的复杂性和成本。
我们在2021年冬季发布会上向我们的社区发布了这个新页面，并实现了与客人支付问题有关的客户支持票的大幅减少；这为2021年节省了近150万美元的成本。这也说明了我们正朝着具有高可靠性和低延迟的强大技术基础迈进。
客人可以使用 "客人付款历史 "跟踪他们的付款和退款。
该架构与TH非常相似，数据通过统一的API和模式提供给客户，并由一个二级存储支持。
在通过TH和GPH公开这些新实体后，我们开始加入许多其他关键用例，以利用相同的流程，从而有效地提供和浮现支付数据。
总结
微服务/SOA架构极大地帮助后端团队独立地扩展和开发各种领域，而对彼此的影响最小。同样重要的是，要确保这些服务的客户和他们的数据在这种新的行业标准架构下不会受到额外的挑战。
在这篇博文中，我们说明了一些潜在的解决方案，如统一的API和更高层次的实体，以向调用者隐藏内部服务和架构的复杂性。我们还建议利用非规范化的二级数据存储，在摄取时间内执行昂贵的连接和转换操作，以确保客户端查询可以保持简单和高性能。正如我们在多个项目中所展示的那样，复杂的领域，如支付，可以从这些方法中大大受益。
