使用ESB架构有一个细节点,就是关于API日志的设计
虽然可以通过消息通知模式来统一接口间的相互调用,但是最终还需要各个服务API来真正承接服务。
而对API进行监控既有利于对系统整体行为进行记录,也能对系统的性能进行分析排查系统的性能瓶颈点。
存储仍然使用Cassandra集群
请求记录ESBAPILog
序号 | 字段名 | 类型 | 备注 |
1 | id | string | 请求id |
2 | ServiceName | string | 服务名 |
3 | FunctionName | string | 方法名 |
4 | createtime | datetime | 添加日期 |
5 | clientId | string | 服务调用端id |
6 | Variables | string | 参数数据记录 |
7 | ClientSafeKey | string | 安全密匙 |
请求结果记录ESBAPIResultLog
序号 | 字段名 | 类型 | 备注 |
1 | id | string | 请求id |
2 | Endtime | datetime | 添加日期 |
3 | ActionResult | bool | 调用结果 |
4 | message | string | 相关消息 |
编码实现思路:
- 由于不是主业务逻辑,所以日志数据存储最佳模式是切面化编程,同时还需要是多线程异步化的数据写入,不能阻塞主业务流程。同时在发生异常时要进行全面捕捉,不能使异常影响服务的正常运行。
- 在API方法首先执行ESBAPILog数据的插入,生成请求id作为ESBAPILog表和ESBAPIResultLog表连接点。由于Cassandra的特性,所以设计为两张表分别写入而非一张表下更新。
版权声明:本文为博主原创文章,未经博主允许不得转载。