有关译者：陈东海(seachen)，⽬前就职于腾讯，同时在社区也是⼀名Dapr Member.

导语：在SDLC(Software Development Lifecycle软件开发⽣命周期中)，绝⼤多数CNCF项⽬都是专注于软件开发的中后期阶段，特别是运维和可观测性⽅⾯。⽽很少有CNCF项⽬专注于早期阶段。⽽Dapr就是在软件开发的早期阶段，帮助开发者提⾼⽣产⼒。

适合阅读⼈群：研发童鞋以及云原⽣产品童鞋。

内容摘要(若感兴趣，再读原⽂，阅读原文可以到达)：

1.⼤多数IT项⽬，都是来源于增加收⼊、降低成本和降低⻛险三个业务⽬标；由此推导出产⽣的三个副作⽤，分别是多语⾔、多负载和多环境的⽀持。并以此作为XYZ三维坐标轴，提出问题和分析问题；并引出云原⽣；

2.了解SDLC(软件开发⽣命周期)不同阶段的CNCF项⽬，往往都聚焦于中后期的应⽤运维，⽐较少地关注如何创建应⽤并提⾼开发者的⽣产⼒。⽽Dapr就是这样的⼀款产品；

3.从集群上、集群外和多集群的三个案例，来分析Dapr如何与Kubernetes互补来帮助开发者开发出云原⽣应⽤。

---------------以下是译者想告诉读者的------------------

Bilgin Ibryam之前是Red Hat的产品经理和架构师。他在2020年写过《 Multi-Runtime Microservices Architecture》⼀⽂，⽂章中的分布式原语(distributed primitives)就是这位童鞋提出来的。Dapr社区开源产品和他提出的这个理念⾮常契合，2022年中旬了解到Dapr后并迅速加⼊了diagrid⼩型创业公司。⽬前在该公司担任产品经理，⽽diagrid公司是由两位前微软童鞋 Mark Fussell(现任CEO)和Yaron Schneider(现任CTO)在2021年底创办的。

diagrid公司融资详情：Diagrid Emerges from Stealth with $24.2 Million in Funding, Launches Fully Managed Dapr for Kubernetes

由 Dapr 和 KEDA（Kubernetes Event-Driven Autoscaling）创始⼈ Mark Fussell 和 Yaron

Schneider 创办的 Diagrid 最近获得 2400 万美元融资。投资⼈阵容⼗分强⼤，包括 Kubernetes 联合创始⼈ Joe Beda、Buoyant CEO William Morgan(这⼈是开创性地提出了服务⽹格(Service Mesh)概念，其著名的开源项⽬Linkerd)笔者最早在2016年使⽤(java开发，⾯向服务治理的代理)， Azure CTO Mark Russinovich，前Atlassian CTO Sri Viswanath，以及前 Heroku CEO Adam Gross。

-----------------以下是译⽂-------------------------

Kubernetes已经成为运⾏分布式应⽤的事实标准，⽆论它们是集群上的、集群外的还是多集群的。但是Kubernetes并没有为业务开发者提供很多好处，也没有为⼤多数其他CNCF项⽬提供好处。但是也有例外，新的CNCF项⽬（例如Dapr(孵化中)）正在提⾼开发者的⽣产⼒，让业务开发变得简单。在这篇⽂章中，我们将探索前三个案例，以展示Kubernetes也可以扩展新的运营领域，以及为什么Dapr是最适合开发者的Kubernetes伙伴。

技术扩散阻碍⽣产⼒

如果我们从较⾼的层⾯看⼀下⼤多数IT项⽬，它们都属于以下类别之⼀：增加收⼊、降低成本或降低⻛险。在您的组织中，您可能有这三者的变体，例如提⾼客户满意度、减少客户流失等，但它们⼤致属于同⼀类。有多种⽅法可以实现这些⽬标，这⾥我挑选了⼀些作为示例，但对于您的组织⽽⾔，这些⽅法的顺序会有所不同。

业务⽬标与副作⽤

您可决定采⽤⼀些很新很酷的开源机器学习技术，并利⽤它开发⼀些创新服务来增加收⼊。您可以通过迭代开发实践和较⼩的开发单元（如微服务）按时更新软件来降低合规⻛险。裁员并不是性价⽐最⾼的⽅式，在公司内部或者⼩团队内并不是所有事情都需要亲⼒亲为，⽽是通过⾃动化，采⽤云和SaaS服务的⽅式来实现软件⽣命周期的全流程管理，这样性价⽐更⾼。但后果总是有的，您意识到机器学习最流⾏的语⾔是Python，Javascript是Web开发的最佳语⾔，Java⽤于桌⾯，Swift⽤于移动终端，C++⽤于IoT应⽤等等，您最终会在组织内使⽤多种语⾔。

然后您意识到您必须运维微服务、函数、单体服务以及介于这两者之间的许多其他应⽤。⽽且您必须在本地和⼀个或多个云上执⾏此操作。从组织层⾯来看，所有这些都导致了同时发⽣多个维度的技术扩散。

技术扩散对开发和运维的影响

技术扩散不同程度地影响着不同的团队。仅仅使⽤Python，您就可以有⾃⼰的数据科学团队，但是这个平台的⼯程团队必须为使⽤不同语⾔的多个团队提供构建和打包⼯具。您可能有新创建的微服务，它们遵循12-factor原则。但是运维团队可能还必须照顾单体应⽤，以及不断增加函数的实例。您的基础设施团队必须创建⾃动化以遵循多个云和本地部署上进⾏配置。

平台和运维团队的挑战在于如何保证许多团队之间的⼀致性和统⼀性，开发团队的挑战在于其团队内部的⽣产⼒。通常，开发团队使⽤某些语⾔(例如：java和.net，他们更适合创建分布式应⽤，和可以连接到各个SaaS端点的应⽤)，⽽使⽤不同语⾔的其他团队往往是孤⽴的，他们并不能从丰富的云原⽣⽣态系统中受益。这些团队不能复⽤相同的⼯具和模式来解决常⻅问题。应对技术扩散带来的这些挑战，答案是什么？⼀个答案就是成为云原⽣，这是CNCF定义的⽅式以及那⾥不断增⻓的项⽬⽣态系统。

开发者的期望仍未得到满⾜作为⼀名前开发⼈员，我决定检查哪些CNCF项⽬，可以帮助开发者编写代码并实现云原⽣应⽤。我粗略地绘制了SDLC阶段(全称：Software Development Lifecycle软件开发⽣命周期)，并将它们放在所有已毕业的CNCF项⽬中，趋势很明显。没有任何⼀个已毕业的CNCF项⽬可以帮助软件开发的早期阶段。我也增加了孵化中的CNCF项⽬，专注于运维和可观测性应⽤的趋势更加强烈。如下图所示：

在软件开发⽣命周期中的CNCF项⽬

该图不是完整的，它不能完全代表⽣态系统中的所有变化。例如：这⾥有些是聚焦运⾏时的项⽬，也帮助了开发者。例如，可观测性⼯具总是提供SDK。Knative serving为运⾏应⽤提供⾃动伸缩和蓝绿发布功能，⽽Knative eventing帮助开发者实现事件驱动的应⽤。与此同时，⽆论是Kubernetes, 代理还是基于eBPF的linux内核，任何以前属于应⽤层的分布式系统职责也正在通过eBPF转移到基础设施层。但是总体来说，所显示的趋势是准确的，CNCF项⽬的重点仍然是运维应⽤，⽽不是创建应⽤。好消息是这⾥有新的项⽬，例如：Dapr和其他针对开发者的项⽬，并专注于实现适应云原⽣环境的应⽤。

接下来，我们将研究三个具体的⽤例，其中 Kubernetes正在成为部署和运维应⽤的事实标准，⽽Dapr使开发者能够实现云原⽣应⽤，并以云原⽣⽅式使⽤基础设施。这些⽤例展示了Dapr如何与Kubernetes互补并提⾼开发者的⽣产⼒，就像Kubernetes提⾼运维团队的⽣产⼒⼀样。

创建和运维集群上的应⽤

如今，Kubernetes API是部署和运⾏分布式系统最流⾏的⽅式。容器和Kubernetes允许我们定义和实施应⽤程序资源约束。具有初始化容器和Sidecar的Pod抽象提供了应⽤⽣命周期的保障。健康检查APIs提供了从短暂地运⾏时故障中检测和恢复的能⼒。有声明式部署、回滚和策略驱动的应⽤placement。所有这些都允许运维⾃动化部署和管理⼤量⼯作负载，但对开发⼈员来说有什么好处呢？

Dapr帮助开发者实现运维能够在k8s上运⾏的分布式应⽤

开发⼈员可以使⽤Kubernetes⾃带的服务发现，但它缺乏重试、超时和熔断等⽹络弹性功能。

虽然Kubernetes有ConfigMaps和Secrets，但它们缺乏动态更新和细粒度的访问控制。

Kubernetes有StatefulSet，但没有⽤于访问该状态的API。 Kubernetes有健康检查，但它不会申请出⼝连接，例如从队列中消费(翻译得不太明⽩)。Kubernetes中没有任何东⻄可以帮助实现事件驱动的应⽤。

这就是 Dapr 的⽤武之地。Dapr 解决了这些限制，并为开发者提供了与Kubernetes为运维提供了相同的⽣产⼒。Kubernetes通过抽象基础设施来帮助运维应⽤。Dapr帮助开发者实现这些应⽤并以可靠的⽅式连接它们。 Dapr具有服务调⽤和Pub/SubAPI，可帮助以任何语⾔编写的应⽤，在动态云基础设施上可靠地交互。它具有状态管理、配置中⼼、秘钥和其他API，可帮助开

发者通过通⽤且可复⽤的模式实现应⽤需求和使⽤基础设施。

提供和使⽤集群外的资源

Kubernetes可以很好地管理集群上的应⽤。但这些集群上的应⽤需要并依赖于集群外的资源，例如数据库、⽂档存储、消息队列和数⼗种其他云服务。如果您已经在使⽤Kubernetes 来运维应⽤，那意味着您使⽤的是YAML语法，以及定义所需资源状态的声明性概念。如果您正在使⽤基础设施即代码和GitOps等⼯具来实现⾃动化，那么您也可以使⽤Kubernetes API来管理外部资源。这使得Kubernetes成为资源所需状态的单⼀“真实来源”，不仅适⽤于集群上的容器，也适⽤于集群外的资源。现在有这样的Kubernetes云⼚商，例如 AWS Controller for Kubernetes、Azure Service Operator、Google Config Connector，以及像Crossplane这样的 CNCF 项⽬，它们使⽤ Kubernetes CRD来管理外部资源。但是这些⼯具的职责在管理外部资源的⽣命周期之后结束，并且不会扩展到绑定到在 Kubernetes 数据平⾯中运⾏的应⽤。通常，这些云⼚商有⼀种机制，可以将外部资源的坐标和访问机制添加到configmap、secret或 CRD 中。但是使⽤特定协议从应⽤到资源的实际绑定会再次留给开发者处理。

Dapr帮助开发者使⽤运维通过k8s提供的第三⽅服务

这就是Dapr能够帮助开发者的地⽅。 Dapr绑定可帮助开发者将应⽤与外部资源连接起来，⽆论您的应⽤程序使⽤何种语⾔。提供外部资源只是故事的⼀半。 Dapr帮助您从应⽤中使⽤该基础设施。并通过添加弹性、跟踪、安全性并以⼀致性的⽅式做到这⼀点，并通过 API 和sidecars以云原⽣⽅式做到这⼀点，⽽不是将难以升级的库嵌⼊到应⽤中。

开发和编排多集群的应⽤

我们已经了解了 Kubernetes 如何⽤于管理集群上的应⽤程序以及如何⽤于管理集群外的资源。使⽤ Kubernetes API还有⼀种趋势，那就是管理多个远端集群上的应⽤。

如今，由于规模、应⽤和数据本地化、隔离等各种原因，组织必须将应⽤部署到多个数据中⼼、云和 Kubernetes集群中。Kubernetes集群的物理边界并不总是符合所需的应⽤边界。通常，必须将同⼀个应⽤或⼀组应⽤部署到多个集群中，这需要多集群部署和编排。有许多项⽬和服务可以让您在多个集群上运⾏应⽤，例如 Azure Arc、Google Anthos、Red Hat Advanced Cluster Manager、Hypershift和 kcp.io等项⽬。这些项⽬提供统⼀的⽤户界⾯、仪表板、警报、⽇志、策略和对多个集群的访问控制。他们中的⼤多数通过提供Kubernetes API作为控制平⾯，并将每个集群作为数据平⾯来实现这⼀点。为了使⽤⼀致的操作、安全、合规模型，您可以集成DevOps ⼯具包。

Dapr帮助开发者创建运维可以通过Kubernetes API操作的多云应⽤

在这种场景下，Dapr帮助创建可以运⾏并与任何云环境交互的多云应⽤。在不同的云环境中打包和运⾏应⽤⼜是故事的另⼀半。通常在云环境中运⾏的应⽤必须使⽤该云环境的本地服务，⽽Dapr⽀持这⼀点。通常，不同的云⼚商提供不同的抽象、模式和⼯具来解决相同的问题，这些问题在不同的环境中不可转移和重⽤。 例如，Azure 有 Event Grid，AWS 有 EventBridge，GCP 有 Eventarc ⽤于创建事件驱动的应⽤程序。这些服务中的每⼀个都有独特的学习曲线，并与云⼚商耦合。另⼀⽅⾯，Dapr pub/sub API 提供了通⽤的异步构建块，可⽤于为任何云和本地创建事件驱动的应⽤程序。

在多云场景中，Dapr API充当统⼀的构建块，使开发者能够创建独⽴于云的解决⽅案，并使运维团队能够应⽤弹性策略并从统⼀的独⽴于云的应⽤程序运⾏时获取指标和跟踪。Diagrid Conductor等服务可以帮助在多个云环境中运⾏Dapr。所有这些使得Dapr成为创建多云应⽤的开发者和运维这些应⽤程序的理想补充。

（ps. 译者备注，开发和编排多集群的应⽤：主要是讲可移植性。使⽤Dapr Sidecar后就与云⼚商解耦了。）

⽆处不在的云原⽣API

Kubernetes已经不仅仅是⼀个容器编排器。它也可以管理集群内、集群外和多集群资源。它是⽤于管理多种资源的通⽤且可扩展的操作模型。其声明式YAML API和异步协调过程已成为资源编排范式的代名词。它的CRD 和 Operators已经成为将领域知识与分布式系统合并的通⽤扩展机制。

Kubernetes和Dapr APIs的特点

Dapr建⽴在与Kubernetes相同的原则和基础之上。Dapr通过定义明确的API(称为构建块)提供其 协议上运⾏，使它们⽀持多种语⾔，并且可以从任何语⾔或环境中访问。 Dapr功能随着新构建块的添加⽽不断增⻓，例如最近的分布式锁API，以及内容存储和⼯作流 API的提案。 Dapr功能还通过添加当前超过100个并且还在增⻓的构建块来扩展。

这篇⽂章基于我在底特律Dapr社区⽇的演讲。在@bibryam和@diagridio关注我，看看我使⽤Dapr和构建Diagrid Cloud的旅程，或者说出您的任何想法和评论。