本文主要是讲解《面向 .NET 开发人员的 Dapr》实例程序的实操。
有兴趣可以详看这本书。
交通控制示例应用程序模拟高速公路交通控制系统。 其用途是检测超速车辆,并向违规司机发送罚款通知。 这些系统实际上存在于现实生活中,下面是它们的工作原理。 一组摄像头(每个车道上方各一个)被放置在高速公路的起点和终点(假设该路段为 10 公里),没有上匝道或下匝道。 当车辆在摄像头下方经过时,摄像头会拍摄车辆照片。 使用光学字符识别 (OCR) 软件,从照片中提取车辆的车牌号。 系统使用每个车辆的入口和出口时间戳来计算该车辆的平均速度。 如果平均速度高于高速公路的最大速度限制,系统会检索司机信息并自动发送罚款通知。
所需环境
Attribute | Details |
---|---|
Dapr runtime version | v1.9.3 |
Dapr.NET SDK version | v1.9.0 |
Dapr CLI version | v1.9.1 |
Language | C# |
Platform | .NET 6 (SDK 6.0.402) |
Environment | Self hosted or Kubernetes |
服务通过直接调用彼此的 API 进行通信。 此设计可以正常运作。
设计难点如下:
问题 | 解决方案 |
---|---|
如果其中一项服务处于脱机状态,则调用链将中断 | 通过将直接调用替换为异步消息传递来分离服务,可以解决此问题。 异步消息传送通常使用消息代理(如 RabbitMQ 或 Azure 服务总线)来实现。 |
每个车辆的车辆状态都存储在 TrafficControl 服务的内存中。 如果服务在更新或崩溃后重新启动,则此状态将丢失 | 要提高系统持久性,应将状态存储在服务外部。 |
Dapr 的目标之一是为微服务应用程序提供云原生功能。 交通控制应用程序使用 Dapr 构建基块来提高可靠性并缓解上文所述的设计缺陷所带来的影响。
在自托管模式下,一切都将在本地计算机上运行。为了防止端口冲突,所有服务都侦听不同的HTTP端口。使用Dapr运行服务时,需要额外的端口voor HTTP和gRPC与Sidecar通信。默认情况下,这些端口为“3500”和“50001”。但为了避免混淆,您将在分配中使用完全不同的端口号。服务将使用以下端口:
Service | Application Port | Dapr sidecar HTTP port | Dapr sidecar gRPC port |
---|---|---|---|
TrafficControlService | 6000 | 3600 | 60000 |
FineCollectionService | 6001 | 3601 | 60001 |
VehicleRegistrationService | 6002 | 3602 | 60002 |