接口日志设计

当前系统大多采用前后端分离架构，后端采用微服务等分布式系统架构，同时与众多的第三方平台又存在大量的接口交互，如图6-9所示。当系统出现问题时，80%以上的情况需要先排查接口的请求和应答是否正常，因此对于接口日志的记录就显得至关重要。

图6-9 系统间接口交互

1.切面记录接口日志

接口日志的存储要充分利用面向切面编程（Aspect Oriented

Programming，AOP）和动态代理的思想，在所有系统的交互链路上加入切面，然后在切面上进行日志存储，当接收到请求后记录请求日

志，在程序应答前记录应答日志，接口日志的切面位置如图6-10所示。

图6-10 接口日志的切面位置

以Java项目为例，对于后端应用程序，可以开发出统一的日志切面 JAR包，其他项目只需要依赖该JAR包即可。但是，要求所有服务必须遵守方法的命名规则。例如，所有Controller方法必须以Handler结尾，否则无法经过日志切面记录日志。这种方式的缺点是所有项目必须与切面程序保持紧密的依赖关系，耦合性较高。

2.网关记录接口日志

如图6-11所示，所有的前后端交互都需要通过网关再请求到后端服务，如果后端服务之间也存在接口调用，如服务1调用服务2，则不可以直接调用，而是必须通过网关的代理转发，因此可以在网关上完成接口日志的记录。

图6-11 网关代理记录日志

这种方式的好处是所有的后端服务无须做任何类库的集成和修改，通过服务的分层，解决了耦合性过高的问题。但是，它使得一个去中心化的微服务架构变为了集中化的ESB架构（参见3.3节），使得服务端之间的接口调用必须经过网关（或ESB）的转发，从而降低了接口响应速度。

因此，也可以将两种设计方案进行融合和取舍。对于前后端的交互通过网关记录日志，而微服务之间的调用则通过面向切面编程的方式记录日志。

3.接口日志存储结构

接口日志存储的内容要多一些，因为除要记录接口的请求和应答报文外，还要记录它们之间的调用关系，到底是哪个系统调用了哪个系统。因此，需要分别定义应用和接口的存储结构。

应用的构成和相互调用如图6-12所示。一个应用包含多个接口，定义应用和接口的目的是将各个客户端、后端服务、第三方服务及它们所包含的接口全部实例化为具体的数据（如应用A和应用B），用于应用之间的访问授权，以及交互日志的记录。

图6-12 应用的构成和相互调用

最终记录的交易日志要能够明确地表达出，在什么时间、哪个系统调用了哪个系统的什么接口，在什么时间收到了应答，双方交互的耗时有多长，以及交互的内容是什么。

应用定义表的结构如表6-9所示。

表6-9 应用定义表的结构

接口定义表的结构如表6-10所示。

表6-10 接口定义表的结构

如表6-10所示，授权方式用于接口交互的安全控制，各自具有不同的用途，具体如下。

（1）     开放式调用：对接口不进行任何校验和拦截，可以直接调用上游服务。这种接口一般是对外公开的，如官网的新闻资讯、公开的信息查询等。

（2）     需验证密钥：这种一般为服务之间的调用，或者提供给第三方的服务接口，需要验证应用所携带的SecretID和SecretKey是否存在并且匹配。

（3）     需要登录：一般为用户级别的私密接口，必须先验证登录状态，才可以调用。

接口日志表的结构如表6-11所示。

表6-11 接口日志表的结构

4.接口日志的积极作用

通过接口日志，按照不同的维度进行统计分析，可以达到以下5个目的。

（1）     可以清晰地观察系统的实时交易量，制作动态交易监控仪表盘，实时监控系统接口调用链路是否正常，是否存在服务节点故障，服务性能是否下降。

（2）     如果某个接口突然频繁超时，则其对应的应用一定出现了问题，可以快速定位问题服务进行排查。如果某个接口的交易耗时过长，或者只有请求数据，没有应答数据，则可以断定接口或服务出现了问题。

（3）     可以轻松统计出交易趋势曲线，查看系统在每天的交易高峰与低谷，以及在每周、每月、每年的交易量变化。

（4）     可以清晰地判断出哪些服务被频繁调用，找到热点服务，避免其成为系统瓶颈，从而有针对性地提高其可靠性和服务性能，使资源更加有目的性地投放。

（5）     可以纵观全局，看到整个系统的交易链路，哪些应用访问量高，哪些应用访问量低，哪些服务应该被整合，哪些服务应该被拆分。

接口日志是对系统进行跟踪、检测、评估的数据基础，也为架构设计的调整提供了重要的数据支撑。