1. Dapr介紹
Dapr 實際是被定義為Distributed Application Runtime（分布式的程序運行時），為開發人員提供一個分布式的程序的開發環境，提供分布式的程序所依賴的功能模塊庫，提供了分布式程序的運行環境，或者說為分布式的程序提供了一套完整運行方案。
Dapr是一個自上而下的框架，也就是說從從頂層開發者運行介面（遠程服務方法調用 pubsub ），到傳輸協議（http grpc），到消息組件， 到基礎設施環境（k8s 本地主機 docker）。這種設計的好處是將開發者作為第一位，先滿足需求而不是創造需求。從解決問題出發到最終實現。本人比較喜歡這種自上而下的理念，在現實中這種理念也相較成功率更高。
Dapr是站在開發者角度設計的，給開發者提供了服務調用，消息隊列，事件驅動的服務模型，並提供需要的狀態存儲，加密數據存儲的基礎服務，使得開發者不用去關心底層基礎設施細節。
Dapr同時支持standalone和基於Kubernetes的模式，想要了解可以從standalone模式開始，standalone相對概念較少，排除Kubernetes復雜概念的干擾。
Dapr實現遠程方法直接調用，實現了事件匯流排非同步處理功能，將兩者集中到一個平台，這就滿足了絕大部分分布式程序的核心需求。
Dapr從使用角度出發，優先實現了程序員所關心的最核心的功能，並沒追究serverless概念的完整實現，如沒有提供從零擴容等類似非核心功能和概念，當然Dapr也是在一個快速開發與擴展階段，一些新的概念和功能會不斷引入，但是肯定是以最核心功能為基點來拓展。
Dapr提供了完備的可觀察性，提供了完備的tracing metrics logs, 方便追蹤問題，支持opentelemetry（opencensus）， 所有支持opentelemetry的tracing工具都可以被接入，opentelemetry目前還在發展階段。
Dapr 採用 mutual authentication TLS 加密安全方式，提供了生產級別的安全性。
Dapr是基於sidecar模式模式， 實際等於給程序提供一個直接的代理，類似於每個web app 前面綁定一個nigix。
Dapr K8S模式利用AdmissionReview AdmissionRequest通過PatchOperation注入Dapr的sidecar。
Dapr沒用採用標準的net/http庫，而是採用fasthttp一個高性能http庫，在性能上有顯著提升。
web session之間是無狀態的，State store components提供了狀態的存儲，類似於web開發中將web session存儲於伺服器端的功能。
Dapr不是service mesh，service mesh是關注於網路服務，Dapr則是為用戶構建microservices提供基礎架構支持，使用戶更方便的構建microservices，是以開發者為中心而不是網路為中心。
Service invocation 實現遠程服務方法的調用，實現類似faas功能，實際提供了服務發現，反向代理的功能。
DaprService invocation 實現了反向代理、負載均衡。
2. gRPC 安全篇-2: 快速實現服務端 JWT 驗證
本文將介紹如何利用rk-boot實現服務端JWT驗證邏輯。
JWT，即JSON網路令牌，是一種Internet標准，用於在兩方之間安全地表示聲明，並可選擇性地使用簽名或加密。通過JWT機制，客戶端可以使用密鑰加密信息，並將其添加到HTTP請求的Header中，服務端則驗證客戶端的合法性。更多關於JWT的信息，可以參考其官網。
許多SAAS服務，如github，都採用了JWT作為用戶驗證方式。
想要獲取完整教程，請訪問以下地址。
rk-boot默認會為gRPC服務開啟grpc-gateway，使得兩個協議監聽同一個埠。因此，無論是gRPC請求還是Restful請求，都可以驗證JWT。
創建boot.yaml文件，這個文件會指導rk-boot如何啟動gRPC服務。
在下面的YAML文件中，我們聲明了三件事：
因此，boot.yaml文件會告訴rk-boot在8080埠啟動gRPC服務，並開啟commonService以及JWT驗證攔截器。
由於我們開啟了commonService，所以不需要額外給gRPC添加API進行驗證。
根據不同的語言，有許多開源庫可以幫助我們創建JWT Token，更多信息可以參考官網。
為了方便，我們直接從官網創建一個Token，這個Token使用了my-secret作為密鑰，HS256作為演算法，與boot.yaml里的配置一致。
rk-boot提供了若干JWT攔截器選項，除非有特殊需要，通常不推薦覆蓋這些選項。
支持的簽名演算法包括HS256，HS384，HS512，RS256，RS384，RS512，ES256，ES384，ES512，EdDSA。
gRPC只支持從Header里讀取Token，如果是gRPC協議發出的請求，Header就是grpc.metadata。
請參考RFC7515以了解多種signing keys的使用方法。
提供多個signing keys，用:分開Key和Value。
下面的例子中，我們使用了Restful API作為請求例子，這次，我們使用gRPC。
啟動同樣的gRPC服務，這次我們使用grpcurl直接調用gRPC服務。
為了能使用grpcurl，我們需要在boot.yaml中通過enableReflection開啟grpc reflection。