设计一个微服务用户API网关

在《企业应用架构模式》中，提出当使用分布式系统时，对于通过远程调用获取的对象，应该封装在比较粗粒度的远程外观(Remote Facade)中。像微服务这种通过HTTP协议进行远程调用的方法，远程外观可以说即是数据传输对象(Data Transfer Object)。至于为什么需要使用远程外观，因为一次远程调用的代价都是非常大。两个微服务间的通信，传输时间是一个不能忽视的问题。如果对方响应请求比较慢，这边远程调用又是同步调用，处理的方法肯定也会比较慢。因为这种传递性造成的延时，有时候是急需解决的。

根据网上流行的说法，在用户API网关即可进行用户鉴权。用户权限的获取，自然是通过远程调用获取。如何获取，一般做法是根据当前用户id去用户中心查找。这种处理方法的API网关，远程调用获取用户权限的响应时间，将会是系统的瓶颈。而这种响应时间，是无法消除的，因为只要通过网络传输的数据，就会一定的延时，相比进程内调用，差距不是一个数量级。

既然响应时间无法消除，只能减少远程调用的次数——即引入缓存机制。每次根据用户id进行用户鉴权前，看看是否有缓存存在，如果有则从缓存中获取。如果没有，则进行远程调用再存入缓存。流程图如下。

不过这样，又引入了另外的问题，即何时刷新缓存问题。因为现在API网关无法知道用户中心的用户权限是否已经修改。轮询是不可取的，因为用户量一多轮询一次需要花费很多时间，既浪费系统资源，还不能有效命中更新需要的缓存数据。所以，需要找到一种机制，可以让用户知道API网关数据哪些数据已经更新。

现在有两种方法可以选择：

用户中心与API网关连接同一个第三方缓存，用户中心修改用户权限同时更新缓存

引入消息通知机制，用户中心修改用户权限时发送消息通知API网关更新缓存

第一种方法的缓存工具，无疑要使用第三方工具。而第二种方法的缓存工具，则可以是内存缓存或是第三方缓存工具。具体使用哪一种选择，暂时想不出个孰优孰劣。但是这样一来，缓存数据中势必存在非常多的重复数据。因为用户权限控制，一般是通过url请求做判断。一个系统不可能每个用户访问的url请求都不同，大部分还是具有相当高的相似度。所以，这就需要再往上抽象一层，分类重复的权限。如何抽象，通用的做法是根据用户角色划分。

前文提到粗粒度的远程外观，这是不是意味着获取用户权限的接口，可以修改为通过用户角色获取。一个用户，通常具有一系列的角色。现在通过用户角色获取用户权限。修改后流程图如下。

从流程图看来，这似乎是把接口的颗粒度更加细分了。一次用户请求，可以会有好几次根据用户角色获取权限。因为一般用户，肯定不止一个角色。另外，获取用户角色部分的方法，估计也是需要使用远程调用的。所以这种根据用户划分角色以减少缓存的方法，不可取。

那有没有更好的方法，即不产生过多的缓存数据，又提高API网关的响应。倒是有一个——放弃使用远程调用。也就是说，API网关与用户中心，使用同一份数据库连接。这种做法是不是可行呢，从网上的资料来看，用户API网关似乎没有规定不能直接连接数据库。不过，在API网关与用户中心同时维护了两份数据库配置，似乎跟有些思想有点出入。但是从另一方面来看，网关是系统的入口，更快的响应速度才是首要追求。放弃远程调用，似乎才能满足这种需求。