共计 4094 个字符，预计需要花费 11 分钟才能阅读完成。
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-arc…
eShopOnContainer 的开发架构示意图如下所示。
蕴含网关的架构架构图如下图所示，其中蕴含多个网关服务解决客户端的申请。
4、微服务的模块拆分
微服务依据性能或者利用场景进行拆分，如把一个大型简单的零碎利用，拆分为多个微服务利用模块，而后进行整合应用。
或者按上面界线上下文进行划分
不过微服务也不是拆分的越细越好，个别依据理论状况进行度量，引入微服务尽管可能解决一些技术上和性能上的问题，不过拆分过多可能会导致开发和保护上劫难。