目录

前言

技术栈

架构设计

前端统一门户

后端用户中心

UserAuthority公用依赖

过滤器

application/json

form-data

后记

---

前言

       在多个子工程的微服务开发的时候，后端通常情况下都是不止一个工程，前端深知也会不止一个工程，开发的团队也许也不止一个团队。 这时候，在用户校验、权限控制、功能集成方面就会需要有一套架构方案来管控。在整体的架构方面有几个要求：

       （1）根据业务需要独立拆分新建的子工程，只需要关注业务功能的代码开发即可，不需要再关注用户、角色、权限以及集成的问题；

       （2）子系统开发的时候，只需要引入pom依赖就可以非常方便获取用户信息以及对接口服务进行鉴权处理；

       （3）前端子工程同样只需要关注实际的业务功能页面开发，不需要考虑登录、登出、用户信息获取这些问题；

       （4）集成的时候，只需要提供微服务的上层负载接口地址和前端页面的路由地址即可。

       如何做到这样松耦合？但是又能紧密依赖和协调一致呢？ 

       对于后端来说，重点在于统一的规范设计、Redis分布式缓存、Filter过滤器、Maven依赖；对于前端来说，重点在于统一的axios过滤请求、路由处理、sessionStorage、自定义npm依赖包等等。

技术栈

       前端：vue/axios/vueRouter 等等

       后端：Springboot/SpringCloud/Dubbo 等等

       中间件：Redis/Nginx 等等

架构设计

       在软件的系统架构上，主要有以下几点：

       （1）完全的前后端分离项目

       （2）统一前端门户中心+统一后端用户中心

       （3）多个前端工程打包后放到Nginx中进行静态代理的访问

       （4）系统入口是统一门户中入口路由

       （5）通过router.beforeEach校验sessionStorage中是否有用户信息，对前端路由进行鉴权控制

       （6）通过axios的interceptors统一将sessionStorage中的token信息放入header中，并统一过滤非法请求

       （7）通过Reids存储用户信息

       （8）通过Nginx做请求转发，代替传统意义的网关

       （9）通过开发UserAuthority依赖包，让每个子工程引入该依赖来完成用户信息传递以及权限校验

       重点介绍和业务无关的两个工程，前端统一门户和后端用户中心。 

前端统一门户

       前端统一门户主要包括登录页面、门户首页框架两部分。 其中门户首页框架是典型的标题栏加左右布局结构，左边菜单栏、右边是内容区域。

       标题栏可以根据项目规模大小再扩展下，支持logo自定义、横向一级菜单、消息中心、用户个人中心等功能。 

       左侧菜单区域是标准的菜单menu组件，菜单信息通过接口获取。 右侧内容区域正常是一个ifream，通过点击菜单中的url地址，更新ifream的src来实现。

       统一门户登录成功过之后，前端会将用户信息、token信息保存到sessionStorage中。其他前端工程中直接从storage中获取这些信息，在路由跳转和axios请求的时候，直接使用。

       如下是axios和router的全局通用处理参考示意代码

// axios请求前置处理,请求之前，将token放到header中
axios.interceptors.request.use(request => {
  request.headers["token"] = localStorage.getItem("token");
  return request;
});
// axios请求后置处理
axios.interceptors.response.use(
    function(response) {
      let data = response.data;
      return new Promise(resolve => {
        if (data.code === "401") {
          if(localStorage.getItem("token")!=null && localStorage.getItem("token")!==""){
            Modal.error({
              title: "提示",
              content: data.message
                  ? data.message
                  : "您的账号已在其他地方登录，点击确定重新登录！",
              onOk: () => {
                sessionStorage.clear();
                localStorage.clear();
                window.parent.postMessage("refresh", "*");
              }
            });
          }else{
            window.parent.postMessage("refresh", "*");
          }
        } else {
          resolve(response);
        }
      }).catch(error => {
        console.log(error);
      });
    },
    function(error) {
      // 对响应错误做点什么
      console.log(error);
      const res = error.response;
      if (res && res.status === 401) {
        //token失效状态码
        // Message.warning("登陆失效，请您重新登陆!");
        message.warn("登陆失效，请您重新登陆!");
        //刷新当前页面
        window.parent.postMessage("refresh", "*");
        return new Promise(() => {});
      } else {
        return Promise.reject(error);
      }
    }
);
//router中的全局处理
router.beforeEach(async (to, from, next) => {
  let token = localStorage.getItem("token");
  if (to.name === "login") {
    if (token === "" || token == null) {
      next();
    } else {
      next({ name: "index" });
    }
  } else {
    if (token === "" || token == null) {
      //登录失效，跳转到登录
      next({ name: "login" });
    } else {
      if (to.matched.length === 0) {
        //没有匹配的路由，跳转到404
        next({ name: "404" });
      } else {
        next();
      }
    }
  }
});

       这里有个细节，就是如下这一行代码：

window.parent.postMessage("refresh", "*");

       它的主要作用是子框架和父框架进行通信，如果子框集中出现鉴权失败了，要通知父框架进行页面路由跳转，直接跳转到登录页面。 在整个架构中，子框架就是ifream中业务前端独立工程，父框架是统一门户的前端，在统一门户中，关于这块消息通信的处理如下：

window.addEventListener("message", function(e) {
  if (e.data === "refresh") {
    localStorage.removeItem("token");
    localStorage.clear();
    rootApp.$router.push({ name: "login" });
  }
});

       主要作用就是清空storage，然后跳转页面到登录页面。

后端用户中心

       用户端用户中心主要提供登录、登出、查询用户菜单权限这些接口功能。重点是是登录登出接口，登录成功之后，会将用户信息、token返回给前端，同时保存一份到redis中。

       关于redis中存储用户信息，建议将key设置为用户的userId，将value设置为一个对象，包含有token和用户基本信息，同时设置有效期。 然后token的生成规则可以通过AES可逆的加密加密解密方式来实现，解密token后，可以从token中直接split出userId，然后再拿userId到redis中获取用户信息，再校验传递过来的token和从token解析出来的用户Id从redis查到的token是否一致，进而判断请求是否合法。

UserAuthority公用依赖

       主要作用是继承一个filter，集合白名单机制对接口进行过滤校验。 如果在白名单中，则直接放行，如果没有在白名单中，则判断header中是否有token，如果没有token或者token校验不通过则返回401鉴权不通过。 前端在统一个axios.interceptors.response中进行页面的统一跳转。 如果token校验通过了，可以在filter中通过token获取从redis中获取用户信息，然后将用户信息作为入参信息向后传递，即：我们给入参数据新增一些用户信息字段，向后传递，在后面的业务工程接口中，直接从reqBo中就能获取到用户信息了。

       这也要求所有的入参对象都要继承统一的入参Bo。 

过滤器

       前面说了那么多，都是在整个软件的集成架构上来讨论的，我们回到本篇文章的重点，如何在Filter中对请求的入参信息进行增加。在Filter中获取入参信息包括两种方式，一种是获取InputStream，一种是getParameterMap。前者对应content-type是application/json，后者对应content-type是form-data或者application/x-www-form-urlencoded或者是get请求。 content-type不同，处理方式是不同的。 

       注：我们暂时先不考虑文件类型。 

application/json

       正常情况下，request的getInputStream和getParameterMap返回的对象都是受保护，不允许修改的，所以就需要我们进行一些特殊处理，关于stream这种，我们需要自定义个集成HttpServletRequestWrapper的类，然后重载它的一些方法，并将这个对象向后传递，这样在后哦面流程中就可以使用我们放进去的数据的了。 先看下重写的类，参考代码如下：

public class BodyReaderHttpServletRequestWrapper extends HttpServletRequestWrapper {
    private String bodyJsonStr;
    public BodyReaderHttpServletRequestWrapper(HttpServletRequest request,String bodyJsonStr) throws IOException {
        super(request);
        this.bodyJsonStr = bodyJsonStr;
 
    }
    @Override
    public ServletInputStream getInputStream() throws IOException {
        final ByteArrayInputStream bais = new ByteArrayInputStream(bodyJsonStr.getBytes("utf-8"));
        return new ServletInputStream() {
            @Override
            public int read() throws IOException {
                return bais.read();
            }
            @Override
            public boolean isFinished() {
                return false;
            }
            @Override
            public boolean isReady() {
                return false;
            }
            @Override
            public void setReadListener(ReadListener listener) {
            }
        };
    }
 
    @Override
    public BufferedReader getReader() throws IOException {
        return new BufferedReader(new InputStreamReader(this.getInputStream()));
    }
 
    public String getBodyJsonStr() {
        return bodyJsonStr;
    }
 
    public void setBodyJsonStr(String bodyJsonStr) {
        this.bodyJsonStr = bodyJsonStr;
    }
}

       可以看到，我们上是重写了getInputStream，将原来的stream和新的参数合并到一块，返回出去。 实际上我们并没有真的修改原始的request参数，只不过是重新生成了一个request。

       下面贴一段具体使用时候的代码：

@Override
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
	HttpServletRequest req = (HttpServletRequest) request;
	HttpServletResponse rep = (HttpServletResponse) response;
 
	BufferedReader streamReader = new BufferedReader(new InputStreamReader(req.getInputStream(), "UTF-8"));
 
	StringBuilder responseStrBuilder = new StringBuilder();
	String inputStr;
	while ((inputStr = streamReader.readLine()) != null)
		responseStrBuilder.append(inputStr);
	if(responseStrBuilder!=null && responseStrBuilder.length()>0){
		JSONObject jsonObject = JSONObject.parseObject(responseStrBuilder.toString());
		
		jsonObject.put("userId","123");
		jsonObject.put("name","test");
		try
		{
			chain.doFilter(new BodyReaderHttpServletRequestWrapper(req,jsonObject.toJSONString()),rep);
			return;
		}catch (Exception e){
			e.printStackTrace();
			log.error("包装参数失败，失败原因:{}",e.getMessage());
		}
	}
	chain.doFilter(req, rep);
}

form-data

       form-data的处理方式实际上和application/json是差不多的，原理都一样，区别在于重构的类不同，需要继承HttpServletRequestWrapper重写一个类。参考代码如下：

public class ParameterRequestWrapper extends HttpServletRequestWrapper
{
 
    private Map params = new HashMap();
 
 
    @SuppressWarnings("unchecked")
    public ParameterRequestWrapper(HttpServletRequest request)
    {
        // 将request交给父类，以便于调用对应方法的时候，将其输出，其实父亲类的实现方式和第一种new的方式类似
        super(request);
        //将参数表，赋予给当前的Map以便于持有request中的参数
        this.params.putAll(request.getParameterMap());
    }
 
    //重载一个构造方法
    public ParameterRequestWrapper(HttpServletRequest request, Map extendParams)
    {
        this(request);
        addAllParameters(extendParams);//这里将扩展参数写入参数表
    }
 
    @Override
    public String getParameter(String name)
    {//重写getParameter，代表参数从当前类中的map获取
        String[] values = params.get(name);
        if (values == null || values.length == 0)
        {
            return null;
        }
        return values[0];
    }
 
    @Override public Map getParameterMap()
    {
        return params;
    }
 
    @Override public Enumeration getParameterNames()
    {
        return new Vector(params.keySet()).elements();
    }
 
    @Override
    public String[] getParameterValues(String name)
    {
        return params.get(name);
    }
 
 
    public void addAllParameters(Map otherParams)
    {//增加多个参数
        for (Map.Entry entry : otherParams.entrySet())
        {
            addParameter(entry.getKey(), entry.getValue());
        }
    }
 
 
    public void addParameter(String name, Object value)
    {//增加参数
        if (value != null)
        {
            if (value instanceof String[])
            {
                params.put(name, (String[]) value);
            }
            else if (value instanceof String)
            {
                params.put(name, new String[]{(String) value});
            }
            else
            {
                params.put(name, new String[]{String.valueOf(value)});
            }
        }
    }
}

       仔细看看这个重写的类会发现，实际上就是重写了getParameter/getParameterMap等等这些方法，在这些方法内部返回的数据加上自己传递的参数。 

       具体使用的时候如下：

ParameterRequestWrapper requestWrapper = new ParameterRequestWrapper((HttpServletRequest)request);
Map      rMap           = new HashMap<>();
rMap.put("userId","1");
rMap.put("useName","zhangsan");
requestWrapper.addAllParameters(rMap);
chain.doFilter(requestWrapper, rep);

后记

       我们在业务工程中定义所有的reqBo的时候，都将这个Bo的定义继承父类的BaseReqBo，在父类的BaseReqBo中我们可以定义那些公用的用户信息或者通用字段信息，这些信息可以在上面的filter中去赋值，这样只要业务工程依赖了UserAuthority.jar，就会自动处理用户、权限这些信息。非常的方便，而且对于实际开发的同学来说，无需关心这些细节，只需要关心业务逻辑代码处理即可。