Dapr是一個由微軟主導的云原生開源項目，國內云計算巨頭阿里云也積極參與其中，2019年10月首次發布，到今年2月正式發布V1.0版本。在不到一年半的時間內，github star數達到了1.2萬，超過同期的kubernetes、istio、knative等，發展勢頭迅猛，業界關注度非常高。

什么是云原生

云原生技術有利于各組織在公有云、私有云和混合云等新型動態環境中，構建和運行可彈性擴展的應用。云原生的代表技術包括容器、服務網格、微服務、不可變基礎設施和聲明式API。

這些技術能夠構建容錯性好、易于管理和便于觀察的松耦合系統。結合可靠的自動化手段，云原生技術使工程師能夠輕松地對系統作出頻繁和可預測的重大變更。

云原生計算基金會（CNCF）致力于培育和維護一個廠商中立的開源生態系統，來推廣云原生技術。我們通過將最前沿的模式民主化，讓這些創新為大眾所用。

什么是Dapr

Dapr(Distributed Application Runtime)分布式應用運行時，是一個可移植的、事件驅動的運行時，它使任何開發人員能夠輕松構建出彈性的、無狀態和有狀態的應用程序，并可運行在云平臺或邊緣計算中，它同時也支持多種編程語言和開發框架。

Dapr 愿景

可移植，事件驅動，彈性，有狀態和無狀態，云和邊端，語言無關，框架無關。

Any language, Any framework, Anywhere

其核心是要提供一個有標準，可配置，包含各種分布式能力的運行時。

如今，我們正經歷著上云浪潮。開發人員對Web+數據庫應用結構（例如經典3層設計）非常熟悉，并且使用得手，但對本身能支持分布式的微服務應用結構卻感覺陌生。成為分布式系統專家很難，并且你也不需要這么做。開發人員希望專注于業務邏輯，同時希望平臺為其提供可伸縮的、彈性的、可維護性和云原生架構的其他功能。

這就是Dapr所要解決的。Dapr將構建微服務應用的最佳實踐設計成開放、獨立和模塊化的方式，讓你能夠選擇的任意開發語言和框架構建可移植應用程序。每個構建塊都是完全獨立的，您可以采用其中一個或多個或全部來構建你的應用。

此外，Dapr是和平臺無關的，這意味著您可以在本地、Kubernetes群集或者其它集成Dapr的托管環境中運行應用程序。這使得您能夠在云平臺和邊緣計算中運行微服務應用。

使用Dapr，您可以使用任何語言、任何框架輕松構建微服務應用，并運行在任何地方。

Dapr 發展歷程

• 2019年10月：微軟在GitHub上開源了Dapr，發布0.1.0版本

• 2021年2月：Daprv1.0版本發布

阿里巴巴深度參與Dapr項目，不僅僅以終端用戶的身份成為Dapr的早期采用者，也通過全面參與Dapr的開源開發和代碼貢獻成為目前Dapr項目中的主要貢獻公司之一，僅次于微軟：

• 2020年中：阿里巴巴開始參與Dapr項目，在內部試用功能并進行代碼開發

• 2020年底：阿里巴巴內部小規模試點Dapr，目前已經十幾個應用在使用Dapr。

Dapr 引領云原生的未來

分布式應用所需：

• 生命周期：包括部署，健康檢查，水平擴展，配置管理等，目前這些需求的最佳實踐，都陸續在kubernetes上有了落地。

• 網絡：網絡方面的需求是service Mesh的主戰場，比如istio可以滿足這里絕大部分需求，除了pub/sub。

• 狀態：包括數據的讀寫，狀態其實是非常難以管理的，涉及冪等，緩存，數據流等等。

• 綁定：主要是指和系統外部資源的交互。

Multi runtime是由RedHat首席架構師Bilgin Ibryam提出的，實際上multi runtime和dapr并沒有直接的關系，multi runtime的提出是在dapr開源之后。作者的文章重點對當今分布式應用的需求做了歸類，并且分析了當前流行的云原生項目是如何滿足這些分布式需求，包括kubernetes，istio，dapr等，最后，作者對分布式應用和中間件的未來發展，做了推導和預測，這就是multiruntime。

過去，我們對云原生的全景：

有了Dapr之后，我們對云原生的全景：

應用的期望就是中間件的方向：

• 應用可以使用任意喜愛而適合的語言編寫，可以快速開發和快速迭代。

• 應用需要的能力都可以通過標準的API提供，無需關心底層具體實現。

• 應用可以部署到任意的云端，不管是公有云、私有云還是混合云，沒有平臺和廠商限制，無需代碼改造。

• 應用可以根據流量彈性伸縮，頂住波峰的壓力，也能在空閑時釋放資源。

Service Mesh探索了Sidecar模式，Dapr將Sidecar模式推廣到更大的領域：

• 完善的多語言支持和應用輕量化的需求推動中間件將更多的能力從應用中分離出來

• Sidecar模式會推廣到更大的領域，越來越多的中間件產品會開始Mesh化，整合到Runtime。

• 對廠商鎖定的天然厭惡和規避，會加劇對可移植性的追求，從而進一步促使為下沉到Runtime中的分布式能力提供標準而業界通用的API。

• API的標準化和社區認可，將成為Runtime普及的最大挑戰，但同時也將推動各種中間件產品改進自身實現，實現中間件產品和社區標準API之間的磨合與完善。

預測未來：

Dapr 與Istio、Linkerd或OSM等服務網格相比如何？

Dapr不是一個服務網格。雖然服務網側重于細粒度網絡控制，但Dapr專注于幫助開發人員構建分布式應用程序。Dapr和服務網都使用sidecar模式，并隨應用程序一起運行，它們確實具有一些重疊的功能，但也提供獨特的優勢。

雖然Dapr和服務網格確實提供了一些重疊功能，但dapr不是服務網格，其中服務網格被定義為網絡的服務網格。與專注于網絡問題的服務網格不同，Dapr專注于提供構建基塊，使開發人員更容易將應用程序構建為微服務。Dapr以開發人員為中心，而服務網格以基礎設施為中心。

在大多數情況下，開發人員不需要意識到他們正在構建的應用程序將部署在包括服務網格在內的環境中，因為服務網格會攔截網絡流量。服務網格主要由系統操作員管理和部署。但是，Dapr構建塊API旨在供開發人員在其代碼中明確使用。

Dapr與服務網格共享的一些常見功能包括：

• 使用mTLS加密實現安全的服務到服務通信

• 服務到服務指標集合

• 服務到服務分布式跟蹤

• 通過重試獲得可恢復能力

重要的是，Dapr通過以開發人員為中心的關注點提供服務發現和調用。這意味著，通過Dapr的服務調用API，開發人員在服務名稱上調用一種方法，而服務網格則處理網絡概念，如IP和DNS地址。但是，Dapr不為路由或流量拆分等流量行為提供功能。流量路由通常使用應用程序的入口代理處理，并且不必使用服務網格。此外，Dapr還為狀態管理、發布/訂閱、Actor等提供了其他應用級別的構建塊。

Dapr和服務網之間的另一個區別是可觀察性（跟蹤和指標）。服務網格在網絡級別運行，并跟蹤服務之間的網絡調用。Dapr通過服務調用來達到此操作，但Dapr也使用寫入Cloud Events信封的跟蹤Id在發布/訂閱調用上提供可觀察性（跟蹤和指標）。這意味著Dapr的指標和跟蹤比使用服務到服務調用和發布/訂閱進行通信的應用程序的服務網格更為廣泛。

下圖捕獲Dapr和服務網格提供的重疊功能和獨特功能：

Dapr 三駕馬車

Dapr的設計是典型的分層架構，其核心理念，是利用抽象層來實現應用關注點的分離，用以降低分布式應用的復雜性。

在Dapr的架構中，核心的三個組成部分：API，Building Blocks和Components。

Dapr API

Dapr提供兩種API，HTTP1.1/REST和HTTP2/gRPC，兩者在功能上是對等的。

應用如何能使用到這些分布式能力，這是Dapr最核心的設計，也是dapr應用和非dapr應用最關鍵的區別: dapr利用標準API暴露各種分布式能力。API定義了應用所需的分布式能力。dapr提供兩種API:?HTTP1.1/REST和HTTP2/gRPC，兩者在功能上是等價的。這些API是平臺無關的，或者說是實現無關的，這是dapr能否流行的一個關鍵。

應用只需要按照API規范發起，不管是服務訪問，還是存儲，還是發布消息到隊列里，都是HTTP接口。不管是操作redis還是mysql都是一樣的API。在應用看來，一切所需的能力，都可以用HTTP協議來表示，這些能力的獲取是標準化的，只要應用需要的分布式能力不變，那應用的代碼就不需要改變。

將「分布式原語」映射到HttpAPI上，極大地減少了程序員心智的開銷。在應用代碼中不再需要引入相關的組件調用庫，不需要去封裝組件的具體調用方式，不需要對不同的實現做區分。

另外在用戶應用側，dapr還提供了多種語言的SDK，這些SDK的目的是用更便捷的方式來暴露buildingBlocks的API，用更加語義化的方法調用，來封裝Http/gRPC的調用。

Dapr Building Blocks(構建塊)

翻譯為構建塊，這是Dapr對外提供能力的基本單元，每個構建塊對外提供一種分布式能力。

Dapr對外提供能力的基本單元，是對分布式能力的抽象和歸類，包括以下幾大類:

• service-to-service invocation

• State management

• Publish and subscribe

• Resource bindings

• Actors

• Observability

• Secrets

Dapr目前已有的構建塊和他們提供的能力的簡單描述：

Building Block構建塊是可以從您的代碼中調用的HTTP或gRPC API，并且由一個或多個Dapr組件組成。

構建塊解決了構建彈性微服務應用程序中的常見挑戰，并編纂了最佳實踐和模式。Dapr由一組構建塊組成，并且具有可擴展性以添加新的構建塊。

下圖顯示了構建塊如何公開了可被代碼調用的公共API，并使用組件來實現構建塊的能力。

以下是Dapr提供的構建塊類型:

每個構建塊都是獨立的，這意味著您可以采用其中一個或多個或全部來構建應用。在當前Dapr的初始版本中，提供了以下構建塊：

構建塊描述

服務間調用	彈性的服務間調用能在遠程服務上進行方法調用（包括檢索），無論它們是否位于受支持的托管環境中的。
狀態管理	對于存儲鍵/值對的狀態管理，長時間運行，高可用性，有狀態服務可輕松寫入應用程序中的無狀態服務。狀態存儲是可插拔的，可以包括Azure Cosmos DB，Azure SQL Server，Postgre SQL，AWS Dynamo DB或Redis等。
發布訂閱	發布活動并訂閱主題
資源綁定	帶觸發器的資源綁定通過接收和發送事件到任何外部源（如數據庫、隊列、文件系統等）來進一步構建事件驅動架構，以實現擴展性和彈性。
Actors	一種用于有狀態和無狀態對象的模式，通過方法和狀態的封裝讓并發變得簡單。Dapr在其actor運行時提供了很多能力，包括并發，狀態管理，用于actor激活/停用的生命周期管理，以及喚醒actor的計時器和提醒器。
可觀測性	Dapr可以發出度量，日志和跟蹤以調試和監控Dapr和用戶應用程序。Dapr支持分布式跟蹤，通過使用W3C跟蹤上下文標準和OpenTelemetry發送到不同的監控工具，以方便診斷和服務于生產中的服務間調用。
秘密	Dapr提供秘密管理，并與公有云和本地秘密存儲集成，以檢索秘密，用于應用代碼。

Dapr Components(組件)

組件層，這是Dapr的能力實現層，每個組件都會實現特定構建塊的能力。

Components提供和各種分布式實現的對接，包括自建的，云上的，邊緣等等。

理論上building block可以組合使用任意的components，一個component也可以被不同的building block使用。比如actor和state都會使用state component;另一個例子，service invocation會使用namere solution和middleware component，而且不同的場景下，可以選擇不同的component實現。

Component類型和實現：在實現層面，每一種component類型定義了一系列接口（interface definition），每一種component類型有多種component實現，他們都實現了component類型要求的接口（interface）。

三駕馬車的關系

• Dapr Building Blocks提供“能力”

• Dapr API提供對分布式能力的“抽象”，對外暴露Building Block的能力

• Dapr Components是Building Block能力的具體“實現”

Dapr API如何實現

比如一個電商系統，需要持久化存儲，傳統的做法是，我們要先決策使用什么存儲，mysql或者redis等，我們需要在代碼里引入相應的SDK，編寫各異的實現，未來如果應用想要切換存儲類型，或者從本地存儲遷移到云上，改動非常大。

假設這個系統的特征是讀多寫少，那我們傾向于用樂觀鎖來更新數據。業務提出來的「用樂觀鎖控制并發寫入」這就是一個典型的分布式需求，而這種需求的實現在不同的存儲系統中不盡相同，比如mysql是需要用戶顯式指定一個字段作為版本信息，用戶寫操作是需要把版本信息傳回服務器，而redis樂觀鎖需要用戶指定在redis server端watch某個key。類似的需求還有數據庫一致性，是使用最終一致性還是強一致性，各種存儲實現也不同。

如上圖所示，如果接入使用dapr runtime，應用發起存儲調用非常簡單，不需要在應用代碼里引入redis或者mysql的SDK，也不用關心實際存儲使用是什么通信協議，應用代碼里只需要使用分布式原語和dapr runtime通信，通信的協議是簡單的Http或者gRPC，dapr runtime去實現這些分布式能力。

Dapr 服務發現(Service Invocation)

主要能力：

• 服務發現

• 通信安全

• 失敗重試

• 可觀測性

在kubernetes中使用dapr，dapr會為每個服務生成一個新的service（以-dapr結尾），sidecar之間的通信都是gRPC，每個應用需要指定一個app-id用于服務發現，應用需要顯示的發起對runtimeAPI的調用，沒有類似mesh的iptables透明攔截。

大家可以腦洞一下，如果dapr這種模式能大規模流行，那市面上大部分RPC是不是都不再需要了，如今大部分RPC雖然各有專長，但是大部分功能都是類似的，服務發現、編解碼、網絡傳輸，有的RPC框架還帶服務治理的能力。大部分能力目前都可以由mesh或者dapr這類runtime來提供，這也是一個明顯的趨勢。

Dapr 狀態管理(State Management)

主要能力：

• CRUD，包括批量操作

• 事務

• 并發：

• first-write-wins、last-write-wins

• 一致性：

• 最終一致、強一致性

• 可插拔（Pluggablestatestores）

State提供一致的鍵值對存儲抽象，這里不包括關系型或者其他類型的存儲?？偟膩碚f，在云原生領域（以kubernetes和etcd為代表），鍵值對存儲的適用范圍更廣。另外相比其他存儲類型，鍵值對存儲引擎的接口抽象更容易實現，即使是關系型數據庫，也能輕松的實現對鍵值對API的支持。

但仍然不是所有的存儲引擎都能提供等價的鍵值對存儲能力。為了保證應用程序的可移植性，這里的確是需要一些適配工作。比如像Memcached，Cassandra這些是不支持事務的，而很多數據庫也不能提供基于ETag的樂觀鎖能力。

對于并發控制，在API層，Dapr利用HTTP ETags來實現并發控制，類似kubernetes對象的resource version，具體地：Dapr在返回數據時，會帶上Etag屬性。如果用戶需要使用樂觀鎖做更新操作，請求中需要帶回Etag，只有當Etag和服務器上數據的相同時，更新操作才會成功。如果更新操作沒有帶上Etag，那并發模式將是last-write-wins。

Dapr 發布和訂閱(Publish And Subscribe)

使用發布和訂閱模式，微服務間可以充分的解耦。

主要能力：

• 統一的消息格式：

• CloudEvents

• At-Least-Onceguarantees（消息絕不會丟，但可能會重復傳遞）

• 支持消息過期時間（permessageTTL）

• 支持topic可見性配置

Runtime不僅可以做能力的對接適配，還可以做增強，這是一個例子：如果消息組件原生支持消息有效期，那Runtime直接轉發TTL相關操作，過期的行為由組件直接控制，而對于那些不支持消息有效期的組件，Dapr會在Runtime中補齊相關的過期功能。(Cloud Event里有Expiration)

Dapr 綁定(Bindings)

Bindings其實和之前的pub/sub非常類似，也是利用異步通信傳遞消息。它倆主要的區別是：pub/sub主要面向的是dapr內部應用，而bindings主要解決的和外部依賴系統的輸入輸出。

實際上它倆下層的components有很多是重疊的，比如說kafka，redis既可以作為內部消息傳遞，也可以作為外部消息傳遞。pub/sub基本可以等同于消息隊列，但bindings主要是處理事件（trigger handler），比如twitter關鍵字事件，比如github webhooks等。

Dapr 并發模型(Actor)

• 最基本的計算單元，封裝了可以執行的行為和私有狀態

• 通過信箱異步通信

• 內部單線程

• 虛擬的：不需要顯示創建，自動GC

Actor是一種并發編程的模型，Actor表示的是一個最基本的計算單元，封裝了可以執行的行為和私有狀態。actor之間相互隔離，它們并不互相共享內存，也就是說，一個actor能維持一個私有的狀態，并且這個狀態不可能被另一個actor所改變。在actor模型里每個actor都有地址(信箱)，所以它們才能夠相互發送消息。每個actor只能順序地處理消息。單個actor不考慮并發。

Dapr中actor是虛擬的，它們并不一定要常駐內存。它們不需要顯式創建或銷毀。dapr actor runtime在第一次接收到該actor ID的請求時自動激活actor。如果該actor在一段時間內未被使用，那么runtime將回收內存對象。如果以后需要重新啟動，它還將還原actor的一切原有數據。

Actor placement service為系統提供了actor分發和管理，placement會跟蹤actor類型和所有實例的分區，并將這些分區信息同步到每個dapr實例中，并跟蹤他們的創建和銷毀。

Dapr 中間件原則(Middleware Pipelines)

注意middleware pipelines是一個component類型，而不是building block。

Dapr官方提供流量管控的能力比較弱，和istio相比的話，目前dapr只有重試，加密等少數的管控能力，但dapr提供一個擴展的方式：這就是middleware pipelines，用戶可以按需編寫不同的實現，并把他們級聯起來使用。

其實這種方式在各種編程語言web框架中非常常見，只是叫法不同，有的叫裝飾者模型，有的叫洋蔥模型，其實模式都是一樣：請求在路由到用戶代碼之前，會先按序執行middleware pipelines，請求經過應用處理后，再按相反順序執行上述middleware pipeline。通常在前序中對request做相應的增強處理，在后續中對response做增強處理。

咋一看這可能是一個不太起眼的功能，但和傳統web框架的middleware不一樣，dapr runtime本身是在應用進程之外，所以不存在語言限制的問題。這使得middleware提供的功能可以跨語言共享。比如dapr原生沒有提供限流和自定義鑒權的功能（呼聲很高的2個場景），我們可以遵循middleware的接口按需實現，然后植入dapr運行時中。

Dapr 部署模式(托管方式)

Dapr可以托管在多種環境中，包括用于本地開發的自托管，或部署到一組VM、Kubernetes和邊緣環境（如Azure IoT Edge）。

Dapr使用sidecar模式來暴露building blocks的能力，這里的sidecar除了包括sidecar container外，還可以是sidecar process。

在非容器化環境中，用戶應用和dapr runtime都是獨立的進程；而在kubernetes這種容器化環境中，dapr runtime作為sidecar container注入到業務pod中，這和service mesh sidecar模式是一致的。

自托管

在自托管模式下，Dapr作為單獨的sidecar進程運行，服務代碼可以通過HTTP或gRPC調用該進程。在自托管模式下，您還可以將Dapr部署到一組VM上。

Dapr可以配置為在開發人員本地計算機上以自托管模式運行。每個運行的服務都有一個Dapr運行時進程(或sidecar)，配置為使用狀態存儲，pub/sub，綁定組件和其他構建塊。

您可以使用Dapr CLI在本地機器上運行啟用了Dapr的應用程序。

Kubernetes托管

在容器托管環境（如Kubernetes）中，Dapr作為sidecar容器運行，和應用程序容器在同一個pod中。

Dapr可以配置為在任何Kubernetes集群上運行。在Kubernetes中，dapr-sidecar-injector和dapr-operator服務提供一流的集成，以將Dapr作為sidecar容器啟動在與服務容器相同的pod中，并為在集群中部署的Dapr組件提供更新通知。

dapr-sentry服務是一個認證中心，它允許Dapr sidecar實例之間的相互TLS進行安全數據加密。

Dapr 儀表盤(控制面板)

整個控制面還是一個微服務。和istio早期有點類似。

• Sidecarinjector：利用kubernetes mutating webhook給業務pod注入dapr runtime sidecar容器，以及運行所需的環境變量，啟動參數等。包括連接控制面operator的地址（control-plane-address）等。

• Operator：會list watch用戶定義的Component資源，并下發給數據面的dapr runtime。數據面runtime會持有一個Operator Client去連接控制面Operator。

• Sentry: 為dapr系統中的工作負載提供基于mtls的安全通信。mtls能強制通信雙方進行身份認證，同時在認證之后保證通信都走加密通道。Sentry的功能很類似istio里的Citadel（目前已經合并到istiod）。在整個過程中，sentry充當證書頒發機構（CA），處理dapr sidecar發起的簽署證書請求，另外還要負責證書的輪轉。除了dapr sidecar之間的自動mTLS之外，sidecar和dapr控制面服務之間也是強制性的mTLS。

• Placement：用于跟蹤actor的類型和實例分布，并同步給數據面的runtime。

• Dapr Dashboard

Dapr Dashboard是一個WebUI，可幫助您可視化本地計算機或Kubernetes上運行的Dapr實例的信息。

Dapr 性能

sidecar模式會帶來額外的性能開銷。以我們使用service mesh的經驗來看，這種模式的性能開銷主要是2個方面，一個是流量經過sidecar的攔截、流量管控和轉發損耗，另一個是sidecar需要從控制面同步管理數據，sidecar需要存儲和處理這些數據，這可能會給數據面內存和CPU帶來壓力，特別是大規模場景下。

在官方對daprV1.0的性能測試數據看:在不開啟mtls和遙測的情況下，延遲P90大概增加1.4ms，在開啟mtls和0.1 tracingrate情況下，P90數據大概還會增加了3ms左右。

這個數據要比istio好，dapr sidecar沒有太多的流量管控和修改的功能，也沒有使用iptables攔截，開銷相對較小。為了盡可能提高通信效率，dapr sidecar之間的通信固定使用gRPC協議。而且dapr從數據面同步的數據量也非常少，所以也不會有類似istio場景下頻繁reload xDS的問題。

但相比service mesh，dapr sidecar管控了更多的流量類型，比如狀態存儲，應用系統對這類流量的延遲變化更加敏感，用戶在接入dapr之前需要慎重評估。

Dapr 開發工具支持

DotNet Core SDK

雖然Dapr獨立于任何編程語言，但它可以輕松地集成到具有特定語言的SDK應用程序中。隨著我們看到越來越多的開發人員使用Dapr，我們對這些SDK的投資已增加，以幫助簡化Dapr集成。Dapr為Java、Python、PHP、.NET、Go以及最近添加的Rust和C++提供SDK。此外，根據社區反饋，Java SDK中增加了許多改進，包括虛擬角色、鍵入類和與Spring Boot Web框架的集成。對于.NET，還改進了類型類別，并與ASP.NET核心Web框架集成。作為未來路線圖的一部分，計劃為其他SDK提供類似的支持。

• Dapr SDK for .NET

• dapr.io by Nuget

Visual Studio Code擴展

能夠在沒有任何云依賴的情況下開發本地機器上的應用程序，這對生產力和成本非常重要，也是Dapr的關鍵目標。Dapr視覺工作室代碼（VS代碼）預覽擴展可幫助開發人員使用Dapr調試應用程序，與Dapr運行時間進行交互，并與DaprCLI合并。

• Dapr for Visual Studio Code

Dapr 入門教程(阿里知行動手實驗室)

十分鐘快速領略開源分布式運行時Dapr應用的開發、部署過程

https://start.aliyun.com/course?id=gImrX5Aj

參考

• https://dapr.io/

• https://cloudevents.io/

• Announcing Dapr v1.0

• 云原生社區 Dapr 特別興趣小組

• The Cloud Native Computing Foundation (CNCF)

• CNCF Cloud Native Definition v1.0

• 分布式應用程序運行時介紹

• Dapr微服務應用開發系列0：概述

• Software Architecture and Design InfoQ Trends Report—April 2020

• 構建塊

• https://github.com/dapr/dashboard

• Dapr for Visual Studio Code (Preview)

• Dapr | 云原生的抽象與實現

• 一年增加1.2w星，Dapr能否引領云原生中間件的未來？

• 自發布以來，分布式應用程序運行時間 （Dapr） 是如何增長的

• https://www.algolia.com/ref/docsearch/

• Hugo

• Docsy

• Dapr 入門教程

• Multi-Runtime Microservices Architecture

• Multi-Runtime Microservices Architecture

相關文章：

• Dapr能否引領云原生中間件的未來？
  

• 云原生 | 阿里巴巴的Dapr實踐與探索

• Dapr | 云原生的抽象與實現

• Dapr 可視化指南

• Dapr 知多少 | 分布式應用運行時

• Dapr 正式發布 1.0

• Dapr 交通流量控制示例

• Dapr是如何簡化微服務的開發和部署

• 微軟開源微服務運行時Dapr，賦能云原生應用開發

• YARP實現Dapr服務調用的反向代理

• Dapr微服務應用開發系列0：概述

• Dapr微服務應用開發系列1：環境配置

• Dapr微服務應用開發系列2：Hello World與SDK初接觸

• Dapr微服務應用開發系列3：服務調用構件塊

• Dapr微服務應用開發系列4：狀態管理構件塊

• Dapr微服務應用開發系列5：發布訂閱構建塊

• Windows環境下Dapr入門

• 云原生 | .NET 5 with Dapr 初體驗

• 通過Dapr實現一個簡單的基于.net的微服務電商系統

• 通過Dapr實現一個簡單的基于.net的微服務電商系統(二)——通訊框架講解

• 通過Dapr實現一個簡單的基于.net的微服務電商系統(三)——一步一步教你如何擼Dapr

• 通過Dapr實現一個簡單的基于.net的微服務電商系統(四)——一步一步教你如何擼Dapr之訂閱發布

• 通過Dapr實現一個簡單的基于.net的微服務電商系統(五)——一步一步教你如何擼Dapr之狀態管理

• 通過Dapr實現一個簡單的基于.net的微服務電商系統(六)——一步一步教你如何擼Dapr之Actor服務

• 通過Dapr實現一個簡單的基于.net的微服務電商系統(七)——一步一步教你如何擼Dapr之服務限流

• 通過Dapr實現一個簡單的基于.net的微服務電商系統(八)——一步一步教你如何擼Dapr之鏈路追蹤

• WebAssembly + Dapr = 下一代云原生運行時？

• dapr 應用開發 | 環境配置

總結

以上是生活随笔為你收集整理的乘风破浪，.Net Core遇见Dapr，为云原生而生的分布式应用运行时的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。