-
Istio 0.2：Mesh Expansion
-
Istio 1.1：ServiceEntry
-
Istio 1.6：WorkloadEntry
-
Istio 1.8：WorkloadGroup 和智能 DNS 代理
-
Istio 1.9：虚拟机集成
-
Istio 1.5：控制平面单体化，合并多个组件为 istiod（这是 Istio 开源以来最大的一次架构调整之一）。
-
Istio 1.7：主推 Operator 安装方式，增强 istioctl 工具，支持在 Sidecar 启动之后再启动应用容器。
-
Istio 1.8：改善升级和安装, 引入 istioctl bug-report
Istio 1.8：正式移除 Mixer，在 Envoy 基于 wasm 重新实现 Mixer 功能 （Istio 最大的架构调整之一）Istio 1.9：远程获取和加载 wasm 模块。
5）外部集成和非 service mesh 体系的相互访问，实现应用在两个体系之间的平滑迁移。
-
Istio 曾计划通过 MCP 协议提供统一的解决方案。
-
Istio 1.7：MCP 协议被废弃，改为 mcp over xds。
-
Istio 1.9：Kubernetes Service API 支持 (alpha)，对外暴露服务。
从上面列出的内容，可以看到 Istio 在最近一两年间还是在非常努力地完善自身，虽然过程有些曲折和往复（比如顽固不化的坚持 Mixer 到最后听从全社区的呼唤彻底废弃了 Mixer，开始支持虚拟机后来实质性放弃再到最近重新重视，引入 Galley 再废弃 Galley，引入 MCP 再变相放弃 MCP），但整体上说 Istio 还是在朝 Product Ready 的大方向在努力。
备注：当然，社区对 Istio 的演进速度以及 Product Ready 的实际状态还是很不满意的，以至于出现了这个梗：Make Istio Product Ready (Again, and Again…)。
4. Service Mesh 回顾总结
我们前面快速回顾了 Service Mesh 的定义、Sidecar 模式的原理，以及粗略罗列了一下最近一两年间 Service Mesh 的发展趋势，主要是为了告知大家这样一个信息：
虽然 Service Mesh 蓬勃发展，但核心元素始终未变。
从 2016 年 linkerd 的 CEO William Morgon 给出 Service Mesh 的定义，到 2021 年 Istio 都发布到了 1.9 版本，整整六年期间，Service Mesh 有了很多的变化，但以下三个核心元素始终未变：
-
定位：Service Mesh 的定位始终是提供 服务间通讯 的基础设施层，范围包括 HTTP 和 RPC——支持 HTTP1.1/REST，支持 HTTP2/gRPC，支持 TCP 协议。也有一些小的尝试如对 Redis 、 Kafka 的支持。
-
部署：Service Mesh 支持 Kubernetes 和虚拟机，但都是采用 Sidecar 模式部署，没有采用其他方式如 Node 部署、中心化部署。
-
原理：Service Mesh 的工作原理是 原协议转发，原则上不改变协议内容（通常只是 header 有些小改动）。为了达到零侵入的目标，还引入了 iptables 等流量劫持技术。
演进：云原生分布式应用运行时
===================================================================================
在快速完成 Service Mesh 的回顾之后，我们开始本文第二部分的内容：当 Sidecar 模式进一步推广，上述三个核心元素发生变化时，Sidecar 模式将会如何演进？
1. 实践：更多 Mesh 形态
我之前在蚂蚁金服的中间件团队做 Service Mesh 相关的内容，可能很多朋友是从那个时候开始认识我。当时蚂蚁不仅仅做了 Service Mesh，还将 Service Mesh 的 Sidecar 模式推广到其他的中间件领域，陆陆续续探索了更多的 mesh 形态：
这个图片摘录自我在 2019 年 10 月的上海 QCon 上做的主题演讲 “诗和远方：蚂蚁金服 Service Mesh 深度实践”，当时我们分享了包括消息 Mesh、数据库 Mesh 等在内的多种 mesh 形态。
2. 理论升华：Multi-Runtime 理念的提出
最近有越来越多的项目开始引入 Sidecar 模式， Sidecar 模式也逐渐被大家认可和接受。就在 2020 年，Bilgin Ibryam 提出了 Multi-Runtime 的理念，对基于 Sidecar 模式的各种产品形态进行了实践总结和理论升华。
首先我们介绍一下 Bilgin Ibryam 同学，他是《Kubernetes Patterns》一书的作者，Apache Camel 项目的 committer，目前工作于 Red Hat 。
2020 年初，Bilgin Ibryam 发表文章 “Multi-Runtime Microservices Architecture” ，正式提出了多运行时微服务架构（别名 Mecha/ 机甲，非常帅气的名字）。在这篇文章中，Bilgin Ibryam 首先总结了分布式应用存在的四大类需求，作为 Multi-Runtime 的理论出发点：
这四大类需求中，生命周期管理类的需求主要是通过 PaaS 平台如 kubernetes 来满足，而 Service Mesh 提供的主要是网络中的点对点通讯，对于其他通讯模式典型如 pub-sub 的消息通讯模式并没有覆盖到，此外状态类和绑定类的需求大多都和 Service Mesh 关系不大。
Multi-Runtime 的理论推导大体是这样的——基于上述四大类需求，如果效仿 Service Mesh，从传统中间件模式开始，那么大体会有下面两个步骤：
-
步骤一：将应用需要的分布式能力外移到各种 runtime，此时会出现数量众多的各种 Sidecar 或者 proxy，如上面中列出来的 Istio、Knative、Cloudstate、Camel、Dapr 等。
-
步骤二：这些 runtime 会逐渐整合，只保留少量甚至只有一两个 runtime。这种提供多种分布式能力的 runtime 也被称为 Mecha。
步骤二完成后，每个微服务就会由至少一个 Mecha Runtime 和应用 Runtime 共同组成，也就是每个微服务都会有多个（至少两个）runtime，这也就是 Multi-Runtime / Mecha 名字的由来。
3. Multi-Runtime 和云原生分布式应用
将 Multi-Runtime / Mecha 的理念引入到云原生分布式应用的方式：
-
能力：Mecha 是通用的，高度可配置的，可重用的组件，提供分布式原语作为现成的能力。
-
部署：Mecha 可以与单个 Micrologic 组件一起部署（Sidecar 模式），也可以部署为多个共享（如 Node 模式）。
-
协议：Mecha 不对 Micrologic 运行时做任何假设。它与使用开放协议和格式（如 HTTP/gRPC，JSON，Protobuf，CloudEvents）的多语言微服务甚至单体一起使用。
-
配置：Mecha 以简单的文本格式（例如 YAML，JSON）声明式地配置，指示要启用的功能以及如何将其绑定到 Micrologic 端点。
-
整合：与其依靠多个代理来实现不同的目的（例如网络代理，缓存代理，绑定代理），不如使用一个 Mecha 提供所有这些能力。
4. Multi-Runtime 的特点和差异
虽然同为 Sidecar 模式，但是和 Service Mesh 相比，Multi-Runtime 有自身的特点：
-
提供能力的方式和范围：Multi-Runtime 提供的是分布式能力，体现为应用需要的各种分布式原语，并不局限于单纯的服务间点对点通讯的网络代理.
-
Runtime 部署的方式：Multi-Runtime 的部署模型，不局限于 Sidecar 模式，Node 模式在某些场景下（如 Edge/IoT，Serverless FaaS）可能会是更好的选择。
-
和 App 的交互方式：Multi-Runtime 和应用之间的交互是开放而有 API 标准的，Runtime 和 Micrologic 之间的“协议”体现在 API 上，而不是原生的 TCP 通讯协议。另外 Multi-Runtime 不要求无侵入，还会提供各种语言的 SDK 以简化开发。
Multi-Runtime 和 Service Mesh 的差异总结如下图所示：
5. Multi-Runtime 的本质
至此我介绍了 Multi-Runtime 架构的由来，相信读者对 Multi-Runtime 的特点以及和 Service Mesh 的差异已经有所了解。为了加深大家的理解，我来进一步分享一下我个人对 Multi-Runtime 的感悟：
Multi-Runtime 的本质是面向云原生应用的分布式能力抽象层。
何为 “分布式能力抽象层”?
如上图所示，左侧是分布式应用存在的四大类需求：生命周期、网络、状态、绑定。从需求上说 Multi-Runtime 要为分布式应用提供这四大类需求下所列出的各种具体的分布式能力。以 Sidecar 模式为应用提供这些能力容易理解，但关键在于 Multi-Runtime 提供这些能力的方式。和 Service Mesh 采用原协议转发不同，Multi-Runtime 的方式是：
-
将能力抽象为 API：很多分布式能力没有类似 HTTP 这种业界通用的协议，因此 Multi-Runtime 的实现方式是将这些能力抽象为和通讯协议无关的 API，只用于描述应用对分布式能力的需求和意图，尽量避免和某个实现绑定。
-
为每种能力提供多种实现：Multi-Runtime 中的能力一般都提供有多种实现，包括开源产品和公有云商业产品。
-
开发时：这里我们引入一个“面对能力编程”的概念，类似于编程语言中的“不要面对实现编程，要面向接口编程”。Multi-Runtime 中提倡面向“能力（Capability）”编程，即应用开发者面向的应该是已经抽象好的分布式能力原语，而不是底层提供这些能力的具体实现。
-
运行时：通过配置在运行时选择具体实现，不影响抽象层 API 的定义，也不影响遵循“面对能力编程”原则而开发完成的应用。
备注：分布式能力的通用标准 API，将会是 Multi-Runtime 成败的关键，Dapr 的 API 在设计和实践中也遇到很大的挑战。关于这个话题，我稍后将单独写文章来阐述和分析。
介绍：分布式应用运行时 Dapr
=====================================================================================
在快速回顾 Service Mesh 和详细介绍 multi-runtime 架构之后，我们已经为了解 Dapr 奠定了良好的基础。现在终于可以开始本文的正式聂荣，让我们一起来了解 Dapr 项目。
1. 什么是 Dapr？
Dapr 是一个开源项目，由微软发起，下面是来自 Dapr 官方网站的权威介绍：
Dapr is a portable, event-> driven runtime that makes it easy for any developer to build resilient, stateless and stateful applications that run on the cloud and edge and embraces the diversity of languages and developer frameworks. Dapr 是一个可移植的、事件驱动的运行时，它使任何开发者都能轻松地构建运行在云和边缘的弹性、无状态和有状态的应用程序，并拥抱语言和开发者框架的多样性。
参考并对照 Service Mesh 的定义，我们对上述 Dapr 定义的分析如下：
-
定位：Dapr 将自身定义为运行时（runtime），而不是 Service Mesh 中的 proxy。
-
功能：Dapr 为应用提供各种分布式能力，以简化应用的开发。上面定义中提及的关键点有弹性、支持有状态和无状态、事件驱动。
-
多语言：对多语言的支持是 Sidecar 模型的天然优势，Dapr 也不例外，考虑到 Dapr 为应用提交的分布式能力的数量，这可能比 Service Mesh 只提供服务间通讯能力对应用的价值更高。而且由于 Dapr 语言 SDK 的存在，Dapr 可以非常方便的和各编程语言的主流开发框架集成，如 Java 下和 Spring 框架集成。
-
可移植性：Dapr 适用的场景包括各种云（公有云，私有云，混合云）和边缘网络，Multi-Runtime 架构的几个关键特性如"面向能力编程"、标准 API、可运行时配置实现等为 Dapr 带来了绝佳的跨云跨平台的可移植性。
我们将在后面的介绍中详细展开 Dapr 的这些特性。在开始之前，这里有一个小小的花絮—— “Dapr” 项目名字的由来：
2. Dapr Sidecar 的功能和架构
和 Service Mesh 类似，Dapr 同样基于 Sidecar 模式，但提供的功能和使用场景要比 Service Mesh 的复杂多，如下图所示：
Dapr 的 Sidecar，除了可以和 Service Mesh 一样支持服务间通讯（目前支持 HTTP1.1/REST 协议和 gRPC 协议外，还可以支持到更多的功能，如 state（状态管理）、pub-sub（消息通讯），resource binding（资源绑定，包括输入和输出）。
每个功能都有多种实现，在上图中我简单摘录了这几个能力的常见实现，可以看到实现中既有开源产品，也有公有云的商业产品。注意这只是目前 Dapr 实现中的一小部分，目前各种实现（在 Dapr 中被称为组件，我们下面会介绍）已经有超过 70 个，而且还在不断的增加中。
在 Dapr 的架构中，有三个主要组成部分：API、Building Blocks 和 Components，如下图所示：
-
Dapr API：Dapr 提供两种 API，HTTP1.1/REST 和 HTTP2/gRPC，两者在功能上是对等的。
-
Dapr Building Blocks：翻译为构建块，这是 Dapr 对外提供能力的基本单元，每个构建块对外提供一种分布式能力。
-
Dapr components：组件层，这是 Dapr 的能力实现层，每个组件都会实现特定构建块的能力。
为了帮助大家理解 Dapr 的架构，我们回顾一下前面重点阐述的 Multi-Runtime 的本质：
Multi-Runtime 的本质是面向云原生应用的分布式能力抽象层。
结合 Multi-Runtime 理念，我们再来理解 Dapr Runtime 的架构：
-
Dapr Building Blocks 提供“能力”。
-
Dapr API 提供对分布式能力的“抽象”，对外暴露 Building Block 的能力。
-
Dapr Components 是 Building Block 能力的具体“实现”。
3. Dapr 的愿景和现有能力
下图来自 Dapr 官方，比较完善地概括了 Dapr 的能力和层次架构：
-
居中蓝色的是 Dapr Runtime：这里列出了 Dapr 目前已经提供的构建块。
-
Dapr Runtime 对外通过远程调用提供能力，目前有 HTTP API 和 gRPC API。
-
由于 Sidecar 模式的天然优势，Dapr 支持各种编程语言，而且 Dapr 官方为主流语言（典型如 Java、golang、c++、nodejs、.net、python）提供了 SDK。这些 SDK 封装了通过 HTTP API 或者 gRPC API 和 Dapr Runtime 进行交互的能力。
-
最下方是可以支持 Dapr 的云平台或者边缘网络，由于每个能力都可以由不同的组件来完成，因此理论上只要 Dapr 的支持做的足够完善，就可以实现在任何平台上，总是能找到基于开源产品或者基于云厂商商业化产品的可用组件。
结合以上几点，Dapr 提出了这样一个愿景：
Any language, any framework, anywhere
即：可以使用任意编程语言开发，可以和任意框架集成，可以部署在任意平台。下图是 Dapr 目前已有的构建块和他们提供的能力的简单描述：
4. Dapr 的控制平面
和 Service Mesh 的架构类似，Dapr 也有控制平面的概念：
Dapr 的控制平面组件有：
-
Dapr Actor Placement
-
Dapr Sidecar Injector
-
Dapr Sentry
-
Dapr Operator
比较有意思的是：Istio 为了简化运维，已经将微服务架构的控制平面进行了合并，控制平面回归到传统的单体模式。而 Dapr 的控制平面目前还是微服务架构，不知道未来会不会效仿 Istio。
备注：出于控制篇幅的考虑，本文不对 Dapr 的构建块和控制平面进行详细展开，稍后预计会另有单独文章做详细介绍，对 Dapr 有兴趣的同学可以关注。
5. Dapr 的发展历程和阿里巴巴的参与
Dapr 是一个非常新的开源项目，发展至今也才大约一年半的时间，不过社区关注度还不错（主要是国外），在 GitHub 上目前有接近 12000 颗星（类比：Envoy 16000，Istio 26000，linkerd 7000）。Dapr 项目的主要里程碑是：
-
2019 年 10 月：微软在 GitHub 上开源了 Dapr，发布 0.1.0 版本。
-
2021 年 2 月：Dapr v1.0 版本发布。
阿里巴巴深度参与 Dapr 项目，不仅仅以终端用户的身份成为 Dapr 的早起采用者，也通过全面参与 Dapr 的开源开发和代码贡献成为目前 Dapr 项目中的主要贡献公司之一，仅次于微软：
-
2020 年中：阿里巴巴开始参与 Dapr 项目，在内部试用功能并进行代码开发。
-
2020 年底：阿里巴巴内部小规模试点 Dapr，目前已经十几个应用在使用 Dapr 。
备注：关于 Dapr 在阿里巴巴的实践，请参阅我们刚刚发表在 Dapr 官方博客上的文章 “How Alibaba is using Dapr”。
目前我们已经有两位 Dapr Committer 和一位 Dapr Maintainer，在 2021 年预计我们会在 Dapr 项目上有更多的投入，包括更多的开源代码贡献和落地实践，身体力行的推动 Dap
《一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义》
【docs.qq.com/doc/DSmxTbFJ1cmN1R2dB】 完整内容开源分享
r 项目的发展。欢迎更多的国内贡献者和国内公司一起加入到 Dapr 社区。
6. Dapr 快速体验
在 Dapr 的官方文档中提供了 Dapr 安装和 quickstudy 的内容，可以帮助大家快速的安装和体验 Dapr 的能力和使用方式。
为了更加快捷和方便的体验 Dapr，我们通过 阿里云知行动手实验室 提供了一个超级简单的 Dapr 入门教程，只要大约十分钟就可以快速体验 Dapr 的开发、部署过程：https://start.aliyun.com/course?id=gImrX5Aj。
有兴趣的同学可以实际体验一下。
展望：应用和中间件的未来形态
===================================================================================
在本文的最后部分，我们展望一下应用和中间的未来形态。
1. 云原生的时代背景
首先要申明的是，我们阐述的所有这些内容，都是基于一个大的前提：云原生。
下面这张图片，摘录自我在 2019 年 10 月 QCon 大会上的演讲 “诗和远方：蚂蚁金服 Service Mesh 深度实践” :
当时（2019 年）我们刚完成了 Kubernetes 和 Service Mesh 的探索和大规模落地，并开始 Serverless 的新探索，我在文中做了一个云原生落地总结和是否采纳 Service Mesh 的建议，大体可以概括为（直接援引原文）：
-
有一点我们是非常明确的：Mesh 化是云原生落地的关键步骤。
-
如果云原生是你的诗和远方，那么 Service Mesh 就是必由之路。
-
Kubernetes / Service Mesh / Serverless 是当下云原生落地实践的三驾马车，相辅相成，相得益彰。
两年之后的今天，回顾当时对云原生发展战略大方向的判断，感触良多。上面这张图片我稍加调整，增加了 Multi-Runtime/ 容器 / 多云 / 混合云的内容，修改如下图：
