(这期先了解Dapr，之后在推出如何搭建Dapr，以及如何使用。Dapr(二) 分布式应用运行时搭建及服务调用--Dapr(二) 分布式应用运行时搭建及服务调用-CSDN博客)
目录
[Service Mesh定义](#Service Mesh定义)
[Service Mesh解决的痛点](#Service Mesh解决的痛点)
[Service Mesh遇到的挑战](#Service Mesh遇到的挑战)
[Multiple Runtime 理念推导](#Multiple Runtime 理念推导)
[Dapr 介绍](#Dapr 介绍)
[Dapr 特性](#Dapr 特性)
[Dapr 核心模块](#Dapr 核心模块)
[Dapr 核心：Component & Building Block](#Dapr 核心：Component & Building Block)
[Dapr 整体架构](#Dapr 整体架构)
[Dapr 微软落地场景](#Dapr 微软落地场景)
引言：
从 2010 年的时候，SOA 架构就已经在中大型互联网公司中开始流行，阿里也在2012 年开源了 Dubbo 。而之后微服务架构开始流行，大量互联网和传统企业都投身到微服务的建设中。在国内逐渐形成了Dubbo 和 Spring Cloud 两大微服务阵营。在2016 年的时候，微服务领域一个更具有前沿性，更加符合容器和 Kubernetes 的微服务方案正在孕育，这个技术被称为 Service Mesh(服务网格)。时至今日，Service Mesh 理念已经得到了大范围普及，很多公司都在 Service Mesh 领域有了落地。
Service Mesh定义
Service Mesh 是一个基础设施层，主要围绕服务间通信来进行。现在的云原生应用的服务拓扑结构非常复杂，Service Mesh 可以在这种复杂拓扑结构中实现可靠的请求传送。Service Mesh 是以 Sidecar 的方式运行，应用旁边会运行一个独立的 Service Mesh 进程，Service Mesh 负责远程服务的通信。军用三轮摩托车和 Service Mesh 非常相像，军用三轮摩托车上一个士兵负责开车，一个士兵负责对人发起射击。
- 服务注册与发现
- 服务之间调用
- 服务之间降级，熔断
- 服务之间链接追踪
- 服务监控
Service Mesh解决的痛点
传统的微服务架构大都以 RPC 通信框架为基础，在 RPC SDK 中提供了服务注册/发现，服务路由，负载均衡，全链路跟踪等能力。应用业务逻辑和 RPC SDK 在同一个进程中，这种方式给传统微服务架构带了很多挑战：中间件能力相关代码侵入到了业务代码中，耦合性很高；推动 RPC SDK 的升级成本非常高，进而也导致了 SDK 版本分化非常严重。同时这种方式对应用开发者的要求比较高，需要有丰富的服务治理的运维能力，有中间件的背景知识，使用中间件的门槛偏高。
通过 Service Mesh 方式将一些 RPC 的能力进行下沉，这样可以很好的实现关注点分离、职责边界的明确。随着容器和 Kubernetes 技术的发展，Service Mesh 已经成为云原生的基础设施。
Istio介绍
在 Service Mesh 领域中， Istio 毫无疑问是当中的王者。Istio 由控制面和数据面构成，在 Service Mesh 中，不同的 Service 之间，通过 Proxy Sidecar 进行通信。Istio 最核心功能是流量管理，通过数据面和控制面协调完成。Istio 是由 Google 联合IBM，Lyft 一起发起的，是 CNCF 生态版图 Service Mesh 领域的最纯正血统，有望成为Service Mesh事实标准。
Istio 的数据面默认使用 Envoy，Envoy 是社区里默认的最佳数据面。Istio 数据面和控制面的交互协议是 xDS。
Service Mesh小结：
- Service Mesh 定位就是提供服务间通信的基础设施，社区里主要支持 RPC 和http 。
- 采用 Sidecar 方式部署，支持部署在 Kubernetes 和虚拟机之上。
- Service Mesh 采用原协议转发，所以 Service Mesh 也被称为网络代理。正是由于这种方式方式，所以可以做到对应用的零侵入。
Service Mesh遇到的挑战
用户在云上部署业务的形态主要有普通应用类型和FaaS类型。Faas 场景下，比较吸引用户的是成本和研发效率，成本主要通过按需分配和极致的弹性效率来达成。而应用开发者期望通过 FaaS 提供多语言的编程环境，提升研发效率，包括启动时间、发布时间、开发的效率。
Service Mesh 的实现，本质是原协议转发，原协议转发可以给应用带来零侵入的优势。但是原协议转发也带来了一些问题，应用侧中间件SDK还需要去实现序列化和编解码工作，所以在多语言实现方面还有一定成本；随着开源技术的不断发展，使用的技术也在不断迭代，如果想从 Spring Cloud 迁移到 Dubbo ，要么应用开发者需要切换依赖的 SDK，如果想借助Service Mesh来达到这个效果，Service Mesh 需要进行协议转换，成本较高。
Service Mesh 更加聚焦于服务间的通讯，而对其他形态的 Mesh 的支持上非常少。比如 Envoy， 除了在 RPC 领域比较成功外，在 Redis、消息等领域的尝试都未见成效。蚂蚁的 Mosn 中支持了 RPC 和消息的集成。整体多 Mesh 形态的需求是存在的，但是各个 Mesh 产品各自发展，缺少抽象和标准。如此多形态的 Mesh ，是共用一个进程吗？如果是共用一个进程，那么是共用一个端口吗？许多问题都没有答案。而控制面方面，从功能角度来看的话，大都围绕流量来展开。看过 xDS 协议里的内容，核心是围绕发现服务和路由来展开。其他类型的分布式能力，在 Service Mesh的控制面中基本没有涉及，更谈不上抽象各种类似 xDS 的协议去支持这些分布式能力。
因为成本和研发效率等原因，FaaS 受到了越来越多客户的选择，FaaS 对多语言和编程 API 的友好性上有了更多诉求，那么 Service Mesh 在这两块还是不能给客户带来额外的的价值。
分布式应用的需求
Bilgin Ibryam 是 Kubernetes Patterns 的作者，是 RedHat 的首席中间件架构师，在 Apache 社区里非常活跃。他发表了一篇文章对当前分布式的一些困难和问题进行了抽象，将分布式应用需求分成了 4 个大种类：生命周期、网络、状态、绑定。每种类型下面还有一些子能力，如 Point-to-Point， pub/sub， Caching 等比较经典的中间件能力。应用对分布式能力有如此多的需求，而 Service Mesh 显然不能满足应用的当前的需求。Biligin Ibryam 还在文章中提出了 Multiple Runtime 的理念来解决Service Mesh 的困境。
Multiple Runtime 理念推导
在传统的中间件模式下，应用和分布式能力是在一个进程中，以 SDK 方式进行集成。随着各种基础设施下沉，各种分布式能力从应用中移到了应用外。如 K8s 负责了生命周期相关的需求，Istio、Knative 等都负责一些分布式能力。如果将这些能力都移动到独立的 Runtime 中，那么这种情况无论从运维层面还是资源层面来看，都是没办法接受的。所以这时候肯定需要将部分 Runtime 进行整合，最理想的方式肯定是整合成一个。这种方式被定义成 Mecha ，中文意思是机甲的意思，就像日本动漫里主人公变身穿上机甲，机甲的每个部件就像一个分布式能力，机甲里的人对应的是主应用，也叫 Micrologic Runtime 。 这两个 Runtime 可以是一对一的 Sidecar 方式，这种非常适合传统的应用；也可以是多对一的 Node 模式，适合边缘场景或者网管模式下。
那么对于将各种分布式能力进行整合的 Mecha Runtime 这一目标本身问题不大，那么怎么整合呢？对 Mecha 有什么要求呢？
- Mecha 的组件能力是抽象的，任何一个开源产品可以快速进行扩展和集成。
- Mecha 需要有一定的可配置能力，可以通过 yaml/json 进行配置和激活。这些文件格式最好能和主流的云原生方式对齐。
- Mecha 提供标准的 API ，和主应用之间的交互的网络通信基于此 API 来完成，不再是原协议转发，这样对于组件扩展和 SDK 的维护都能带来极大的便利性。
- 分布式能力中的生命周期，可以将部分能力交接过底层的基础设施，比如 K8s。当然有些复杂的场景，可能需要 K8s、APP、Mecha Runtime 一起来完成。
既然最理想只剩下一个 Runtime , 那么为什么还叫 Multiple Runtime 呢？因为应用本身其实也是一个 Runtime ，再加上 Mecha Runtime ，所以至少是两个 Runtime 。
Dapr 介绍
前面的 Multiple Runtime 介绍地比较抽象，可以来从 Dapr 来重新理解下 Multiple Runtime 。Dapr 是 Multiple Runtime 的一个很好的践行者，所以 Dapr 肯定和应用共存的，要么是 Sidecar 模式，要么是 Node 模式。Dapr 这个词其实是不是造出来的，而是 Distributed Application Runtime 的首字母拼接而成，Dapr 这个图标可以看出来是一个帽子，这个帽子其实是一个服务生的帽子，表示的含义是要为应用做好服务。
Dapr 是由微软开源的，阿里巴巴深度参与合作。当前的 Dapr 已经发布多个版本，现在已经接近生产的能力。
既然 Dapr 是 Multiple 的最佳实践者，那么 Dapr 的运行机制也是基于 Mulitple Runtime 的理念来构建的。Dapr 对分布式能力进行了抽象，定义了一套分布式能力的 API，而且这些 API 是基于 Http 和 gRPC 来构建的，这种抽象和能力在 Dapr 中被称为 Building Block；Dapr 为了支持开源产品和商业化等不同类型的产品对 Dapr中的分布式能力进行扩展，内部拥有一套 SPI 扩展机制，这种 SPI 机制叫 Components 。应用开发者在使用 Dapr 之后，只需要针对各种分布式能力的 API 来进行编程，而无需过多关注具体的实现，而 Dapr 中根据 Yaml 文件可以自由激活对应的组件。
Dapr 特性
应用开发者使用各种多语言的 Dapr SDK 就可以直接拥有各种分布式能力。当然开发者也可以自己基于 HTTP 和 gRPC 来完成调用。Dapr 可以运行在大部分环境里，包括你自己电脑的环境，或者任何 Kubernetes 环境下，或者边缘计算场景，或者阿里云、AWS、GCP 等云厂商。
Dapr 社区里已经集成了 70+ 的 components 实现，应用开发者可以快速进行选择和使用。相似能力的组件的替换，可以通过 Dapr 里完成，应用侧可以做到无感知。
Dapr 核心模块
我们从 Dapr 产品模块纬度来解析下，看为什么 Dapr 是 Mulitiple Runtime 的一个很好实践。
Component 机制确保了可以快速扩展能力的实现，现在社区已经有的 Components实现已经有 70 个以上，不只包含开源产品，还包含云上的商业化产品。
Building Block 表示的的分布式能力，现在只支持 7 个，后续需要更多的分布式能力能够进来。BuildingBlock 现在支持了 HTTP 和 gRPC 这两种开放，而且普及度已经非常高的协议。而 Dapr 中 Building Block 下具体那些 Components 会被激活，需要依赖 YAML 文件来进行。正因为 Dapr 中采用了 HTTP、gRPC 的方式暴露能力，所以在应用侧想要支持多语言的标准的API编程界面就变得更为容易了。
Dapr 核心：Component & Building Block
一个 Building Block 由 1 个或多个 Component 组成，Binding的Building Block 包含 Bindings 和 Middleware 两个 Component 。
Dapr 整体架构
Dapr 和 Istio 一样，也有数据面和控制面。控制面有 Actor Placement，Sidecar Injector， Sentry， OPerator。Actor Placement 主要为 Actor 服务，Sentry 做安全和证书相关的工作，Sidecar Injector 主要负责 Dapr Sidecar 的注入。Dapr 里激活某个组件实现是通过 YAML 文件来完成的，YAML 文件可以通过两种方式来指定：一种是本地指定运行时参数，另外一种是通过控制平面 Operator 来完成，将组件激活的文件以 K8s CRD 方式存储并下发到 Dapr的Sidecar 中。控制面的 2 个核心组件都依赖于 K8s 来运行。现在的 Dapr Dashboard 功能还很弱，短期还不到增强的方向，现在各个组件的集成之后，各个组件的运维还需要在原来的控制台里完成，Dapr 控制平面不参与具体组件实现的运维。
Dapr 微软落地场景
Dapr 经历了多年的发展，在微软内部的落地情况是怎么样的呢？
Dapr 的 github 上有两个项目：workflows 和 Azure Functions Dapr extensions。Azure Logic App 是微软的一个基于云上的自动工作流平台。而 Workflows，就是整合了 Azure Logic App 和 Dapr。Azure Logic App 中有几个关键的概念，Trigger 和 Connector 和 Dapr 非常契合。Trigger 可以使用 Dapr 的 Input Binding 来完成，依赖 Dapr 的 Input Binding 的大量组件实现，可以扩大流量入口的类型。而 Connector 和 Dapr 的 Output Binding 或者 Service Invocation 的能力非常匹配，可以快速访问外部资源。Azure Functions Dapr extensions 则是基于Azure Function extension 做的 Dapr 支持，可以让 Azure Function 快速使用上Dapr 的各种 Building Block 的能力，同时能给函数开发者带来多语言的相对简单一致的编程体验。
Azure API Management Service和上面提到的两个落地场景的角度不太一致，它是前提是应用之间已经通过Dapr Sidecar方式进行访问，应用的提供的服务通过Dapr来进行暴露。这时候如果非K8s的应用或者跨集群的应用想要访问当前集群的服务，就需要一个网关，这个网关可以直接暴露Dapr的能力，在网关中会增加一些安全和权限的控制。当前支持3种Building Block：Service Invocation、pub/sub、resource Bindings。
Dapr 小结：
Dapr 提供的面向能力的 API ，能够给开发者带来支持多语言的一致的编程体验，同时这些 API 的SDK相对比较轻量级。这些特性非常适合 FaaS 场景。而随着 Dapr 集成生态的不断完善，开发者面向能力编程的优势将进一步扩大，通过 Dapr 可以更加方便地将 Dapr 组件的实现进行替换，而无需开发者做代码的调整。当然原来的组件和新的组件实现，必须是相同类型的分布式能力。
Dapr 和 Service Mesh 差异点：
提供能力：Service Mesh 专注服务调用；Dapr 提供的分布式能力范围更广，覆盖多种分布式原语。
工作原理：Service Mesh 采用原协议转发做到零侵入；Dapr 采用多语言SDK + 标准API + 各种分布式能力。
面向领域：Service Mesh 对传统微服务的无侵入升级支持很友好；Dapr 对面向应用的开发者提供了更加友好的编程体验。