敢为人先，从阿里巴巴云原生团队实践Dapr案例，看分布式应用运行时前景
背景
Dapr是一个由微软主导的云原生开源项目，国内云计算巨头阿里云也积极参与其中，2019年10月首次发布，到今年2月正式发布V1.0版本。在不到一年半的时间内，github star数达到了1.2万，超过同期的kubernetes、istio、knative等，发展势头迅猛，业界关注度非常高。
接着上一篇《乘风破浪，.Net Core遇见Dapr，为云原生而生的分布式应用运行时》基本上阐述了Dapr的相关概念。
我们知道除了微软自己以外，阿里巴巴也是国内参与了Dapr的重要一份子，基于对Bilgin Ibryam的Multiple Runtime / Mecha Runtime 的理念的共识，阿里巴巴云原生技术团队也积极参与并开启了Dapr应用的实践探索。
基于阿里巴巴云原生团队的探索经验，我们也可以从中得到自己的业务或者项目的落地启发。、
阿里巴巴对Dapr的参与
阿里巴巴是Dapr开源项目的深度参与者和早期采用者，率先进行了生产落地，阿里巴巴集团内部有十几个应用在使用Dapr；目前已有2位Dapr成员，是Dapr项目中除微软之外代码贡献最多的公司。
阿里巴巴为什么会选择Dapr
在阿里巴巴，Java使用非常广泛，不仅仅业务应用大量使用Java，大量中间件和基础能力的服务器端也是使用Java开发。在过去十几年间，我们围绕Java建立了非常完备的生态体系，经历过各种严酷的考验。
而随着业务形态的日渐丰富，多语言的需求在不断的增加，如nodejs/golang/c/c++/rust等。特别是在微服务流行之后，根据实际情况而选择使用不同的编程语言开发微服务成为趋势。但效仿Java，为每一种编程语言都打造一套功能完备的生态体系在成本上是不现实的。因此，需要一个成本可控的方案来解决多语言问题，让微服务开发能真正的实现“语言自由”。
随着云的采用，业务应用的形态也开始朝云原生方向发展，越来越多的业务应用（尤其是前台业务）开始拥抱FaaS和Serverless作为应用托管和资源调度的解决方案。而在FaaS和Serverless场景下，需要更轻量化的解决方案以满足快速启动和伸缩的需求——传统类库模式下由于需要集成大量的SDK，业务应用变得非常的臃肿。而在Function形态下更加的不协调，以nodejs为例：几百行的nodejs Function代码依然需要依赖多达几十兆的node module。同时FaaS和Serverless也对多语言的支持提供了更高的要求。因此，在FaaS和Serverless这种新型形态下有必要提供有别于传统类库方式的、更轻量化的、支持多语言的解决方案。
显然，Servicemesh倡导的Sidecar模式是解决上述问题的绝佳方案。在过去几年间，随着Servicemesh的发展和采用，Sidecar模式已经得到充分验证：Sidecar模式非常符合云原生的理念，特别是在多语言支持和应用轻量化方面具备天然优势。
我们非常认可Bilgin Ibryam在"Multi-Runtime Microservices Architecture"一文中提出的Multiple Runtime/Mecha Runtime的理念，尤其是他对分布式应用需求的分析，很符合我们的实际情况：
而Dapr是第一个实践Multiple Runtime理念的开源项目，我们从这个项目发布开始就密切关注它，因为Dapr可以很好的解决我们面临的问题：Sidecar模式天然提供了对多语言的支持，各种客户端SDK被Dapr Runtime替代之后应用也得以轻量化。
此外，从长期战略的角度考虑，我们在2020年提出了"三位一体"的理念，即将“自研技术”、“开源项目”、“商业产品”形成统一的技术体系，最大化技术的价值。而当前的实际情况是三者有完全不同的产品和技术方案，导致当我们需要将某个产品在阿里内部、公有云、客户私有云等不同的平台上进行迁移时，或者是跨多个平台部署时，就会遇到非常大的挑战。Dapr面向能力编程的理念，强调可移植性和可扩展性的标准API，平台中立、无供应商锁定的设计，深深的吸引了我们。
“在阿里云，我们相信Dapr将引领微服务的发展。通过采用Dapr，我们的客户现在可以以更快的速度来构建可移植和健壮的分布式系统。”
——阿里云资深技术专家李响
在2020年年中，我们开始基于Dapr项目进行了内部小规模的试点，在实际的落地过程中探索和验证Dapr的理念。我们也积极参与到Dapr开源项目的建设中，提交了大量的改进建议和代码。
下面我们将以Dapr在阿里的实际落地场景来具体说明Dapr是如何帮助我们解决上述问题的。
阿里巴巴实践Dapr案例-多语言场景
1）Faas/Serverless场景
背景：在阿里的电商系统中，存在大量活动和导购需求。
这些需求的特点是"短平快"：需要快速开发、快速迭代、生命周期相对比较短。因此这类需求非常适合通过采用FaaS的方式来落地。
Faas对多语言支持有强烈的诉求，肯定不会局限于Java。而阿里内部大部分应用都是Java体系，对多语言的支持比较弱，尤其是新兴语言（如Dart）或者小众语言（如Rust）。
而从需求上说，采用FaaS的应用也同样需要和内部运行的服务以及各种中间件/基础设施进行通讯，因此FaaS平台迫切的需要解决多语言支持问题。
通过Dapr，我们很好的解决了FaaS的多语言问题，从而使得客户通过FaaS实现了开发效率的大幅提升。
2）多语言应用的接入
背景：阿里收购有大量的公司。
这些收购的公司有大量的应用，而这些应用中很多不是Java体系，在接入阿里的技术体系时，对多语言支持有明确的需求。
另外，由于业务创新的需要，有些应用对nodejs和golang有强烈诉求，还有一些应用则需要使用到Dart和C++。
但目前这些语言的生态系统并没有像Java那么完善，尤其部分中间件和基础设施已经发展的非常成熟，进入维护状态，不太可能在现在重新开发所有语言的客户端：成本上代价很高，时间上也来不及。
通过Dapr，我们可以为这些应用提供多语言解决方案。
3）复杂的Java遗留系统
背景：基于JavaClassLoader机制而设计的复杂系统。
为了解决类冲突问题，隔绝不同的业务模块，阿里针对Java系统设计了基于ClassLoader机制的复杂系统，这些系统的设计往往非常复杂，应用也非常臃肿。
此外，部分业务团队为了能和现有的中间件进行互通，自行维护了一套多语言的中间件SDK，而这些SDK本来应该由中间件团队维护并保持同步更新。这也带来了稳定性方面的隐患和风险。
我们期望将这些遗留的系统迁移到Dapr中，统一实现中间件SDK的维护和更新。比较特殊的是这里存在一个需求：最好能让业务开发团队尽量不做代码层面的调整，以减少迁移时对业务应用的冲击。
所以针对Java遗留系统，在迁往Dapr时，我们额外设计了一个Java适配层：将原来的Java调用适配到Dapr的客户端API上。
以上三种多语言的落地实践场景，如下图所示：
阿里巴巴实践Dapr案例-云间迁移场景
背景：业务应用对外输出时有跨平台需求。
阿里的部分业务，如钉钉文档，原本是提供给阿里内部和外部用户直接使用的，此时钉钉文档只需要部署在阿里内部的业务集群里，直接访问阿里内部的生态体系。
但是随着SaaS业务的发展，以及部分信息安全敏感的用户对于数据安全的强烈诉求，需要将钉钉文档部署到用户VPC下或者公有云下。
为此，我们需要将钉钉文档的系统从阿里内部迁移到公有云上进行部署，而钉钉文档使用的底层技术需要从阿里内部的技术体系迁移到使用开源技术或阿里云的商业化产品上。
借助Dapr的标准API和可扩展的组建模型，我们采取的策略是让用户不需要修改任何代码，直接通过Dapr Runtime屏蔽底层使用的中间件：部署在不同平台时，通过激活Dapr中的不同的Component来提供一致的能力。
以消息通讯为例，当应用需要访问消息系统时：
- 在阿里内部：通过Rocketmq.yaml激活Rocketmq组件。
- 在公有云上：通过Kafka.yaml激活kafka组件。
通过Dapr的可移植性，上层的钉钉文档应用现在可以和底层的基础设施（如消息系统）解耦，从而实现在不同的云平台之间平滑迁移：
最终帮助我们的业务团队实现了他们的业务目标：使Dingtalk在任何地方部署成为可能。
阿里巴巴实践Dapr-未来场景展望
未来我们将继续通过应用试点的方式对Dapr进行验证，包括：
- 适用场景
- 性能
- 稳定性
- 可移植性
同时我们将继续开发Dapr的组件，以集成更多的中间件和基础设施，包括内部产品和阿里云上支持的商业产品。其中对阿里云商业产品的集成代码，我们将在验证通过之后贡献给Dapr项目，从而为Dapr提供阿里云支持。这些项目预计将包括：
- ApacheDubbo的RPC支持
- ApacheRocketMQ的消息传递支持
- Nacos的动态配置支持
- 阿里云RDS的MySQL支持
- 阿里云缓存服务的Redis支持
作为Multiple Runtime架构的先驱者和Dapr项目的早期采用者，我们将继续和Dapr社区合作，在落地的过程中努力完善Dapr的功能、性能、稳定性等关键指标，和社区一起联手打造云原生时代的Distributed Application Runtime！
Dapr 入门教程(阿里知行动手实验室)
十分钟快速领略开源分布式运行时Dapr应用的开发、部署过程
https://start.aliyun.com/course?id=gImrX5Aj
