开源 1 年半 star 破 1.2 万的 Dapr 是如何在阿里落地的？

2021-04-19 533

Dapr 是 2019 年 10 月微软开源的可移植、事件驱动分布式运行时，它使开发人员能够轻松地构建运行在云平台和边缘的弹性而微服务化的无状态和有状态的应用程序，从而降低基于微服务架构构建现代云原生应用的准入门槛。

在今年 2 月份刚刚发布了 v1.0 正式版本。虽然推出至今不过一年半时间，但 Dapr 发展势头十分迅猛，目前已经在 GitHub 上收获了 1.2w 星。阿里是 Dapr 开源项目的深度参与者和早期采用者，率先进行了生产落地，集团内部有十几个应用在使用 Dapr；目前已有 2 位 Dapr成员，是 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. 概况

目前 Dapr 在阿里巴巴内部还处于实验阶段。

我们的首要工作是为内部的中间件开发 Dapr 组件，使业务应用程序可以与这些中间件和实现它们的 Java 语言/ Java Client SDK 解耦。然后通过小规模的业务应用落地，在各种场景下的对 Dapr 进行验证，在验证完成之后计划继续部署较大规模的业务应用。

截止到 2021 年 3 月，Dapr 在阿里内部落地的场景主要集中在 2 个方面：多语言支持和云间迁移。

2. 多语言支持

1）Faas / Serverless 场景

背景：在阿里的电商系统中，存在大量活动和导购需求。

这些需求的特点是"短平快"：需要快速开发、快速迭代、生命周期相对比较短。因此这类需求非常适合通过采用 FaaS 的方式来落地。

Faas 对多语言支持有强烈的诉求，肯定不会局限于 Java。而阿里内部大部分应用都是 Java 体系，对多语言的支持比较弱，尤其是新兴语言（如 Dart）或者小众语言（如 Rust）。

而从需求上说，采用 FaaS 的应用也同样需要和内部运行的服务以及各种中间件/基础设施进行通讯，因此 FaaS 平台迫切的需要解决多语言支持问题。

通过 Dapr ，我们很好的解决了 FaaS 的多语言问题，从而使得客户通过 FaaS 实现了开发效率的大幅提升。

2）多语言应用的接入

背景：阿里收购有大量的公司。

这些收购的公司有大量的应用，而这些应用中很多不是 Java 体系，在接入阿里的技术体系时，对多语言支持有明确的需求。

另外，由于业务创新的需要，有些应用对 nodejs 和 golang 有强烈诉求，还有一些应用则需要使用到 Dart 和 C++。

但目前这些语言的生态系统并没有像 Java 那么完善，尤其部分中间件和基础设施已经发展的非常成熟，进入维护状态，不太可能在现在重新开发所有语言的客户端：成本上代价很高，时间上也来不及。

通过 Dapr ，我们可以为这些应用提供多语言解决方案。

3）复杂的 Java 遗留系统

背景：基于 Java ClassLoader 机制而设计的复杂系统。

为了解决类冲突问题，隔绝不同的业务模块，阿里针对 Java 系统设计了基于 ClassLoader 机制的复杂系统，这些系统的设计往往非常复杂，应用也非常臃肿。

此外，部分业务团队为了能和现有的中间件进行互通，自行维护了一套多语言的中间件 SDK，而这些 SDK 本来应该由中间件团队维护并保持同步更新。这也带来了稳定性方面的隐患和风险。

我们期望将这些遗留的系统迁移到 Dapr 中，统一实现中间件 SDK 的维护和更新。比较特殊的是这里存在一个需求：最好能让业务开发团队尽量不做代码层面的调整，以减少迁移时对业务应用的冲击。

所以针对 Java 遗留系统，在迁往 Dapr 时，我们额外设计了一个 Java 适配层：将原来的 Java 调用适配到 Dapr 的客户端 API 上。

以上三种多语言的落地实践场景，如下图所示：

3. 云间迁移

背景：业务应用对外输出时有跨平台需求。

阿里的部分业务，如钉钉文档，原本是提供给阿里内部和外部用户直接使用的，此时钉钉文档只需要部署在阿里内部的业务集群里，直接访问阿里内部的生态体系。

但是随着 SaaS 业务的发展，以及部分信息安全敏感的用户对于数据安全的强烈诉求，需要将钉钉文档部署到用户 VPC 下或者公有云下。

为此，我们需要将钉钉文档的系统从阿里内部迁移到公有云上进行部署，而钉钉文档使用的底层技术需要从阿里内部的技术体系迁移到使用开源技术或阿里云的商业化产品上。

借助 Dapr 的标准 API 和可扩展的组建模型，我们采取的策略是让用户不需要修改任何代码，直接通过 Dapr Runtime 屏蔽底层使用的中间件：部署在不同平台时，通过激活 Dapr 中的不同的 Component 来提供一致的能力。

以消息通讯威力，当应用需要访问消息系统时：

在阿里内部：通过 Rocketmq.yaml 激活 Rocketmq 组件。
在公有云上：通过 Kafka.yaml 激活 kafka 组件。

通过 Dapr 的可移植性，上层的钉钉文档应用现在可以和底层的基础设施（如消息系统）解耦，从而实现在不同的云平台之间平滑迁移：

最终帮助我们的业务团队实现了他们的业务目标：使 Dingtalk 在任何地方部署成为可能。

阿里的 Dapr 未来规划

未来我们将继续通过应用试点的方式对 Dapr 进行验证，包括：

适用场景
性能
稳定性
可移植性

同时我们将继续开发 Dapr 的组件，以集成更多的中间件和基础设施，包括内部产品和阿里云上支持的商业产品。其中对阿里云商业产品的集成代码，我们将在验证通过之后贡献给 Dapr 项目，从而为 Dapr 提供阿里云支持。这些项目预计将包括：

Apache Dubbo 的 RPC 支持
Apache RocketMQ 的消息传递支持
Nacos 的动态配置支持
阿里云 RDS 的 MySQL 支持
阿里云缓存服务的 Redis 支持

作为 Multiple Runtime 架构的先驱者和 Dapr 项目的早期采用者，我们将继续和 Dapr 社区合作，在落地的过程中努力完善 Dapr 的功能、性能、稳定性等关键指标，和社区一起联手打造云原生时代的DistributedAPplicationRuntime！

微信关注我们

原文链接：https://my.oschina.net/u/3874284/blog/5025004

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

不为人知的网络编程(十二)：彻底搞懂TCP协议层的KeepAlive保活机制

文中引用了参考资料中的部分内容，本文参考资料详见文末“参考资料”一节，感谢资料分享者。 1、引言对于IM开发者而言，网络保活这件事再熟悉不过了，比如这是我最近一篇有关网络保活话题文章《一文读懂即时通讯应用中的网络心跳包机制：作用、原理、实现思路等》，以及我分享的大量代码实战编码中也都必须要考虑这个问题的实现，比如最近的这篇《跟着源码学IM(五)：正确理解IM长连接、心跳及重连机制，并动手实现》。对于IM这种应用而言，应用层的网络保活的最直接办法就是心跳机制，比如主流的IM里有微信、QQ、钉钉、易信等等，可能代码实现细节有所差异，但理论上无一例外都是这样实现。（PS：没错，当初微信跟运营商间的“信令危机”就是跟这个有关）所谓的网络心跳，通常是客户端每隔一小段时间向服务器发送一个数据包（即心跳包），通知服务器自己仍然在线（心跳包中同时可能传输一些必要的数据）。发送心跳包，从通信层面来说就是为了保持长连接，至于这个包的内容，是没有什么特别规定的，但在移动端IM中为了省流量，一般都是很小的包（比如某些第3方的IM云为了说明心跳不费流量，号称1字节的心跳包）。但经常有人会问到，既然TCP...

2021-04-19

540

elasticsearch-datatran v6.2.9 已经发布，这是一个 Elasticsearch 高效数据同步工具。Elasticsearch-datatran 由 bboss 开源的数据同步迁移工具，支持在Elasticsearch、关系数据库(mysql,oracle,db2,sqlserver、达梦等)、Mongodb、HBase、Hive、Kafka、文本文件、SFTP/FTP多种数据源之间进行海量数据同步；支持日志文件实时增量采集到kafka/elasticsearch/database。 Elasticsearch版本兼容性：支持各种Elasticsearch版本（1.x,2.x,5.x,6.x,7.x,+）之间相互数据迁移。 v6.2.9 功能改进数据同步改进：完善ip2region和geoip数据库热加载机制 Restclient改进：升级httpcliet组件版本到最新的官方版本4.5.13 Restclient改进：升级fastxml jackson databind版本2.9.10.8 Restclient改进：增加对elasticsearch pit...

2021-04-19

638

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。