我需要一个在线客户门户安全"消息中心"，以便在客户通过安全渠道登录后，允许后台和前台以双向方式与客户沟通。
我们已经采购了一个CMS平台，该平台具有开箱即用的小部件表示层，它希望连接到API来处理通信和持久性，即CMS是无状态的。
我想知道人们是如何设计和解决这个问题的——我目前的想法：
- 通过 REST API 将其硬塞到我们的后端 CRM 系统中 - 这需要自定义开发
- 使用 RDBMS(遵循消息结构的自定义数据库数据模型)并在数据库上构建 REST API 来处理客户交互事件，即读取、删除、新消息
- 构建一个纯粹的微服务架构，将持久性与服务耦合 - 即坚持模式 - 工程方面，我们还没有这个能力
- 我错过的其他明显解决方案？
我相信这已经解决了多次，很想听听什么效果最好？
*我忘了提到的一件事是，我们正在从旧的遗留系统迁移，需要随身携带大约 10GB 的客户消息，即历史数据;这些数据需要迁移到新的解决方案中。
非常感谢
无论你如何实现后端，这里的关键是在进行任何编码之前，花时间让你的 REST 接口"正确"。尝试将接口分解为小型专用接口，这些接口为以业务为中心的特定职责提供服务。此外，请考虑数据模型抽象及其在 HTTP 有效负载中的表示形式，以及如何使用嵌入在通过接口传输的数据中的链接交叉引用其他数据。如果接口正确，则可以交换实现。
如果不对选项进行深入分析，就不可能说什么是最好的方法。不幸的是，您还没有真正解释所需的API的全部范围或现有CRM的功能，但是我假设选项1将具有有用的业务优势，因为它与您现有的系统和业务流程集成。选项 2/3 需要您的办公室工作人员用户使用不同的系统，需要培训/支持，在我看来这似乎并不理想。选项 3 需要大量的工作(不仅仅是编码，还有集成测试、部署、编排等！)，从您对任务的描述来看，不清楚是否真的需要走这条路。我非常高级的预感是选项 1，但您显然需要研究您提供给 CMS 的 API 与 CRM 上可用的 API 之间是否存在适当的映射。还要记住CRM的安全模型，当然还有响应能力/吞吐量。