分享程序员开发的那些事...
更新时间：2022-05-14 22:18:44
Dapr在阿里云云原生的实践
作者：曹胜利
内容简要：
一、Service Mesh 快速回顾
二、分布式运行时 Dapr 介绍
三、阿里在 Dapr 上的探索
四、分布式运行时 Dapr 未来展望
2016年开始，Service Mesh的理念和一些产品逐渐问世，至今为止已经有许多公司开始实施Service Mesh并取得了一些进展。
Service Mesh是一个基础设施层，用于处理服务间的通信。对于现在的云原生微服务架构，Dapr可以帮它屏蔽掉底层的具体技术，提供可靠的请求传送。
Service Mesh是通过Sidecar的方式提供服务，Service Mesh的进程和应用进程分属于两个进程，就像军用三轮摩托车有两个人，一个人负责行驶，另外一个人负责往外扫射敌人，Servier Mesh的角色其实和扫射的角色是非常相近的。
传统中间件的分布式能力的SDK和应用是部署在一起的，但这种方式带来很多问题，第一个问题是业务代码和中间件的代码进行了耦合，第二个问题是中间件SDK的升级非常困难，进而导致了版本的分化非常严重。第三个问题是一位新员工如果进入到一个公司的时候，熟悉中间件的成本比较高，所以Service Mesh可以将这些底层的基础能力进行下沉，下沉到独立的Sidecar中，可以给应用带来关注点的分离，应用只需要关注自己的业务逻辑，而无需关注具体的中间件能力。
Istio毫无疑问是Service Mesh的强者，是由Google IBM和Lyft共同发起创立的，它主要的核心功能是提供流量的管理。
Service A如果想访问service B，它需要经过旁边的Proxy Sidecar，然后将请求发送给远端的Proxy Sidecar，然后远端的Proxy Sidecar再将请求发送给Service B。Istio其实是由数据面和控制面来实现的，数据面现在的社区最强者是Envoy。
接下来我对Service Mesh做一个小结。
Service Mesh的定位是提供服务间的通讯基础设施，主要支持了Http/RPC，而且Service Mesh是通过原协议转发的方式对应用提供服务，所以对应用的侵入几乎为零。
接下来介绍Dapr，随着云技术和云原生技术的发展，云能给业务开发者提供的服务除了应用之外，还有FaaS场景下的一些服务，你只需要提供一个函数或者一个JAR包，就可以在FaaS场景下进行部署。
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。
Bilgin Ibryam是RedHat中间件首席架构师，也是Apache Commit，在Apache社区里面非常活跃，他提出了一个理论，将分布式的能力进行了抽象，抽象成了4大种类，包括生命周期、网络、状态和绑定。
同时，Bilgin Ibryam还提出了一个理念，叫Multiple Runtime，那么这个理念是怎么推导出来的？
传统的中间件各种分布式能力都在SDK里面，然后和应用部署在同一个进程里面。
随着云原生和基础设施的下沉发展，各种基础能力进行了下沉，出现了各种各样的Sidecar，包括Dapr、Istio等。
这么多Sidecar出现了之后，Sidecar之间怎么共存，它们都是以独立的进程方式运行，就会给运维和资源消耗带来很大的问题，所以说我们希望有某种机制能够将Sidecar进行合并成几种，当然最理想的情况下当然是合并成一种这时候。
它的理论里面有一个概念叫Mecha，Mecha在日本动漫里面就是机甲的意思，男主人公如果在变身的时候，他会穿上机甲，然后就自动带上了分布式的能力。那么通过Mecha来实现各种Sidecar进行合并的这种方式，对Mecha有什么要求？
第一点是Mecha需要能够有一种机制，能够将各种开源的或者商业化的产品能够集成到的Dapr体系中，能够支持插件的扩展机制。
第二点是提供可配置的能力，***是通过Yaml或Json这种在K8s里面比较通用的配置方式。
第三点是Mecha能够提供分布式API能力，这种API***是HDP或GRPC的形式，因为这两种形式是开放的，而且已经得到了大众的认可。
当然，生命周期相关的管理可以交给K8s来完成，而不用Multiple Runtime本身去关注。
接下来我们来介绍一下Dapr，是Multiple Runtime的实践者，名称由来是Distributed Application Runtime的首字母，它是由微软发起的，然后阿里巴巴现在深度参与合作的一个开源项目。
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里面有两个关键的特性，第一个是“Any Languag，Anywhere”，就是应用开发者可以基于Dapr的多语言的SDK就开始面向Dapr编程。
同时，Dapr可以部署在任何环境里，包括本地的环境，边缘计算的场景，拥有K8s的环境，或者说任何商业化的云产品开发厂商中，同时Dapr提供了可插拔/可替换的组件，现在社区里面已经有超过70个组件。
那么我们来从Dapr模块的角度来看一下，为什么说Dapr满足Multiple Runtime的理念。
在整个架构最下面的部分里，它提供了Component的机制，包括了 Component能力的抽象以及多达70多种的Component实现，再往上一层是Building Block就是前面讲到的面向分布式能力的那些能力，同时这些能力可以通过GRPC或者API的方式进行暴露。
那么现在在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组成，像一个Bindings的Building Block可以由一个Component和Middleware共同组成，如果一个开发者想实现Redis和Dapr的集成，该开发者可以去实现State Component，把Redis集成进去就可以做到。
Dapr和普通的Istio其实是一样的，它也包含了数据平面和控制平面，但是它的控制平面和Istio比还是比较偏弱，它没有基于流量的管控，它更多的是拼运维层面，包括Actor Placement，Sidecar Injector，Sentry，Operator。
Actor Placement主要是解决了Actor的服务选址问题，Sentry主要解决证书等安全方面的问题，Sidecar Injector 主要负责 Dapr Sidecar 的注入。
Dapr支持Yaml方式进行配置，它支持的方式有两种，一种是在本地的目录下面放入Yaml文件，然后通过环境变量的方式进行激活。还有一种方式是运维者在Dapr的Operator中写入Yaml文件，然后Yaml文件会写入到K8s的CRD文件中，Dapr Sidecar需要去感知到CRD的文件格式。
Dapr经历两年多的发展，在微软内部也有一些落地场景。
其中，workerflows和Azure Functions Dapr extensions这两个产品都是在GitHub上，Workflows整合了Azure Logic Apps 和 Dapr的一个产品，Azure Logic Apps是里面有几个关键的概念，叫做Trigger、Functions和Connector。
其中，Trigger 可以使用 Dapr 的 Input Binding 来完成，而Connector可以使用Dapr的Service Invocation或者Output Binding完成。Azure Logic Apps和Dapr集成之后可以全部接收Dapr已经集成的70个组件，能够扩大自己的服务范围。
Azure Functions Dapr extensions这个产品其实和上面讲到workerflow比较相近，它里面也有两个比较接近的概念：Trigger和Connector。
Azure API Management Service是微软提供的API管理的一个服务，它和Dapr集成有两种方式。一种方式是当前的API Management Service已经完成了协议转发，然后通过Dapr做服务调用，将流量转发到下面的APP里面去，主要可以运用Dapr Service Invocation的能力。还有一种是API Management Service里面不做任何的协议转换，而将协议转换交给Dapr来做，由Dapr来完成协议的封装和转发。
Dapr提供了标准的API，能够给开发者带来支持多语言、面向能力的统一编程体验，这种能力非常适合函数计算场景。而随着Dapr整个生态的不断发展，越来越多的开源和商业化产品集成到Dapr的生态中，可以利用Dapr组件的可插拔能力，将底层具体的组件实现给屏蔽掉，给业务开发者带来不一样的编程体验。
接下来介绍一下Service Mesh和Dapr的一些差异点.
Service Mesh它主要专注于服务调用， Dapr天生就是为了服务更多的分布式能力而诞生的，它提供了70多种分布式能力的集成，而且将来会覆盖更多的分布式场景。
Service Mesh当前是采用原协议转发的方式进行，可以给应用带来零侵入的体验，Dapr采用了多语言SDK加标准API加各种分布式能力的方式提供服务。
接下来介绍阿里在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之后，函数的部署或启动能够更加快速，使函数能够更加轻量。
函数计算整体架构比较复杂，但是和开发者相关的主要有两块，第一块是 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也进入休眠。
阿里集团的某些SaaS业务随着业务的发展，除了给集团提供服务外，还需要对外进行售卖。但是售卖的过程中客户会提一些诉求，他希望这些SaaS的系统能够部署在专有云或者混合云的场景下，而且底层依赖的技术希望是开源的，或者说某些没有厂商绑定的云产品上，所以它的本质是期望将阿里内部的RPC、Cache、消息、Config这些东西都切换到Redis、RocketMq和Nacos上，这种切换可以通过Dapr的灵活组件插拔形式来完成。
在集团里面的时候，它声明了内部的Yaml文件，当它部署到专有云或混合云场景下的时候，通过指定开源产品的Yaml文件，通过指定不同的Yaml文件来激活不同的组件。但是这时候应用开发者如果想切到Dapr这个体系里面来，它又需要面向Dapr的JAVA SDK进行编程，但这种方式的成本非常高，它如果有10应用，10个应用都需要切换到Dapr的JAVA SDK里面来，所以我们给它提供了一种适配的方案，应用还是依赖JAR包、RPC、Cache、Message和Config，然后底层实现里面将它适配到Dapr的JAVA SDK里面来，这样应用开发者只需要升级SDK的版本，而无需做代码的调整。
通过这种方式之后，无论是云上和云下的代码是统一的，不用做任何调整。
钉钉文档是SaaS场景里一个经典的例子，通过中间件团队给它提供的能力，将底层具体的中间件能力进行屏蔽。但是钉钉又想往前再走一步，它期望能将自己的业务组件也集成到Dapr的Component组件当中。
钉钉的Dapr落地之旅
感兴趣的同学可以参考入门教程，阿里云咨询实验室里有一些教程。
最后我们来介绍一下Dapr的未来的一个展望，软件架构的发展历史极其精彩，回顾阿里巴巴系统架构引进的历史，能了解到国内甚至全球软件架构的发展历史。
淘宝最开始成立的时候是单体应用，最开始的时候是PHP，然后后面切换成JAVA。
随着业务的发展，系统首先对硬件进行了升级，是以Scale Up的方式完成的，但很快发现这种升级方式遇到了各种各样的问题，所以在2008年的时候开始引入了微服务的解决方案。但是SOA的解决方案是分布式的，对于稳定性、可观测性等方面有较高的要求，所以在阿里内部又引入了垄断、隔离、全链路监控等高可用的方案。
接下来面临的问题是怎么在机房IDC层面能让业务达到99.99%以上的可用的SLA，此时就有了异地多活的解决方案。而随着云原生技术的发展，阿里巴巴拥抱和引导云原生技术发展的决心非常大，开始积极拥抱云原生技术，以K8s为基础，积极开展云原生技术相关的升级。
在这个历史中，我们可以发现软件架构的诉求越来越多，需求永无止境，原先底层的基础设施无法完成，只能交给应用层来完成的工作，逐渐在K8s和容器引入之后得到了解决，重新将分布式和微服务相关的能力进行了下沉。
而且，我们相信未来的趋势也是会以Service Mesh、Dapr为代表的分布式能力下沉的方式继续往前演进，逐渐释放云和云原生技术的发展红利，未来的应用开发者应该期望能够面向语言无关的、不和具体云厂商和技术进行绑定的开发体验，同时能够享受到云技术带来的红利，做到极致弹性带来的成本优势。
从当前角度出发，如何才能完成这个目标？
第一点是Multiple Runtime能够真正地落地，就像前面讲到了Dapr能够真正落地，并且能够持续进行发展。
第二点，以Dapr为代表的面向分布式能力的API能够成为一个行业的标准，而且这个标准能够持续地发展，***是能够成为一个工业的标准。
第三点，K8s和Serverless的持续发展，能够给云原生技术带来更多的发展红利。
最后我们来看一下Dapr社区发展的几个方向。
第一点是推动API标准化，同时能够集成更多的分布式能力。
第二点是更多Component集成，Dapr目前已经集成了70多种，期望将来能够集成更多的component，同时这些能力的功能上能够更加完整。
第三点是希望更多公司能够接受Multiple Runtime的理念，积极打磨自己的产品，然后在生产里落地。
最后一点是希望Dapr能够进入CNCF，成为Multiple Runtime的事实标准。