云效峰会——Dapr在阿里云云原生的实践

Dapr在阿里云原生的实践

作者:曹胜利


内容简要:

一、Service Mesh 快速回顾

二、分布式运行时 Dapr 介绍

三、阿里在 Dapr 上的探索

四、分布式运行时 Dapr 未来展望

一、Service Mesh 快速回顾

(一)Service Mesh 介绍

云效峰会——Dapr在阿里云云原生的实践

2016年开始Service Mesh的理念和一些产品逐渐问世,至今为止已经有许多公司开始实施Service Mesh并取得了一些进展。

Service Mesh是一个基础设施层,用于处理服务间的通信。对于现在的云原生微服务架构,Dapr可以帮屏蔽掉底层的具体技术,提供可靠的请求传送。

Service Mesh通过Sidecar的方式提供服务,Service Mesh的进程和应用进程分属于两个进程,就像军用三轮摩托车有两个人一个人负责行驶,另外一个人负责往外扫射敌人Servier Mesh的角色其实和扫射的角色是非常相近的

传统中间件分布式能力的SDK和应用是部署在一起的但这种方式带来很多问题,第一个问题业务代码和中间件的代码进行了耦合二个问题是中间件SDK的升级非常困难,进而导致了版本的分化非常严重。第三个问题是一位新员工如果进入到一个公司的时候,熟悉中间件的成本比较高,所以Service Mesh可以将这些底层的基础能力进行下沉,下沉到独立的Sidecar中,可以给应用带来关注点的分离,应用只需要关注自己的业务逻辑,而无需关注具体的中间件能力。

(二)Istio 介绍

云效峰会——Dapr在阿里云云原生的实践

Istio毫无疑问是Service Mesh的强者,是由Google IBM和Lyft共同发起创立的,它主要的核心功能是提供流量的管理。

Service A如果想访问service B它需要经过旁边的Proxy Sidecar,然后将请求发送给远端的Proxy Sidecar,然后远端的Proxy Sidecar再将请求发送给Service B。Istio其实是由数据面和控制面来实现的,数据面现在的社区最强者是Envoy

(三)Service Mesh 小结

接下来我对Service Mesh做一个小结。

云效峰会——Dapr在阿里云云原生的实践

Service Mesh的定位是提供服务间的通讯基础设施,主要支持了Http/RPC,而且Service Mesh是通过协议转发的方式对应用提供服务,所以对应用的侵入几乎为

二、分布式运行时 Dapr 介绍

(一)Service Mesh 遇到的挑战

接下来介绍Dapr,随着云技术和云原生技术的发展,云能给业务开发者提供的服务除了应用之外,还有FaaS场景下的一些服务,你只需要提供一个函数或者一个JAR包,就可以在FaaS场景下进行部署。

云效峰会——Dapr在阿里云云原生的实践

FaaS场景下能够给用户带来的好处是成本节约,通过极致的弹性和按需的收费方式来实现。Servier Mesh是通过原协议转发的形式进行实现,但是如果要去实现一个多语言的SDK,它还是需要实现序列化和协议的分装,所以说在多实现这一块还是具有一定的成本。

同时随着开源技术的不断发展,技术在不断引进,假设你们公司如果开始使用了Spring Cloud,现在希望将这个技术切换到gRPC上,这时候就有两种方法能够实现

第一种将应用从依赖Spring Cloud切换到gRPC上,同时业务代码层面也需要做一些变更。另一种方式应用层无需做任何改变,通过Servier Mesh协议转换的方式来完成,Service Mesh接收到Spring Cloud流量之后转换成gRPC然后向外发送请求。

随着Service Mesh的发展,现在越来越多的 Mesh开始出现,像Motion中的Mesh不仅支持RPC,还支持了消息同时蚂蚁还有DB Mesh,是通过C++实现的,所以多Mesh的趋势是很明显的.

但这么多Mesh是怎么共存的?是多进程的方式进行共存,还是单进程多端口的方式,协议又是怎么存在的?同时,像Istio这种Service Mesh对微服务调用之外的支持非常有限,像XDS主要是去支持服务发现路由规则等等。

最后FaaS用户越来越多,FaaS落地的话有一些强诉求,业务开发者希望能够提供多语言更加友好的编程API,但是这一块Service Mesh其实是有缺陷的

(二)、分布式应用的需求

此时,社区里面有一个厉害的人出现了——Bilgin Ibryam

云效峰会——Dapr在阿里云云原生的实践

Bilgin Ibryam是RedHat中间件首席架构师,也是Apache Commit,在Apache社区里面非常活跃,他提出了一个理论,将分布式的能力进行了抽象抽象成了4大种类,包括生命周期、网络状态和绑定。

(三)、Multiple Runtime理念

同时Bilgin Ibryam还提出了一个理念Multiple Runtime,那么这个理念是怎么推导出来的?

云效峰会——Dapr在阿里云云原生的实践

传统的中间件各种分布式能力都在SDK里面,然后和应用部署在同一个进程里面。

随着云原生和基础设施的下沉发展,各种基础能力进行了下沉,出现了各种各样的Sidecar,包括Dapr、Istio等

这么多Sidecar出现了之后,Sidecar之间怎么共存,们都是以独立的进程方式运行,就会给运维和资源消耗带来很大的问题,所以说我们希望有某种机制能够将Sidecar进行合并成几种,当然最理想的情况下当然是合并成一种这时候

它的理论里面有一个概念叫MechaMecha在日本动漫里面就是机甲的意思,男主人公如果在变身的时候,他会穿上机甲,然后就自动带上了分布式的能力那么通过Mecha来实现各种Sidecar进行合并的这种方式,对Mecha有什么要求?

第一点是Mecha需要能够有一种机制,能够将各种开源的或者商业化的产品能够集成到的Dapr体系中,能够支持插件的扩展机制。

第二点提供可配置的能力,最好是通过YamlJson这种在K8s里面比较通用的配置方式。

第三点是Mecha能够提供分布式API能力,这种API最好是HDP或GRPC的形式,因为这两种形式是开放的,而且已经得到了大众的认可。

当然生命周期相关的管理可以交给K8s来完成,而不用Multiple Runtime本身去关注。

(四)Dapr 介绍

接下来我们来介绍一下DaprMultiple Runtime的实践者,名称由来是Distributed Application Runtime的首字母,它是由微软发起的,然后阿里巴巴现在深度参与合作的一个开源项目

云效峰会——Dapr在阿里云云原生的实践

Dapr当前的版本是1.1,在今年2月份的时候发布了1.0版本,现在的社区的Star数已经到达13.1k

Dapr有哪些核心的机制呢?

第一点Dapr提供了面向分布式能力的API,而且这些API通过HTTP和GRPC的方式进行暴露

Dapr内部有一套自己的SPI扩展机制,无论是开源或商业化产品都能够很方便集成进来。这个机制在Dapr里面叫做 Component,也叫做组件。应用开发者只需要基于Dapr的多语言的SDK并且面向能力的方式对Dapr进行编程,而底层的具体实现则由Dapr的Yaml文件的方式进行激活应用无需感知到是由哪种实现来完成的。

(五)Dapr 特性

云效峰会——Dapr在阿里云云原生的实践

Dapr里面有两个关键的特性,第一个是“Any Languag,Anywhere”,就是应用开发者可以基于Dapr的多语言的SDK就开始面向Dapr编程。

同时,Dapr可以部署在任何环境里,包括本地的环境,边缘计算的场景,拥有K8s的环境,或者说任何商业化的云产品开发厂商中同时Dapr提供了可插拔/可替换组件,现在社区里面已经有超过70个组件

(六)Dapr 架构

那么我们来从Dapr模块的角度来看一下,为什么说Dapr满足Multiple Runtime的理念

云效峰会——Dapr在阿里云云原生的实践

在整个架构最下面的部分里,它提供了Component的机制,包括了 Component能力的抽象以及多达70多种的Component实现,再往上一层是Building Block就是前面讲到的面向分布式能力的那些能力,同时这些能力可以通过GRPC或者API的方式进行暴露。

(七)Dapr – Components & Building Block

云效峰会——Dapr在阿里云云原生的实践

那么现在在Dapr社区里面已经支持的Components包括Bindings, Pub/sub, Middleware, Service discovery

这些能力有纵向的功能层面的能力,像Bindings, Pub/sub,也有一些横向的能力,像Middleware,Dapr支持的Building Block有以下几种,包括Service Invocation, State, Pub/Sub, Bindings等7种一个Building Block一个或者多个的Component组成,像一个BindingsBuilding Block可以由一个Component和Middleware共同组成,如果一个开发者想实现Redis和Dapr的集成,该开发者可以去实现State Component,把Redis集成进去就可以做到

(八)Dapr 整体架构

云效峰会——Dapr在阿里云云原生的实践

Dapr和普通的Istio其实是一样的,它也包含了数据平面和控制平面,但是它的控制平面和Istio比还是比较偏弱,它没有基于流量的管控,它更多的是拼运维层面,包括Actor Placement,Sidecar InjectorSentry,Operator

Actor Placement主要是解决Actor的服务选址问题Sentry主要解决证书等安全方面的问题,Sidecar Injector 主要负责 Dapr Sidecar 的注入

Dapr支持Yaml方式进行配置,它支持的方式有两种,一种是在本地的目录下面放入Yaml文件,然后通过环境变量的方式进行激活。还有一种方式是运维者在Dapr的Operator中写入Yaml文件,然后Yaml文件会写入到K8s的CRD文件中,Dapr Sidecar需要去感知到CRD的文件格式。

(九)Dapr 微软落地场景

云效峰会——Dapr在阿里云云原生的实践

Dapr经历两年多的发展微软内部也有一些落地场景

其中workerflowsAzure Functions Dapr extensions这两个产品都是在GitHub上,Workflows整合了Azure Logic Apps 和 Dapr的一个产品Azure Logic Apps是里面有几个关键的概念,叫做TriggerFunctionsConnector

其中Trigger 可以使用 Dapr 的 Input Binding 来完成,而Connector可以使用DaprService Invocation或者Output Binding完成Azure Logic Apps和Dapr集成之后可以全部接收Dapr已经集成的70个组件能够扩大自己的服务范围。

Azure Functions Dapr extensions这个产品其实和上面讲到workerflow比较相近,它里面也有两个比较接近的概念TriggerConnector。

Azure API Management Service是微软提供的API管理的一个服务,Dapr集成有两种方式一种方式当前的API Management Service已经完成了协议转发,然后通过Dapr做服务调用,将流量转发到下面的APP里面去,主要可以运用Dapr Service Invocation的能力还有一种是API Management Service里面做任何的协议转换,而将协议转换交给Dapr来做,由Dapr来完成协议的封装和转发

(十)Dapr 小结

云效峰会——Dapr在阿里云云原生的实践

Dapr提供了标准的API能够给开发者带来支持多语言面向能力的统一编程体验,这种能力非常适合函数计算场景而随着Dapr整个生态的不断发展,越来越多的开源和商业化产品集成到Dapr的生态中可以利用Dapr组件的可插拔能力,将底层具体的组件实现给屏蔽掉,给业务开发者带来不一样的编程体验。

接下来介绍一下Service MeshDapr的一些差异点.

Service Mesh它主要专注于服务调用, Dapr天生就是为了服务更多的分布式能力而诞生的,它提供了70多种分布式能力的集成,而且将来会覆盖更多的分布式场景。

Service Mesh当前是采用协议转发的方式进行,可以给应用带来零入的体验,Dapr采用了多语言SDK加标准API加各种分布式能力的方式提供服务。

三、阿里在 Dapr 上的探索

(一)Dapr 的发展路线 (阿里巴巴内部参与时间点)

接下来介绍阿里在Dapr上的一些探索和实践。

云效峰会——Dapr在阿里云云原生的实践

首先看一下Dapr和阿里的渊源,在2019年10月份的时候,微软开源了Dapr,那时候版本是0.1.0。彼时阿里巴巴刚好和微软有一个项目合作,从侧面了解到了Dapr项目的存在,经过内部一定时间的评估之后,2020年初阿里巴巴和微软进行了一次线下的沟通。

在沟通过程中,微软介绍了Dapr以及一些规划和想法以及内部落地的情况,然后我们认定Dapr云原生场景下有一定的发展前景。2020年年中,阿里巴巴开始投入Dapr项目,主要是解决函数计算对外流量的问题。到了2020年10月份,在函数计算场景下,我们试点了RPC这一中间件的能力,到年底的时候我们试点了Catch、消息、Config等能力,到2021年2月份的时候,Dapr发布了1.0版本

(二)阿里云函数计算

云效峰会——Dapr在阿里云云原生的实践

前面提到过函数计算能给业务带来的价值,主要能够大幅降低成本从开发者角度来看,函数计算能够给开发者带来更好的研发体验和研发效率。

所以,Dapr在这一块能够提供的最大价值是提供多语言面向能力的统一编程界面,而且期望通过Dapr之后,函数的部署或启动能够更加快速,使函数能够更加轻量。

函数计算整体架构比较复杂,但是和开发者相关的主要有两块,第一块是 Function Compute Gateway还有一块是函数的运行时Gateway方面主要有两个功能,第一个是流量的转发,第二个就是根据流量的QPS根据函数实例的CPU和内存消耗情况提供弹性。

当前的Dapr实例和函数的实例其实是部署在同一个Pod下面的两个容器里面,类似于Service Mesh的标准形式进行部署。

整个流量流转的形式是这样的,当有流量流进来的时候,会先进入Gateway,然后Gateway经过一定的判断,看是否需要做弹性的扩缩,同时它会将流量转发到某个函数的实例中函数实例在执行它的函数代码过程中,会调用Dapr多语言SDK然后向Dapr发起一次RPC的请求,通过Dapr Sidecar向外发送BaaS的服务请求。

之前的这种方式我们是在同一个Pod下面部署了两个容器的方式,这种方式和传统的Service Mesh Sidecar的方式相同,但是函数计算场景下对资源消耗要求更加高,将Dapr部署到一个独立容器中的这种方式资源消耗过高,所以我们需要将函数和Dapr两个进程部署到同一个容器中,然后Dapr Sidecar由Extension模块进行管理。

在函数计算场景下,最小的实例数可以缩容到0,但是应用开发者为了能够在有流量进来的时候能够快速提供服务,往往会申请一些预留实例,主要是为了解决突发的流量但是当预留的实例没有流量的时候,函数计算期望能够将资源的消耗降下来,所以函数计算里面提供了一种机制,当某个预留实例很久没有流量的时候,它会让实例进入休眠的状态。

前面讲到了Dapr和函数计算的实例是部署在同一个容器的两个进程,那么Dapr当然也需要去进入休眠状态,所以说Dapr还需要感知到函数计算进入休眠的状态,然后Dapr也进入休眠。

(三)阿里云函数计算:Dapr 方案优化

云效峰会——Dapr在阿里云云原生的实践

阿里集团的某些SaaS业务随着业务的发展,除了给集团提供服务外,还需要对外进行售卖。但是售卖的过程中客户会提一些诉求,他希望这些SaaS的系统能够部署在专有云或者混合云的场景下,而且底层依赖的技术希望是开源的,或者说某些没有厂商绑定的云产品上,所以它的本质是期望将阿里内部的RPCCache、消息、Config这些东西都切换Redis、RocketMq和Nacos上,这种切换可以通过Dapr的灵活组件插拔形式来完成。

在集团里面的时候,它声明了内部的Yaml文件,当它部署到专有云或混合云场景下的时候,通过指定开源产品的Yaml文件通过指定不同的Yaml文件来激活不同的组件但是这时候应用开发者如果想切到Dapr这个体系里面来,它又需要面向Dapr的JAVA SDK进行编程,但这种方式的成本非常高,它如果有10应用,10个应用都需要切换到Dapr的JAVA SDK里面来,所以我们给提供了一种适配的方案,应用还是依赖JAR包、RPCCache、Message和Config,然后底层实现里面将它适配到Dapr的JAVA SDK里面来,这样应用开发者只需要升级SDK的版本,而无需做代码的调整。

通过这种方式之后,无论是云上和云下的代码是统一的,不用做任何调整

(四)SaaS 业务上云

云效峰会——Dapr在阿里云云原生的实践

钉钉文档是SaaS场景里一个经典的例子,通过中间件团队给提供的能力,将底层具体的中间件能力进行屏蔽但是钉钉又想往前再走一步,期望能将自己的业务组件也集成到Dapr的Component组件当中。

云效峰会——Dapr在阿里云云原生的实践

钉钉的Dapr落地之旅

(五)Dapr 快速入门教程 (阿里云知行实验室)

云效峰会——Dapr在阿里云云原生的实践

感兴趣的同学可以参考入门教程,阿里云咨询实验室里有一些教程。

四、分布式运行时 Dapr 未来展望

(一)基础设施下沉

最后我们来介绍一下Dapr的未来的一个展望,软件架构的发展历史极其精彩,回顾阿里巴巴系统架构引进的历史,能了解到国内甚至全球软件架构的发展历史。

云效峰会——Dapr在阿里云云原生的实践

淘宝最开始成立的时候是单体应用,最开始的时候是PHP,然后后面切换成JAVA。

随着业务的发展,系统首先对硬件进行了升级,是Scale Up方式完成的,但很快发现这种升级方式遇到了各种各样的问题,所以在2008年的时候开始引入了微服务的解决方案但是SOA的解决方案是分布式的,对于稳定性、可观测等方面有较高的要求所以在阿里内部又引入了垄断隔离全链路监控等高可用的方案。

接下来面临的问题是怎么在机房IDC层面能让业务达到99.99%以上的可用的SLA,此时就有了异地多活的解决方案。而随着云原生技术的发展,阿里巴巴拥抱和引导云生技术发展的决心非常大,开始积极拥抱云原生技术,以K8s为基础,积极开展云原生技术相关的升级。

在这个历史中我们可以发现软件架构的诉求越来越多,需求永无止境,原先底层的基础设施无法完成,只能交给应用层来完成的工作,逐渐在K8s和容器引入之后得到了解决,重新将分布式和微服务相关的能力进行了下沉。

而且,我们相信未来的趋势也是会以Service Mesh、Dapr为代表的分布式能力下沉的方式继续往前演进,逐渐释放云和云原生技术的发展红利,未来的应用开发者应该期望能够面向语言无关的不和具体厂商和技术进行绑定的开发体验,同时能够享受到技术带来的红利,做到极致弹性带来的成本优势。

从当前角度出发,如何才能完成这个目标?

(二)云原生场景下的应用开发者的诉求

云效峰会——Dapr在阿里云云原生的实践

第一点是Multiple Runtime能够真正落地,就像前面讲到了Dapr能够真正落地,并且能够持续进行发展。

第二点,以Dapr为代表的面向分布式能力的API能够成为一个行业的标准,而且这个标准能够持续地发展,最好是能够成为一个工业的标准。

第三点,K8s和Serverless的持续发展,能够给云原生技术带来更多的发展红利。

(三)Dapr 社区方向

最后我们来看一下Dapr社区发展的几个方向。

云效峰会——Dapr在阿里云云原生的实践

第一点是推动API标准化,同时能够集成更多的分布式能力

第二点更多Component集成,Dapr目前已经集成了70多种,期望将来能够集成更多的component,同时这些能力的功能上能够更加完整。

第三点希望更多公司能够接受Multiple Runtime的理念,积极打磨自己的产品,然后在生产里落地。

最后一点希望Dapr能够进入CNCF成为Multiple Runtime的事实标准

上一篇:抢抓战略机遇期 加快智能传感器产业发展


下一篇:银行家算法