在微服务中网关的作用
- 统一反向代理
- 流量控制，降级，熔断
- 统一日志管理
- 内外网管理，权限控制
其中1，2，3相对比较确定，通过hystrix，filter，redis ratelimit等机制可以完成。和架构本身关系不大。
内外网控制
对于第4点内外网控制，需要解决几个问题
- 模块A可能是内网访问，也可能是外网访问，也可能是内外网都可以访问
- 模块A是外网可以访问，但是模块A中个别接口是只能内网访问
对于第1点，有几种做法
使用多个eureka，内网系统注册到内网eureka，外网注册外网eureka，使用不同的网关访问对应eureka的系统。
缺点：如果一个系统内网外网都要访问，必须注册两个eureka。
使用一个eureka，但是使用两个网关，内网网关和外网网关。微服务在注册时候通过eureka maps填写自定义字段NETWORK_TYPE, 如果是外网系统，该值设为OUTER。
内网网关可以访问所有微服务，外网网关访问微服务的时候，获取eureka中对应的NETWORK_TYPE字段，如果为空，默认为内网系统，如果是OUTER则表示可以外网访问
对于第2点，有几种做法：
- 拆分系统，保证某个模块中所有接口只能外网访问
- 规定某个urlpath，比如/private，这个路径下的接口是不能外网访问的，只能通过内网网关进行访问
网关Token校验
外网网关
对于对外暴露的接口，不能以userid形式暴露，必须通过token，避免userid可以遍历。如果让底层微服务校验token会造成耦合问题。所以统一在外网网关中进行token校验，并转化为userid。
- 擦除header中USER_ID字段，避免客户端直接透传
- 如果header里面没有token，不做任何操作
- 如果header中有token，将token通过sso转为userid，并访问header的USER_ID字段
- 下游服务根据接口需求通过header中获取userid，如果获取不到，则根据业务返回特定数据
- token统一在sso生成，使用jwt，网关通过http请求sso，如果觉得性能有问题，可以增加缓存
- 原则，永远不能对外暴露userid的接口
内部网关
内部调用或者调试等原因，可能直接调用userid比较方便，可以开设一个内部网关，不进行token校验。
后端系统
后端不处理token，获取header中的userid