Dapr实际上是把分布式系统与微服务架构实践的挑战以及k8s 这三个主题的全方位的设计组合，特别是《Kubernetes设计模式》一书作者Bilgin Ibryam提出的Multi-Runtime Microservices Architecture这一概念。
分布式系统 和微服务架构实践的核心问题就是要解决系统复杂性这个难题，降低复杂性的通常做法就是分而治之，Dapr的最核心的设计就是Sidecar Pattern + Building Block，如下图：
Kubernetes 託管的側車架構
Sidecar Pattern: 通过职责分离与容器的隔离特性，降低应用程式的复杂度。
Building Block: 类似于乐高搭积木方法，通过Dapr 提供的核心组件(Component)，分离与抽象化系统架构。
Dapr 设计上几乎和Bilgin Ibryam 提出的Multi-Runtime Microservices Architecture 不谋而合，它有几个核心的设计点：
- Sidecar
- Building Block & Component
- Service Invocation
- Middleware
- State
基于上面的这些核心设计，Dapr 有了多运行时微服务架构 的特性，以此延伸出底下的重要功能，或者说设计模式：
- Security
- Observability: tracing, metrics, logs and health
- Pub / Sub / Batch Process
- Actors
- Secret Management
- Config Management
- Sidecar
Sidecar是非常重要的云计算设计模式，下面这张图是 Sidecar 与Microservice 之间搭配后形成多个服务的关系图，这样的结构形成了服务网格的概念， Dapr 通过配置的方式，动态生成Sidecar ，随后伴随着App，一组Dapr Sidecar + App 的组合称为Dapr App
服务网格
Dapr App 在K8s 里面的形态就是 Pod = (App_Container + Sidecar_Container)
Kubernetes 托管的 sidecar 体系结构
同样的概念，如果Dapr App跑在k8s外面，也就是自承载模式。 在自承载模式下，微服务和 Dapr sidecar 在没有容器业务流程协调程序（如 Kubernetes）的单独本地进程中运行。
自承载 sidecar 体系结构
每个Dapr App 都通过Sidecar 沟通，在通信之前，Dapr App 要知道的是对方在哪？所以服务发现和服务调用是Dapr App 要解决的第一个问题，知道彼此在哪了，然后就是通信模式，Dapr 支持HTTP / gRPC 两种通信模式。 Dapr App 之间的默认的通信模式使用gRPC，也就是如果使用HTTP调用Dapr API，内部服务之间的通信也会转成gRPC。
gRPC 是一种新式的高性能框架，它通过 RPC (远程过程调用) 改进。 gRPC 使用 HTTP/2 作为传输协议，该协议通过 HTTP RESTFul 服务提供显著的性能增强，包括：
对通过同一连接发送多个并行请求的多路复用支持 - HTTP 1.1 将处理限制为一次处理一个请求/响应消息。
双向全双工通信，用于同时发送客户端请求和服务器响应。
内置流式处理，支持对大型数据集进行异步流式处理的请求和响应。
若要了解有关详细信息，请查看适用于 Azure 电子书的.NET Cloud-Native中的 gRPC概述。
Dapr Sidecar 有了服务调用、服务发现和通信模式之后，定义出来了一个Building Block （构建块）的概念，使用声明的方式，定义多个组件Component 扩展Sidecar的能力，这些能力正是分布式系统需要面对的问题。
