一、问题
在实际的产品实现和开发过程中我们会接触到各种各样的接口，有我们请求第三方的，有我们自己作为接口提供方的。某些情况下，为了接口数据排错，数据分析，以及业务优化，对接口数据进行日志监控很有必要。
在诸多的接口请求或响应中，当接口数量变多或业务变复杂之后，在实际的操作中需要对接口数据进行排查，快速定位到异常接口并查出接口的请求和响应参数，以此来复盘分析可能出现的问题。
例如：某订单支付业务出现异常，导致下单失败。现在需要对该问题进行排查，以确定是因为接口问题导致的支付异常，还是实际的业务逻辑错误导致的支付异常，亦或是其他情况引起的。此时，我需要知道是谁请求了我的接口，若能根据相关的条件（支付账户，支付时间，支付人等）快速查出当时的接口请求和响应日志，那么就能快速定位到问题所在，最起码也能最大程度的还原当时的场景，反之，没有相关的接口监控日志，要想还原场景，重现问题，就变得很麻烦。
那么，如何设计一套简单易用的接口数据监控组件呢？ 我们继续往下看。
二、思路
先整理一下接口流程和实现思路：
设想：如果我们能在A点和B点记录下接口的相关数据（主要是请求数据a和响应数据b），那么我们就能对该接口进入和流出的数据进行日志监控了。
最简单的方式就是在A点和B点分别埋下日志锚点，接口流程走到此处记录下相关数据。这确实可行，但是稍显麻烦，意味着要想捕获接口数据，每个接口都需要至少两段代码，对开发者而言，无异于重复造轮子。
那我们再深入思考一下，既然是需要对接口进入的数据流和返回的数据进行监控，又是在.Net平台下，那我们很容易想到另外一种讨巧的方式，使用C#原生的Attribute特性去监控每个接口（Method）的数据。
值得注意的是，在系统尚未接入ELK日志平台，且系统业务还未达到十分庞大的量级前，如何简单并高效的记录各接口日志数据满足当前业务需求才是关键。
所以，对于接口组件起码要满足以下2点：
（1）对于开发者而言，调用你的日志组件要足够简单，最大程度的降低学习成本；
（2）对于业务而言，记录的接口日志数据要足够详细，查找分析数据要足够方便。
结合米多来发平台早期的业务发展和项目需要，我们需要设计出一套合理的接口日志组件提供给普通开发者使用。前面已经说了，基于平台和编程语言的考虑，我们决定使用Attribute来设计一套底层接口日志组件。
三、简单实现
说做就做，根据以上的构思，一步步实现：
- 设计一张数据库接口日志表，用以保存分析接口数据，主要字段如下图：
- 新建一个接口日志帮助类LogFilterAttribute，因为我们只需要对接口数据进行监控，所以该类只需要作用在方法（Method）上，所以简要设置目标属性，如图：
- 重写OnActionExecuting方法，用以在接口收到请求后捕获请求内容：
- 重写OnActionExecuted方法，用以在接口业务逻辑执行完成后捕获接口返回的响应内容：
- 经过以上步骤，我们已经完成了基于Attribute实现的接口内容的捕获和记录。在需要记录接口日志数据的接口方法上，直接添加Attribute标记，设置相关的参数，即可实现接口数据捕获，使用非常简单，如图：
- 试着请求该接口，然后查看数据库中记录的接口日志数据如下：
通过查看数据库中记录的数据，即可快速定位到每个接口的请求日志，如果还需要记录接口的其他数据，则直接在OnActionExecuting和OnActionExecuted方法里面扩展即可。
为了避免每次都要去打开数据库客户端查询接口日志数据，还可以添加一个接口日志管理的功能模块，将接口日志可视化，这一部分不展开讲解，实现效果如图：
- 以上便实现了一个简单的接口日志数据管理组件的开发。
四、其他
由于业务型的平台业务量增长速度都比较快，达到一定数量级之后，如果还是采用这种方式，数据库的性能可能就会受到影响，当系统接口业务量过大时，为了避免频繁读写数据库，可以将得到的日志数据接入ELK平台，或者高并发的时候，对于日志数据实时性要求不高的接口，可以先写入消息队列，再移到数据库中，又或者进行读写分离等。
这个利用Attribute特性制作的接口日志监控组件，还可以扩展出很多有意思的东西，做出更多精细化的日志组件，此处不展开赘述。
对于开发者来说，使用的时候打一个标签就能完成接口日志的记录，对于业务而言，能够快速查到每个接口的分析数据，就已经完成了我们最开始的目标。
