如何构建高可用和可伸缩的架构？

如何构建高可用和可伸缩的架构？

发表于 2015-09-22 13:42| 4669次阅读| 来源 CSDN| 5 条评论| 作者 蒲婧

CTO CTO俱乐部 CTO讲堂 云存储 七牛 架构 高可用

width="22" height="16" src="http://hits.sinajs.cn/A1/weiboshare.html?url=http%3A%2F%2Fwww.csdn.net%2Farticle%2F2015-09-22%2F2825769-CTO&type=3&count=&appkey=&title=%E5%A6%82%E4%BD%95%E6%9E%84%E5%BB%BA%E9%AB%98%E5%8F%AF%E7%94%A8%E5%92%8C%E5%8F%AF%E4%BC%B8%E7%BC%A9%E6%9E%B6%E6%9E%84%EF%BC%9F%E6%9C%89%E5%93%AA%E4%BA%9B%E5%85%B3%E9%94%AE%E7%9A%84%E6%8A%80%E6%9C%AF%E8%8A%82%E7%82%B9%E5%92%8C%E9%9A%BE%E7%82%B9%E6%8C%91%E6%88%98%EF%BC%9F%E5%AF%B9%E4%BA%8E%E5%85%AC%E5%8F%B8%E6%9D%A5%E8%AF%B4%EF%BC%8C%E4%B8%BA%E4%BB%80%E4%B9%88%E6%9C%89%E5%BF%85%E8%A6%81%E8%80%83%E8%99%91%E9%AB%98%E5%8F%AF%E7%94%A8%E5%8F%AF%E4%BC%B8%E7%BC%A9%EF%BC%9F%E6%9C%AC%E6%96%87%E4%B8%BA%E4%B8%83%E7%89%9B%E9%A6%96%E5%B8%AD%E6%9E%B6%E6%9E%84%E5%B8%88%E6%9D%8E%E9%81%93%E5%85%B5%E5%9C%A8CTO%E8%AE%B2%E5%A0%82%E4%B8%AD%E7%9A%84%E7%B2%BE%E5%BD%A9%E5%88%86%E4%BA%AB%E6%95%B4%E7%90%86%E3%80%82&pic=&ralateUid=&language=zh_cn&rnd=1449926446249" frameborder="0" scrolling="no" allowtransparency="true"> 摘要：如何构建高可用和可伸缩架构？有哪些关键的技术节点和难点挑战？对于公司来说，为什么有必要考虑高可用可伸缩？本文为七牛首席架构师李道兵在CTO讲堂中的精彩分享整理。

为了帮助IT从业者职业之路拥有更多收获，在诸多C粉的殷切期待下，由CTO俱乐部打造的CTO线上讲堂自登场以来获得大家好评。本期邀请七牛首席架构师李道兵带来“如何构建高可用和可伸缩的架构？ ”的主题分享。

欢迎加入CTO讲堂微信群与业界大咖零距离沟通，每周都有技术大咖进群分享，报名拖至文末查看。

主讲人：七牛首席架构师李道兵

嘉宾简介：李道兵（新浪微博 @lidaobing， 个人博客：http://blog.lidaobing.com/），七牛首席架构师，Debian开发者，ISO-Codes等开源软件维护者，python-lunardate、apistrano-scm-jenkins作者，原盛大云资深研究员。关注服务安全、架构健壮性（高可用、可测试、可追溯）等领域，参与了多个高压力项目的结构设计，推崇高可用、可伸缩、低耦合的架构设计。

公司简介：七牛由国内云存储领域领军人物之一许式伟于2011年创立，专注以数据为中心的公有云服务市场，公司核心团队在海量存储等领域拥有超过十年的技术积累，核心技术完全自主研发。七牛是全世界第一个提出用存储、加速和数据处理这三个词来描述云存储服务的公司，为了更好地服务平台上的用户，七牛用KODO对象存储服务、FUSION融合CDN管理平台、DORA就近计算平台、PILI直播云服务四大产品重新定义了云存储，志在成为最开放、最完备的数据服务提供商。从成立至今的4年里，七牛已服务超28万企业用户，其中不乏很多重量级和明星企业。如新型创业中的美图、Camera360、穷游、豌豆荚等，也有传统企业中的顺丰、PPTV、步步高、OPPO、海康威视、平安科技等。

以下是9月16日CTO讲堂现场完整速记：

主持人：今天的嘉宾是七牛云存储首席架构师李道兵，请您做下自我介绍。

李道兵：hi, 大家好，我是七牛的李道兵，在七牛担任首席架构师。我07年开始工作，先后在金山、盛大、七牛工作。在金山加入了金山实验室，主要方向是存储和爬虫。加入盛大后先后参与了盛大网盘和盛大云项目。

中间有一年在一个创业公司（GIGABASE.ORG）工作，之后就加入了七牛。

主持人：那么是在什么情况下您加入了七牛团队，开始了创业团队之旅的呢？

李道兵：2013 年还在GIGABASE 的时候，收到七牛CEO老许的邀请，一起吃了个饭，聊了一下。

聊完之后觉得七牛在做的事情就是我想做的事情，我觉得云的存在不应当只是为了降低采购周期，提高利用率，而应该着眼在如何利用云去给开发者和运维构建一个更好的平台，如何去提高开发者和运维的效率。所以后来就辞去了 GIGABASE 的工作，加入了七牛。

主持人：请介绍一下目前七牛云存储目前的情况以及技术团队构成。

李道兵：七牛成立差不多4年了，但作为一家ToB的企业还算很年轻的，我们现在有200多人，围绕数据这个核心组织了多个产品，包括存储、分发、富媒体处理、大数据、还有通用计算平台等。现在前面三个已经正式对外，其余的还在内测当中。

技术团队的构成：200多人中一半人左右是一线的研发团队，跟很多互联网公司一样，我们都是一个超扁平的结构，团队小的5个人， 大的10来个人，所有的研发团队都是平行的，直接汇报给CEO。

主持人：那么请您介绍下云存储行业目前的具体情况以及未来发展前景吧。

李道兵：云存储这几年发展迅速，我觉得主要是几个方面的原因：

• a.  首先是数据自然增长，每年全世界创造的数据都在以一个很大的幅度增长；
• b.  其次是带宽的增长，导致大家对音频、视频等富媒体（当然未来还有VR)的需求大规模增加，当然镜头分辨率的提高对需求的增加贡献也不小；
• c.  越来越多的智能设备引入，这些设备会自动地产生大量的数据，现在主动产生的数据（比如拍照）占主流，未来可能被动产生的数据会成为主流（比如你的身体状况监控）；
• d.  对于中国来讲，国家的去 IOE政策，以及推动政府采购云，这些也帮助了云存储行业的发展；
• e.  当然最重要的一点是，大家发现数据的价值越来越大，比如 LinkedIn，240亿美金的市值，大部分来自于大家对 LinkedIn 拥有的数据的高估值。在电商等行业，数据价值的案例也越来越多

主持人：可否从案例角度来介绍一下七牛的产品服务应用场景？

李道兵：以一个典型的短视频应用为例。首先是上传，一个10s左右的视频在 1-2MB, 60s 的在 10MB 左右，这个大小的文件从手机直接上传的成功率不高，那么就需要用到的我们的分片上传技术以及就近上传技术，前者可以提高成功率，后者提高上传速度。

由于硬件原因，不是每个视频的编码格式都是一致的，比如音频就有 mp3/aac 等格式，那么转成一致的格式，再打上水印就是必要的了，这就需要我们提供的视频转码技术。

每个视频需要一个封面，封面通常从视频中抽取，那么用我们提供的抽帧服务加上图片裁剪服务效果就很好。视频需要审核，这个也需要通过我们的转码服务来提供一个超小视频用来审核。

最后就是视频分享后需要分发，这个就可以利用我们提供的融合CDN来达到最佳的覆盖、速度和性价比。当然还有就是数据的分析（不过还在内测阶段）。

主持人：那么七牛目前的产品及服务都有哪些？相比其他公司类似产品，竞争力体现在哪些方面？

李道兵：七牛围绕着数据平台这一概念组织了一系列的产品，包括存储、转码、分发等业务。未来，我们会围绕如何让用户更方便地管理数据，如何让用户的数据价值最大化这几个方向来开发更多产品。

正如我之前提到的，我们跟 AWS 等云服务最大的不同在于终极目标的不同。AWS的目标是围绕着降低采购周期，提高使用率这个方向去发展，而我们更多是从如何提高软件工程师和运维工程师的生产率去考虑。

所以我们会率先引入在 URL 中指定转码规格，支持URL转码管道，支持灵活的回调策略，分片上传、镜像存储等等功能。我们的售前也会努力和客户一起来制定解决方案，帮助解决接入时遇到的各种问题。

主持人：我们来聊聊今天的主题~对于公司来说，为什么有必要考虑高可用可伸缩？必要性体现在哪些方面？

李道兵：现在各种应用用户量起来很快，特别是2C/娱乐业的一些应用（比如逗拍，一个春节就起来了，小咖秀之类的也很快），用户量起来本来是让你离成功近了一大步，但如果这时候因单机故障出现不可用，或者因为系统容量不足导致响应不畅，那么你的用户也会很快离你而去。

更何况，其实我们也可以看到，高可用也好，可伸缩也好，都是有章可循的，成本也不高。

主持人：如何构建高可用和可伸缩架构？有哪些关键的技术节点和难点挑战？

李道兵：我觉得首先一点是分离控制流和数据流，当然如果你的应用不涉及富媒体或者其他大流量的数据那么就可以跳过这步。这么做的好处主要是，控制流其实流量不高，那么我们就可以租8线BGP的机房来提高动态请求的响应速度和覆盖率，毕竟好机房贵的是流量成本，而不是机架成本。而数据流的高可用和可伸缩的技术门槛高，运维成本也不低，那么最好往云上搬。

对于控制流这边，我们又可以简单地把需求分解到入口、业务、数据库、缓存、消息队列这几个子模块。

• 入口比较简单，低流量的情况下一对 Nginx，加上心跳就可以满足。即使是高流量，那么心跳+LVS也是一个漂亮的选择。当然在 DNS 层先做一次负载均衡也不错。另外，如果你的应用是有客户端的，你还可以选择发送所有入口IP到客户端，由客户端来选择，做负载均衡。
• 业务层牢记一个原则，不要保存状态，就可以轻易地做到高可用和可伸缩，状态尽量放到缓存层和数据库层，而不是自己兜着。初期两个节点，后来水平加节点就可以了。
• 数据库这方面的文档和PPT反而是最多的，高可用方面，MySQL的 master-master方案，MongoDB的 ReplicaSet 方案都不错，主要是看你的使用场景。伸缩性主要靠水平和垂直拆表，毕竟各种数据库的集群方案都有很大的缺陷，个人觉得不如放在业务逻辑层来做。另外，数据库层有条件的话就上 SSD，成本虽然贵一点，但2个数量级左右的性能提升，对你的帮助会非常非常大。
• 缓存层随着 Redis 3.0 和 Codis 这类方案的推出，反而是率先解决了缓存层的高可用问题，我觉得大家可以直接采用，在业务逻辑层搭也可以，针对不同的情况可以用一致性Hash，主备缓存等多种方式来处理。如果自己搭，那么缓存层的节点数不能少，毕竟要防止缓存失效后对数据库的冲击，一个简单的手法是缓存层和业务逻辑层混合部署，一起水平扩展。
• 消息队列一般依赖于数据库或者其他持久化层，自己的高可用和可伸缩倒是比较方便，设计时注意即可，比较值得注意的是，一般这种情况下很难保证消息队列的顺序，这也是设计时需要考虑的，不依赖于消息顺序即可。

主持人：那么云存储作为一个服务端的业务，在实现高可用和可伸缩的时候有什么自己的特点？

李道兵：云存储也是服务端的业务，所以上面提到的各个点都要考虑。（当然不能再分离数据流了）。

此之外，储存还要额外考虑几个点，比如如何优化数据流，降低数据流在内网的传递次数，降低内网拥塞的可能性，同时也能提高响应性。还有就是如何避免突发的大规模数据冲击服务器，也就是说如何避免出现性能毛刺。

主持人：在提升用户体验方面七牛做了哪些努力呢？对于用户反馈都是如何及时解决的？

李道兵：针对用户体验，我们是从两个方面来优化的。

• 首先是产品本身的质量，比如服务的可用性，服务的响应速度，如何减少 bug等，这方面我们有持续的优化措施。
• 另一个方面是如何提升七牛的服务水平。七牛有一个很强的售前团队，能够和客户一起来分析客户的场景，帮助客户设计最佳的接入和迁移方案。

七牛的支持团队也很厉害，绝大部分的工单都可以让客户得到满意的答复，少量比较深的问题则会直接转发给开发团队，让开发团队来做一个深度剖析。

问题的解决速度则是支持团队的一个重要考核指标，我们的客户对这响应速度这点也很在意。

主持人：看到您简历中一直在深钻技术的第一线，结合您的切身体会跟我们分享下一名合格的架构师应该是怎样的呢？

李道兵：之前在知乎回答过一个类似的问题，我就直接贴过来吧

• 多看书

1. 《设计模式》和《重构》这两本让我能从程序员的视野往外走一点
2.  《企业应用架构模式》、《领域驱动设计》，比《设计模式》深一点，解决的也是更实际的问题
3.  《人件》、《人月神话》、《梦断代码》，理解一下软件工程为啥会失败

• 多看文章

1. QCon 的就不错，有很多架构相关的PPT，拿着一个PPT，等对方讲完问题之后，自己想想，自己的解决方案是什么？
2. 多看看各个企业的架构变化史
3. 多看看基础组件的设计思路，比如MySQL、MemCache、Nginx...

• 多做

1. 做点算法题，不是为了练习算法，而是为了让你思考更细致，毕竟少考虑一个点，肯定就无法AC
2. 对于不同组件，自己去测试，上压力，真实测量容量。压死为止，看瓶颈究竟在哪儿？
3. 到线上去，看一看你的系统，哪些响应慢，不稳定。哪些资源消耗狠，需要优化或者扩容。

还有多找人聊天，说出你的想法，等别人反驳，从别人的反驳中吸取知识，再去做验证。修改。

主持人：您在提升七牛技术团队方面，有哪些思考呢？

李道兵：首先是招聘，校招要看这个人是否聪明，之前是否努力，之前的努力是否有成果，性格是否适合这个团队，这个团队能否给他合适的成长空间。社招要追求这个人能否给你的团队带来新知识、新理念、新方法，能否让你的团队进一步成长。

其次是学习，团队如果是忙于工作没有时间学习是不行的，当然仅仅是有时间学习也不够，如何创建一个让大家愿意去学习的环境也很重要，所以我们每周五会有分享讲座，每人的季度OKR里边也要有如何提升自己的内容，我们期望大家成长，也期望大家很严肃地看待这份工作，而不仅仅是为了混日子。

主持人：七牛的技术团队氛围是怎样的？公司招人过程中，比较看重新人的哪些特质？

李道兵：首先是平等，大家的角色都是比较类似的，架构设计也不是上面决策下面执行，而是大家一起来讨论。

其次是大家都觉得成长比较快，这个可能跟我们 peer review 的机制有点关系，每个人都需要 review 别人的代码，自己的代码也需要别人来 review, 那么你可以很快学习到一些很实用的技巧，自己的代码缺陷也很容易被人指出来，迅速改掉。

最后是担当，我们公司比较推崇担当这个词，一个好的工程师也要有好的推进能力，如何去把一个事情跟进到底是一个必须要掌握的能力。

新人的问题刚才提过，主要是聪明，努力，以及努力沉淀下来的成果。

主持人：对想在技术架构路线上走得更远的技术人，您都有什么建议吗？

李道兵：之前知乎那个链接讲得差不多了，最后再送夫子的一句话，“学而不思则罔，思而不学则殆”。当然对我来讲，思我会理解为思考再加讨论。

互动环节：如何优化数据流，降低数据流在内网的传递次数，降低内网拥塞的可能性，同时也能提高响应性----------对于业务交互较多的平台来说，数据流在内网传递次数很多，我想请教一下，这块有什么样的优化经验？
李道兵：1. 控制流不用担心传递次数太多，服务分解细一点是好事；2. 数据流方面一是减少环节，而是用控制流代替数据流。
问：服务分解细，节点就很多
李道兵：比如数据直接发往缓存节点，然后把缓存节点的 URI 直接往下传递。节点多，但每个节点的功能内聚和单一，这对你的服务的稳定性是好事，在加上 etcd 这类的工具来降低部署难度就好。

互动环节：您有没有接触过 OpenStack？
李道兵：openstack 其实应该算是一个开源的 AWS 实现，特别是主要的虚拟机，存储，EBS这几块。存储这一块，openstack 的实现很差，性能不好，运维难度也高，内部的bug也不少。不过最近很多人都在用 ceph 来做 openstack 的存储，这样也挺好。
问：您接触过的话，我想和您请教一下，OpenStack控制节点主机的高可用，都有哪些比较成熟可用的方案？
李道兵：抱歉这个快不太熟，如果我来设计，一般就是两种方案，如果有内存一致性的需求，那么模仿或者直接使用 zookeeper/etcd。

互动环节：有个问题请教，你们有没有需要跨机房数据实时同步的场景，如果有，如何保证数据实时和一致的？
李道兵：有，我们走的方案偏保守。首先，如果多个机房要共用一套数据，那么需要保证只有一个节点可以写入。对于其他机房，则在业务逻辑层重放主机房的操作，并且按照业务逻辑清理缓存。只要保证你的缓存形式满足: 1. 能够根据单条数据来清理 2. 列表类的缓存有有效期，并且不会导致业务出错即可。

互动环节：传统ERP每天有销售流水5万多条，不停插入Oracle，采购和其他业务不停查看历史销售记录一查查两三年的销售，各种计算，特别客户销售品类多而且杂，计算方法也是千奇百怪， 也做一些优化，效果不明显。请问您有什么好的建议？
李道兵：每天5万条其实 qps 很低，峰值应该低于 5qps。计算需要有独立的数据库，而不是在线的数据库。数据库需要有 admin, 分析大家的慢请求。要么加索引，要么禁止或者迁移到 hadoop/hive 这类适合慢请求的平台。

互动环节：能否介绍一下纠删码在七牛存储的实现？
李道兵：纠删码在七牛存储的实现：细节不便透漏，但是 EC 也不是一个太新的东西，比如内存，RAID都有过实现，你可以看看他们的实现。

互动环节：能问一个偏业务问题吗？比如几万人秒杀10个产品，怎么做架构保证不出错和性能稳定
李道兵：秒杀最常见的做法是两段式，第一段是接受秒杀请求，并且扔进队列，这个步骤只需保证入口和队列的容量即可。第二段是后台从队列拿到请求，应用在数据库，然后通知用户，只一个步骤就是按照数据库的容量来有序执行即可。

互动环节：为什么很多网站的登录域名和首页不是一个域名？passport.jd.com这个是jd的登录域名，为什么很多站这样，和分布式架构有关还是其他原因？
李道兵：分拆能降低单个模块的开发和维护难度，特别是你的开发分到多个团队以后，多个团队维护一个模块是很恐怖的，当然还有不同的域名有不同的部署需求，分拆后部署更灵活。

互动环节：在mysql集群，水平分表的情况下，有几种方式自动生成表的ID主键保证不重复，目前你们是如何处理的？
李道兵：几个方法, 1. 使用 UUID ；2. 每个数据库用不同的数列，比如第一个用 1,4,7,10, 第二个用 2,5,8,11, 第三个用 3,6,9,12 ；3. 当然也可以用外部的主键生成器。

互动环节：能提供一个，mysql集群架构的方式吗？
李道兵：数据库的文档都比较好找。（例如： How To Set Up MySQL Master-Master Replication）