Asp.Net Core

138 阅读7分钟

Asp.Net Core

PRC

RPC指的是远程过程调用(Remote Procedure Call),它是一种计算机通信协议,用于在不同的进程或计算机之间进行通信和调用远程服务。通过RPC,一个程序可以请求另一个计算机上的程序执行,并且不需要显式地处理网络细节。

RPC的工作原理通常涉及以下步骤:

  1. 客户端调用: 客户端程序调用本地的代理库(Proxy),该代理库包装了要调用的远程过程的信息。
  2. 网络传输: 代理库将封装好的请求通过网络发送到远程计算机上的服务。
  3. 服务端响应: 远程计算机上的服务接收到请求后执行相应的操作,并将结果返回给客户端。
  4. 客户端响应处理: 客户端代理库接收到响应后,将结果返回给调用程序。

常见的RPC协议包括基于HTTP的RESTful API、基于TCP的gRPC(Google Remote Procedure Call)、基于HTTP的JSON-RPC等。RPC使得分布式系统中的各个部分能够像调用本地函数一样调用远程服务,极大地简化了分布式系统的开发和维护。

  • 支持使用 gRPC 托管远程过程调用 (RPC)。

gRPC 的主要优点是:

  • 现代高性能轻量级 RPC 框架。
  • 协定优先 API 开发,默认使用协议缓冲区,允许与语言无关的实现。
  • 可用于多种语言的工具,以生成强类型服务器和客户端。
  • 支持客户端、服务器和双向流式处理调用。
  • 使用 Protobuf 二进制序列化减少对网络的使用。

这些优点使 gRPC 适用于:

  • 效率至关重要的轻量级微服务。
  • 需要多种语言用于开发的 Polyglot 系统。
  • 需要处理流式处理请求或响应的点对点实时服务。

托管服务

未使用 IIS 托管时,ASP.NET Core 项目模板默认使用 Kestrel。

Kestrel 的功能包括:
  • **跨平台:**Kestrel 是可在 Windows、Linux 和 macOS 上运行的跨平台 Web 服务器。

  • **高性能:**Kestrel 经过优化,可有效处理大量并发连接。

  • **轻量级:**它经过优化,可在资源受限的环境(如容器和边缘设备)中运行。

  • **强化了安全性:**Kestrel支持 HTTPS 并经过强化可抵御 Web 服务器漏洞。

  • 宽协议支持:

    Kestrel 支持常见的 Web 协议,包括:

  • **与 ASP.NET Core 集成:**与其他 ASP.NET Core 组件(例如中间件管道、依赖项注入和配置系统)无缝集成。

  • 灵活工作负载

    :Kestrel 支持许多工作负载:

    • ASP.NET 应用框架,例如最小 API、MVC、Razor 页、SignalR、Blazor 和 gRPC。
    • 使用 YARP 生成反向代理。
  • **扩展性:**通过配置、中间件和自定义传输自定义 Kestrel。

  • **性能诊断:**Kestrel 提供内置的性能诊断功能,例如日志记录和指标。

仓储+服务架构模式

Repository 仓储只和数据库交互

Service 对从数据库中查询出来的数据 做一个细化

仓储+服务架构模式通常指的是一种软件架构模式,特别是在微服务架构中比较常见。这种模式将系统的功能模块划分为两大类:

  1. 仓储(Repository)
    • 仓储层主要负责数据的持久化和访问,通常与数据库或其他数据存储系统进行交互。
    • 它提供了数据访问的接口和实现,隐藏了数据访问细节,使得业务逻辑层可以专注于业务处理,而不用关心数据存储和访问的具体实现。
  2. 服务(Service)
    • 服务层则包含了系统的业务逻辑,通过调用仓储层提供的接口来完成特定的业务功能。
    • 这些服务可以是独立的、自治的,每个服务关注一个特定的业务功能或用例,通过组合仓储层的数据来完成操作。

在实际应用中,这种架构模式有助于实现以下几个优势:

  • 分离关注点(Separation of Concerns):将数据存储和业务逻辑分离,提高了系统的可维护性和可测试性。
  • 单一职责原则(Single Responsibility Principle):每个模块(仓储或服务)只需关注自己的职责,降低了耦合度。
  • 可扩展性和灵活性(Scalability and Flexibility):可以根据需求独立扩展仓储或服务,而不影响整体系统的其他部分。

总结来说,仓储+服务架构模式在软件开发中被广泛应用,特别是在复杂系统中,通过清晰的分层和责任划分,提升了系统的整体结构和开发效率。

依赖注入

在NetCore开发中,减少new的使用,尽量使用依赖注入。(不应该使用new,比如复杂的链路、GC回收、内存泄露等)

  1. 松耦合性(Loose Coupling)
    • 使用依赖注入可以减少类与类之间的直接依赖关系。当一个类直接通过 new 创建其它类的实例时,它们之间的耦合度很高,难以维护和测试。而通过依赖注入,类不需要负责自己的依赖关系的创建和生命周期管理,只需声明依赖,由外部容器来负责注入。
  2. 可测试性(Testability)
    • 依赖注入使得单元测试更加简单和有效。通过注入依赖的方式,可以轻松地在测试时用模拟对象替换真实的依赖,从而隔离被测试对象的行为,确保测试的独立性和可重复性。
  3. 灵活性和可维护性(Flexibility and Maintainability)
    • 使用依赖注入可以更容易地进行代码重构和更改。当系统需要更换某个依赖实现时,只需调整依赖注入容器中的配置,而不需要修改大量的代码。这种灵活性使得系统更易于扩展和维护。
  4. 单一职责原则(Single Responsibility Principle)
    • 依赖注入有助于确保每个类专注于其主要职责,而不涉及创建和管理依赖对象的逻辑。通过外部注入依赖,类的职责更加清晰和单一,有助于代码的组织和理解。
  5. 更好的代码组织和可读性
    • 使用依赖注入容器管理依赖关系,可以将配置和实现解耦,使代码更加整洁和易于理解。依赖注入明确地表达了类之间的依赖关系,提高了代码的可读性和可维护性。

总结来说,依赖注入通过将依赖关系的管理和对象的创建解耦,提高了代码的灵活性、可测试性和可维护性,使得代码更加清晰和易于扩展。相比之下,直接使用 new 创建对象容易导致代码耦合度高、难以测试和维护。

Program.cs
  • AddScoped:每个请求(scope)返回一个新的实例,适合于 Web 应用程序中,确保在同一请求中共享同一个实例。
  • AddTransient:每次请求都返回一个新的实例。
  • AddSingleton:整个应用程序生命周期中只有一个实例。

这些方法接受两个参数:服务接口类型和具体实现类型

  1. 服务的生命周期
    • Scoped:在同一个 Scope(如一个 HTTP 请求)中共享同一个实例。
    • Transient:每次请求都创建一个新的实例。
    • Singleton:整个应用程序生命周期中只创建一个实例。

如果我七点起来 12点睡觉 那么我一天就有 24-7=17个小时