18 | Docker容器化：说一说IM系统中模块水平扩展的实现

袁武林



该思维导图由 AI 生成，仅供参考

你好，我是袁武林。
在第 10 讲“自动智能扩缩容：直播互动场景中峰值流量的应对”中，我较为系统地讲解了直播场景中突发流量的应对策略。其中比较重要的一点就是：当有热点流量进来时，我们能够通过监控指标对服务进行快速扩缩容。
而快速扩缩容的一个重要前提，就是部署的服务和资源能够做到水平扩展。
那么，今天我们就来聊一聊服务和资源水平扩展的实现问题。
垂直扩展首先从水平扩展 (Scale out) 的概念说起吧。
要解释水平扩展是什么，我们要先了解下与水平扩展相对应的另一个概念：垂直扩展（Scale up）。只有通过这两者可行性和实现层面的对比，我们才能更好地理解为什么水平扩展能力对于实现一个架构良好的系统如此重要。
当业务的用户量随着产品迭代不断增长时，相应的后端资源和服务器的压力也在逐渐加大。而解决资源和服务器瓶颈一个有效且较快的方式就是：提升资源服务器和应用服务器的单机处理能力，也就是对资源服务器和应用服务器进行“垂直扩展”。
提升单机硬件性能要对资源和服务进行垂直扩展，一个简单粗暴但也比较有效的方式就是：增强单机服务器的性能。
比如：对 CPU 出现瓶颈的服务器进行升级，增加 CPU 核数和主频；对于网卡有瓶颈的服务器，升级到万兆网卡并接入到万兆交换机下；内存出现瓶颈导致系统吃 Swap 的情况，我们也可以将内存升级到更高配置来进行垂直扩展。一般情况下，通过对服务器硬件的升级，往往能快速解决短期的系统瓶颈问题。

公开

同步至部落

取消

完成

0/2000

荧光笔

直线

曲线

笔记

复制

AI

深入了解
翻译
英语
中文简体
中文繁体
法语
德语
日语
韩语
俄语
西班牙语
阿拉伯语
解释
总结

文章标题：Docker容器化：IM系统中模块水平扩展的实现本文深入探讨了在即时聊天场景中，如何实现IM系统中模块的水平扩展。首先介绍了垂直扩展和水平扩展的概念，强调了水平扩展对于应对突发流量的重要性。在垂直扩展方面，文章提到了提升单机硬件性能和增加单机服务处理能力的方式。然后，重点讨论了水平扩展在接入层的实现，包括通过DNS轮询多VIP来解决单VIP入口瓶颈问题，以及对接入服务的无状态化设计和中央资源的维护，实现接入层的水平扩展解耦。文章通过详细的技术分析和实际场景举例，为读者呈现了IM系统中模块水平扩展的实现方法和技术特点。在业务层方面，文章提到了利用DNS轮询“单域名多VIP”来解决接入层VIP入口的瓶颈问题，以及通过“服务拆分”和“中央的在线状态资源”实现业务层的水平扩展。对于资源层的水平扩展，文章提到了通过数据分片机制和增加从库来缓解主库和从库的压力，实现资源的水平扩展。最后，文章介绍了容器化部署的重要性，以及如何利用Docker等容器化技术来实现快速扩容，提高部署效率。总的来说，本文通过深入的技术分析和实际案例，详细介绍了在即时消息场景中，如何实现IM系统中模块的水平扩展。从接入层、业务层到资源层，都提出了相应的解决方案和技术特点，为读者呈现了一幅完整的技术实现图景。同时，强调了容器化部署在实现快速扩容和提高部署效率方面的重要性，为读者提供了一种解决方案。

仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《即时消息技术剖析与实战》，新⼈⾸单¥59

立即购买

登录后留言

全部留言(23)

最新
精选

leslie
老师：目前有没有什么不错的开源IM项目可以学习和研究？
作者回复: 可以看看mqtt的github项目，另外国内应该蘑菇街开源了一款叫teamtalk的im软件，也可以看看。
2019-10-07

17
大魔王汪汪
老师的课程应该是最近半年极客时间最棒的啦！其他的竟是些概念理论的泛泛而谈😜
作者回复: 欣慰，感谢支持，继续努力～
2019-10-07
2
13
东东🎈
老师，如果遇到ddos攻击，有啥处理方案吗？
作者回复: 硬件层面可以上硬件防火墙来清洗异常流量，软件层面可以通过缩短syn半连接的超时来缓降。
2019-10-07

8
clip
用分片来做水平扩展的话灵活性是低的吧，是不是不适合随着每天波峰、波谷来调整？感觉只能扩很难收。如果某个时段有大量写入，用什么方式应对比较合适呢？
作者回复: 跟随流量波动来进行资源层的扩缩容对于数据读取可能比较有效，但是对于数据依赖master的写入扩缩容实现会比较麻烦。对于写入的优化可以采用类似操作系统buffer的机制，来对写入数据进行合并后批量写入，甚至根据业务来进行更高级的定制化合并逻辑。这一块我在第20篇万人群聊系统的设计中会讲一下。
2019-10-09

6
QQ怪
可以分库分表来解决单表写入数据量大，查询时间过长，但实现其复杂性也增加了，需要实现分区键或者说以什么依据来进行分库分表
作者回复: 嗯，分库分表是一个有效提升写入能力的手段，除了这个还有其他优化方式吗？
2019-10-07
2
5
HelloTalk
要想解决资源层的写入瓶颈，除了分片机制外，还可以移步写用队列来操作
作者回复: 是个方案，不过队列更多起到的是削峰填谷的作用，对写入瓶颈的真实写入能力提升有限。
2019-10-07

4
kamida
老师请问长链接请求是怎么从lvs转到网关的啊。是接入服务先返回给用户一个网关地址然后用户直接长链接到那个网关的吗
作者回复: 用户拿到的是vip地址，实际请求会路由到lvs所在的机器，再由lvs转发给真正后面的网关服务器。当然，也可以不用vip来直连网关机，存在的问题是服务上线时需要暂时下线这台网关机可能比较麻烦。
2020-03-13
5
3
面爸
人数统计的话，应该用redis就可以实现，写入的话，可以队列，异步去写
作者回复: 嗯，redis作为计数没问题的，不过异步写入只是起到削峰填谷的作用，并不能提升写入的绝对能力，可以再想一想哈
2019-10-07

3
唯我天棋
1.连接层和业务层之间增加一个业务代理，这样连接层可以更加专注于处理连接问题，让业务代理来完成服务发现，管理业务集群，这样会不会更好？ 2.为什么在连接层直接rpc调用业务端。那业务端需要通过这条连接推送消息不是会很不方便吗？
作者回复: 服务发现本身是rpc框架自带的通用特性，对系统消耗很小，再增加一层会使消息收发链路变长，整体稳定性可能会有影响。业务层推送消息是通过消息队列来实现的，不需要依赖rpc。
2019-11-04

2
Jun
是否可以先在服务器端聚合一段时间的数据再写入
作者回复: 嗯，不错的想法，业务允许一定的风险的话这是一个不错的优化手段。
2019-10-11

2

收起评论