ABP VNext从单体切换到微服务-技术圈

https://www.cnblogs.com/CKExp/p/13735261.html
作者：微笑刺客D

注：此处的微服务只考虑服务部分，不考虑内外层网关、认证等。

ABP VNext从单体切换到微服务，提供了相当大的便利性，对于各模块内部不要做任何调整，仅需要调整承载体即可。

ABP can help you in that point by offerring a microservice-compatible, strict module architecture where your module is splitted into multiple layers/projects and developed in its own VS solution completely isolated and independent from other modules. Such a developed module is a natural microservice yet it can be easily plugged-in a monolithic application.

分层架构

ABP VNext自身提供的分层方式如下图，核心部分是Application、Domain与EntityFrameworkCore层，至于HttpApi.Client与HttpApi都是属于将应用去承载到其他系统之上的。

Controller层在ABP VNext中被削弱了，VNext提供了将Application提供动态Controller，所以可能习惯了将部分逻辑写在控制器中的会有些唐突，但理解就行。

规划层次结构

新建空文件夹，取名随意(本次取名GravelService)，用于存放整体项目。
在上一步的空文件夹内新建空白解决方案，可以用VS去生成或是按照dotnet的命令生成。

习惯上按照ABP VNext给定的微服务Demo中的格式创建三个文件夹，思路清晰。当然提供的微服务Demo还有更多文件夹，但是这次只关注这三个。

增加三个模块

设计三个限界上下文并绘制上下文映射。依照常见的订单、产品与客户划分成三个限界上下文。并规划好订单作为下游依赖产品与客户作为的上游。

从官网直接下载三个模块，或是按照命令行去生成(前提是已经安装了ABP CLI)，无论哪种方式，确保准备好就行，依照模块化思想，将其存到modules文件夹下。

如本次准备了三个模块Product，Order，Customer，依照实际需要，可以去精简一下内部文件，此处各模块内部我只留着src和test文件夹。

对于customer模块的src内部，具体生成的文件夹如下，对于其中的HttpApi、HttpApi.Client及MongoDB，我采取了剔除，无需这部分(在稍后的承载体中有同等功能)。

清理之后变得简简单单的。

对于test内部，同样采取剔除无需的HttpApi.CLient、MongoDB文件夹(注：此处的无需只是针对我而言，如果有需要还是留着吧)。

清理之后，层次划分变得简简单单的。

改造下各模块内给定的Sample案例，改造成各模块命名开头，方便加以区分。以Customer模块为例，将自带的Sample案例更名成Customer，仅作该项改动。

模拟服务调用

对于Order与Product模块内增加一个下游访问上游服务的链路，方便验证从单体跨越到微服务，底层服务的无需任何改动。对于下游访问上游服务的调用形式，了解到的有两种方式。

当前上下文的应用层直接依赖其他上下文的应用服务；
当前上下文设定出防腐层(在限界上下文间增加一层隔离，方便保证依赖限界上下文存在变动时只需更改隔离层)，在防腐层的实现中去依赖或远程调用其他上下文的应用服务；

我个人倾向于增加防腐层，虽然在VNext中并无相关说法。具体使用时，在领域层或应用层增加防腐层接口，及在EF Core层给与防腐层实现，此时的EF Core层，更应该更名为基础设施层，而不单单是作为资源库的形式。

在Order中Domain层增加ServiceClients文件夹用于存放防腐层接口，而在EntityFrameworkCore层增加ServiceClients文件夹用于存放防腐层实现。

在防腐层接口中增加IProductServiceClient。

public interface IProductServiceClient : ITransientDependency
{
    Task<int> GetProductId();
}

在防腐层实现中增加ProductServiceClient。
在Order中的EntityFrameworkCore层引用Product模块内的Application.Contracts层。
依赖ProductAppService并完成调用。

public class ProductServiceClient : IProductServiceClient
{
    private readonly IProductAppService _productAppService;
    public ProductServiceClient(IProductAppService productAppService)
    {
        _productAppService = productAppService;
    }
    public async Task<int> GetProductId()
    {
        var productDto = await _productAppService.GetAsync();
        return productDto.Value;
    }
}

在OrderAppService中依赖防腐层接口，并完成调用。

public class OrderAppService : OrderManagementAppService,   IOrderAppService
{
    private readonly IProductServiceClient _productServiceClient;
    public OrderAppService(IProductServiceClient productServiceClient)
    {
        _productServiceClient = productServiceClient;
    }
    public async Task GetAsync()
    {
        var productId = await _productServiceClient.GetProductId();
        ...
    }
}

这样一来，在防腐层实现中便可以使用到Product上下文的应用服务了，对于这个应用服务的请求是当前进程内的还是进程间的，由具体的承载方式而决定。

大单体承载

将依照如下图，将三个模块承载到GravelService.Host上。

新建一个GravelService.Host的项目,采用WebApi类型即可。存放到microservices文件夹下，这样方便理解整个层级划分。

其次依赖一些基本的Nuget包，诸如ABP自身的及方便展示Api的Swagger。本次不考虑实体的创建，也就不考虑EF Core包的依赖了。

Volo.Abp
Volo.Abp.AspNetCore.MultiTenancy
Volo.Abp.AspNetCore.Mvc
Volo.Abp.Autofac
Swashbuckle.AspNetCore

引用各模块内的Application层及EntityFrameworkCore层。模仿着给定的微服务Demo，完成一波CV操作。增加一个类出来承担着服务与中间件的配置。

在其中依赖引用的各Application层及EntityFrameworkCore层中的Module，这样一来模块依赖就搞定了。

[DependsOn(
    typeof(AbpAutofacModule),
    typeof(AbpAspNetCoreMvcModule),
    typeof(AbpAspNetCoreMultiTenancyModule),
    typeof(CustomerManagementApplicationModule),
    typeof(CustomerManagementEntityFrameworkCoreModule),
    typeof(OrderManagementApplicationModule),
    typeof(OrderManagementEntityFrameworkCoreModule),
    typeof(ProductManagementApplicationModule),
    typeof(ProductManagementEntityFrameworkCoreModule)
   )]
public class GravelServiceHostModule : AbpModule
{
  ...
}

增加服务配置，将各模块中的应用服务动态转换成Api控制器。

Configure(options =>
{
    options.ConventionalControllers
        .Create(typeof(CustomerManagementApplicationModule).Assembly,
        opts =>
        {
            opts.RootPath = "CustomerManagement";
        })
        .Create(typeof(OrderManagementApplicationModule).Assembly,
        opts =>
        {
            opts.RootPath = "OrderManagement";
        })
        .Create(typeof(ProductManagementApplicationModule).Assembly,
        opts =>
        {
            opts.RootPath = "ProductManagement";
        });
});

然后，启动即可，所有模块中的接口都承载到了该承载体中。

通过访问Order的api/OrderManagement/order接口获得返回的9527，也就验证了，防腐层内去访问Product上下文的应用服务。

此时是在同一进程内，使用到的是ProductAppService的具体实现，断点查看也可看出当前进程内的请求，依赖其他上下文服务的应用服务为ApplicationServiceProxy。

多服务承载

依照如下图开始切换承载模式，只更改承载体，将一个大的承载体切分成各上下文独自承载体。

新建三个和GravelService.Host同等的WebApi项目。在GravelService.Host上裁剪即可，每个独立的承载体只拥有自身的上下文。

依据上下文映射关系，对处于下游的Order承载体增加对上游Product的依赖，在Order承载体中增加对Product模块中Application.Contracts层的依赖。并在服务配置中完成依赖(第7行)。

[DependsOn(
    typeof(AbpAutofacModule),
    typeof(AbpAspNetCoreMvcModule),
    typeof(AbpAspNetCoreMultiTenancyModule),
    typeof(OrderManagementApplicationModule),
    typeof(OrderManagementEntityFrameworkCoreModule),
    typeof(ProductManagementApplicationContractsModule)
    )]
public class OrderServiceHostModule : AbpModule
{
...
}

配置远程服务代理，在服务配置中设置从Order承载体到Product承载体的远程服务请求。在Order承载体中增加Volo.Abp.Http.Client包并在服务配置中完成依赖。

[DependsOn(
    ...
    typeof(AbpHttpClientModule),
    ...
    )]
public class OrderServiceHostModule : AbpModule
{
    public override void ConfigureServices(ServiceConfigurationContext context)
    {
        var configuration = context.Services.GetConfiguration();
        ...   
        context.Services.AddHttpClientProxies(         typeof(ProductManagementApplicationContractsModule).Assembly);
        ...
    }
}

在配置源appsettings文件中加入对Product承载体的远程调用地址

 {
  "RemoteServices": {
    "Default": {
      "BaseUrl": "http://localhost:57687"
    }
}

更改项目配置，启动多个文件，一并启动三个独立承载体，再次调用Order中的Get请求，同样获得了从Product上下文的应用服务中的数据

这次采用的不同进程间的承载方式，通过防腐层，然后经ABP提供的Http代理服务调用Product承载体，可以断点查看当前在防腐层中的AppService类型，已经不再是直接使用ProductAppService了。

真香

从大单体承载切换多服务承载，Modules部分不需要做任何更改，着实方便。至于内部的远程调用，本身ABP VNext还存在一些问题像类似集合的Get请求在3.1的版本中才做了修复，但是这丝毫不影响这一巨人的前行。