使用.NETCore应用面向服务的架构

### 使用.NET Core应用面向服务的架构 #### 1. OpenAPI标准 随着REST服务的使用日益增加，需要对REST服务接口进行描述，类似于为SOAP开发的接口描述，这就催生了OpenAPI标准。OpenAPI目前是3版本，用于描述REST API。整个服务通过一个JSON端点来描述，这个JSON对象有一个通用部分，包含服务的通用特性，如版本、描述和共享定义。每个服务端点还有一个特定部分，描述端点URL或URL格式、所有输入、所有可能的输出类型和状态码，以及所有授权协议，并且可以引用通用部分的定义。 虽然本书不详细介绍OpenAPI语法，但各种开发框架可以通过处理REST API代码和开发者提供的更多信息自动生成OpenAPI文档，团队无需深入了解OpenAPI语法。 #### 2. REST服务的授权和认证 由于REST服务是无状态的，当需要认证时，客户端必须在每个请求中发送认证令牌，通常放在HTTP授权头中，但具体取决于使用的认证协议。 - **API密钥认证**：最简单的认证方式是显式传输共享密钥，即API密钥。可以通过以下代码实现： ```plaintext Authorization: Api-Key <string known by both server and client> ``` 也可以在其他头中发送： ```plaintext X-API-Key: <string known by both server and client> ``` 不过，基于API密钥的认证需要HTTPS来防止共享密钥被盗。API密钥使用简单，但不包含用户授权信息，适用于客户端操作比较标准、没有复杂授权模式的情况，并且在请求中交换时容易在服务器或客户端受到攻击。 - **短生命周期令牌认证**：更安全的技术是用户登录后获得一个长期有效的共享密钥，登录返回一个短生命周期令牌，用于后续所有请求。当短生命周期密钥即将过期时，可以调用更新端点进行更新。 登录逻辑与基于短生命周期令牌的授权逻辑完全分离。登录通常基于接收长期凭证并返回短生命周期令牌的登录端点，登录凭证可以是用户名 - 密码对，也可以是其他类型的授权令牌。登录还可以通过基于X.509证书的各种认证协议实现。 最广泛使用的短生命周期令牌类型是Bearer令牌，每个Bearer令牌编码了其有效期信息和一系列用于授权的声明（claims）。Bearer令牌可以通过登录操作或更新操作返回，其特点是不与接收它的客户端或任何其他特定客户端绑定。客户端获得Bearer令牌后，就可以获得其声明所隐含的所有权利，甚至可以将其转移给第三方，使其获得相应权利。 与API密钥认证相比，基于Bearer令牌的认证遵循标准，必须使用以下授权头： ```plaintext Authorization: Bearer <bearer token string> ``` REST服务通常使用JWT令牌，它是通过对JSON对象进行Base64URL编码得到的。JWT的创建从一个JSON头和一个JSON有效负载开始，头指定令牌类型和签名方式，有效负载包含所有声明。例如： ```json { "alg": "RS256", "typ": "JWT" } ``` ```json { "iss": "issuerbomain.com", "sub": "example", "aud": ["S1", "S2"], "roles": [ "ADMIN", "USER" ], "exp": 1512975450, "iat": 1512968250230 } ``` 头和有效负载进行BASE64URL编码后连接起来，再用头中指定的算法（如RSA + SHA256）签名，最终得到Bearer令牌字符串。也可以使用对称签名，但需要JWT发行者和使用它进行授权的所有服务共享一个公共密钥，而使用RSA时，JWT发行者的私钥无需共享，因为可以仅使用发行者的公钥验证签名。 一些有效负载属性是标准的，如下表所示： | 属性 | 描述 | | ---- | ---- | | iss | JWT的发行者 | | aud | 受众，即可以使用该令牌进行授权的服务和/或操作 | | sub | 标识JWT发行对象（即用户）的字符串 | | iat | JWT发行时间 | | exp | JWT过期时间 | | nbf | 如果设置，令牌生效时间 | 其他声明如果用唯一URI表示则为公共声明，否则为发行者和其已知服务的私有声明。 #### 3. .NET Core对SOA的处理 .NET Core通过ASP.NET Core对REST服务提供了出色的支持。对于SOAP服务，经典.NET使用WCF技术处理。在WCF中，服务规范通过.NET接口定义，实际服务代码在实现这些接口的类中提供。端点、底层协议（HTTP和TCP/IP）和其他特性在配置文件中定义，该配置文件可以使用易于使用的配置工具进行编辑。这样，开发者只需提供服务行为作为标准的.NET类，并以声明方式配置所有服务特性，服务配置与实际服务行为完全分离，每个服务可以重新配置以适应不同环境，而无需修改代码。 不过，WCF技术未移植到.NET Core，也没有完全移植的计划。微软转而投资Google的开源技术gRPC，原因如下： - SOAP技术在大多数应用领域已被REST技术超越。 - WCF技术与Windows紧密相关，在.NET Core中从头重新实现其所有特性成本很高，而经典.NET仍会提供支持，需要WCF的用户可以继续依赖它。 - 作为一般策略，微软在.NET Core中更喜欢投资可以与其他竞争对手共享的开源技术。 虽然.NET Core不支持SOAP技术，但支持SOAP客户端。在Visual Studio 2017及更高版本中，可以很容易地为现有SOAP服务创建SOAP服务代理。操作步骤如下： 1. 在Visual Studio中右键单击“连接服务”节点，转到“解决方案资源管理器”，选择“添加连接服务”。 2. 在出现的表单中，选择“Microsoft WCF服务引用提供程序”。 3. 指定服务的URL（包含WSDL服务描述）、要添加代理类的命名空间等。 4. 向导结束后，Visual Studio会自动添加所有必要的NuGet包并搭建代理类，创建该类的实例并调用其方法即可与远程SOAP服务交互。 也有第三方NuGet包提供对SOAP服务的有限支持，但目前用处不大，因为其有限的支持不包含REST服务中没有的特性。 从.NET Core SDK开始，Visual Studio 2019支持gRPC项目模板，它可以搭建gRPC服务器和客户端。目前gRPC不是标准，只是Google的开源项目，但如果微软和Google继续投资，可能会成为事实上的标准。gRPC实现了远程过程调用模式，提供同步和异步调用。 gRPC的配置类似于WCF和.NET远程处理，服务通过接口定义，代码在实现这些接口的类中提供，客户端通过实现相同服务接口的代理与服务交互。gRPC适用于微服务集群内部通信，特别是不完全基于Service Fabric技术且不能依赖.NET远程处理的集群。由于主要语言和开发框架都有gRPC库，它可以用于基于Kubernetes的集群和托管其他框架实现的Docker镜像的Service Fabric集群。gRPC比REST服务协议更高效，数据表示更紧凑，使用更方便，但目前其特性没有基于成熟标准，只能用于集群内部通信。 #### 4. ASP.NET Core简介 ASP.NET Core应用程序是基于主机（Host）概念的.NET Core应用程序。`program.cs`文件创建、构建并运行主机，代码如下： ```csharp public class Program { public static void Main(string[] args) { CreateHostBuilder(args).Build().Run(); } public static IHostBuilder CreateHostBuilder(string[] args) => Host.CreateDefaultBuilder(args) .ConfigureWebHostDefaults(webBuilder => { webBuilder.UseStartup<Startup>(); }); } ``` `CreateDefaultBuilder`设置一个标准主机，`ConfigureWebHostDefaults`配置主机以处理HTTP管道，具体操作如下： - 设置`IHostingEnvironment`接口的`ContentRootPath`属性为当前目录。 - 从`appsettings.json`和`appsettings.[EnvironmentName].json`加载配置信息，这些信息可以通过ASP.NET Core选项框架映射到.NET对象属性。`appsettings.[EnvironmentName].json`中的特定环境信息会覆盖`appsettings.json`中的相应设置，`EnvironmentName`从`ASPNETCORE_ENVIRONMENT`环境变量获取，该变量在Visual Studio运行应用程序时在`Properties\launchSettings.json`文件中定义。例如，典型的`launchSettings.json`文件如下： ```json { "iisSettings": { "windowsAuthentication": false, "anonymousAuthentication": true, "iisExpress": { "applicationUrl": "http://localhost:2575", "sslPort": 44393 } }, "profiles": { "IIS Express ```