没有Kubernetes，如何巧妙运用Dapr实现微服务架构？

Dapr 被设计成一个面向开发者的企业级微服务编程平台，它独立于具体的技术平台，可以运行在“任何地方”。Dapr本身并不提供“基础设施（infrastructure）”，而是利用自身的扩展来适配具体的部署环境。就目前的状态来说，如果希望真正将原生的Dapr应用与生产，只能部署在K8S环境下。虽然Dapr也提供针对Hashicorp Consul的支持，但是目前貌似没有稳定的版本支持。Kubernetes对于很多公司并非“标配”，由于某些原因，它们可以具有一套自研的微服务平台或者弹性云平台，让Dapr与之适配可能更有价值。这两周我们对此作了一些可行性研究，发现这其实不难，记下来我们就同通过一个非常简单的实例来介绍一下大致的解决方案。（拙著《ASP.NET Core 6框架揭秘》热卖中，首印送签名专属书签）。 目录 一、从NameResolution组件说起 二、Resolver 三、模拟服务注册与负载均衡 四、自定义NameResolution组件 五、注册自定义NameResolution组件 六、编译部署daprd.exe 七、配置svcreg 八、测试效果 一、NameResolution组件虽然Dapr提供了一系列的编程模型，比如服务调用、发布订阅和Actor模型等，被广泛应用的应该还是服务调用。我们知道微服务环境下的服务调用需要解决服务注册与发现、负载均衡、弹性伸缩等问题，其实Dapr在这方面什么都没做，正如上面所说，Dapr自身不提供基础设施，它将这些功能交给具体的部署平台（比如K8S）来解决。Dapr中于此相关唯有一个简单得不能再简单的NameResolution组件而已。 从部署的角度来看，Dapr的所有功能都体现在与应用配对的Sidecar上。我们进行服务调用得时候只需要指定服务所在得目标应用的ID（AppID）就可以了。服务请求（HTTP或者gRPC）从应用转到sidecar，后者会将请求“路由”到合适的节点上。如果部署在Kubernetes集群上，如果指定了目标服务的标识和其他相关的元数据（命名空间和集群域名等），服务请求的寻址就不再是一个问题。实际上NameResolution组件体现的针对“名字（Name）”的“解析（Resolution）”解决的就是如将Dapr针对应用的标识AppID转换成基于部署环境的应用标识的问题。从dapr提供的代码来看，它目前注册了如下3种类型的NameResolution组件： mdns：利用mDNS（Multicast DNS）实现服务注册与发现，如果没有显式配置，默认使用的就是此类型。由于mDNS仅仅是在小规模网络中采用广播通信实现的一种DNS，所以根本不适合正式的生成环境。kubernetes：适配Kubernetes的名字解析，目前提供稳定的版本。consul: 适配HashiCorp Consul的名字解析，目前最新为Alpha版本。二、Resolver一个注册的NameResolution组件旨在提供一个Resolver对象，该对象通过如下的接口来表示。如下面的代码片段所示，Resolver接口提供两个方法，Init方法会在应用启动的时候调用，作为参数的Metadata会携带于当前应用实例相关的元数据（包括应用标识和端口，以及Sidecar的HTTP和gRPC端口等）和针对当前NameResolution组件的配置。对于每一次服务调用，目标应用标识和命名空间等相关信息会被Sidecar封装成一个ResolveRequest 接口，并最为参数调用Resolver对象的ReolveID方法，最终得到一个于当前部署环境相匹配的表示，并利用此标识借助基础设施的利用完整目标服务的调用。