不过，通过对业务模块更细粒度的划分，我们可以将一些核心的小模块用 C/C++ 语言改写，在一定范围的复杂度内，可以有效提升整体处理性能。这也是我们接下来优化核心系统的思路之一。

MQTT 的 Pub/Sub 模型与高可用 KV 存储

MQTT 协议采用的是 Pub/Sub 的编程模型。其中有三个比较关键的动作：publish，subscribe 和 unsubsribe。通过前面几个章节的讨论，我们又可以得到这么一个场景：

假如存在一个订阅量巨大的 topic（百万级），如何在单次 publish 中保证实时性 ？

其实，解决思路跟之前的场景是一致的：分而治之。我们必须通过某种策略对 topic 进行分片，然后将分片分发到不同的 publish 模块上进行处理。在一定的算法复杂度下，这个问题理论上是可以被有效解决的。于是，topic 的分片策略就成了高性能 publish 的关键。其实，如果想采用 MQTT 做海量消息系统，订阅关系的管理一定是无法绕开的大问题。它主要有以下几个设计难点：

• 如果采用 KV 方式存储，如何设计数据结构 ？同上，我们要怎样去设计一种高效的 topic 分片存储策略；

• 订阅关系的管理是 MQTT 消息系统的核心模块，假如这个存储模块失效，就必定会导致消息通信失败，从而让客户端收不到消息，这就必须要求这个模块一定是高可用的，也就意味着我们必须构建一个高可用的 KV 存储集群，该集群要能容忍一定程度的节点失效；

• 冷热 topic 要有淘汰机制，要有一定策略将不活跃的 topic 定期淘汰到磁盘以节约内存容量；

• KV 存储集群要能高效地动态扩容；

在很长一段时间的实践中，我们采用过好几种 KV 存储的集群方案，踩了不少坑，最后还是决定自己造轮子来开发一个高可用的 KV 存储模块。不过这又是一个很大的话题，我们将在后续博客中具体阐述我们的做法。

缺陷与不足

在团队发展初期，由于人力和时间等种种因素，我们把业务逻辑模块开发成了一个巨大的单体架构应用。在团队规模较小的情况下，单体架构的应用确实较好维护和开发，但随着新人的加入，单体架构则严重制约着特性开发和性能优化。从架构层面上来看，合理地划分更细粒度的模块，在性能和可维护性上采用微服务（microservice）设计模式，成了我们未来优化系统的方向之一。

总结

软件工程上有「没有银弹」（No Silver Bullet）这条金科玉律，用户选择云服务商亦是如此，绝对没有完美的第三方云服务商，每一家都可能存在明显的优点和缺陷。用户必须从自己应用场景和痛点出发，选择合适的后端服务。云巴将会在自己产品的核心竞争力上持续发力，精打细磨，吸取行业内的高效实践经验，打造出更加优秀的高可用实时通信系统。