この記事は、Service Weaver オープンソース製品 Web サイトで Google が公開した論文を翻訳したもので、原文へのリンクや詳細については、Dubbo の公式ブログをご覧いただくか、記事後の [原文を読む] をクリックしてください。
https://dubbo.apache.org/zh-cn/blog
まとめ
分散アプリケーションを作成する場合、伝統的に、アプリケーションを個別にプルアップできる独立したサービスに分割することが賢明です。このアプローチには良い意図がありますが、このようなマイクロサービスベースのアーキテクチャは裏目に出ることが多く、アーキテクチャが達成しようとしている利点を打ち消すような課題が生じます。これは基本的に、マイクロサービスが論理境界 (コードの記述方法) と物理境界 (コードのデプロイ方法) を混同しているためです。この記事では、これらの課題に対処するために、この 2 つ (コードの記述方法とデプロイ方法) を切り離す、別のプログラミング アプローチを提案します。私たちのアプローチでは、開発者はアプリケーションを論理モノリスとして作成し、アプリケーションを自動化されたランタイムに配布して実行する方法を決定し、アプリケーションをアトミックにデプロイします。現在のマイクロサービス開発モデルと比較して、当社のプロトタイプ アプリケーションはレイテンシーを最大 15 倍削減し、コストを最大 9 倍削減できます。
ACM参照形式:
サンジェイ・ゲマワット、ロバート・グランドル、スルジャン・ペトロヴィッチ、マイケル・ホイットテイカー、パルヴィーン・パテル、イワン・ポズヴァ、アミン・ヴァハダット。2023. クラウド アプリケーションの現代開発に向けて。2023 年 6 月 22 ～ 24 日、米国ロードアイランド州プロビデンスで開催されるオペレーティング システムのホット トピックに関するワークショップ (HOTOS '23)。ACM、米国ニューヨーク州ニューヨーク、 8ページ。https://doi.org/10.1145/3593856.3595909
1 はじめに
クラウド コンピューティングは近年、前例のない成長を遂げています。Kubernetes [25] などのフレームワーク、 [7、18、31、33、40、60] などのおかげで、数百万のユーザーにスケールする分散アプリケーションの作成とデプロイがかつてないほど簡単になりました。ソリューションとデータの提供[5、6、23、30 ]などの形式。これらのテクノロジを使用する場合、一般的な方法は、アプリケーションを個別にデプロイできる独立したマイクロサービスに手動で分割することです。
さまざまなインフラストラクチャ チームの内部調査を通じて、ほとんどの開発者が次のいずれかの理由でアプリケーションを複数のバイナリ パッケージに分割していることがわかりました。 (1) パフォーマンスを向上させるため。個々のバイナリを個別にスケーリングできるため、リソースの使用率が向上します。(2) 耐障害性の向上。1 つのマイクロサービスがクラッシュしても他のマイクロサービスがクラッシュすることはないため、エラーの範囲は限定されます。(3) 抽象的な境界を改善します。マイクロサービスには明確で明確な API が必要であり、コードが複雑になる可能性は大幅に減少します。(4) 柔軟なローリングリリースを可能にします。異なるバイナリ パッケージを異なるレートでリリースできるため、コードのアップグレードがより迅速になります。
ただし、アプリケーションを独立してデプロイ可能なマイクロサービスに分割することには課題がないわけではなく、その中には利点と直接矛盾するものもあります。
C1: パフォーマンスに影響します。データをシリアル化してネットワーク経由で送信するオーバーヘッドがますますボトルネックになりつつあります[72]。これらのオーバーヘッドは、開発者がアプリケーションを過度に分割した場合にも増加します[55]。
C2: 正確さを損なう。各マイクロサービスのデプロイされた各バージョン間の相互作用を推論するのは非常に困難です。広く使用されている 8 つのシステムで 100 件を超える壊滅的な障害が発生したケーススタディでは、障害の 3 分の 2 がシステムの複数のバージョン間の相互作用によって引き起こされていました [78 ]。
C3: 管理が難しい。開発者は、ビルド、テスト、デプロイに 1 つのバイナリを使用するのではなく、独自のリリース スケジュールに従ってさまざまなバイナリ パッケージを管理する必要があります。アプリケーションをローカルで実行し、エンドツーエンドの統合テストを実行する必要がある場合、それは大規模なプロジェクトになります。
C4: API が凍結されました。マイクロサービスが API を確立すると、その API を使用する他のサービスを中断せずに API を変更することは困難です。レガシー API は長期間存在する必要があり、継続的にパッチを適用することしかできません。
C5: アプリケーションの開発速度を低下させます。開発アクティビティが複数のマイクロサービスへの変更に影響を与える場合、開発者は変更をアトミックに実装してデプロイすることができません。
開発者はリリース スケジュールを慎重に計画し、マイクロサービス全体に変更を導入する時期を決定する必要があります。私たちの経験では、圧倒的な数の開発者が上記の課題をビジネスの運営に必要な部分であると考えていることがわかりました。実際、多くのクラウド ネイティブ企業は、上記の課題の一部を軽減するために設計された内部フレームワークとプロセスを開発していますが、これによって課題が根本的に変更されたり、完全に排除されるわけではありません。例えば、
継続的デプロイメント フレームワーク[12、22、37]は、単一のバイナリ パッケージを構築して運用環境にプッシュする方法を簡素化しますが、バージョン管理の問題は解決しません。この機能を提供すると、コードがより迅速にリリースして実稼働環境に移行できます。さまざまなプログラミング ライブラリ[13、27]を使用すると、ネットワーク エンドポイントの作成と検出が容易になりますが、アプリケーション管理を簡素化することはできません。gRPC [18]などのネットワーク プロトコルやプロトコル バッファ [30] などのデータ形式は絶えず改良されていますが、依然としてアプリケーション実行コストの大部分を占めています。
これらのマイクロサービスベースのソリューションが上記の C1 ～ C5 を解決できない理由は 2 つあります。1 つ目の理由は、開発者がアプリケーションを手動で複数のバイナリ パッケージに分割すると想定しているためです。これは、アプリケーションのネットワーク レイアウトがアプリケーション開発者によって事前に決定されていることを意味します。さらに、ネットワーク レイアウトが決定されると、ネットワーク コード (ネットワーク エンドポイント、クライアント/サーバー スタブ、[30] などのネットワーク最適化データ構造など) をアプリケーションに追加することによって、より強固なものになります。これは、分割を元に戻したり変更したりすることが理にかなっていても、より困難になることを意味します。これは、上記の課題 C1、C2、および C4 に暗黙的に寄与します。
2 番目の理由は、アプリケーション バイナリ パッケージが運用環境に個別に (場合によっては順次に) リリースされることを想定しているためです。これにより、クロスバイナリ プロトコルに変更を加えることがより困難になります。さらに、バージョン管理の問題が発生し、 [23、30]などのより効率的なデータ形式の使用が強制されます。これは、上記の課題 C1 ～ C5 につながります。
この記事では、分散アプリケーションを作成してデプロイするための別のアプローチ、つまり問題 C1 ～ C5 を解決するアプローチを提案します。私たちのプログラミングアプローチは、次の 3 つの基本原則で構成されています。
(1) モジュール方式で論理的に複数のコンポーネントに分割されたモノリシック アプリケーションを作成します。
(2) ランタイムを活用して、実行特性に基づいて論理コンポーネントを物理プロセスに動的かつ自動的に割り当てます。
(3) アプリケーションをアトミックに展開して、アプリケーションの異なるバージョンが相互作用するのを防ぎます。
其他解决方案（例如，actor 系统）也尝试提高抽象度。但是，它们无法解决其中一项或多项挑战（第 7 节）。尽管这些挑战和我们的提案是在服务型应用 (serving application) 的背景下讨论的，但我们相信我们的观察和解决方案具有广泛的用途。
2 提出的解决方案
我们提案的两个主要部分是 (1) 具有抽象的编程模型（programing model），允许开发人员编写仅关注业务逻辑的单一二进制模块化应用程序，(2) 用于构建、部署和优化这些应用程序的运行时（runtime）。
编程模型使开发人员能够将分布式应用程序编写为单个程序，其中代码被拆分为称为组件的模块化单元（第 3 节）。这类似于将应用程序拆分为微服务，除了微服务将逻辑和物理边界混为一谈。相反，我们的解决方案将两者分离：组件以基于应用程序业务逻辑的逻辑边界为中心，而运行时以基于应用程序性能的物理边界为中心（例如，两个组件应位于同一位置以提高性能）。这种解耦——连同边界可以自动更改的事实——解决了 C4。
通过将所有执行责任委托给运行时，我们的解决方案能够提供与微服务相同的优势，但性能更高，成本更低（解决 C1）。例如，运行时决定如何运行、放置、复制和缩放组件（第 4 节）。由于应用程序是原子部署的，因此运行时可以鸟瞰应用程序的执行情况，从而实现进一步的优化。例如，运行时可以使用自定义序列化和传输协议，利用所有参与者都以相同版本执行的事实。
将应用程序编写为单个二进制文件并以原子方式部署它还可以更轻松地推断其正确性（解决 C2）并使应用程序更易于管理（解决 C3）。我们的提案为开发人员提供了一个编程模型，使他们能够专注于应用程序业务逻辑，将部署复杂性委托给运行时（解决 C5）。最后，我们的提案支持未来的创新，例如分布式应用程序的自动化测试（第 5 节）。
3 编程模型
3.1 组件
我们提案的关键抽象是组件 (component)。组件是一种长期存在的、可复制的计算代理，类似于 actor [2]。每个组件都实现一个接口（interface），与组件交互的唯一方法是调用其接口上的方法。组件可能由不同的操作系统进程托管（可能跨越多台机器）。组件方法调用在必要时变成远程过程调用，但如果调用者和被调用者组件在同一个进程中，则仍然是本地过程调用。
组件如 图-1 所示。示例应用程序包含三个组件：A、B 和 C。当部署应用程序时，运行时决定如何共同定位和复制组件。在此示例中，组件 A 和组件 B 位于同一个操作系统进程中，因此它们之间的方法调用作为常规方法调用执行。组件 C 不与任何其他组件位于同一位置，同时组件 C 被部署到了两台不同机器上，组件 C 之间的方法调用是通过跨网络 RPC 完成的。
图-1：说明如何编写和部署组件。应用程序被编写为一组组件（左）并跨机器部署（右）。请注意，组件可以复制和放置在同一位置。
组件通常是长期存在的，但运行时可能会根据负载随时间增加或减少组件的副本数量。同样，组件副本可能会失败并重新启动。运行时还可以四处移动组件副本，例如，将两个交互非常多的组件放在同一个操作系统进程中，以便组件之间的通信在本地而不是通过网络完成。
3.2 接口
为了具体起见，我们在 Go 中提供了一个组件 API，尽管我们的想法与语言无关。图-2 给出了一个“Hello, World!” 应用程序。组件接口表示为 Go 接口，组件实现表示为实现这些接口的 Go 结构。在图-2 中， hello 结构嵌入了 Implements[ Hello] 结构来表示它是 Hello 组件的实现。
Init 初始化应用程序。Get[Hello] 将客户端返回给具有接口 Hello 的组件，必要时创建它。对 hello.Greet 的调用看起来像是常规方法调用，开发人员不需要关心任何序列化和远程过程调用相关内容。
图-2: “Hello, World!” 应用
4 运行时
4.1 概述
在编程模型之下是一个负责分发（distributing）和执行（executing）组件的运行时。运行时做出关于如何运行组件的所有高级决策。例如，它决定将哪些组件放在一起并进行多副本部署。运行时还负责底层细节，例如将组件运行到物理资源以及在组件失败时重新启动组件。最后，运行时负责执行原子滚动更新，确保一个应用程序版本中的组件永远不会与不同版本中的组件进行通信。
有许多方法可以实现运行时。本文的目的不是规定任何特定的实现。不过，重要的是要认识到运行时并没有什么神奇魔法。在本节的其余部分，我们将概述运行时的关键部分并揭开其内部工作原理的神秘面纱。
4.2 代码生成
运行时的首要职责是代码生成。通过检查一个项目中使用 Implements[T] 的相关源码调用，代码生成器即可计算出所有组件接口和实现的集合。然后它生成代码来编码和解码组件方法的参数。它还生成代码以将这些方法作为远程过程调用来执行。生成的代码将与开发人员的代码一起编译成一个二进制文件。
4.3 应用-运行时交互
根据我们的提案，应用程序不需要包含任何特定于其部署环境的代码，但由于它们最终必须运行并集成到特定环境中（例如在本地集群中跨机器或在公共云中跨区域运行)，为了支持这种集成，我们引入了一个 API（在表-1 中进行了部分概述），它将应用程序逻辑与部署环境的细节隔离开来。
表-1：应用程序和运行时之间的示例 API。
API 的调用者是一个 proclet。每个应用程序二进制文件都会运行一个小型的、与环境无关的守护进程，称为 proclet，它在编译期间链接到二进制文件中。proclet 管理正在运行的二进制文件中的组件:运行、启动、停止、在失败时重新启动这些组件等等。
API 的实现者是运行时，它负责所有控制平面操作。运行时决定 proclet 应该如何运行以及在何处运行。例如，多进程运行时可以运行子进程中的每个 proclet；SSH 运行时可以通过 SSH 运行 proclet；云运行时可以将 proclet 作为 Kubernetes pod [25、28] 运行。
具体而言，proclet 通过 Unix Pipeline 与运行时交互。例如，当构造一个 proclet 时，它会通过管道发送一条 RegisterReplica 消息，以将自己标记为活动和就绪。它定期发出 ComponentsToHost 请求以了解它应该运行哪些组件。如果组件调用不同组件的方法，proclet 会发出 StartComponent 请求以确保它已启动。
运行时以对部署环境有意义的方式实现这些 API。我们希望大多数运行时实现包含以下两部分：
(1) 一组通过 UNIX 管道与 proclet 直接通信的信封（Envelope）进程，以及
(2) 协调 proclet 执行的全局管理器（Global Manager）（参见图-3）。
图-3：提案中的 Deployer 架构
信封（Envelope）作为 proclet 的父进程运行，并将 API 调用中继到管理器。管理器跨可用资源集（例如服务器、VM）启动信封和（间接）proclet。在应用程序的整个生命周期中，管理器与信封交互以收集运行组件的健康和负载信息；聚合组件导出的指标、日志和跟踪；并处理启动新组件的请求。管理器还发布特定于环境的 API（例如，谷歌云[16]、AWS [4]）更新流量分配并根据负载、健康状况和性能约束扩展和缩减组件。请注意，运行时实现控制平面（Golbal Manager）而不是数据平面，Proclet 直接相互通信。
4.4 原子滚动更新（Rollout）
开发人员不可避免地必须发布其应用程序的新版本。一种广泛使用的方法是执行滚动更新，其中部署中的机器一台一台地从旧版本更新到新版本。在滚动更新期间，运行不同版本代码的机器必须相互通信，这可能会导致失败。[78]表明大多数更新失败是由这些跨版本交互引起的。
为了解决这些复杂性，我们提出了一种不同的方法。运行时确保应用程序版本以原子方式推出，这意味着所有组件通信都发生在应用程序的单个版本中。运行时逐渐将流量从旧版本转移到新版本，但是一旦用户请求转发到特定版本，它就会完全在该版本内处理。原子部署的一种流行实现是使用蓝/绿部署[9]。
5 启用创新
5.1 传输（Transport）、放置（Placement）和缩容（Scaling）
运行时可以鸟瞰应用程序执行，这为性能优化开辟了新途径。例如，我们的框架可以在组件之间构建一个细粒度的调用图，并用它来识别关键的路径路径、瓶颈组件、频繁交互型组件等。使用这些信息，运行时可以做出更智能的扩缩容、独立部署和组合部署决策。此外，由于序列化和传输机制对开发者透明（Code Generate 机制自动实现），运行时可以自由地优化它们。例如，对于网络瓶颈应用程序，运行时可能决定压缩网络上的消息，对于某些部署，传输可能会利用 RDMA [32] 等技术。
5.2 路由（Routing）
当请求以亲和力（affinity）路由时，某些组件的性能会大大提高。例如，考虑由基于磁盘的底层存储系统支持的内存缓存组件。当对相同键的请求被路由到相同的缓存副本时，缓存命中率和整体性能会提高。Slicer [44]表明，许多应用程序可以从这种基于亲和力的路由中受益，并且当路由嵌入到应用程序本身时，路由效率最高[43]。我们的编程框架可以自然地扩展为包含路由 API。运行时还可以了解哪些方法从路由中获益最多并自动路由它们。
5.3 自动化测试（Automated Testing）
微服务架构被吹捧的好处之一是容错。这个想法是，如果应用中的一个服务组件失败，应用的部分功能可用性会降低，但整个应用仍然可用。这在理论上很棒，但在实践中它依赖于开发人员确保他们的应用对故障具有弹性，更重要的是，测试他们的故障处理逻辑是否正确。由于构建和运行不同的微服务、系统地失败和恢复它们以及检查正确行为的开销，测试尤其具有挑战性。结果，只有一小部分基于微服务的系统针对这种类型的容错进行了测试。根据我们的建议，运行端到端测试能带来的帮助是微不足道的。因为应用程序是用单一编程语言编写的单个二进制文件，所以端到端测试变成了简单的单元测试。这为自动化容错测试打开了大门，类似于混沌测试[47]、Jepsen 测试[14]和模型检查[62]。
5.4 有状态应用滚动更新（Rollout）
我们的建议确保一个应用程序版本中的组件永远不会与不同版本中的组件通信。这使开发人员更容易推理正确性。但是，如果应用程序更新持久存储系统（如数据库）中的状态，则应用程序的不同版本将通过它们读取和写入的数据间接影响彼此。这些跨版本交互是不可避免的——持久状态，根据定义，跨版本持续存在 —— 但一个悬而未决的问题是如何测试这些交互并及早发现错误以避免在推出期间出现灾难性故障。
5.5 讨论
请注意，本节讨论的领域中的创新并不是我们提案所独有的。对传输协议[63、64]、路由[44、65]、测试[45、75]、资源管理[57、67、71]、故障排除[54、56]等。然而，我们的编程模型的独特功能支持新的创新，并使现有的创新更容易实现实施。
例如，通过在我们的提议中利用原子部署，我们可以设计高效的序列化协议，可以安全地假设所有参与者都使用相同的模式。此外，我们的编程模型可以轻松地将路由逻辑直接嵌入到用户的应用程序中，从而提供一系列好处[43]。同样，我们的提案提供应用程序鸟瞰图的能力允许
研究人员专注于开发用于调整应用程序和降低部署成本的新解决方案。
6 原型实现
我们的原型实现是用 Go [38]编写的，包括图2 中描述的组件 API、第4.2节中描述的代码生成器以及第 4.3 节中描述的 proclet 架构。该实现使用自定义序列化格式和直接构建在 TCP 之上的自定义传输协议。该原型还带有一个谷歌 Kubernetes 引擎 (GKE) 部署器，它通过渐进的蓝/绿部署实现多区域部署。它使用 Horizontal Pod Autoscalers [20]根据负载动态调整容器副本的数量，并遵循类似于图3中的架构。我们的实现可在github.com/ServiceWeaver 获得。
6.1 评价
为了评估我们的原型，我们使用了一个流行的 Web 应用程序[41]，它代表了开发人员编写的各种微服务应用程序。该应用程序有 11 个微服务，并使用 gRPC [18]和 Kubernetes [25]部署在云端。该应用程序是用各种编程语言编写的，因此为了公平比较，我们将应用程序移植为完全用 Go 编写。然后我们将应用程序移植到我们的原型中，每个微服务都被重写为一个组件。我们使用 Locust [26]，一种工作负载生成器，在有和没有我们的原型的情况下对应用程序进行负载测试。
工作负载生成器向应用程序发送稳定速率的 HTTP 请求。两个应用程序版本都配置为自动缩放容器副本的数量以响应负载。我们测量了应用程序版本在稳定状态下使用的 CPU 内核数量，以及它们的端到端延迟。表-2 显示了我们的结果。
我们原型的大部分性能优势来自它使用专为非版本化数据交换设计的自定义序列化格式，以及它使用直接构建在 TCP 之上的流线型传输协议。例如，使用的序列化格式不需要对字段编号或类型信息进行任何编码。这是因为所有编码器和解码器都以完全相同的版本运行，并且预先就字段集以及它们的编码和解码顺序达成一致。
为了与基线进行同类比较，我们没有将任何组件放在一起。当我们共同定位所有将 11 个组件集成到单个操作系统进程中，内核数量下降到 9，中值延迟下降到 0.38 毫秒，均比基线低一个数量级。这反映了行业经验[34、39]。
7 相关工作
演员系统。最接近我们建议的解决方案是 Orleans [74]和 Akka [3]。这些框架还使用抽象来解耦应用程序和运行时。Ray [70]是另一个基于角色的框架，但专注于 ML 应用程序。这些系统都不支持原子部署，而原子部署是完全应对 C2-C5 挑战的必要组成部分。其他流行的基于 actor 的框架，如 Er-lang [61]、E [52]、Thorn [48]和 C++ Actor Framework [10]，给开发人员带来了处理系统和有关部署和执行的低级细节的负担，因此它们未能分离应用程序和运行时之间的关注点，因此没有完全解决 C1-C5。CORBA、DCOM 和 Java RMI 等分布式对象框架使用与我们类似的编程模型，但存在许多技术和组织问题[58]，并且也没有完全解决 C1-C5。
基于微服务的系统。Kubernetes [25]广泛用于在云中部署基于容器的应用程序。但是，它的重点与我们的提案正交，不涉及 C1-C5 中的任何一个。Docker Compose [15]、Acorn [1]、Helm [19]、Skaffold [35]和 Istio [21]抽象出了一些微服务挑战（例如，配置生成）。然而，与将应用程序拆分为微服务、版本化推出和测试相关的挑战仍然留给了用户。因此，它们不满足 C1-C5。
其他系统。还有许多其他解决方案可以让开发人员更轻松地编写分布式应用程序，包括数据流系统[51、59、77]、ML 推理服务系统[8、17、42、50、73]、无服务器解决方案[11, 24、36]、数据库[29、49]和 Web 应用程序[66]。最近，服务网格[46、69]提出了网络抽象以分解出常见的通信功能。我们的提案体现了这些相同的想法，但在通用服务系统和分布式应用程序的新领域中。在这种情况下，出现了新的挑战（例如，原子推出）。
8 讨论
8.1 多个应用程序二进制文件
我们认为应用程序应该作为单个二进制文件来编写和构建，但我们承认这可能并不总是可行的。例如，应用程序的大小可能超出单个团队的能力，或者不同的应用程序服务可能出于组织原因需要不同的发布周期。在所有这些情况下，应用程序可能需要包含多个二进制文件。
虽然本文没有解决需要使用多个二进制文件的情况，但我们相信我们的提议允许开发人员编写更少的二进制文件（即尽可能将多个服务分组为单个二进制文件），实现更好的性能，并推迟做出艰难的决定与如何划分应用程序有关。我们正在探索如何容纳以多种语言编写并编译成单独的二进制文件的应用程序。
8.2 与外部服务集成
应用程序通常需要与外部服务（例如，Postgres 数据库[29]）进行交互。我们的编程模型允许应用程序像任何应用程序一样与这些服务交互。什么都不是，一切都必须是一个组件。但是，当外部服务在应用程序内部和跨应用程序广泛使用时，定义相应的组件可能会提供更好的代码重用。
8.3 分布式系统挑战
虽然我们的编程模型允许开发人员专注于他们的业务逻辑并推迟将他们的应用程序部署到运行时的大量复杂性，但我们的提议并没有解决分布式系统的基本挑战 [53 ，68, 76]。应用程序开发人员仍然需要意识到组件可能会失败或经历高延迟。
8.4 编程指导
没有关于如何编写分布式应用程序的官方指南，因此关于将应用程序编写为单体应用程序还是微服务是更好的选择，一直存在着长期而激烈的争论。但是，每种方法都有其优点和缺点。我们认为开发人员应该使用我们的建议将他们的应用程序编写为单个二进制文件，然后再决定他们是否真的需要迁移到基于微服务的架构。通过推迟决定如何准确地拆分成不同的微服务，它允许他们编写更少但更好的微服务。
9 结论
编写分布式应用程序时的现状涉及将应用程序拆分为可独立部署的服务。这种架构有很多好处，但也有很多缺点。在本文中，我们提出了一种不同的编程范式来回避这些缺点。我们的提议鼓励开发人员 (1) 编写划分为逻辑组件的单体应用程序，(2) 将物理分布和执行模块化单体的挑战推迟到运行时，以及 (3) 原子部署应用程序。这三个指导原则带来了许多好处，并为未来的创新打开了大门。与现状相比，我们的原型实施将应用程序延迟最多减少了 15 倍，并将成本最多减少了 9 倍。
[1] Acorn. https://www.acorn.io/.
[2] Actor model. https://en.wikipedia.org/wiki/Actor_model.
[3] Akka. https://akka.io.
[4] Amazon Web Services. https://aws.amazon.com/.
[5] Apache avro. https://avro.apache.org/docs/1.2.0/.
[6] Apache thrift. https://thrift.apache.org/.
[7] AWS Cloud Map. https://aws.amazon.com/cloud-map/.
[8] Azure Machine Learning. https://docs.microsoft.com/en-us/azure/machine-learning.
[9] Blue/green deployments. https://tinyurl.com/3bk64ch2.
[10] The c++ actor framework. https://www.actor-framework.org/.
[11] Cloudflare Workers. https://workers.cloudflare.com/.
[12] Continuous integration and delivery - circleci. https://circleci.com/.
[13] Dapr - distributed application runtime. https://dapr.io/.
[14] Distributed systems safety research. https://jespen.io.
[15] Docker compose. https://docs.docker.com/compose/.
[16] Google Cloud. https://cloud.google.com/.
[17] Google Cloud AI Platform. https://cloud.google.com/ai-platform.
[18] grpc. https://grpc.io/.
[19] Helm. http://helm.sh.
[20] Horizontal Pod Autoscaling. https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/.
[21] Istio. https://istio.io/.
[22] Jenkins. https://www.jenkins.io/.
[23] Json. https://www.json.org/json-en.html.
[24] Kalix. https://www.kalix.io/.
[25] Kubernetes. https://kubernetes.io/.
[26] Locust. https://locust.io/.
[27] Micro | powering the future of cloud. https://micro.dev/.
[28] Pods. https://kubernetes.io/docs/concepts/workloads/pods/.
[29] Postgresql. https://www.postgresql.org/.
[30] Protocol buffers. https://developers.google.com/protocol-buffers.
[31] RabbitMQ. https://www.rabbitmq.com/.
[32] Remote direct memory access. https://en.wikipedia.org/wiki/Remote_direct_memory_access.
[33] REST API. https://restfulapi.net/.
[34] Scaling up the Prime Video audio/video monitoring service and reduc-ing costs by 90%. https://tinyurl.com/yt6nxt63.
[35] Skaffold. https://skaffold.dev/.
[36] Temporal. https://temporal.io/.
[37] Terraform. https://www.terraform.io/.
[38] The Go programming language. https://go.dev/.
[39] To Microservices and Back Again - Why Segment Went Back to a Monolith. https://tinyurl.com/5932ce5n.
[40] WebSocket. https://en.wikipedia.org/wiki/WebSocket.
[41] Online boutique. https://github.com/GoogleCloudPlatform/microservices-demo,2023.
[42] M. Abadi, P. Barham, J. Chen, Z. Chen, A. Davis, J. Dean, M. Devin,
S.Ghemawat, G. Irving, M. Isard, M. Kudlur, J. Levenberg, R. Monga,
S.Moore, D. G. Murray, B. Steiner, P. Tucker, V. Vasudevan, P. Warden,
M.Wicke, Y. Yu, and X. Zheng. Tensorflow: A system for large-scale machine learning. In OSDI, 2016.
[43] A. Adya, R. Grandl, D. Myers, and H. Qin. Fast key-value stores: An idea whose time has come and gone. In HotOS, 2019.
[44] A. Adya, D. Myers, J. Howell, J. Elson, C. Meek, V. Khemani, S. Fulger,
P.Gu, L. Bhuvanagiri, J. Hunter, R. Peon, L. Kai, A. Shraer, A. Merchant, and K. Lev-Ari. Slicer: Auto-sharding for datacenter applications. In OSDI, 2016.
[45] D. Ardelean, A. Diwan, and C. Erdman. Performance analysis of cloud applications. In NSDI, 2018.
[46] S. Ashok, P. B. Godfrey, and R. Mittal. Leveraging service meshes as a new network layer. In HotNets, 2021.
[47] A. Basiri, N. Behnam, R. De Rooij, L. Hochstein, L. Kosewski, J.Reynolds, and C. Rosenthal. Chaos engineering. In IEEE Software, 2016.
[48] B. Bloom, J. Field, N. Nystrom, J. Östlund, G. Richards, R. Strniša, J.Vitek, and T. Wrigstad. Thorn: Robust, concurrent, extensible script-ing on the jvm. In OOPSLA, 2009.
[49] J. C. Corbett, J. Dean, M. Epstein, A. Fikes, C. Frost, J. J. Furman, S. Ghe-mawat, A. Gubarev, C. Heiser, P. Hochschild, W. Hsieh, S. Kanthak, E.Kogan, H. Li, A. Lloyd, S. Melnik, D. Mwaura, D. Nagle, S. Quin-lan, R. Rao, L. Rolig, Y. Saito, M. Szymaniak, C. Taylor, R. Wang, and D.Woodford. Spanner: Google’s globally-distributed database. In OSDI, 2012.
[50] D. Crankshaw, X. Wang, G. Zhou, M. J. Franklin, J. E. Gonzalez, and I.Stoica. Clipper: A low-latency online prediction serving system. In NSDI, 2017.
[51] J. Dean and S. Ghemawat. Mapreduce: Simplified data processing on large clusters. In OSDI, 2004.
[52] J. Eker, J. Janneck, E. Lee, J. Liu, X. Liu, J. Ludvig, S. Neuendorffer, S.Sachs, and Y. Xiong. Taming heterogeneity - the ptolemy approach. In Proceedings of the IEEE, 2003.
[53] M. J. Fischer, N. A. Lynch, and M. S. Paterson. Impossibility of dis-tributed consensus with one faulty process. In ACM Journal, 1985.
[54] Y. Gan, M. Liang, S. Dev, D. Lo, and C. Delimitrou. Sage: Practical and Scalable ML-Driven Performance Debugging in Microservices. In ASPLOS, 2021.
[55] Y. Gan, Y. Zhang, D. Cheng, A. Shetty, P. Rathi, N. Katarki, A. Bruno, J.Hu, B. Ritchken, B. Jackson, et al. An open-source benchmark suite for microservices and their hardware-software implications for cloud & edge systems. In ASPLOS, 2019.
[56] Y. Gan, Y. Zhang, K. Hu, Y. He, M. Pancholi, D. Cheng, and C. De-limitrou. Seer: Leveraging Big Data to Navigate the Complexity of Performance Debugging in Cloud Microservices. In ASPLOS, 2019.
[57] R. Grandl, G. Ananthanarayanan, S. Kandula, S. Rao, and A. Akella. Multi-resource packing for cluster schedulers. In SIGCOMM, 2014.
[58] M. Henning. The rise and fall of corba: There’s a lot we can learn from corba’s mistakes. In Queue, 2006.
[59] M. Isard, M. Budiu, Y. Yu, A. Birrell, and D. Fetterly. Dryad: Distributed data-parallel programs from sequential building blocks. In Eurosys, 2007.
[60] K. Jay, N. Neha, and R. Jun. Kafka : a distributed messaging system for log processing. In NetDB, 2011.
[61] A. Joe. Erlang. In Communications of the ACM, 2010.
[62] L. Lamport. The temporal logic of actions. In ACM TOPLS, 1994.
[63] A. Langley, A. Riddoch, A. Wilk, A. Vicente, C. Krasic, D. Zhang, F.Yang, F. Kouranov, I. Swett, J. Iyengar, J. Bailey, J. Dorfman, J. Roskind, J.Kulik, P. Westin, R. Tenneti, R. Shade, R. Hamilton, V. Vasiliev, W.-T. Chang, and Z. Shi. The quic transport protocol: Design and internet-scale deployment. In SIGCOMM, 2017.
[64] N. Lazarev, N. Adit, S. Xiang, Z. Zhang, and C. Delimitrou. Dagger: Towards Efficient RPCs in Cloud Microservices with Near-Memory Reconfigurable NICs. In ASPLOS, 2021.
[65] S. Lee, Z. Guo, O. Sunercan, J. Ying, T. Kooburat, S. Biswal, J. Chen, K.Huang, Y. Cheung, Y. Zhou, K. Veeraraghavan, B. Damani, P. M. Ruiz, V.Mehta, and C. Tang. Shard manager: A generic shard management framework for geo-distributed applications. In SOSP, 2021.
[66] B. Livshits and E. Kiciman. Doloto: Code splitting for network-bound web 2.0 applications. In FSE, 2008.
[67] S. Luo, H. Xu, C. Lu, K. Ye, G. Xu, L. Zhang, Y. Ding, J. He, and C. Xu. Characterizing microservice dependency and performance: Alibaba trace analysis. In SOCC, 2021.
[68] N. A. Lynch. Distributed algorithms. In Morgan Kaufmann Publishers Inc., 1996.
[69] S. McClure, S. Ratnasamy, D. Bansal, and J. Padhye. Rethinking net-working abstractions for cloud tenants. In HotOS, 2021.
[70] P. Moritz, R. Nishihara, S. Wang, A. Tumanov, R. Liaw, E. Liang, M. Eli-bol, Z. Yang, W. Paul, M. I. Jordan, and I. Stoica. Ray: A distributed framework for emerging ai applications. In OSDI, 2018.
[71] H. Qiu, S. S. Banerjee, S. Jha, Z. T. Kalbarczyk, and R. K. Iyer. FIRM: An intelligent fine-grained resource management framework for SLO-Oriented microservices. In OSDI, 2020.
[72] D. Raghavan, P. Levis, M. Zaharia, and I. Zhang. Breakfast of champi-ons: towards zero-copy serialization with nic scatter-gather. In HotOS, 2021.
[73] F. Romero, Q. Li, N. J. Yadwadkar, and C. Kozyrakis. Infaas: Automated model-less inference serving. In ATC, 2021.
[74] B. Sergey, G. Allan, K. Gabriel, L. James, P. Ravi, and T. Jorgen. Orleans: Cloud computing for everyong. In SOCC, 2011.
[75] M. Waseem, P. Liang, G. Márquez, and A. D. Salle. Testing microser-vices architecture-based applications: A systematic mapping study. In APSEC, 2020.
[76] Wikipedia contributors. Fallacies of distributed computing.
[77] M. Zaharia, M. Chowdhury, T. Das, A. Dave, J. Ma, M. McCauly, M. J. Franklin, S. Shenker, and I. Stoica. Resilient distributed datasets: A fault-tolerant abstraction for in-memory cluster computing. In NSDI, 2012.
[78] Y. Zhang, J. Yang, Z. Jin, U. Sethi, K. Rodrigues, S. Lu, and D. Yuan. Understanding and detecting software upgrade failures in distributed systems. In SOSP, 2021.
本文分享自微信公众号 - Apache Dubbo（ApacheDubbo）。
如有侵权，请联系 [email protected] 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。