Dapr 知多少，分布式应用运行时懂几许？

Intro Dapr 官方团队已于最近（2021.2.17）正式发布Dapr v1.0，Dapr已正式生产可用，可以部署到自托管环境或 Kubernetes 集群。对于绝大多数开发者来说，想必对Dapr只是有所耳闻，而具体是什么（What），可以解决什么样的问题（Why&How），有怎样的应用场景（Where），并不知悉。本文就尝试简要梳理下Dapr，并尝试回答以上问题。 What's Dapr Distributed Application Runtime. An event-driven, portable runtime for building microservices on cloud and edge. 分布式应用运行时。一个事件驱动、可移植的运行时用于在云上和边缘计算上构建微服务。 以上是Dapr官方GitHub仓库上对Dapr的简介。文字虽短，口气却很大，因为其除了涵盖了当前所有的技术热点：分布式、云、微服务，还自我标榜为：分布式应用运行时。分布式应用我们或多或少有些了解，运行时也听到不少，比如常见的语言运行时：Java 运行时，.NET 运行时，Go 运行时等等，那运行时又是什么东西？简要来说：运行时是程序运行依赖的执行环境。以.NET 程序运行时CLR为例，它为.NET应用程序提供了一个托管的代码执行环境负责应用程序在整个执行期间的内存管理、线程管理、安全管理、远程管理、即时编译等。 那分布式应用运行时，就是提供分布式应用运行所依赖的的执行环境。那运行分布式应用需要哪些环境依赖呢？回答这个问题，我们要先思考开发分布式应用的挑战是什么？明确了挑战，那就找到了答案。 从单机到分布式，是追求更快和更高的性能，但也带来了更多的不确定性。比如，不确定计算机何时异常，不确定磁盘何时损坏，不确定网络通信的延迟，也不确定消息是否被正常消费。这些不确定性构成了分布式应用的挑战，简而言之： 异构的机器与网络：稳定性问题 普遍的节点故障：可靠性问题 不可靠的网络：一致性问题 面对这些挑战，业界提出了诸多的分布式理论、协议，如CAP定理，BASE理论，一致性协议2PC/3PC/ZAB，来保证系统的正常运行。虽然问题貌似是有了解决方案，但是应用的复杂度升高了。应用除了需要实现业务需求，还要兼顾非业务需求，集成诸如服务发现、负载均衡、失效转移、动态扩容、数据分片、调用链路监控等分布式系统的核心功能，对应用有很强的侵入性，这就是以Spring Cloud为代表的微服务框架的常见做法。 那如何解决侵入性的问题呢？这个问题随着容器编排技术的成熟有了新的解法。Kubernetes可以不侵入应用层，在容器层解决问题，比如K8S Service就具有服务发现、负载均衡的能力，HPA具有动态扩容的能力。随着K8S的快速发展，云原生的概念，也就越来越深入人心，那如何利用好K8S提供的基座能力，将更多的分布式能力下沉，让应用开发回归业务呢？其中Service Mesh提出的Sidecar模式，就很好的解决了微服务架构中网络通信的问题。Sidecar主要就是用来处理诸如服务发现、负载均衡、请求熔断等一系列非业务需求，应用在部署时动态插入Sidecar，服务间的通信通过Sidecar进行代理，以完成对服务间网络通信的接管。 到这里，微服务开发在Service Mesh的帮助下，已经渐渐回归业务本身，让更多的开发者看到了一丝曙光。It's enough? 来看下Bilgin Ibryam在Multi-Runtime Microservices Architecture文章中提及的分布式应用的四大需求： 从上图可以看出，除了网络（Networking）外，生命周期（Lifecycle）、状态（State）、捆绑（Binding）也是分布式应用要解决的问题之一。网络问题可以借由Service Mesh 比如Istio予以解决。那其他三个该如何解决呢？又要应用自行开发集成吗？显然不符合应用回归业务本身的诉求。这时，Dapr登场了，Dapr提出的分布式应用运行时就是实现了以上四个需求并将其下沉作为分布式应用的运行环境。 简而言之：Dapr将分布式能力进行封装下沉作为运行时以简化分布式应用开发的技术复杂度。 How Dapr Works 那Dapr如何简化分布式应用的开发呢？下面我们来看一看Dapr的主要特性。 一图胜千言：Dapr通过以HTTP/gRPC API这种与语言无关的方式暴露封装的分布式能力供应用调用，从而支持使用任意语言或框架进行开发集成。目前官方已经提供了Go，Node，Python，.NET，Java， C++，PHP，Rust，Javascript的Sdk，简化Dapr的集成。