总体架构

所有应用服务、API网关、身份认证服务均部署在Kubernetes容器中，由Kubernetes提供应用配置、服务治理、服务监控等功能。

客户端所有访问均通过Kubernetes的Nginx-Ingress接入服务集群，并由API网关负责路由匹配和身份认证后转发至响应的应用服务处理。应用微服务中不需要二次做身份认证。

身份认证服务提供OAuth2.0协议的令牌获取、验证等接口。

数据库、缓存、日志服务等服务中间件建议部署于独立的服务器上，按需求也可以部署于容器中。

具体架构如下图：

分层架构

这里我们主要讲述服务端，服务分层架构如下：

• 网关层作为业务服务的总出入口，所有服务调用均需要通过API网关。这里我们使用.Net Core中常用的Ocelot网关
• 身份认证服务我们采用ABP vNext框架模板提供的身份服务模块，其核心为封装了IdentityServer4.0框架用于提供OAuth2.0协议各种接口。身份认证服务所需数据直接来自数据库或缓存。
• 聚合服务层主要用于聚合、调度服务层一个或多个微服务。客户端访问的所有接口（除身份认证服务接口以外）均由应用层提供。应用层服务不直接访问数据库，而是通过调用服务层对应服务实现数据操作。通常我们做详细的接口权限管理，也是应用层接口与权限做对应。应用层服务我们采用WebApi+ABP vNext框架实现。
• 基础服务层，建议依据领域驱动设计思想划分，每个领域设计为一个微服务。该层服务提供具体的领域模型、领域业务的实现。通常每个微服务对应一个数据库，通过仓储实现数据库操作。服务层服务不直接提供客户端访问接口，收到请求时也不需要做身份认证、鉴权处理。这里我把服务层服务分为两类：第一种是身份管理服务，负责用户角色权限管理，使用ABP vNext框架Application模板构建；第二种是其他业务微服务，提供用户角色权限管理以外的其他业务功能，使用ABP vNext框架Module模式构建。
• 数据库这里我们采用MySQL、缓存这里采用Redis、日志服务采用Elasticsearch+Logstash+Kibana（ELK）。
• 具体服务图中服务划分以Demo为例，实际开发中请依据各自项目实际需求对服务进行拆分设计。
• 由于Demo中设计的应用场景相对简单，更多技术及ABP框架详细用法请参考ABP官方文档。