如果采用 KV 方式存储，如何设计数据结构 ?同上，我们要怎样去设计一种高效的 topic 分片存储策略;
订阅关系的管理是 MQTT 消息系统的核心模块，假如这个存储模块失效，就必定会导致消息通信失败，从而让客户端收不到消息，这就必须要求这个模块一定是高可用的，也就意味着我们必须构建一个高可用的 KV 存储集群，该集群要能容忍一定程度的节点失效;
冷热 topic 要有淘汰机制，要有一定策略将不活跃的 topic 定期淘汰到磁盘以节约内存容量;
KV 存储集群要能高效地动态扩容;
在很长一段时间的实践中，我们采用过好几种 KV 存储的集群方案，踩了不少坑，最后还是决定自己造轮子来开发一个高可用的 KV 存储模块。不过这又是一个很大的话题，我们将在后续博客中具体阐述我们的做法。
缺陷与不足
在团队发展初期，由于人力和时间等种种因素，我们把业务逻辑模块开发成了一个巨大的单体架构应用。在团队规模较小的情况下，单体架构的应用确实较好维护和开发，但随着新人的加入，单体架构则严重制约着特性开发和性能优化。从架构层面上来看，合理地划分更细粒度的模块，在性能和可维护性上采用 微服务 (microservice)设计模式，成了我们未来优化系统的方向之一。
总结
软件工程上有「没有银弹」(No Silver Bullet)这条金科玉律，用户选择云服务商亦是如此，绝对没有完美的第三方云服务商，每一家都可能存在明显的优点和缺陷。用户必须从自己应用场景和痛点出发，选择合适的后端服务。云巴将会在自己产品的核心竞争力上持续发力，精打细磨，吸取行业内的高效实践经验，打造出更加优秀的高可用实时通信系统。