介绍
通过使用服务调用,您的应用程序可以使用标准的gRPC或HTTP协议与其他应用程序可靠、安全地通信。
为什么不直接用HttpClientFactory呢
先问几个问题:
- 如何发现和调用不同服务的方法
- 如何安全地调用其他服务,并对方法应用访问控制
- 如何处理重试和瞬态错误
- 如何使用分布式跟踪指标来查看调用图来诊断生产中的问题
此时你会发现这些事情HttpClientFactory没有帮你完成,而在微服务中这些又是必不可少的能力,接下来看看服务调用都做了什么
服务调用如何工作的
先看一下两个服务之间的调用顺序
-
服务A 向服务B发起一个HTTP/gRPC的调用。调用转到了本地的Dapr sidecar
-
Dapr使用名称解析组件发现服务B的位置
-
Dapr 将消息转发至服务 B的 Dapr sidecar
注: Dapr sidecar之间的所有调用都通过gRPC来提高性能。 仅服务与 Dapr sidecar之间的调用可以是 HTTP或gRPC
-
服务B 的 Dapr sidecar将请求转发至服务B 上的特定端点 (或方法) 。 服务B 随后运行其业务逻辑代码
-
服务B 发送响应给服务A。 响应将转至服务B 的Dapr sidecar
-
Dapr 转发响应至服务A 的 Dapr sidecar
-
服务 A 接收响应
命名空间作用域
默认情况下,调用同一个命名空间的其他服务可以直接使用AppID(假设是:nodeapp)
localhost:3500/v1.0/invoke/nodeapp/method/neworder
服务调用也支持跨命名空间调用,在所有受支持的宿主平台上,Dapr AppID遵循FQDN格式,其中包括目标命名空间。
FQDN:(Fully Qualified Domain Name)全限定域名:同时带有主机名和域名的名称。(通过符号“.”)
例如:主机名是bigserver,域名是mycompany.com,那么FQDN就是bigserver.mycompany.com
注:FQDN是通过符号.
来拼接域名的,这也就解释了AppID为什么不能用符号.
,这里不记住的话,应该会有不少小伙伴会踩坑
比如.net开发者习惯用 A.B.C
来命名项目,但AppID需要把.
换成-
且所有单词最好也变成小写 (a-b-c),建议把它变成约定遵守
比如调用命名空间:production,AppID:nodeapp
localhost:3500/v1.0/invoke/nodeapp.production/method/neworder
这在K8s集群中的跨名称空间调用中特别有用
服务间安全性
通过托管平台上的相互(mTLS)身份验证,包括通过Dapr Sentry服务的自动证书转移,可以确保Dapr应用程序之间的所有调用的安全。 下图显示了自托管应用程序的情况。
访问控制
应用程序可以控制哪些其他应用程序可以调用它们,以及通过访问策略授权它们做什么。 这使您能够限制具有个人信息的敏感应用程序不被未经授权的应用程序访问,并结合服务到服务的安全通信,提供了软多租户部署。
具体的访问控制后续章节会介绍
重试
在调用失败和瞬态错误的情况下,服务调用执行自动重试,并在回退时间段内执行。
注:自动重试,默认是开启的,可以关。但如果不关且业务又不支持幂等是很危险的。建议服务的接口要设计支持幂等,这在微服务里也是一个标配的选择。
导致重试的错误有:
网络错误,包括端点不可用和拒绝连接。
由于在调用/被调用的Dapr sidecars上更新证书而导致的身份验证错误。
每次呼叫重试的回退间隔为1秒,最多为3次。 通过gRPC与目标Sidecar连接的超时时间为5秒
可插拔的服务发现
Dapr可以在各种托管平台上运行。 为了启用服务发现和服务调用,Dapr使用可插拔的名称解析组件。 例如,K8s名称解析组件使用K8s DNS服务来解析集群中运行的其他应用程序的位置。 自托管机器可以使用mDNS名称解析组件。 Consul名称解析组件可以在任何托管环境中使用,包括K8s或自托管环境
划重点,自托管机器使用mDNS,在开发环境中后面文章会推荐VS上的无缝开发体验,就是基于mDNS的
但它有点点小问题,我们已经解决了。你只需要像开发一个控制台程序一样,基于Minimal API开心的F5就可以了
建议还没有了解Minimal API的小伙伴可以研究起来了,真香
使用mDNS进行轮询负载均衡
一图胜千言,就使用mDNS轮着调用
可观测性的跟踪和指标
默认情况下,将跟踪应用程序之间的所有调用,并收集指标,以提供应用程序的洞察力和诊断,这在生产场景中尤其重要。 这为您提供了服务之间调用的调用图和指标。
服务调用API和gRPC代理
pythonapp 通过Dapr sidecar调用nodeapp,通过服务调用的API及gRPC代理依然是上面见到的那个调用流程,做到了语言无关
使用HTTP调用服务
创建Assignment.Server
创建ASP.NET Core空
项目,并修改launchSettings.json
,让启动HTTP的启动端口变为5000
profiles.Assignment.Server.applicationUrl 的值改为 "https://localhost:6000;http://localhost:5000"
修改Program.cs
文件
var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();
app.MapPost("/", () => Console.WriteLine("Hello!"));
app.MapGet("/Hello1", () =>
{
Console.WriteLine("Hello World1!");
return $"\"Hello World1!\"";
});
app.MapPost("/Hello2", () => Console.WriteLine("Hello World2!"));
app.Map("/Hello3", () => Console.WriteLine("Hello World3!"));
app.Run();
此时一共有4个服务
-
/ :Post方法,打印Hello!
-
/Hello1:Get方法,打印Hello World1!,返回Hello World1!
注:返回的类型要是Json字符串,方便SDK反序列化
-
/Hello2:Post方法,打印Hello World2!
-
/Hello3:不带后缀表示适配所有方法,打印Hello World3!
先使用Dapr CLI来验证一下
运行Assignment.Server
:在目录dapr-study-room\Assignment04\Assignment.Server
打开命令行工具,并执行下面命令
dapr run --app-id assignment-server --app-port 5000 dotnet watch
细心的小伙伴应该可以发现与上一篇的命令有一点点不同,dontet run变成了dotnet watch,这样会开启热重载,方便调试
调用服务:再打开一个新的命令行工具,并执行下面命令
dapr invoke --app-id assignment-server --method /
dapr invoke --app-id assignment-server --method Hello1
dapr invoke --app-id assignment-server --method Hello2
dapr invoke --app-id assignment-server --method Hello3
可以发现4个命令都调用成功了,但是Assignment.Server
输出结果有点意外
== APP == Hello!
== APP == Hello World2!
== APP == Hello World3!
是的,没有Hello World1!
,那怎么办呢?我们把Hello1的命令改一下
dapr invoke --app-id assignment-server --method Hello1 --verb GET
invoke调用的输出除了App invoked successfully
以外还多了一行Hello World1!
与此同时Assignment.Server
的输出正确了
== APP == Hello World1!
除此之外invoke
还有一些参数,比如--data
,--data-file
,喜欢研究Dapr CLI的小伙伴可以继续尝试。不过一般情况下用SDK就可以了
创建Assignment.Client
HTTP服务调用
创建控制台应用程序
项目,使用NuGet包管理器添加Dapr.Client
SDK,并修改Program.cs
文件
using Dapr.Client;
var appId = "assignment-server";
var client = new DaprClientBuilder().Build();
await client.InvokeMethodAsync(appId, "/");
var resp = await client.InvokeMethodAsync<string>(HttpMethod.Get, appId, "Hello1");
Console.WriteLine($"Hello1 Response: {resp}");
await client.InvokeMethodAsync(appId, "Hello2");
await client.InvokeMethodAsync(appId, "Hello3");
看几个细节
-
DaprClient是从
DaprClinetBuilder
Build出来的还有一种方式使用DaprClient,通过DI
首先都是需要添加
Dapr.AspNetCore
NuGet包然后开始有分支了,如果是以前Web API的方式可以在Startup.cs文件
ConfigureServices
方法加入一行代码services.AddControllers().AddDapr();
如果使用Minimal API默认是没有Controllers的,那可以在
var builder = WebApplication.CreateBuilder(args);
之后加入一行代码builder.Services.AddDaprClient();
成功的注入进来了,在
构造函数
或者[FromServices]
里愉快的玩耍吧 -
HttpMethod.Post 的我都没有指定,默认就是Post
-
HttpMethod.Get的时候,返回值会自动用Json反序列化
不喜欢Json?可以通过 DaprClient.CreateInvokeHttpClient 构造 HttpClient,聪明的你肯定知道后面怎么办了
注:
1. Minimal API虽香,但新,所以不是所有功能都支持,比如从参数中直接映射状态管理,要等Minimal API支持Model Binder以后且SDK也同步支持了才可以
2. DaprClient是TCP的,也是线程安全的,可以大胆的复用,如果不用DI的话不需要频繁构建DaprClient
验证调用成功
使用命令行工具打开目录dapr-study-room\Assignment04\Assignment.Client
,然后执行命令
dotnet run
如果你不是用VS Code终端的PowerShell执行dapr run就可能遇到下面的错误
即便你没有遇到也建议了解一下如何支持非默认端口
An exception occurred while invoking method: '/' on app-id: 'assignment-server'
---> System.Net.Http.HttpRequestException: 由于目标计算机积极拒绝,无法连接。 (127.0.0.1:3500)
---> System.Net.Sockets.SocketException (10061): 由于目标计算机积极拒绝,无法连接。
因为上面使用dapr run的时候没有指定dapr http port,而默认client访问的是3500端口
解决的办法有两种:
-
修改
Assignment.Server
启动参数,增加--dapr-http-port 3500
,这个方法治标不治本,因为将来我们可能启动多个服务dapr run --app-id assignment-server --app-port 5000 --dapr-http-port 3500 dotnet watch
-
修改
Assignment.Client
的环境变量首先执行
dapr list
查看端口,以下面为例,HTTP PORT是51460
APP ID HTTP PORT GRPC PORT APP PORT COMMAND AGE CREATED PID
assignment-server 51460 51461 5000 dotnet watch 7s 2021-10-29 14:13.49 11676
修改
Assignment.Client
的启动参数,注意把51460
换成你自己的端口,使用PowerShell
执行下面命令$Env:DAPR_HTTP_PORT = 51460 dotnet run
再执行一次dotnet run
就可以看到正确的输出结果了
Hello1 Response: Hello World1!
gRPC服务调用
篇幅太长了,举一反三吧。就是调用InvokeMethodGrpcAsync
,然后dapr-http-port换成dapr-grpc-port,DAPR_HTTP_PORT换成DAPR_GRPC_PORT
查看跟踪
还记得dapr init的时候docker里有个zipkin吧,通过zipkin可以看一下调用跟踪,通过浏览器打开下面地址
此时页面是空的
根据步骤操作一下就可以看到了
随便点开一行数据尾部的SHOW,就可以看到调用详情
本章源码
Assignment04
https://github.com/doddgu/dapr-study-room
我们正在行动,新的框架、新的生态
我们的目标是*的
、易用的
、可塑性强的
、功能丰富的
、健壮的
。
所以我们借鉴Building blocks的设计理念,正在做一个新的框架MASA Framework
,它有哪些特点呢?
- 原生支持Dapr,且允许将Dapr替换成传统通信方式
- 架构不限,单体应用、SOA、微服务都支持
- 支持.Net原生框架,降低学习负担,除特定领域必须引入的概念,坚持不造新*
- 丰富的生态支持,除了框架以外还有组件库、权限中心、配置中心、故障排查中心、报警中心等一系列产品
- 核心代码库的单元测试覆盖率90%+
- 开源、免费、社区驱动
- 还有什么?我们在等你,一起来讨论
经过几个月的生产项目实践,已完成POC,目前正在把之前的积累重构到新的开源项目中
目前源码已开始同步到Github(文档站点在规划中,会慢慢完善起来):
QQ群:7424099
微信群:加技术运营微信(MasaStackTechOps),备注来意,邀请进群