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。