一、思路
1、整体思路
用户通过客户端访问项目时，前端项目会部署在nginx上，加载静态文件时直接从nginx上返回即可。当用户在客户端操作时，需要调用后端的一些服务接口。这些接口会通过Gateway网关，网关进行一定的处理（jwt合法性校验，黑名单、白名单，过滤一部分请求）之后再转发给具体的微服务。具体的资源服务会对请求进行解析，判断当前登录用户是否有权限调用该资源的接口。
微服务的认证授权方案，目前大体分为两类：
（1）网关只负责转发请求，认证鉴权交给每个微服务控制
（2）统一在网关层面进行认证鉴权，微服务只负责业务
目前主流采用第二种方案，通过Spring Cloud Gateway + Spring Security + OAuth2 + Jwt整合进行统一认证鉴权，大致流程如下：
2、微服务分解
springcloud+nacos+gateway+feign+oauth2+jwt+sercurity。
（1）nacos作为注册中心和集中配置管理；
（2）多个provider提供数据库服务，多个consumer处理业务逻辑；
（3）采用Spring Security + Oauth2作为安全框架，采用JWT操作令牌；
所有服务有一个统一的springsercurity鉴权
（4）gateway作为网关。
所有组件之间的接口调用通过feign实现。
二、demo
如现有用户管理、订单管理、公共业务，针对上述架构梳理出以下服务：
1）工程前缀-auth：认证授权服务，负责认证和授权，整合Spring Security + Oauth2 + Jwt；
进行登录用户的认证授权，返回用户名和token的json数据，权限信息放在token中。
2）工程前缀-gateway：网关服务，负责校验认证和鉴权，对请求进行动态路由、校验认证和鉴权；
3）业务：（以下provider数据库层如果没有其他组件复用可以写在consumer中）
① 工程前缀-user：用户业务微服务，处理业务逻辑，需要鉴权；
工程前缀-user-provider：用户业务数据库层，处理业务逻辑；
② 工程前缀-order：订单业务微服务，处理业务逻辑，需要鉴权；
工程前缀-order-provider：订单业务数据库层，处理业务逻辑；
③ 工程前缀-common：公共资源微服务，处理业务逻辑，不需要鉴权；
工程前缀-common-provider：公共资源业务数据库层，处理业务逻辑；
4）工程前缀-api：以上组件的公共封装。
