在 2018 年一个阴沉的秋季下午，Boris Schol、Yaron Schneide 和我（Haishi）挤在微软雷德蒙德园区的一个小电话室里，讨论云应用开发。当时，我们正在设想一种平台无关的应用模型，允许开发人员在与任何特定平台隔离的情况下设计分布式应用的拓扑结构。这个想法最终成为开放应用模型（OAM，Open Application Model），它将一个应用描述为在软件定义的网状结构上相互连接的服务的集合。

这个应用模型并不关心每个服务是如何编写的。当时，我认为提出一个统一的编程模型过于雄心勃勃；因此，我们试图严格定义一个应用模型将始终把一个服务当作一个黑盒子。然而，当我们进一步讨论这个想法时，似乎缺少一些东西。

突然间，Yaron 跳到白板上开始涂鸦。通过他生动的书写，一个绝妙的想法浮出水面，他称之为 Reaktive（Reactive with a k，反映了 Yaron 对 Kubernetes 的深厚感情）。Reaktive 的核心思想非常简单 —— 通过一个边车容器或进程将分布式系统构件带给用户代码。我们将在 序章 中解释这个优雅而强大的想法是如何为分布式系统的设计和实施带来全新思维的，但现在还是要回到这个故事。

几天后，Yaron 带着一个原型回来了，我们都被震惊了。Reaktive 给用户的代码带来了诸如状态管理、服务发现和可靠的消息传递等功能，而不需要用任何 SDK 或库来污染这些代码；它可以用任何编程语言工作（为了证明这一点，Yaron 后来甚至做了一个 COBOL 样本），而且它是惊人的轻量化。

在接下来的几周里，我们三个人花了很多时间一起头脑风暴，思考增加/删除什么功能是有意义的，我们应该如何在更大的微软技术背景下考虑它，以及我们如何发布它。Boris 邀请了微软和其他公司的架构师和开发人员，以进一步验证我们的想法并获得早期反馈。总的来说，我们三个人的想法是正确的，所以我们把它交给了 Azure 的首席技术官 Mark Russinovich，他立刻就爱上了它。他认为这个编程模型有可能对框架设计和分布式应用开发产生深远的影响，这比我们梦想的要大。

后来，Mark 建议我们把 Reaktive 改名为 Actions，是 Actors 和 Function 的组合。这个名字反映了新产品的核心价值主张：一个非侵入式的编程模型，将无状态服务、有状态服务、功能和行为者统一起来。我们都喜欢这个名字，所以我们保留了它。

转眼一年过去了，Actions 经历了几个月的开发，大量的辩论，以及众多早期用户的验证。最终，它准备在佛罗里达州奥兰多市的微软 Ignite 主题演讲台上以一个新的名字向世界介绍：Dapr，它代表了分布式应用运行时。这是由微软发起的最成功的开源项目之一。在最初的 24 小时内，该项目收集了超过 1000 颗 GitHub 的星星，并在短短几天内被一些最受欢迎的开源项目所放大（图 P-1）。星级热持续了几周，然后团队成员感到厌烦，不再每隔几小时检查一次。
image.png

图 P-1. Dapr 的 GitHub 趋势，用 Mark Russinovich 的 Star Track 工具进行追踪

很快我们就被淹没了，因为社区的贡献从各个方向涌来：我们的合作伙伴、竞争对手、大公司、小公司 —— 每个人都在为使 Dapr 更有用而努力。这的确是开放源码的最佳表现。

巧合的是，O’Reilly 的 Kathleen Carr 通过 LinkedIn 联系我，问我是否有任何新书的想法。我提议出版一本《Actions in Action》。这是一个大胆的提议：写一些还在酝酿中的东西。不过，凯瑟琳很喜欢这个想法，几周后，我们签订了一份合同，向世界介绍 Actions（现在的 Dapr）的书。

你在读这本书的事实证明，冒这个险是值得的。不管 Dapr 会发生什么，你在这里，我们很高兴你在这里。

资源