ABP VNext框架如果不考虑在微服务上的应用，也就是开发单体应用解决方案，虽然也是模块化开发，但其集成使用的难度会降低一个层级，不过ABP VNext和ABP框架一样，基础内容都会设计很多内容，如数据库都支持Oracle、SQLServer、MySql、PostgreSQL、SQLite，都有利用Redis作为分布式缓存，使用RabbitMQ作为事件总线的消息处理方式，使用MongoDB的NoSQL类型数据库作为特殊数据的存储服务，使用Quartz/HangFire作为定时任务的处理等。如果考虑引入微服务的话，会更需要了解IdentityServer服务，以及了解Ocelot库管理网关，使用 Elasticsearch & Kibana 来存储和可视化日志 (使用Serilog写日志)，有时候感觉引入框架并非一件轻松的事情，各种知识点一股脑的涌来。

"作为面向服务架构(SOA)的一个变体,微服务是一种将应用程序分解成松散耦合服务的新型架构风格. 通过细粒度的服务和轻量级的协议,微服务提供了更多的模块化,使应用程序更容易理解,开发,测试,并且更容易抵抗架构侵蚀. 它使小型团队能够开发,部署和扩展各自的服务,实现开发的并行化.它还允许通过连续重构形成单个服务的架构. 基于微服务架构可以实现持续交付和部署."

ABP VNext 框架引入微服务后，就需要使用API网关来，ABP框架可以使用Ocelot来做网关统一处理上游的HTTP请求，并在内部网络上使用内部网关，处理微服务之间的调用，从而把微服务的调用接口统一为一个固定的模式处理。本篇随笔介绍一下网关的基本智知识，以及ABP VNext 框在引入Ocelot来做网关后的架构图场景，介绍一下ABP VNext 微服务的案例的基本情况。

1、网关和认证服务的介绍

API网关是系统暴露在外部的一个访问入口。就像一个公司的门卫承担着寻址、限制进入、安全检查、位置引导、等等功能。从面向对象设计的角度看，它与外观模式类似。API网关封装了系统内部架构，为每个客户端提供一个定制的API。它可能还具有其它职责，如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理等等。
API网关方式的核心要点是，所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能。通常，网关也是提供REST/HTTP的访问API。

Ocelot是一个用.NET Core技术实现并且开源的API网关技术，它的功能包括了：路由、请求聚合、服务发现、认证、鉴权、限流熔断、并内置了负载均衡器、Service Fabric、Butterfly Tracing等的集成。而且这些功能都只需要简单的配置即可完成。

Ocelot首先通过配置将HttpRequest对象保存到一个指定的状态直到它到达用来创建HttpRequestMessage对象并将创建的HttpRequestMessage对象发送到下游服务中的请求构造中间件。通过中间件来发出请求是Ocelot管道中做的最后一件事。它不会再调用下一个中间件。下游服务的响应会存储在每个请求 scoped repository中，并作为一个请求返回到Ocelot管道中。有一个中间件将HttpResponseMessage映射到HttpResponse对象并返回给客户端。

单网关服务示意图如下所示。

API 网关一般放到微服务的最前端，并且要让API 网关变成由应用所发起的每个请求的入口。这样就可以明显的简化客户端实现和微服务应用程序之间的沟通方式。

上游和下游描述消息流：所有 消息从上游流动到下游。

网关作为上游会接收所有的客户端请求，并路由到对应的下游服务器进行处理，再将请求结果返回。而这个上下游请求的对应关系也被称之为路由。

我们的下游服务接口都是公开的，没有经过任何的认证，只要知道接口的调用方法，任何人都可以随意调用，因此，很容易就造成信息泄露或者服务被攻击。

正如，我要找Wlling干活之前，我得先到 HR 部门那里登记并且拿到属于我自己的工卡，然后我带着我的工卡去找Wlling，亮出我是公司员工的身份，并且有权利要求他帮我完成一个任务。

IdentityServer4认证服务器有多种认证模式，包括用户密码、客户端等等。客户端需要先想IdentityServer4 请求认证，获得一个token，然后再带着这个token向下游服务发出请求。

ApiResources 为数组类型，表示identityserver管理的所有的下游服务列表。

• Name: 下游服务名称
• DisplayName: 下游服务别名

Clients为数组类型，表示identityserver管理的所有的上游客户端列表

• ClientId: 客户端id
• ClientSecret: 客户端对应的密钥
• GrantType: 该客户端支持的认证模式
• Scope: 该客户端支持访问的下游服务列表，必须是在apiresources列表中登记的

当接入ocelot网关时，我们要达到内外互隔的特性，于是就把identityserver服务也托管到ocelot网关中，这样我们就能统一认证和服务请求时的入口。

如ABP案例中的微服务网关【PublicWebSiteGateway.Host】项目中的配置内容，配置服务器上下游的信息如下所示。

"Routes": [
{
"DownstreamPathTemplate": "/api/productManagement/{everything}",
"DownstreamScheme": "https",
"DownstreamHostAndPorts": [
{
"Host": "localhost",
"Port": 44344
}
],
"UpstreamPathTemplate": "/api/productManagement/{everything}",
"UpstreamHttpMethod": [ "Put", "Delete", "Get", "Post" ]
},
{
"DownstreamPathTemplate": "/api/blogging/{everything}",
"DownstreamScheme": "https",
"DownstreamHostAndPorts": [
{
"Host": "localhost",
"Port": 44357
}
],
"UpstreamPathTemplate": "/api/blogging/{everything}",
"UpstreamHttpMethod": [ "Put", "Delete", "Get", "Post" ]
}
],
"GlobalConfiguration": {
"BaseUrl": "https://localhost:44397"
},

多网关服务示意图如下所示，这种模式是针对不同的客户端来实现一个不同的API网关。

ABP VNext 框架里面也采用了多网关的应用，其微服务的整体架构图如下所示。

其中网关包含了后台管理应用网关【BackendAdminAppGateway.Host】，以及公开的应用接入网关【PublicWebSiteGateway.Host】，而内部网关服务【InternalGateway.Host】，则是用于内部微服务之间调用的统一网关解析。

ABP VNext框架中的微服务，有各个模块的微服务组成一个集合，一起为各个应用提供不同的数据处理服务。

2、ABP VNext项目的微服务项目

前面说到，ABP VNext 框架里面也采用了多网关的应用，其中网关包含了后台管理应用网关【BackendAdminAppGateway.Host】，以及公开的应用接入网关【PublicWebSiteGateway.Host】，而内部网关服务【InternalGateway.Host】，则是用于内部微服务之间调用的统一网关解析。

ABP VNext的微服务项目如下所示。

生成的数据库包含两个部分，其中基础数据库包含IdentityServer4所需的基础表，以及用户、角色、租户、日志、组织机构、权限等权限模块的基础表；另外一个部分就是业务模块的数据库了，如下所示。

我们通过AuthServer.Host和ProductService.Host项目，初始化相关的数据库。

最后获得两个初始数据库，包含基础的表信息。

之前随笔也提到过，虽然ABP VNext的官方提供了构建权限系统的相关表信息，但是组织机构、用户、角色业务表和中间表的管理没有在其对应的Identity项目中提供，官方提供的Identity项目如下所示。

这部分完善的应用接口及管理，他们是在ABP VNext商业版中进行开发并提供的，因此我们开发具体的应用所需的权限基础内容，需要自己进行项目模块的扩展，然后完善组织机构、角色、用户、菜单、日志（审计日志、对象修改日志）、权限点的管理和维护等内容。

3、微软的eShopOnContainer微服务架构

eShopOnContainer是基于Docker技术微服务架构demo，由微软架构师利用.net core技术实现并在github上开源，同时发布的还有关于微服务架构的白皮书(点这里)，微服务架构是一个比较新的架构模式，通读白皮书并结合该demo代码，可以做到按图索骥的作用，对理解.net core技术实现微服务架构可以做到事半功倍。

在Github中的微软eShopOnContainer 项目地址：https://github.com/dotnet-architecture/eShopOnContainers

eShopOnContainer 的开发架构示意图如下所示。

包含网关的架构架构图如下图所示，其中包含多个网关服务处理客户端的请求。

4、微服务的模块拆分

微服务根据功能或者应用场景进行拆分，如把一个大型复杂的系统应用，拆分为多个微服务应用模块，然后进行整合使用。

或者按下面界限上下文进行划分

不过微服务也不是拆分的越细越好，一般根据实际情况进行度量，引入微服务虽然能够解决一些技术上和性能上的问题，不过拆分过多可能会导致开发和维护上灾难。