极客时间已完结课程限时免费阅读

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

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

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

2019-10-07 袁武林 来自北京
《即时消息技术剖析与实战》
课程介绍

讲述：袁武林

时长17:59大小14.38M

你好，我是袁武林。
在第 10 讲“自动智能扩缩容：直播互动场景中峰值流量的应对”中，我较为系统地讲解了直播场景中突发流量的应对策略。其中比较重要的一点就是：当有热点流量进来时，我们能够通过监控指标对服务进行快速扩缩容。
而快速扩缩容的一个重要前提，就是部署的服务和资源能够做到水平扩展。
那么，今天我们就来聊一聊服务和资源水平扩展的实现问题。

垂直扩展

首先从水平扩展 (Scale out) 的概念说起吧。
要解释水平扩展是什么，我们要先了解下与水平扩展相对应的另一个概念：垂直扩展（Scale up）。只有通过这两者可行性和实现层面的对比，我们才能更好地理解为什么水平扩展能力对于实现一个架构良好的系统如此重要。
当业务的用户量随着产品迭代不断增长时，相应的后端资源和服务器的压力也在逐渐加大。而解决资源和服务器瓶颈一个有效且较快的方式就是：提升资源服务器和应用服务器的单机处理能力，也就是对资源服务器和应用服务器进行“垂直扩展”。

提升单机硬件性能

要对资源和服务进行垂直扩展，一个简单粗暴但也比较有效的方式就是：增强单机服务器的性能。
比如：对 CPU 出现瓶颈的服务器进行升级，增加 CPU 核数和主频；对于网卡有瓶颈的服务器，升级到万兆网卡并接入到万兆交换机下；内存出现瓶颈导致系统吃 Swap 的情况，我们也可以将内存升级到更高配置来进行垂直扩展。一般情况下，通过对服务器硬件的升级，往往能快速解决短期的系统瓶颈问题。

增加单机服务处理能力

除了提升单机硬件的整体性能，我们还可以通过优化单机的服务进程处理能力，来实现对资源和服务的垂直扩展。
比如：我们部署的应用程序可以通过增加处理线程数，进一步榨干单机的硬件性能，以此提升服务进程整体的处理能力；或者通过扩大应用程序的使用内存，来提升请求的处理效率，如 Java 进程通过 -Xmx 增大堆内存空间，使用机器的本地缓存来优化访问速度；对于容易出现带宽瓶颈的业务来说，也可以通过架构改造，对收发的数据进行压缩，以降低数据传输量。
通过对单机服务架构和部署的优化，我们能够在不升级服务器硬件的前提下，提升单机服务的处理能力。
不过，虽然我们可以通过以上这两种方式来解决部分资源和服务的瓶颈问题，但不管是通过什么办法来提升服务器的单机性能，它总是会达到极限的。
所以，采用“垂直扩展”的方式，我们基本上只能解决短期的资源和服务瓶颈，而真正长远且有效的解决方案是：让资源和服务做到可以随时随地进行无差别的扩容，也就是对资源和服务进行“水平扩展”。

水平扩展

对于即时聊天的场景来说，用户的消息收发往往会牵涉到多层的服务和资源。因此，要让 IM 系统也能做到“水平扩展”，我们需要让 IM 系统涉及到的服务和资源都能够通过快速扩容，来缓解突发流量带来的压力。
我在课程第 1 讲“架构与特性：一个完整的 IM 系统是怎样的？”中，也有讲过一个典型的 IM 系统架构是怎样的，你可以参考下图：
客户端通过 DNS Server 或者 HttpDNS，查询接入服务对外提供的公网 VIP（虚拟 IP）。这个公网 VIP 通过 Keepalived 绑定到多台 LVS（Linux Virtual Server，Linux 虚拟服务器）上，能够实现单台 LVS 故障后自动切换到另一台。当用户访问这个公网 VIP 时，就会被路由重定向到真正的 LVS 上。
LVS 运行在操作系统内核态，会按照设定的负载均衡策略，将 IP 数据包分发到后端接入网关机，接入服务器再把数据透传给业务处理服务层，业务处理服务进行具体的业务逻辑处理，比如读写缓存和消息存储等。
那么我们就来看看，在上图所示的整个链路上，具体各层在出现压力和瓶颈时，如何做到“水平扩展”？

接入层如何水平扩展

首先，我们看下链路最外层入口的 VIP。
对于 LVS 服务器来说，由于只是在 TCP/IP 层对数据包进行简单的转发，并不需要解析数据包给到应用层，所以服务器相应的处理性能是很高的，单机每秒数据包转发 PPS 能达到千万级别。因此在大部分情况下，LVS 服务器本身不会成为瓶颈。
但是对于 IM 系统中的直播互动场景来说，由于存在瞬时上万级别的长连建连请求场景，单台 LVS 服务器可能会导致建连失败的情况。
针对这种情况，我们一般可以通过 DNS 轮询来实现负载均衡。
简单地说就是：在 DNS 服务器中，针对接入服务域名配置多个 VIP；当用户访问接入服务时，DNS 服务器就会通过轮询或者其他策略，来从 A 记录中选择某一个 VIP 供用户连接。
比如上图所示：微信长连接通道针对同一个域名进行 DNS 查询，就返回了多条 A 记录供接入设备选择。
在通过“DNS 轮询多 VIP”的水平扩展，解决了单 VIP 入口可能出现的瓶颈问题后，对于用户的消息收发来说，另一个容易出现瓶颈的点就是应用层的接入服务了。
要想解决这个问题，我们先从业务使用的角度来分析一下。
以大型聊天室或者大型直播间的场景为例，其链路压力一般来自于消息扇出后的下推，其他链路环节实际上对于聊天室成员增长，或者直播间在线人数增长并不会太敏感。
所以，正如在第 10 篇中所讲到的，我们要对那些容易随着用户热度增加，而出现流量突升的环节进行架构上的剥离，以便在出现流量峰值时，对这些拆分后相对较轻量的接入服务进行扩容。
另外，我们在设计接入服务时，要尽量做到无状态化。
无状态化的意思就是任意用户随时都可以连接到任意一台接入服务器上，这样我们的接入服务才可以随时进行“水平扩展”。除了接入用户连接外，当服务端有消息需要推送给客户端时，业务逻辑层需要把消息精确推送到具体某个用户连接的网关机上。
要想实现接入层的水平扩展解耦，我们一般可以通过维护一个中央的用户和“所在网关机 IP”的映射关系，或者通过网关机 IP 维度的 Topic，来利用消息队列进行精准推送（比如离线消息的拉取）。通过中央的“在线状态”服务，我们就能让接入层和业务层通过这个中央资源来进行交互，让接入层做到无状态化。其实现方式如下图：
用户通过接入服务上线后，接入服务会在中央资源中（比如 Redis）记录当前用户在哪台网关机上线。如果业务层有消息需要推送给这个用户时，通过查询这个中央资源，就能知道当前用户连接在哪台网关机上，然后就可以通过网关机的 API 接口，把消息定向投递推送给用户了。

业务层如何水平扩展

利用 DNS 轮询“单域名多 VIP”，我们解决了接入层 VIP 入口的瓶颈问题。此外，对于应用层的接入服务的瓶颈问题，我们可以结合业务场景，通过“服务拆分”，将容易出现峰值波动的应用接入服务进行抽离，以便于接入层扩容；最后通过“中央的在线状态资源”，让接入层做到完全“无状态”，从而实现了接入层的“水平扩展”。
虽然很多时候，我们的业务层不像接入层一样，对流量的波动那么敏感，但在实际业务中，每天的用户访问也会呈现出比较明显的流量变化。比如在很多聊天场景中，凌晨和上午的流量相对会低一些，而晚上的用户访问量会更大。
因此，为了更好地提升服务器资源利用率，我们的业务层也需要做到“水平扩展”。我们可以在流量低峰时，让业务层服务保持较低的部署规模；在晚上高峰时，通过扩容来保证用户访问的速度。
由于接入层对业务层是强依赖关系，因此业务层水平扩展的关键在于：如何让业务层在扩缩容后，能够被接入层及时感知到？
对于这个关键问题，业界比较常见的解决方式是：对业务层进行“服务化”改造，以此让接入层通过“自动服务发现”，来感知到业务层的变化。
比如，通过 Thrift、gRPC、Dubbo、Motan 等 RPC 框架，结合服务发现和健康检查组件，就能对业务层进行“服务化”的改造了。这里我简单画了一张图，来说明一下对业务层“服务化”改造的实现过程。
业务层的多台服务器在启动上线时，先在“服务注册中心”进行服务注册，登记当前业务机器支持调用的“服务”；启动后，服务注册中心通过“注册中心主动检测”或者“业务服务器主动上报”的方式，定期对服务的可用性进行健康检查，不可用的业务服务器会从注册中心摘除。
长连网关机在需要调用业务层服务时，会先通过服务发现、获取当前要用到的服务所注册的业务服务器地址，然后直连某一台具体的业务服务器进行 RPC 服务调用。
这样，通过对业务层进行“服务化”改造，利用服务注册和服务自动发现机制，我们就能够让业务层做到完全的无状态化。不管我们的业务层如何进行扩缩容，接入层也能随时调用到业务层提供的服务，从而实现了业务层的“水平扩展”。

资源层如何水平扩展

解决了业务层水平扩展的问题，我们再来看一下资源层是如何“水平扩展”的。
对于即时消息场景中，依赖度非常高的资源层来说，当面临高并发的突发流量时，同样容易出现读写的瓶颈。比如前面讲到的消息内容和消息索引的缓存、维护未读数的资源、存储离线消息的资源，等等，当用户量和消息收发频率很高时，也都会面临较大压力。
这里所说的资源层，包括我们使用到的缓存和存储。
缓存的水平扩展，咱们在上一篇中有讲过：针对数据读取压力的问题，我们可以通过增加从库、增加 L1 缓存、应用层支持本地缓存的多级缓存模式等手段来解决。
而对于支持数据写入的主库来说，由于其存在单主的情况，所以在写入量大时，也容易出现瓶颈。因此，我们可以通过分片（Sharding）机制来解决。
下面我用聊天场景中“最近联系人”的缓存来举个例子。
当用户的消息收发非常频繁的时候，主库的缓存更新压力会很大。通过分片机制，我们就可以把不同用户的“最近联系人”缓存分散到不同的缓存实例中；通过增加缓存实例的方式，来缓解单实例的写入压力。
同样，对于存储层资源来说，我们也可以通过增加从库和数据分片，对资源层进行水平扩展，从而提升资源的压力应对能力。

容器化部署

现在，我们针对接入层、业务层、资源层的水平扩展方案都有了，接下来要考虑的就是如何实施的问题。
比如，接入层服务和业务层服务在出现瓶颈的时候，我们如何进行快速扩容呢？
目前，业界比较成熟的方案是通过 Docker 等容器化技术来解决。
Docker 容器化就是指：当我们的服务需要扩容时，先把服务打包为 Docker 镜像，通过运维系统或者第三方的 Kubernetes 等容器管理服务，来动态分发镜像到需要部署的机器上，并进行镜像的部署和容器启停。
这里的 Docker 镜像，你可以理解为一个“包含服务运行代码和运行环境的最小的操作系统”。当镜像分发到需要部署的机器上后，启动此镜像的容器，这个“最小化的操作系统”就能够把你的服务运行代码快速部署并运行起来。
那么，为什么 Docker 等类似的容器化技术能够让我们的服务做到快速扩容呢？
举个例子，我们在聊天场景中用到的图片和视频转码服务，在生成缩略图和处理视频时，需要先安装一些本地化的工具。
在没有容器化部署前，我们要扩容这个图片或视频服务时，就需要先在相应的部署机器上安装一堆工具，然后才能部署服务。不过有的时候，安装工具对操作系统的内核版本和其他依赖有要求，因此经常会出现有的机器装不上，有的机器还需要安装些别的依赖等情况，整个的扩容效率很低。
而有了 Docker 等容器化技术之后，就能非常方便地解决以上这些问题了。
我们可以以某一个固定版本的操作系统镜像为基础，然后在构建自己的应用镜像时，再安装上依赖的工具包。这样，所有的依赖都已经固化到“最小化的操作系统”中了，不再依赖部署机器本身的操作系统版本，也不需要在部署机器上安装各种工具了。
可见，通过 Docker 等容器化技术，我们能非常方便地解决服务部署复杂和低效的问题，你可以在以后的实际业务中尝试运用一下。

小结

接下来简单回顾一下今天课程的内容。
这一讲，我主要针对即时消息场景中，链路各层如何实现快速地“水平扩展”，介绍和分析了一些解决瓶颈问题的方案。
由于“垂直扩展”的可扩展性依赖于单机自身的硬件能力，并不能彻底解决资源和服务器“无限扩容”的问题，因此需要链路各层能够做到“水平扩展”。
各层的水平扩展的实现，有以下几种参考方案。
针对接入层的水平扩展，我们需要解决好两个瓶颈问题：
一个是接入层的入口 VIP 瓶颈问题，我们可以针对单域名支持多 VIP 映射，并通过 DNS 轮询来进行负载均衡；
而针对业务自身的接入层服务，我们可以通过中央的“在线状态”资源，来解耦业务层的依赖，从而实现水平扩展。
针对业务层的水平扩展，我们可以进行“服务化”改造，依托“服务注册中心”和“服务自动发现”解决调用方寻址问题，实现业务层的水平扩展。
针对资源层的水平扩展，我们可以通过数据分片机制缓解主库和从库压力，还可以通过多从库提升读取能力，实现资源的水平扩展。
在链路各层的水平扩展的具体实施上，我们可以借助 Docker 等容器化技术，来屏蔽部署机器的差异。通过应用镜像的自定义部署环境，来提升链路各层水平扩展时的部署效率。
服务和资源的水平扩展能力，决定了我们的系统架构随着业务发展是否具备“高可扩展性”，也决定了这个架构的生命周期。
因此，我们在设计一个系统的时候，可以先问一下自己：我设计的这套架构是否能够随着业务的增长，相应的“业务支撑能力”也能随着服务的“水平扩容”做到线性的提升？相信当你开始思考这些问题的时候，你离成为一位合格的架构师也越来越近了。
最后给大家留一道思考题：要想解决资源层的写入瓶颈，除了分片机制外，还有什么办法能解决资源写入瓶颈的问题呢（比如直播间观看人数的计数资源）？
以上就是今天课程的内容，欢迎你给我留言，我们可以在留言区一起讨论，感谢你的收听，我们下期再见。
分享给需要的人，Ta购买本课程，你将得18元
生成海报并分享

赞 5

提建议

© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
17 | Cache：多级缓存架构在消息系统中的应用
下一篇
19 | 端到端Trace：消息收发链路的监控体系搭建
 写留言

精选留言(23)

  • leslie
    2019-10-07
    老师：目前有没有什么不错的开源IM项目可以学习和研究？

    作者回复: 可以看看mqtt的github项目，另外国内应该蘑菇街开源了一款叫teamtalk的im软件，也可以看看。

    14
  • 大魔王汪汪
    2019-10-07
    老师的课程应该是最近半年极客时间最棒的啦！其他的竟是些概念理论的泛泛而谈😜

    作者回复: 欣慰，感谢支持，继续努力～

    共 2 条评论
    13
  • 东东🎈
    2019-10-07
    老师，如果遇到ddos攻击，有啥处理方案吗？

    作者回复: 硬件层面可以上硬件防火墙来清洗异常流量，软件层面可以通过缩短syn半连接的超时来缓降。

    6
  • QQ怪
    2019-10-07
    可以分库分表来解决单表写入数据量大，查询时间过长，但实现其复杂性也增加了，需要实现分区键或者说以什么依据来进行分库分表

    作者回复: 嗯，分库分表是一个有效提升写入能力的手段，除了这个还有其他优化方式吗？

    共 2 条评论
    5
  • clip
    2019-10-09
    用分片来做水平扩展的话灵活性是低的吧，是不是不适合随着每天波峰、波谷来调整？感觉只能扩很难收。 如果某个时段有大量写入，用什么方式应对比较合适呢？

    作者回复: 跟随流量波动来进行资源层的扩缩容对于数据读取可能比较有效，但是对于数据依赖master的写入扩缩容实现会比较麻烦。对于写入的优化可以采用类似操作系统buffer的机制，来对写入数据进行合并后批量写入，甚至根据业务来进行更高级的定制化合并逻辑。这一块我在第20篇万人群聊系统的设计中会讲一下。

    5
  • kamida
    2020-03-13
    老师 请问长链接请求是怎么从lvs转到网关的啊。 是接入服务先返回给用户一个网关地址 然后用户直接长链接到那个网关的吗

    作者回复: 用户拿到的是vip地址，实际请求会路由到lvs所在的机器，再由lvs转发给真正后面的网关服务器。当然，也可以不用vip来直连网关机，存在的问题是服务上线时需要暂时下线这台网关机可能比较麻烦。

    共 5 条评论
    3
  • 面爸
    2019-10-07
    人数统计的话，应该用redis就可以实现，写入的话，可以队列，异步去写

    作者回复: 嗯，redis作为计数没问题的，不过异步写入只是起到削峰填谷的作用，并不能提升写入的绝对能力，可以再想一想哈

    3
  • 唯我天棋
    2019-11-04
    1.连接层和业务层之间增加一个业务代理，这样连接层可以更加专注于处理连接问题，让业务代理来完成服务发现，管理业务集群，这样会不会更好？ 2.为什么在连接层直接rpc调用业务端。那业务端需要通过这条连接推送消息不是会很不方便吗？

    作者回复: 服务发现本身是rpc框架自带的通用特性，对系统消耗很小，再增加一层会使消息收发链路变长，整体稳定性可能会有影响。 业务层推送消息是通过消息队列来实现的，不需要依赖rpc。

    2
  • Jun
    2019-10-11
    是否可以先在服务器端聚合一段时间的数据再写入

    作者回复: 嗯，不错的想法，业务允许一定的风险的话这是一个不错的优化手段。

    2
  • HelloTalk
    2019-10-07
    要想解决资源层的写入瓶颈，除了分片机制外，还可以移步写 用队列来操作

    作者回复: 是个方案，不过队列更多起到的是削峰填谷的作用，对写入瓶颈的真实写入能力提升有限。

    3
  • Ricky Fung
    2021-07-26
    提升写入能力： 1.分片（数据库、缓存分片）； 2.批量写入，例如点赞数统计 如果有N个用户对某条微博点赞可以直接incr N
  • Geek_1cc6d1
    2021-04-29
    业务层调用网关层rpc服务发送消息（客户端连接着具体的某台网关服务器）时应该是跟ip有关的，所以默认的路由策略应该是不行了。通常都有什么解决方法？
  • Vicky
    2020-12-07
    请教老师： 中央资源中（比如 Redis）记录当前用户在哪台网关机上线，如果其中一个网关机宕机，是如果及时的将redis中相关的记录删除？
    共 1 条评论
    1
  • 包子浣熊
    2020-08-02
    解决资源写入瓶颈的问题（比如直播间观看人数的计数资源）？ 能否在人数过多的账号后面加上一个不同的数字作为key，让它们布到不同的切片上。 写入的时候可以写到其中的任意一个。 读取的时候需要把它们的结果聚合起来。
  • piboye
    2020-05-10
    水平扩展接入层，还有一种特殊方式，接入层是带状态的，这种方式不需要全局状态，接入层容灾就是两个备份机器
  • piboye
    2020-05-10
    1 合并写，增加了延迟，同时使用directio 2 多机器写日志方式，因为没有sync，顺序写性能高 3 多机器，写内存，异步合并写磁盘，同时挂机可能会丢失部分数据。
  • 康家沟偶像天团王大锤
    2020-01-16
    在连接的前端机对进出直播间事件做初步统计，定期将统计结果刷入缓存，多次进出可以变为一次更新
  • 分清云淡
    2019-12-04
    分表 存贮 对于一些热点列 在cache里面增加特殊索引字段 也可以在内存中 直接存储计算结果 节省 查询 计算时间
  • GeekAmI
    2019-11-12
    请问老师：长连网关调用业务层为何是RPC，而不是通过消息队列调用呢？

    作者回复: 如果发送消息是否成功依赖于消息存储是否成功，而消息存储的逻辑在业务层，那么发消息需要业务层明确告知是否存储查成功，这种情况rpc通过response明确告知网关层是否成功实现上更方便。

    共 2 条评论
  • 唯我天棋
    2019-11-04
    要想解决资源层的写入瓶颈，除了分片机制外，还有什么办法能解决资源写入瓶颈的问题呢（比如直播间观看人数的计数资源）？ 1.使用高性能缓存。。 2.请求合并