微信分享|如何在云中构建大规模分布式系统



  • 分享主题:如何在云中构建大规模分布式系统

    时间:3月15日 20:00 —— 21:30

    地点:本微信群

    内容介绍:本次分享 William 将从技术角度分析在云计算环境中,当用户业务面对流量激增、数据量翻番、访问量指数级攀升的“烦恼”时,如何利用云计算平台的弹性,结合业务自身特点,设计和构建一个高可用、高伸缩性的后端系统架构。同时会以 QingCloud 平台上的真实案例为背景,讲述从简单后端系统到大规模分布式系统的演进之路。

    大家对于此话题有什么想了解的可以在帖子下面留言。



  • 本次分享 William 将从技术角度分析在云计算环境中,当用户业务面对流量激增、数据量翻番、访问量指数级攀升的“烦恼”时,如何利用云计算平台的弹性,结合业务自身特点,设计和构建一个高可用、高伸缩性的后端系统架构。同时会以 QingCloud 平台上的真实案例为背景,讲述从简单后端系统到大规模分布式系统的演进之路。

    讲师介绍

    青云QingCloud 系统研发工程师,负责 QingStor 对象存储服务的设计与研发,对 Linux 操作系统、计算机网络、分布式系统、云计算等领域有较深入的研究。原街旁团队创始成员,基础架构负责人。九零前,文青程序员,代码诗人,北京土著。


    大家好,我是 QingCloud 系统工程师王煜,今天由来分享在云计算平台上构建稳定可靠的分布式系统架构。

    很多企业和开发者在开发一款产品时,首要考虑的是产品功能的实现,其后端架构通常都是非常简单直接的。产品在刚上线初期,由于用户访问压力很小,数据量积累也并不大,在短时间内都会运行良好。

    然而如今移动互联网的普及和成熟,让一款产品很可能在短时间内聚集大量用户,面对流量激增、数据量翻番、访问量指数级攀升等诸多“烦恼”,这本来是一件好事,可是如果后端系统不能及时扩展,势必会造成响应缓慢,频繁出错甚至拒绝服务的情况。

    即便没有上述系统压力突然增大的“烦恼”,产品在不断开发升级的过程中,各种功能模块会变的越来越复杂,如果不能很好的梳理和组织后端架构,系统出错崩溃、不可使用的风险也会越来越大。

    在没有云计算的时代,物理硬件从采购、上架、插线,到安装、调试、部署,再到真正投入使用,是一个漫长而耗费人力的过程,往往跟不上系统紧急扩容的节奏。而云服务的出现不仅仅让我们节约了使用成本,更重要的是可以利用云计算极度弹性的特点,让企业和开发者根据需求,对系统进行在线快速的扩容。

    但仅仅在云服务上快速扩容是不够的,企业也需要在业务层面,关注各个系统组件的可用性和伸缩性。接下来我来给大家介绍如果利用云计算的优势,结合企业的业务特点构建稳定可靠的分布式系统。

    首先我们从一个最简单的后端架构开始:

    接入层:nginx
    业务层:Java application
    数据层:MySQL

    在云计算环境中,网络架构的组织非常重要,QingCloud 提供了基础网络和 VPC 两种网络,他们的区别在官网用户指南和以前的文章中已经介绍,这里不赘述。推荐企业使用 VPC 来构建自己的网络,将所有主机和系统资源放置在 VPC 网络中,指定内网网段(如 192.168.x.x / 172.16.x.x),主机可以通过内网地址进行通信,该地址不会变化。

    随着主机越来越多,IP 地址不易记忆,为了方便主机间相互识别,可以给每台主机设置内网别名。为方便在控制台管理,给每个资源打上标签,按照标签来组织分类。

    接下来我们回到上面那个简单的后端架构。随着访问压力越来越大,单台 nginx + Java application 可能不足以应付,你会看到这台主机的 CPU 越来越忙 ,内存使用越来越多。而且这台主机一旦故障,整个服务都不可用了。

    所以我们首先调整这里的结构,增加多台 nignx + Java application 同时提供服务,在接入层引入负载均衡器(下文用 LB 这个词代替),使外网请求首先发到 LB 上。LB 的选择有很多,比如提供七层负载能力的 nginx 和 HAProxy,也有提供四层负载能力的 LVS,安装和配置的方法各有不同。

    LB 的引入可以分摊请求压力到后端的多台业务服务器,并且可通过心跳检查,自动隔离后端出现故障的服务器,实现业务层的高可用。但这时 LB 本身也会成为一个单点,当出现故障也会导致全局不可用。所以可以使用 Keeplived 服务为 LB 提供一个副本,在一台出问题的时候可以马上顶上,部署方法网上有很多资料。

    有人会说可以通过 DNS 轮询到不同的 IP ,实现 LB 的高可用,但事实上这样不行,因为一旦一台 LB 挂掉,DNS 还会解析到这个 LB,此时即便马上修改 DNS,在 DNS 缓存更新之前(通常要很久),服务也是不可用的。

    虽然 LB 的原理并不复杂,但是部署配置有很多工作量,而且为了实现 LB 的高可用还要额外做一些事情。QingCloud 从北京3区开始提供了高性能、高可用的 LB 集群服务,可以直接拿来使用。

    改造后的架构如下图所示:

    接下来我们来思考业务层的扩展问题。首先要解决如何快速扩充业务服务器。如果业务服务器的运行环境和程序不会频繁更新,可以基于已有的业务服务器制作主机映像,当需要扩容时,直接基于映像创建新的主机,挂接到 LB 后端就可以马上对外服务了。

    此时你还可以使用 AutoScaling 功能自动化这一过程,即当到达某种触发条件,如 LB 并发数、响应延迟达到多少后,自动触发主机的扩容。当触发条件不满足时,可以回收资源。

    当然如果你的业务服务器的环境或程序需要频繁更新,不适合做成固定模版。此时可以自己搭建自动化部署(如 Puppet / Ansible)实现业务自动扩容,这一切操作可以使用 QingCloud 的开放 API 接口,结合你的自动化部署程序完成。

    此外你还需要保证业务服务器是无状态的,因为每次 LB 请求的后端可能不同,不能假设上一次请求和这一次请求落在同一台业务服务器上。如果服务器需要保存用户访问的 session 信息,可将其下放到缓存或数据库中存储。

    随着产品功能越来越丰富,你会发现原有单一的业务项目越来越庞大,各种功能逻辑交织在一起,当一个功能出现故障,可以引发全局不可用。此时你需要考虑将单一的业务项目分拆成多个独立子服务。子服务之间可以基于消息的通信,亦或基于 RPC 的通信方式。

    子服务的调用可分为需同步处理和可异步处理两类。你应该尽量异步化所有不需要马上返回结果的请求。对于可异步处理的请求,我们通过引入消息队列,为请求产生的数据做缓冲,请求的接收者(队列消费者)可根据队列中任务的数量做水平扩容。消息队列的选择有很多,例如 Redis, RabbitMQ, ActiveMQ, Kafka,QingCloud 平台上目前已经提供分布式、可分区、多副本的消息队列服务,具有高吞吐量、低延迟等特点,用户可以方便的集成到自己的系统中。

    如今数据分析对于企业越来越至关重要,业务服务器在处理请求的过程中,可以将原始数据通过队列,源源不断地导入大数据处理系统,QingCloud 提供完善的大数据分布式处理平台 Spark 和 Hadoop,用户可以根据需求方便的创建,使用和扩容。

    通过拆分子服务,使得我们有能力在某项子服务发生故障时,尽可能降低对于全局的影响,提高系统整体的可用性。另外,对于处理压力比较大的子服务,我们还可以进行独立的水平扩容,方式和前面讲到的业务服务器扩容相似,QingCloud 内网 LB 服务也可以在这里发挥作用。

    改造后的架构如下图所示:

    随着业务的增长,数据层面临的压力会越来越大,单机数据库已经不足以支撑,接下来我们谈一下数据层的分布式和扩展技术。

    对于大多数的业务场景来说,数据的操作都是读多写少,而且读都集中在少部分的热点数据上,首先应该引入缓存层来缓解数据库的读压力,如果缓存容量需求比较大,可以构建缓存集群,在上层按照 consistent hashing 算法将数据分散到多个节点,后续需要增加新缓存节点时,只有少部分的数据会失效。

    接着引入新的数据库种类,Redis 已经成为诸多企业的首选标配,因为其支持丰富的数据类型和数据查询接口,且内存型的数据库天然具有更高的性能。
    你可以讲业务中关系性要求不高的数据,从 MySQL 转移到 Redis 中,尤其是列表类的数据以及计数统计类的数据。给 MySQL 减负的同时提高数据的查询性能。
    单台 Redis 节点也许不能满足你对容量的需求,QingCloud 平台提供了支持多主多从 Redis 3.0 集群服务,一方面可对数据自动分区提高存储容量,另一方面保证了服务的高可用性。

    对于 MySQL 的扩展可以分为几个步骤来做。首先,增加 MySQL slave 节点,在上层将部分读请求分发到 slave 节点上去,由于 slave 同步可能有延时,业务应该能容忍短暂的数据不一致现象,举例,比如你的一个用户修改了年龄属性,其他用户要等一会儿才能看到他的新年龄。

    QingCloud MySQL 数据库支持一主多从的架构,并且已经在多个从节点之上做好了负载均衡,你可以轻易在界面上操作增加新的从节点来为你分担读压力。

    即便有 slave 作为数据副本,你也应该定期对你的数据库进行冷备份,方便当业务出现误操作时,能够回滚或恢复到曾经的某个时间点。在 QingCloud 平台上,备份的过程可以手动执行或者配置为自动任务,在备份过程中对数据库正常使用没有影响。

    随着数据的增长,单个数据库不能承载完整的数据集合,并且写操作对于单库的压力越来越明显,你应该考虑分库分表技术。将比较庞大的数据表拆分出来单独存放,可以给主数据库腾出来一部分空间,分担读写压力。拆分的时候,还可以按照功能逻辑,把相关联的数据表存在一个库里。

    当数据库单表非常庞大,对读写都造成瓶颈时,你需要开始考虑水平分表 sharding,这种扩展方式可以同时解决单表容量过大,读压力和写压力很大的问题,但带来的研发和运维难度也会增大,推荐把上述的优化做完以后,最后在有必要的情况下再做。

    这里简略说一下水平分表的要点。首先要从数据表的字段中,选择一个合理的分区键(shard key),这个键应该是所有该表查询条件里,最经常用到的字段,这样才会使大部分的查询,能够提前判断应该向哪些特定的分区(shard)发送请求,如果查询条件中不带shard key,需要遍历所有的分区,并将结果进行merge。

    有了 shard key 还要设计一种分区算法,比如常见的有按照区间,如 user_id in [0, 100] 在 shard 1,user_id in [101, 200] 在 shard2,还比如按照 hash 取模等等。设计分区算法的时候要充分考虑业务特点,多从读写操作的角度思考,这么设计能否将压力和数据均匀分摊到每个 shard 上去。

    还需要考虑数据层的扩展如何对上层透明,比如引入分布式数据库中间件,或者结合业务逻辑把数据库操作做成一个独立的子服务,供其它服务调用。如果不做成子服务,至少在业务代码里有独立的一层来封装对数据库的操作。

    至此,数据层的扩展示意图如下所示:

    除了上述的结构化数据的存取以外,企业还有存储海量小文件数据(非结构化数据)的需求,单机硬盘、LVM 和 NAS 可以作为临时方案使用,但都无法同时满足无限容量、高性能、高安全性、高可用性的多重需要。而自行搭建分布式存储系统,如 Ceph、GlusterFS、HDFS 适用场景非常有限,且运维和二次开发的成本也非常高。

    在 QingCloud 平台上用户可以使用 QingStor 对象存储服务来存储海量的数据文件,服务本身提供了无限容量、高扩展性、高可用性和高安全性的特性。

    讲完数据层的扩展技术,最后来谈一下多机房部署和异地容灾的话题。QingCloud 从北京3区机房开始,通过自营的骨干网光纤和多路环网技术,使得当机房出现网络故障时对用户无感知,在基础设施上保障了高可用性。但是用户的业务如果能够多机房部署,可以在分摊访问负载的同时加速区域访问,比如加速中国南北方的用户或者海外用户的访问。

    如上图所示,若是有三个机房,中间是 QingCloud 北京3区机房,负责主营业务。左边是 QingCloud 亚太1区机房,主要服务亚太和海外的客户。这两个机房都使用了 QingCloud 私有网络(VPC)部署,通过GRE或IPsec加密隧道在网络上的互联互通。右边是你办公室的物理机房,IT 人员可以在这个环境下进行开发和办公。

    在业务上实现异地多活时,通常从易到难有三个阶段:第一,在备用机房搭建反向代理,用户请求到备用机房,请求直接被转向主机房,如果两机房有专线互联或延时很小,这样部署最为简单。第二,两个机房同时部署业务服务器和缓存,由于大部分数据请求可以从缓存中读取,不用进行跨机房访问。但当缓存失效时,依然要从主机房的数据库去查询。第三,两机房同时部署全套系统,包括接入层、业务层和数据层。数据层依靠数据库双主或主从技术进行跨机房同步。

    最后总结一下今天的分享。没有一个所谓经典或完美的架构,只有最适合企业业务的架构,今天分享的是在最通用的业务场景下,系统在接入层、业务层和数据层的常用扩展方法。企业后端架构的演进过程是一个漫长而艰巨的过程,不可能从零开始一蹴而就,就能设计出一个万般周全的系统,但如果设计之初能更多着眼于未来,就可以为进一步优化留出了余地。



  • 问题

    1、企业客户,私有云如何建设不同规模下的分布式系统?

    企业首先要清楚当前业务的规模有多大,比如业务的种类,服务QPS,数据的种类和数据量的大小,同时清楚业务和数据的SLA 和性能预期。只有在清楚这些的情况下,才能在规划的过程中有权衡取舍。

    云计算环境下,基础资源的创建和销毁都非常迅速,要把更多关注放在业务层面的可扩展能力上,比如业务层要无状态,数据层要做好索引,做好冷热区分。无论规模大小,系统的组件不应该有单点故障和单点瓶颈。在规模较小的时候,系统可以不扩展,但是要具备可扩展的能力。

    2、冷热数据管理以及数据持久化是怎么做的?

    更热的数据应该被更快的访问到,决定存取速度的因素主要是距离和介质。从距离来看 本地内存 > 本地硬盘 > 远端内存 > 远端硬盘,从介质来看 SSD > SAS > SATA。冷热数据的比例一般是非常悬殊的,要将热的数据存放到更近更好的介质上。

    每一种存储系统诸如 MySQL Redis 都有自己的数据持久化策略。

    3、数据大集中平台的安全性是否比原来点对点接口低?

    其实无论数据的存储形式是怎样的,数据的安全性主要取决于是否有冗余,冗余度是多少,冗余的分布是否是跨物理机,甚至是否跨机房。数据写入是否真正落盘,以及数据的副本是同步写入还是异步写入。

    4、构建大型分布式平台系统,缓存管理用redis来实现,应该注意什么?

    首先考虑缓存的粒度,太粗的粒度会导致失效太频繁。还要考虑缓存容量,如果单台节点无法承载足够的热点数据,在使用多节点是要注意选择合适分布策略,比较常有的有一致性hash和hash取模。Redis3.0以上版本提供了集群能力,可以自动对数据分区,并提供高可用能力。

    5、分布式数据库、缓存,如何实现资源池化?

    可在数据库服务之上增加代理中间件,有开源方案也有自己实现,对使用者提供的接口要屏蔽分布式的细节,用户不用关心容量,性能,分布策略等,仿佛看到的是一台单机数据库

    6、大规模分布式系统下后端交易数据是如何存放的,如何实现数据的多中心容灾保护?

    交易数据最重要的是不能丢失,性能是次要,曾经很多传统企业会选择oracle这样的商业数据库,新型企业越来越多愿意采用 MySQL PostgreSQL 等开源实现,但是配置的时候一定是配成最严格的同步写多份成功才返回,并且有日志留存

    7、云计算适合哪些类型的应用,衡量标准是什么?

    云计算做为 IT 基础设施资源,在各行各业都有成功案例,已经不分适合哪类应用。唯一衡量标准就是能否满足需求,要看是否能取代传统硬件能够提供的能力,并且能够提供传统硬件以外的能力,例如弹性伸缩,按用量计费,快速启动销毁等。

    8、keepalived的性能如何?后端是HAPROXY吗?

    keepalived 主要通过引入虚拟路由冗余(VRRP)来实现高可用,本质上不会对性能造成影响,它是一个独立的服务,和HAProxy没有关系。

    9、青云QingCloud 的云服务是否能够预防由于namenode掉电等原因引发的hadoop集群崩溃?

    目前青云的IaaS层在物理机掉电时会触发灾难恢复,另一台同样的主机会启动起来,数据不会丢失,然后再启动hdfs的服务即可恢复集群使用。Hadoop的自身的HA也会很快提供,这样就可以自动恢复hdfs服务了。

    10、auto scaling太多实例,db最大连接耗尽如何处理?

    可以在实例和db之间引入代理中间件,还可以自己实现一个独立的数据访问服务,不让实例直接操作db。



  • 企业客户,私有云如何建设不同规模下的分布式系统?

    企业首先要清楚当前业务的规模有多大,比如业务的种类,服务QPS,数据的种类和数据量的大小,同时清楚业务和数据的SLA 和性能预期。只有在清楚这些的情况下,才能在规划的过程中有权衡取舍。

    云计算环境下,基础资源的创建和销毁都非常迅速,要把更多关注放在业务层面的可扩展能力上,比如业务层要无状态,数据层要做好索引,做好冷热区分。无论规模大小,系统的组件不应该有单点故障和单点瓶颈。在规模较小的时候,系统可以不扩展,但是要具备可扩展的能力。



  • 2、冷热数据管理以及数据持久化是怎么做的?
    更热的数据应该被更快的访问到,决定存取速度的因素主要是距离和介质。从距离来看 本地内存 > 本地硬盘 > 远端内存 > 远端硬盘,从介质来看 SSD > SAS > SATA。冷热数据的比例一般是非常悬殊的,要将热的数据存放到更近更好的介质上。

    每一种存储系统诸如 MySQL Redis 都有自己的数据持久化策略。



  • 3、数据大集中平台的安全性是否比原来点对点接口低?
    其实无论数据的存储形式是怎样的,数据的安全性主要取决于是否有冗余,冗余度是多少,冗余的分布是否是跨物理机,甚至是否跨机房。数据写入是否真正落盘,以及数据的副本是同步写入还是异步写入。



  • 4、构建大型分布式平台系统,缓存管理用redis来实现,应该注意什么?
    首先考虑缓存的粒度,太粗的粒度会导致失效太频繁。还要考虑缓存容量,如果单台节点无法承载足够的热点数据,在使用多节点是要注意选择合适分布策略,比较常有的有一致性hash和hash取模。Redis3.0以上版本提供了集群能力,可以自动对数据分区,并提供高可用能力。



  • 5、分布式数据库、缓存,如何实现资源池化?
    可在数据库服务之上增加代理中间件,有开源方案也有自己实现,对使用者提供的接口要屏蔽分布式的细节,用户不用关心容量,性能,分布策略等,仿佛看到的是一台单机数据库



  • 云计算适合哪些类型的应用,衡量标准是什么?
    云计算做为 IT 基础设施资源,在各行各业都有成功案例,已经不分适合哪类应用。唯一衡量标准就是能否满足需求,要看是否能取代传统硬件能够提供的能力,并且能够提供传统硬件以外的能力,例如弹性伸缩,按用量计费,快速启动销毁等。



  • 问题:请问对于不同需求的客户是如何分开的。比如高读写,高运算的。读写会分不同的存储吗。高运算会分不同的节点吗?


登录后回复
 

与 青云QingCloud 社区 的连接断开,我们正在尝试重连,请耐心等待