Contentsquare通知系统的构建与优化

Contentsquare在其平台中需要为多种用例提供通知功能。为此，公司在微服务架构中创建了一个通用的解决方案，并在实施过程中提升了系统的可观测性，并克服了一些扩展性挑战。

通知功能的应用与实现

Contentsquare的通知功能可用于多种场景，如密码重置、API配额超限的关键警报等，并通过电子邮件、Slack或Microsoft Teams根据用户偏好进行发送。公司选择逐步推出通知相关功能，以便在需要时进行性能和扩展性改进。

通知系统的架构

Contentsquare的平台采用微服务架构，通知子系统由多个微服务组成：

• Notification Consumer：负责处理来自Apache Kafka主题的消息。
• Mailer Service：处理电子邮件通知的发送，并使用EJS模板引擎根据预配置的模板渲染电子邮件内容。
• Integration Service：处理Slack和Microsoft Teams通知，基于Slack的Block Kit或Microsoft Teams的Adaptive Cards构建JSON消息体。
• Slack Service和Microsoft Teams Service：分别负责将通知消息发送到Slack或Microsoft Teams的API。

实施过程中的挑战与优化

在实施过程中，Contentsquare的团队遇到了一些瓶颈，并采取了以下优化措施：

• Kafka主题优化：最初使用单个Kafka主题进行微服务间通信，后来为通知功能创建了专用的Kafka主题，以提升系统可靠性。
• 通知存储优化：优化通知存储以避免读取时的高延迟，并实施数据保留机制以删除旧的通知记录。
• 电子邮件发送问题：部分用户未收到电子邮件，经调查发现是SPF（Sender Policy Framework）配置错误，由安全团队解决。
• 电子邮件可观测性：创建了专用的电子邮件可观测性解决方案，通过定期检索第三方电子邮件服务的交付事件并将其存储在平台内，实现了电子邮件通知流的端到端可见性。

平台可观测性的提升

在推出通知功能的同时，开发人员还致力于提升平台的可观测性：

• Kibana仪表板：用于监控和分析日志。
• Grafana仪表板：用于监控通知微服务使用的云资源。
• Kafka集群监控：扩展了对生产Kafka集群的监控，确保资源利用率和消费者组延迟在可接受范围内。

未来计划

Contentsquare的团队计划在未来进一步提升系统的弹性，以应对系统故障，并改进通知的及时性，以实现近实时的通知交付。