拔插网站

背景

大体从2015年开始，我与团队对所负责的一个电商系统启动架构改造大手术。当时改造的第一初衷其实是在全球分布式团队协作模式下，如何实现各地团队自治性问题。首先提一句这个电商系统主要聚焦在公司XaaS软件产品的在线试用、报价、订单、服务开通、计量、计费、账单、发票等业务领域，并非我们所熟悉的亚马逊、京东、淘宝等实体商品电子商务交易。提到现代化改造相信大家脑海中闪现的一定是类似微服务、容器化、上云、Kubernetes，服务网格、无服务器化、基础设施即代码、gitOps等词汇。我们也毫不意外的经历了这么一个过程：从单体架构使用领域驱动方法进行微服务化改造，上云（最初还主要是CloudFoundry），到后来持续的演进到容器化以及使用Kubernetes、服务网格、函数计算等等。

在这样的一个演进过程中，有采纳新技术后看到实际业务价值的兴奋，也有对技术碎片化发展的迷茫。于是乎想把自己在这个过程中的一些感受写下来。从哪里开始呢，既然分布式架构现在已成主流架构风格，那就从分布式（不考虑过去的SOA架构，故这里特指微服务架构）开始吧。

虽然说从分布式架构开始，但我不想花笔墨去普及它的基础知识。只想提下分布式架构给我们带来很多价值的同时也让我们经历了不少的挑战。比方说在服务治理方面尤其对于大规模系统，我们不得不投入大量精力去解决服务注册/发现、服务负载均衡、服务配置管理、服务灰度发布、服务容错（超时、重试、熔断）、服务可观测性、服务安全等诸多课题。在这个过程中也诞生了优秀的解决方案比如Netflix开源的系列微服务治理方案，到后来的SpringCloud全家桶、以及这两年堪称当红炸子鸡的服务网格。

机缘巧合之下在2021年时了解到了Dapr这个项目。当时就被它的思想所深深吸引，后来一直持续在关注它的发展至今。今天这篇文章就作为介绍Dapr系列的引子，给大家介绍下这个项目的整体框架。

初识Dapr

Dapr全称是Distributed Application Runtime，即分布式应用运行时。它是由微软在2019年发起的一个开源项目，2021年11月被CNCF接纳目前处于孵化阶段。目前发展到v1.9版本，在GitHub上有20k star，受欢迎程度可见一斑。

Dapr的官方定义是一个可移植的、事件驱动的运行时，它使开发人员能够轻松构建出弹性的、无状态和有状态的应用程序，并可运行在云平台或边缘计算中，它支持多种编程语言和开发框架。

去掉一系列繁琐的定语，我们可以看到Dapr的核心是一个应用运行时。那作为应用运行时，它都提供什么方面的能力呢？我们又为什么需要这样的运行时环境？这还要回到分布式架构带来的挑战说起。

Multi-Runtime理念

Multi-Runtime是由RedHat的架构师Bilgin Ibryam提出。他总结了一个分布式应用存在四大类需求：生命周期、网络、状态、绑定。平时我们大都把这些需求统称为服务治理。

其中生命周期类需求主要包括应用构建打包、部署、健康检查、扩缩容、配置管理等。

网络类需求包括服务注册/发现、灰度发布、服务容错、服务调用、发布/订阅、服务安全、服务可观测性等方面能力。

状态类需求包括服务幂等性、缓存、工作流管理等方面。

绑定类需求则聚焦与链接器、协议转换、消息路由等。

在传统模式下这些能力与业务逻辑基本都是打包在一起，侵入性较大。

为简化业务应用开发，把这些能力外移到各种运行时中去，就基本形成了现代化应用的大体模样：以业务逻辑为核心，各项治理能力下沉形成类似外挂形式发挥作用。

继续将这些多个运行时进行归并整合，便形成被业界称为Mecha-Runtime（来源于阿凡达1中AMP机甲）模式。从形态上来看它跟一些服务网格的Sidecar模式几乎一样，事实上这也一直延伸到了Dapr架构中。

Multi-Runtime可以理解为针对分布式架构下服务治理能力的一个组合。如果我们能够将这些分布式能力进一步泛化形成一个抽象层，比方说将各种能力抽象为API，为不同能力提供多种实现，在开发时面向能力（接口）编程而在运行时通过配置选择不同实现，这个听上去是不是有点炫酷？这就是Dapr的思想，而且Dapr也是业界第一个Multi-Runtime实践项目。

解构Dapr

首先我们来看下Dapr的整体架构，大体分为三层：业务逻辑层、Dapr构建块层、基础设施层。

我们可以看到Dapr 将构建分布式应用的最佳实践设计成开放、独立和模块化的方式，让开发者能够使用任意开发语言和框架构建可移植的应用程序。 每个构建块都是完全独立，可以采用其中一个、多个或全部来构建应用。它是平台无关的，可以运行在本地、Kubernetes以及各种主流云平台中。从架构设计的角度看，如下图所示Dapr 的精髓在于：通过抽象/隔离/可替换，解耦能力和实现，从而实现可移植性。

Dapr倡导面向能力编程即：

• Dapr API 提供了对分布式能力的抽象，并提取为标准API
• Dapr 的 Runtime 隔离 应用和底层组件的具体实现

进一步打开来看Dapr的核心，也就是它的构建块层。一个构建块是在我们代码中可以通过HTTP或gRPC调用的一组API，一个构建块由若干组件组成实现它的能力。

下表详细介绍了Dapr原生提供的9大构建块：

Dapr采用组件化设计，每个构建块的能力都是由组件来承载实现。每个组件有接口定义， 所有组件都是可插拔的，因此可以将组件换为另一个具有相同接口的组件。比方说状态构建块中，Dapr提供了面向Redis的组件、面向MemCache的组件。这些组件对外接口使用统一化缓存接口，这也就赋予了开发者无缝迁移缓存实现方案的能力。在需要时也可以通过 components contrib repo 为组件接口贡献实现并扩展 Dapr 功能。而Dapr 可移植性的基石就在于标准API + 可拔插可替换的组件。

下图展示了Dapr目前支持的组件：

每一个组件定义都需要遵从如下格式规范：

在调用Dapr API时可以通过下发策略方式配置服务容错、检查检查、可观测性能力，比如超时、重试、熔断、链路跟踪等。

在运行态，Dapr表现为一个被命名为daprd的独立进程，它对外暴露了三组API：

构建块API：被业务逻辑代码调用来使用各种分布式能力。

元数据API：通过此类API可以获取加载的组件、类型、支持的特性等。

健康检查API：检测sidecar健康、liveness、readiness状态等

Dapr采用sidecar模式暴露能力，这使得它成为一种对应用无侵入的解决方案，注意看以下几个示例调用中的端点。

在Kubernetes环境下，Dapr以附属容器形式和应用容器运行在同一pod中，熟悉服务网格的同学对这种模式应该不会陌生。Dapr提供了对各种构建块能力的抽象和屏蔽。

Dapr与服务网格

从架构形态上来看，Dapr与Istio等服务网格方案极为类似。而且事实上Dapr与服务网格存在一定的能力交集，但Dapr并不是一种服务网格实现。服务网格在定位上是处理服务间通讯的基础设施层，它聚焦在网络层面，在大部分情况是由系统运维人员管理。而Dapr是面向开发者的，目标是通过构建块的方式简化微服务开发。从下图可以清晰看到两者在能力方面的不同定位：

后续

到这里我们只是简单认识了Dapr的整体框架，但大都是图文描述偏于理论介绍。Dapr 通过抽象API+构建块的方式，实现了能力和实现的解耦，并给出了一个美好的愿景：在有一个业界普遍认可并遵循的标准化API的基础上，用户可以自由选择编程语言开发云原生，这些云原生可以在不同的平台上运行，不被厂商和平台限制——终极目标是使得云原生应用真正具备跨云跨平台的可移植性。

下一篇让我们从代码出发来看下如果实际使用Dapr！

推荐阅读

期货kdj看几分钟线准(期货短线看几分钟kdj线)

k1620次列车时刻表(k1620次列车途经站点名称)

YEX是什么币？YEX币官网总量和项目详情介绍

2009年比特币网络正式上线运行时间(2009年比特币网络正式上线运行时间表)

欧意交易所区块链怎么做

拔插网站

用友运行时错误9 下标越界(用友429错误)

用友t3记账时出现运行时错误提示

用友u8 错误提示70(用友u8运行时错误440)

用友 运行时错误481 无效图片(用友440错误)