作者 | Rafal Gancarz
译者 | 平川
策划 | Tina
Contentsquare 平台的许多场景都需要通知功能。作为其微服务架构的一部分，该公司创建了一个跨多个服务的通用解决方案。在实现过程中，开发人员改进了可观察性，同时还克服了一些可扩展性挑战。
Contentsquare 的通知功能可以用于密码重置、API 配额超标告警等，并根据用户的喜好通过电子邮件、Slack 或 Microsoft Teams 发送。该公司选择循序渐进地推出与通知相关的功能，以便在需要时提高性能和可扩展性。
通知组件（来源：Contentsquare 工程博客）
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 发送通知消息。
用于向 Slack 和 Teams 发送通知的微服务（来源：Contentsquare 工程博客）
Contentsquare 软件工程师 Joseph-Emmanuel Banzio 分享了该团队在推出通知功能时的经验：
在此过程中，我们遇到了几个瓶颈，为此，我们扩展并增强了系统的可靠性。一个值得注意的挑战是，在创建 Notifications 主题之前，我们最初使用了单个 Kafka 主题进行微服务间通信。在我们发布实时告警测试版之前，这个功能一直运行良好。
除了使用专用的 Kafka 主题进行告警通知外，该团队还优化了通知存储，以免读取时出现高延迟。他们实现了一种数据保留机制，用来删除旧的通知记录。另一个需要调查的问题是，一些用户没有收到电子邮件。经过仔细研究，这是由于 SPF（Sender Policy Framework）配置错误引起的，安全团队已经解决了这个问题。
为了帮助解决电子邮件通知问题，该团队创建了一个专门的电子邮件可观察性解决方案。其中，它会定期检索第三方电子邮件服务收集的发送事件并存储在 Contentsquare 的平台中。这种方法提供了电子邮件通知流的端到端可见性。
在该功能上线的过程中，开发人员还致力于提高了平台的可观察性。他们创建了一个 Kibana 仪表板来监控和分析日志，一个 Grafana 仪表板来监控通知微服务使用的云资源。此外，该团队还扩展了对 Kafka 生产集群的监控，以确保资源利用率和 Consumer Group Lag 在可接受的范围之内。将来，该团队计划提升系统弹性，以防系统故障，并提高通知发送的及时性，实现近实时发送。
原文链接：
https://www.infoq.com/news/2023/10/contentsquare-notifications/
声明：本文为 InfoQ 翻译，未经许可禁止转载。
