现在业务的需求大致如下图注释所示，如果创建人脸的功能可以只提供给user访问，而查看完成所有的状态只能master访问，其他的两个角色都可以访问
考虑这个功能的实现新从接口的定义，以及如何获取用户信息的角度思考，接口定义如下，需要用户登录的时候吧token记录到cookiet里面去，需要记录返回的json信息
这时候就考虑创建一个用户模块来对用户信息处理
设置统一的配置
因为后续的用户服务对外提供接口，所以这里设计用户服务成多模块，如果是对外提供服务的就创建server模块，如果需要依赖其他服务的再创建client模块，后面整合项目的时候会提取所有模块都共同部分，作为基础模块，这样就可以减少代码的冗余
设计三层架构，包括数据库对象，以及service层，dao层，下面重点是看看controller层的逻辑
逻辑处理的时候，每种可能情况做处理，分别给出处理的结果，这里使用了枚举类来封装返回的信息。
这里把角色分别做了不同的存储处理，就是为了判断以后登录的角色判断，而且为了避免因为刷新页面导致往redis重复写入不同的redis，又从cookie里面获取了请求的token然后在处理
总结流程，从gateway路由到服务的过程，会被过滤掉cookie信息，这时候需要配置上全局的敏感头不过滤的配置在config服务上，其次单个的服务，针对用户的角色处理，如果是注册人脸服务的用户，角色判断，openid判断，如果是查看完成的人脸特征的管理员用户，除了token之外还需要UUID，以及存到redis中，最后在人脸的识别的服务里面，对权限进行校验的时候，就从用户登录的cookie里面获取信息，比如用户的角色等。
这里还有很关键的逻辑就是自定义继承了ZuulFilter的这个类的run()方法逻辑，这里的一切权限判断的开始。
下节将会针对zuul权限的管理做一次全面的总结，毕竟这里涉及的模块以及基础模块的抽取部分还没有完善。