Web服务，中央日志记录的架构设计建议

Question

我们有一定数量的SOAP和REST Web服务，它们为客户提供法律信息。管理层要求记录此服务请求的所有信息。使用日志，他们想收集统计数据并向客户收费。

我的同事提议使用中央关系数据库进行日志记录。 我不喜欢这个解决方案，因为服务的数量正在增长，我认为这样的架构将成为生产力的瓶颈。

你能告诉我什么样的建筑设计对这类任务有好处吗？

Answer 1

当您说中央数据库将成为瓶颈时，您是否意味着跟上日志记录请求的速度太慢？或者您是说您希望每个日志记录请求类型都有数据库更改？

我将为日志记录定义更通用的有效负载（计算出最小的标准化字段），然后为这些日志创建数据库。

<log><loglevel>INFO</loglevel><systemName>ClientValueActualizer</systemName><userIp>123.123.123.432</userIp><logpayload><![CDATA[useful payload for billing]]</logpayload></log>

如果你担心容量，可以在它前面放一个队列，这样做的好处就是如果日志忙，不会让客户端陷入困境。

您可以将这些消息的消耗分离到单独的系统中。每个都可以理解各种有效载荷。这里的风险是，如果要添加新属性，将很难控制哪些系统正在发送什么。但这只是解耦服务的一个普遍问题。

Answer 2

您可以将Apache Kafka视为分布式提交日志。这对性能有利，因为它可以横向扩展，只有在客户端提取这些消息时才能传递消息。