面试时问到年代久远的项目忘了咋办？给自己的项目来一次复盘，记起那些遗忘的宝藏。笔记：安全网关项目复盘

前言

项目复盘应该是一个人应该具备的基本能力，它可以提升我们的个人能力，明确自己的价值和工作的成果，可以强化我们的优点，弥补我们的缺点。所以定期对自己做过的项目进行复盘是很有必要的。

项目复盘大概可以按以下四个步骤来进行：

1. 目标回顾

   • 项目立项的目的是什么？（项目背景）

   • 项目想要达到的目标是什么？

   • 项目的开发计划是什么样子的？

   • 预期的困难有哪些？

2. 结果陈述

   • 实际的开发结果是什么样子的？
   • 遇到了什么困难？在什么情况下怎么发生的？
   • 与目标相比，哪些做得好？哪些未达预期？

3. 过程分析

   • 实际状况与预期有何差异？
   • 如果有，为什么会发生这些差异？
   • 失败/成功的根本原因是什么？

4. 总结规律

   • 从过程中学到了哪些东西？
   • 如果有人要开发同样的项目，有哪些建议？
   • 接下来的开发计划是什么？
   • 哪些工作可以立即开始？

一、目标回顾

1、项目背景

顺应时代背景，规划对公司内部的多个项目进行微服务化改造。需要一个统一的接口管理服务，因此安全网关项目被提上日程。

2、业务目标

基础目标：微服务的路由转发、传统服务的路由转发和负载均衡。

进阶目标：参数安全校验、限流、部分服务的认证授权（后续独立出用户中心模块管理所有服务的认证授权）、参数的加解密、后端服务的灰度环境快速切换等。

3、系统架构方案

由于安全网关是一个业务网关，需要处理很多耗费性能的功能，因此安全网关采用集群化部署，前面再加一层 Nginx 作为流量网关，提供业务网关层的负载均衡。

4、开发计划

项目调研 ==> 需求提取 ==> 功能设计 ==> 代码实现 ==> 系统对接

5、预期目标

网关基本功能：

• 路由转发、负载均衡、限流。

安全验证相关功能：

• URL防重放、参数安全校验（http host、XSS、SSRF）、签名验证、参数加解密。

权限验证相关功能：

• 微服务认证授权、单端登录。

服务接入：

• Spring Boot微服务：A服务、B服务等

• 传统web服务：C服务、D服务等。

二、结果陈述

1、开发结果

网关基本功能开发完成：路由转发、负载均衡、限流。

安全验证相关功能开发完成：URL防重放、参数安全校验（http host、XSS、SSRF）、签名验证、参数加解密。

权限验证相关功能开发完成：微服务认证授权、单端登录。

成功接入服务：A服务、B服务、C服务、D服务。

三、过程分析

1、开发结果与预期目标的差异

部分传统后端系统未能接入安全网关提供的所有功能，例如参数加解密、用户授权认证等，对于这部分情况在网关配置中忽略为这些系统提供部分功能。

2、遇到的困难及解决方式

1. 问题： 不同的前端环境（例如：网页、微信小程序、Android APP、IOS App）对请求参数的编码情况不同（Encode次数），导致网关使用统一的解码方式解析出的参数不同，参数签名校验不通过。

   解决方式： 寻找出各种前端的编码方式，（开发人员是否手动进行了编码或者使用的技术框架进行了编码操作）。第一种解决方式是在网关区分不同的前端来选择不同的解码方式，后来发现增加网关的复杂性且非常难以维护，于是制定统一标准，网关只进行一次解码，由各前端保证参数只进行一次编码。

2. 问题： 权限验证、参数签名验证、参数加解密三个功能出现冲突。这三个功能本质上是网关的三个过滤器，由于刚开始过滤器配置的顺序不严格，导致解密的操作放在了验证参数签名的后面，由于未进行解密，导致参数签名无法进行，权限验证自然也无法进行。

   解决方式： 将参数解密过滤器的顺序调整到根过滤器后第一个执行。PS：由此问题引起了团队对过滤器顺序的重视，其后对项目内所有过滤器进行了梳理和优化，并记录文档，后续开发新的过滤器必须评估其位置并记录。

3. 问题： 加解密功能所拦截的接口配置随着接入的应用增多而变得过于复杂。

   解决方式： 协调各系统前端，梳理接口，优化不同情况下的配置，例如 /a/** 下的需要拦截的接口数量和不需要拦截的接口数量比例，以及后续增加新接口后可能的比例变化情况，来决定是采用黑名单配置方式还是白名单配置方式。规范各系统的接口命名方式。

4. 问题： 部分传统服务的开发未彻底完成前后端分离，有些接口响应的结果是一整个页面，加解密的加密功能加密了整个页面数据，导致前端无法解析加密后的数据。

   解决方式： 配置部分接口不进行响应结果的加密功能，将密钥放在请求头中路由到后端业务系统，如有需要让业务系统自己完成响应结果的部分加密（此时安全网关就相当于扮演了帮业务系统管理密钥的角色）。

四、总结规律

1、项目收获

1. 加深了对 http/https 协议的理解。
2. 加深了对微服务架构的理解。
3. 学习了统一配置中心，以及动态配置的使用。
4. 提升了与其它项目沟通的能力。
5. 由于新项目处于探索阶段，除了基本功能，没有明确的额外需求，这时需要项目组成员有提前发现问题和解决问题的能力，在这样的项目组中工作提升了发现问题解决问题的能力。

2、经验总结

1. 网关项目一旦接入系统过多，将产生大量的配置文件，需要提前对配置文件做规划，例如：根据模块不同，项目不同，将复杂庞大的配置文件拆分成不同的配置文件，对这些配置文件进行分组管理。
2. 配置方式要尽可能做的灵活，且要能尽可能的把更多的配置做成动态配置（例如：每个过滤器的前置和后置都要能够单独进行配置，且每个功能都要有开关和降级方案）。
3. 如果有条件，对接入网关的项目制定一些统一的标准很有必要。
4. 网关日志需要认真对待，不同的项目会遇到很多问题，日志可能是你查找问题的唯一方式。

3、后续迭代计划

网关2.0计划（1.x版本上线第一个版本后，2.x版本就已经在同步开发了）：

1. 优化项目结构，制定统一标准，强制下游系统改造适配（升级过程中提供1.x和2.x两套网关服务，直至所有下游系统适配到2.x版本后下线1.x版本），以减少后期维护成本。

2. 将网关的认证授权功能拆分成单独的服务，升级为统一用户中心，用于维护所有系统用户的公共身份信息。