如今，完全独立的业务应用几乎不存在，不管是在企业内部微服务之间的调用，还是与外部第三方服务的调用，Http的API交互是常见的场景，这些实际情况给我们的开发带来了比较大的挑战，一是第三方服务可能会牵制我们的开发进度，特别是在多团队开发的情况下，由于依赖于其他团队的服务，有时候需要等待其他团队的进度，导致自己团队的无效等待。有时因为其他团队的延期，导致团队的被动延期。二是第三方服务的质量问题或开发过程中的频繁更新导致的部署问题，将严重拖累自己团队的开发进度，同时让你无法专心的开发自己的服务。三是单元测试困难，特别是在依赖于多个第三方服务时，使得单元测试可能依赖于其他服务环境，导致单元测试结果的不确定性。
为了解决以上这些问题，Xfrogcn.AspNetCore.Extensions扩展库提供了Http请求模拟的功能，通过此功能可以让你在开发、单元测试时实现你的服务与第三方服务的完全解耦，让你能够更聚焦于自己服务的开发。
Http请求模拟构建在.NET Core HttpClientFactory架构之上，通过在HttpClient请求管道中替换实际发送Http请求的主消息处理器为模拟消息处理器来完成请求的模拟应答。
一、在服务端使用
假设我们负责开发一个订单服务，在订单提交接口，我们保存完订单数据之后，需要发送消息通知，消息通知的发送由消息服务来实现，该服务由另一团队负责，如下图所示：
由于订单服务依赖于消息服务，在项目启动时，一般两个团队会协商好消息服务的接口定义，然后消息服务团队会快速搭建一个空接口供订单服务团队调用，如果是这种流程，订单服务团队只需等待消息服务团队搭建好环境即可开始工作，好像影响不大，但在实际开发过程中，会存在以下现本文来源gaodai#ma#com搞@@代~&码*网/实的问题：
- 虽然消息服务团队提供空接口的时间不长，但是如果项目工期紧张，计划都是以小时计算，那么这也将影响订单服务的开发进度
- “空消息服务”实际上无法一直保持空的状态，消息服务团队会不断对服务进行更新加入他们的实现逻辑，而消息服务本身也可能依赖于其他的服务，这导致订单团队所使用的消息服务不稳定，那么订单团队的进度实际上还是会受到消息服务团队，以及消息服务所依赖的其他团队的影响。
- 订单服务团队可以使用空的消息服务，但消息服务团队往往需要连接企业外部的第三方服务，比如App的消息推送通道，这让整个项目依赖更加复杂。
- 订单服务团队编写单元测试会比较困难（当然，此点可以通过抽象来解决，但结合扩展库的Http请求模拟功能，我们可以简化此过程）
以下介绍如何使用扩展库的请求模拟功能。
为了聚焦于模拟功能的演示，该示例进行了简化，比如与消息服务的通讯，在正式项目中会通过消息服务的SDK来完成，示例中将直接使用HttpClient，有关SDK与扩展库的结合，我们将在后续文章中说明。
1.引用Xfrogcn.AspNetCore.Extensions
2.定义订单类
public class Order
{
public string Id { get; set; }
public string ProductCode { get; set; }
public decimal Price { get; set; }
public int Quantity { get; set; }
public decimal Amount { get; set; }
}
转载请注明原文链接：ASP.NET Core扩展库之Http请求模拟功能的使用
