您的应用程序的通知：您应该构建还是购买？

披露：本文是由 Novu 委托撰写的。

让用户了解情况并参与其中对于任何应用程序或 SAAS 的成功都至关重要。为了实现这一目标，开发和产品团队需要构建自己的通知系统，或者购买专门构建的解决方案。功能强大的通知基础设施由后端系统组成，该系统管理通过各种渠道向用户传递消息。这些系统确保用户及时收到相关更新，帮助他们保持联系并了解应用或服务中的重要事件、更新和操作。

建立强大的通知基础设施涉及多个组件，包括消息路由、用户偏好管理、内容个性化/定制和交付跟踪。目标是提供无缝、可靠的通知体验，可以随着用户的增长和不断变化的需求而扩展。对于具有解决方案意识的用户来说，了解通知基础设施的复杂性至关重要，因为它会影响用户的参与度、保留率和整体满意度。无论您是构建新产品的初创公司还是希望简化通知系统的企业，选择内部构建还是利用第三方服务都是一个重大决定，可能会影响您项目的成功。

通知景观

组织面临着管理巨大工作负载的挑战，包括主要架构重构、新云应用程序和内部技术采用。在这些任务中，处理通知变得特别复杂。通知已从一个被忽视的功能发展成为用户跨各种应用程序参与的重要组成部分。然而，通知需求的快速增加和时间线的压缩，往往会导致不同团队开发的系统各自为政、不一致、缺乏协调，从而造成“通知混乱”。

这种混乱的特点是孤立通知组件的激增，使管理变得复杂并导致效率低下。支持多个通知渠道进一步增加了复杂性，因为用户需要控制他们的通知首选项。脱节的系统可能会导致交付不一致、忽视用户偏好以及增加维护成本。

通知混乱的关键问题

• 碎片化：各个团队独立开发的通知系统互不相连。
• 复杂性：多个渠道和用户偏好需求增加了系统复杂性。
• 运营挑战：交付不一致、用户不满意、维护成本高。
• 战略决策：组织必须在构建定制解决方案或采用 Novu 这样的供应商之间做出选择，平衡定制需求与运营效率。

最终，正确的选择将取决于组织的具体需求和资源，以及其长期战略目标。

组织1：

初创公司需要向其应用添加通知
想象一下，您正在运营一家科技初创公司，需要一个强大的通知系统来通知任务更新、截止日期和协作活动。您面临着电子邮件、短信、推送通知和应用内消息等多种渠道的通知混乱。您必须决定是在内部构建该系统还是利用第三方服务。内部构建提供了完全的控制和定制，但会分散核心产品开发的工程资源。它占用资源且耗时，可能会减慢产品的增长。

另一方面，使用第三方服务简化了流程，提供多渠道支持、用户偏好管理和开箱即用的可扩展交付。这种方法使您的团队能够专注于核心功能，加快产品的上市时间并确保可靠性和可扩展性。作为一家注重解决方案的初创公司，您必须权衡利弊：定制和控制与效率，并专注于您的核心产品。选择正确的路径将帮助您管理通知混乱，同时推动增长和创新。

组织 2：来自不同平台的企业通知整合

考虑一个拥有多个应用程序的大型企业，每个应用程序都使用自己的通知系统，从而导致通知混乱、用户体验不一致和冗余系统。企业希望集中其通知基础设施，以提高一致性并增强所有平台的用户体验。

开发内部统一通知平台可提供最大限度的控制和定制，与现有系统深度集成。然而，它需要大量的工程资源和持续的维护，使其成为一项复杂且资源密集型的工作。

或者，采用集中式通知基础设施可以提供高效且可扩展的解决方案。此类服务可管理通知的复杂性，提供智能消息路由和用户偏好管理等功能。这种方法释放了工程资源，使他们能够专注于核心业务目标。

如何构建通知系统：核心要求

构建通知系统需要 7 个核心部分才能使其成功、可维护且合规。这些要求包括用于集中消息管理的收件箱、用户可配置的首选项、智能消息路由、动态内容管理、团队交互功能、综合分析以及持续维护、扩展和调试的注意事项。其中每个组件对于提供及时、相关和个性化的通知，同时保持系统效率和可扩展性都至关重要。利用正确的基础设施和第三方依赖项来支持这些要求对于满足用户期望和确保通知系统的可靠性至关重要。

核心需求1：收件箱

收件箱提供了一个集中的位置来查看和管理用户消息。收件箱可以采用不同的形式，例如应用程序内的通知铃或专用通知框。每种类型都有其独特的要求和挑战：

• 集中消息存储库： 将来自不同渠道的消息收集到一个可访问的流中，以便于导航和管理。
• 通知已读/未读状态管理：允许用户使用视觉提示区分和管理新通知和已读通知。
• 用户友好的访问和管理：通过简单的控件和搜索功能实现直观的导航、标记、删除和存档通知。

支持基础设施和 SAAS 以满足用户收件箱要求

多个基础设施组件和 SAAS 支持这些收件箱功能：

1. 消息队列（例如，RabbitMQ、Kafka、Nats）：这些确保通知的可靠传递和处理，确保消息不会丢失并以正确的顺序传递。 数据库（例如 MongoDB、PostgreSQL）：用于以结构化和可扩展的方式存储通知数据，包括已读/未读状态。
2. 通知管理平台（例如 Firebase Cloud Messaging、OneSignal）：这些 SAAS 提供用于跨多个渠道管理和传递通知的工具。
3. 前端框架（例如 React、Vue.js、Angular、Svelte）： 对于构建用户友好的界面至关重要，让用户能够与其收件箱高效交互。
4. 搜索和过滤工具（例如 Elasticsearch）：这些工具增强了搜索和过滤通知的能力，尤其是在电子邮件收件箱场景中。

选择正确的基础设施和 SAAS 取决于您的通知系统的具体要求以及您想要实施的收件箱类型。无论是通知铃声还是电子邮件信箱，拥有一个强大且用户友好的收件箱是维持有效的通信系统并确保积极的用户体验的关键。

核心要求 2：订阅者偏好

管理订阅者偏好至关重要，但在通知系统中经常被忽视。用户指定的首选项可提供量身定制的通知体验，从而提高满意度和参与度。以下是用户可配置的通知设置和支持基础设施的关键要求。

• 用户可配置的通知设置：用户应该通过用户友好的界面轻松选择通知类型、频率和渠道，以管理他们的偏好。
• 可定制的发送渠道和时间表：用户可以选择首选渠道（电子邮件、短信、推送通知）并安排特定时间的通知，增强相关性并减少被忽略的消息。
• 取消订阅（个人、类别和站点范围）：用户应该轻松取消订阅个人、类别或所有通知，从而减少疲劳并保持参与度。
• 用于多语言支持的语言集成： 用户可以以其首选语言接收通知，需要强大的翻译功能来提供准确且适合文化的消息。
• 无缝嵌入的框架集成：通知首选项应与第三方系统和框架（如 React、Angular 或 Vue.js）顺利集成，以获得无缝的用户体验。

支持基础设施和 SAAS 以满足用户偏好要求

多个基础设施组件和 SAAS 可以支持这些高级通知首选项：

1. 用户偏好管理工具（例如，Customer.io、UserEngage）：这些工具提供用于管理用户偏好的界面和后端系统，确保用户可以轻松自定义其通知设置。
2. 消息平台（例如，Twilio、SendGrid）：这些 SAAS 促进了通知的多渠道传递，包括电子邮件、短信和推送通知，允许自定义传递选项。
3. 调度 SAAS（例如 Quartz Scheduler、DKron）： 用于安排通知，确保它们在用户指定的时间发送。
4. 国际化库（例如 i18next、Globalize）：这些库支持多语言功能，有助于翻译和传递各种语言的通知。
5. 集成平台（例如 Zapier、Integromat）：这些平台有助于将通知系统与其他应用程序和框架集成，确保平稳运行和用户体验。

通过利用这些工具和SAAS，您可以构建一个不仅满足而且超越用户期望的通知系统，提供高度个性化且高效的通知体验。

核心需求3：消息路由

有效的消息路由对于确保通知及时、相关并通过首选渠道传递至关重要。先进的消息路由功能可以显着提高用户满意度和参与度。

• 基于用户偏好和通知上下文的智能路由：通过分析用户设置、行为和上下文来定制通知传递，以确保相关性和受欢迎程度。 确保及时且相关的通知：通过考虑用户活动和上下文，最大限度地提高影响并避免消息过载，及时（
• 针对多个收件人的扇出功能：有效地将单个通知发送给多个收件人，保持协作应用程序的性能和交付速度。 时区感知传送：根据收件人的时区调整传送时间，以确保在最佳、无干扰的时间收到通知。
• 处理在线/离线状态：将离线用户的通知排队并在重新连接时传递它们，确保不会错过任何重要更新。

满足消息路由要求的支持基础设施

多个基础设施组件和 SAAS 支持这些高级消息路由功能：

1. 消息队列（例如，RabbitMQ、Apache Kafka、NATS、Apache Pulsar）：这些确保可靠且高效的消息传递和排队，允许智能路由和扇出操作。
2. 通知中心（例如 AWS SNS、Azure 通知中心）：这些提供了可扩展的平台，用于跨多个渠道向广大受众发送通知。
3. 调度 SAAS（例如 Quartz Scheduler、DKron）： 这些有助于安排通知，以确保根据时区和用户偏好在最佳时间发送通知。
4. Presence SAAS（例如 Firebase 实时数据库、PubNub）：这些 SAAS 可以跟踪用户在线/离线状态并相应地管理通知的排队和传递。
5. 用户分析平台（例如 Mixpanel、Segment）：这些平台可以深入了解用户行为和偏好，从而实现基于上下文和用户设置的智能路由决策。

核心要求4：团队互动性

确保团队交互顺畅对于通知的有效管理至关重要。这涉及使用协作工具、设置角色和权限以及授权非技术用户在不需要开发人员帮助的情况下进行更改。以下是这些要求的详细介绍。

• 评估工程人员的内容管理角色：确定开发人员是否需要处理所有内容任务，或者他们是否可以委托以改进资源管理和生产力。
• 非技术人员管理通知：允许非技术人员处理日常通知任务，提高效率并使开发人员能够专注于技术问题。
• 内容管理协作：使用共享工作区和文档编辑器等平台，通过实时更新和共享反馈来实现通知内容的团队协作。
• 团队成员角色和权限：定义特定角色和权限，以确保适当的访问、防止未经授权的更改并增强团队内的问责制。
• 非技术用户更改副本和图像：允许非技术用户通过用户友好的界面更新文本和图像，减少开发人员参与的需要并加快通知部署。

满足团队交互需求的支持工具和基础设施

多个基础架构组件和 SAAS 支持高级团队交互：

1. 多个基础架构组件和 SAAS 支持高级团队交互：
2. 协作平台（例如 Slack、Microsoft Teams、Discord、Google Chat）：这些平台促进团队成员之间的实时沟通和协作，简化通知管理流程。
3. 内容管理系统（例如 Contentful、WordPress）：这些系统通常具有内置角色和权限，允许结构化访问控制并使非技术用户能够轻松更新内容。
4. 文档编辑器（例如 Google Docs、Quip）：这些工具提供协作编辑功能，使团队成员能够共同处理通知内容并进行实时更新和评论。
5. 所见即所得编辑器（例如TinyMCE、Froala）：这些编辑器允许非技术用户无需编写代码即可更改通知内容和图像，从而轻松更新和管理通知。
6. 版本控制系统（例如 Git、Bitbucket）：虽然主要由开发人员使用，但这些系统还可以通过跟踪更改并确保所有更新在上线前经过审核和批准来支持协作。

通过利用这些工具和 SAAS，您可以创建一个协作环境，增强团队交互性，确保高效的内容和消息管理，同时为非技术用户提供支持。这种方法有助于维护一个动态且响应迅速的通知系统，可以快速适应不断变化的需求和用户反馈。

核心要求 5：分析和指标

分析和指标是有效通知系统的支柱。它们提供了有关交付成功、用户参与度和系统性能的见解。以下是对这些关键方面以及支持它们的基础设施的深入了解。

• 跟踪交付成功率和用户参与度： 监控跨渠道的通知交付并分析用户交互，以完善策略并提高满意度。
• 设置各个渠道的递送率：通过了解和调整不同渠道的递送率来优化通知活动，以确保及时递送。
• 监控和处理集成停机时间：使用监控工具和警报来快速解决集成问题，最大限度地减少通知传递的中断。
• 衡量用户参与度和响应率：分析打开率和点击率等指标，以确定通知有效性并改进内容和交付策略。

满足分析需求的支持基础设施和工具

多个基础设施组件和 SAAS 支持通知系统的高级分析和指标：

1. 分析平台（例如 Google Analytics、Mixpanel）：这些平台提供有关用户行为和参与度的详细见解，帮助您跟踪和分析关键指标。
2. 监控工具（例如 Datadog、New Relic）：这些工具有助于监控系统性能和集成停机时间，确保及时检测和解决问题。
3. 电子邮件/短信分析（例如 SendGrid、Twilio）：这些 SAAS 提供内置分析，用于跟踪跨电子邮件和短信渠道的交付成功率和用户参与度。
4. 推送通知 SAAS（例如 Firebase Cloud Messaging、OneSignal）：这些平台提供有关推送通知交付和参与度的详细指标，帮助您优化营销活动。
5. A/B 测试工具（例如 Optimizely、VWO）： 这些工具允许您测试不同的通知策略并衡量它们对用户参与度和响应率的影响。

通过利用这些工具和 SAAS，您可以构建全面的分析和指标框架，深入了解通知系统的性能。这使您能够做出数据驱动的决策、优化通知策略并确保高质量的用户体验。

核心需求6：体积和缩放

管理不断增加的通知负载：设计您的系统以实现最佳性能以处理大量信息，并水平扩展以满足不断增长的需求。

• 扩展策略：根据网络请求和队列大小使用水平扩展来分配负载、提高冗余并在高峰时段保持性能。
• 自定义指标：监控 CPU 使用率、内存、网络延迟和队列长度等指标，以便就扩展和资源分配做出明智的决策，以实现最佳性能。

自定义指标挑战

自定义指标需要全面了解系统架构以及影响通知基础设施的具体性能指标。其中包括：

1. 确定相关指标：确定哪些指标最能反映系统性能和资源需求。
2. 实施监控工具：集成可以实时捕获和报告这些指标的工具，例如 Prometheus 和 Grafana 或第三方监控系统。
3. 配置警报和阈值：设置警报和阈值，以便在某些指标超过预定义限制时通知您的团队，表明需要进行扩展调整。
4. 测试和校准：持续测试和校准指标，以确保它们准确反映系统性能并提供可行的见解。

使用自定义指标进行动态扩展

自定义指标到位后，利用它们进行动态扩展涉及：

1. 自动扩展策略： 开发基于实时指标触发扩展操作的自动化策略。例如，当 CPU 使用率超过一定百分比时添加服务器，或者当队列大小低于阈值时减少服务器。
2. 持续监控和调整：定期监控扩展策略的性能，并根据需要进行调整，以应对不断变化的条件和工作负载。
3. 与编排工具集成：使用 Kubernetes、Nomad 或托管容器解决方案等编排工具来无缝管理扩展过程，确保资源在无需人工干预的情况下高效分配。

使用自定义指标的挑战

使用自定义指标进行动态扩展会带来一些挑战：

1. 复杂性：管理多个指标的复杂性并确保它们准确反映系统的需求可能会令人畏惧。
2. 资源分配：平衡资源分配以避免过度配置（导致更高的成本）和不足（影响性能）需要不断调整。
3. 与现有系统集成：确保自定义指标和扩展策略与现有基础设施和工作流程顺利集成在技术上要求很高。

概括

有效设置和利用自定义指标进行动态扩展对于维护强大、可扩展且高效的通知基础设施至关重要。虽然该过程很复杂并且需要付出巨大的努力，但提高性能、成本效率和弹性的好处使其成为一项值得的投资。通过专注于这些策略并克服相关挑战，您可以确保您的通知系统能够适应不断变化的需求并提供无缝的用户体验。

核心需求7：调试和通知追踪

使用先进的工具和方法来解决消息传递问题可以让您及时诊断并解决问题。跟踪消息路径通过跟踪每条消息的旅程来确保责任，确认其到达目的地。分析队列有助于识别瓶颈和传送失败，确保消息流顺畅。此外，确定问题是由内部系统还是第三方集成引起的有助于更有效地隔离和解决问题。

• 排除传送问题的工具和方法：使用诊断工具来检测和解决消息传送问题，确保通知的一致性。
• 跟踪消息路径并确保责任：跟踪每条消息以验证交付并识别故障点，维护系统完整性和改进见解。
• 分析队列以识别瓶颈和故障：监控和分析队列数据以检测瓶颈和传送故障，从而采取纠正措施以实现顺利的消息处理。
• 确定问题根源：将问题隔离到内部系统或第三方集成，以进行有效的故障排除和解决。

概括

先进的工具可以快速诊断和解决问题，同时跟踪消息路径可确保问责制。分析队列有助于识别瓶颈，区分内部问题和第三方问题可以实现高效的故障排除。这些做法确保了通知操作的顺利和高效。

运行通知平台：操作注意事项

确保通知系统稳健可靠需要仔细关注多个操作方面。其中包括持续维护、处理量和扩展、调试和跟踪问题以及团队考虑因素。以下是这些关键领域的简要概述。

持续维护/修补、更新和安全更新

定期系统更新和安全补丁对于保护您的通知基础设施免受漏洞的影响至关重要。通过保持最新补丁，您可以确保平稳运行并防止潜在的安全漏洞。这种主动方法可以最大限度地减少停机时间并保持系统完整性。

处理不断变化的需求和功能增强

调整您的系统以满足新用户需求并融入高级功能对于保持相关性至关重要。这涉及定期评估用户反馈和市场趋势以更新您的通知基础设施。通过这样做，您可以增强用户体验并保持竞争优势。

集成更改以适应新的 SAAS 和平台

随着新的 SAAS 和平台的出现，确保兼容性至关重要。定期更新您的系统以与 Firebase Cloud Messaging (FCM) 等工具集成，让您能够利用新技术并保持无缝通信。这种适应性使您的基础设施保持灵活且面向未来。

通知模板和内容更新

保持通知模板和内容最新可确保您的消息保持相关性和吸引力。定期更新可帮助您满足不断变化的用户偏好并保持高参与率。新鲜的内容和吸引人的模板可以显着提高通知的有效性。

提供商集成

维护和更新与各种服务提供商的集成对于无缝通信至关重要。这涉及确保您的通知基础设施能够有效地与电子邮件、短信和推送通知 SAAS 交互。定期检查和更新可确保这些集成顺利运行。

API和SDK维护和测试

定期维护和测试 API 和 SDK 是确保它们与其他系统组件正常工作所必需的。这包括更新到最新版本并进行彻底的测试以识别和修复任何问题。有效的API/SDK管理确保系统性能可靠高效。

凭证管理和安全

安全地管理凭据对于防止未经授权的访问和保护数据至关重要。定期更新和安全存储凭据可以降低安全漏洞的风险。实施强身份验证方法和监控访问控制是凭证管理的关键实践。

概括

定期系统更新和安全补丁对于保护您的基础设施免受漏洞、最大限度地减少停机时间和维护系统完整性至关重要。适应不断变化的需求并与新的 SAAS 集成，使您的系统保持相关性和灵活性，同时持续的安全升级可以防范新出现的威胁。
维护和更新通知模板可确保消息保持吸引力和有效性。定期检查和更新提供商集成，以及对 API 和 SDK 进行全面维护和测试，确保无缝通信和可靠的性能。安全凭证管理可防止未经授权的访问并保护数据。
通过关注这些操作注意事项，您可以确保您的通知系统保持稳健、可扩展和高效，提供无缝的用户体验并支持您不断变化的业务需求。

资源配置

在决定是否构建或购买通知基础设施时，准确估计所需时间至关重要。以下是构建通知基础设施的不同层级的细分，重点关注每个层级所需的时间投入，从简单的集成到复杂的系统，包括持续的维护估算。

1. 简单的通知集成
   • 范围：重要更新的基本通知。
   • 资源：1 名工程师，2 周。
   • 复杂性：低；最少的定制和功能。
   • 外部包：通常有 2-4 个外部包（例如 SMTP 库、基本通知框架）。
   • 持续维护：低。预计每季度更新需要 1-2 天的工程时间来进行测试和集成。
2. 多渠道通知
   • 范围：支持多种渠道（例如电子邮件、短信、推送）。
   • 资源：1-3 名工程师，1 个季度。
   • 复杂性：中等；需要与各种通信 API 和偏好管理集成。
   • 外部软件包：大约 6-24 个外部软件包（例如，用于 SMS 的 Twilio、用于推送通知的 Firebase、电子邮件服务提供商等）。
   • 持续维护：中等。每月至少更新一个软件包，每月需要大约 1 周的工程时间来测试和集成。
3. 分段通知
   • 范围：针对有针对性的通知进行用户细分。
   • 资源：2-4 名工程师，2 个宿舍。
   • 复杂性：高；涉及构建用户细分的基础设施、管理不同的用户组以及确保可扩展性。
   • 外部包：大约 8-24 个外部包（例如，用户细分库/系统、高级通知 SAAS）。
   • 持续维护：高。多个软件包每两周更新一次，每月估计需要 2-3 周的工程时间进行测试和集成。
4. 国际化
   • 范围：全面支持多种语言和区域偏好。
   • 资源：3-5 名工程师，6 个宿舍。
   • 复杂度：非常高；涉及开发强大的语言翻译系统、管理不同的区域偏好以及确保遵守国际法规。
   • 外部包：大约 10-24 个外部包（例如翻译 SAAS、本地化框架）。
   • 持续维护：非常高。每周更新各种软件包，每月需要大约 4-6 周的工程时间来测试、集成和持续改进。
5. 个性化
   • 范围：基于用户行为和偏好的个性化通知。
   • 资源：4-6 名工程师、1-2 名数据工程师、2-4 名基础设施工程师至少 14 个季度。
   • 复杂度：极高；需要复杂的数据处理、用户分析和动态内容生成。
   • 外部包：大约 16-32 个外部包（例如机器学习库、推荐引擎、基础设施和数据湖集成）。
   • 持续维护：极高。每周更新和合规性检查，每月需要 6-8 周的工程时间来维护、测试和集成更新，同时确保遵守法规。

决策时间

通过了解构建通知基础设施每一层的时间要求，您可以更好地评估是构建还是购买。考虑您组织的具体需求、可用资源和长期目标，以做出符合您的战略优先事项的决策。无论是选择简单的集成还是完全个性化和国际化的系统，确保您拥有正确的资源和时间表对于成功至关重要。

通过检查通知基础设施的不同层级（从简单的集成到复杂、个性化和国际化的系统），您可以更好地了解每个实施级别所需的时间和精力。这些知识将帮助您做出符合您的战略重点的明智决策，确保您的通知系统强大、可扩展，并且能够满足用户不断变化的需求。

无论您选择构建还是购买，目标都是创建无缝且有效的通知体验，提高用户参与度和满意度，同时支持组织的成长和成功。

以上是您的应用程序的通知：您应该构建还是购买？的详细内容。更多信息请关注PHP中文网其他相关文章！