诸多C粉殷切地期待着, 为助力IT从业者在职业道路上能有更多收获, 源于CTO俱乐部所打造的CTO线上讲堂, 自其登场之后便收获了大家的好评。进而, 本期邀请了七牛首席架构师李道兵, 给他带来了“如何构建高可用和可伸缩的架构? ”这样一个主题分享。热忱欢迎加入CTO讲堂微信群, 从而能够与业界大咖进行毫无距离感的沟通, 每周都会有技术大咖进入群内展开分享, 具体报名方式需将页面拖动至文末方可查看。主讲人七牛首席架构师李道兵嘉宾简介李道兵新浪微博 个人博客他是七牛首席架构师, 身为开发者且为ISO - Codes等开源软件维护者, 还是 -、-scm -作者, 曾是原盛大云资深研究员, 关注服务安全、架构健壮性包含高可用、可测试、可追溯等领域, 参与了多个高压力项目的结构设计, 推崇高可用、可伸缩、低耦合的架构设计。七牛是一家公司, 它由许式伟创立于2011年, 许式伟是国内云存储领域领军人物之一, 该公司专注于那个以数据为中心的公有云服务市场, 其公司核心团队在海量存储等领域有着超过十年的技术所积累, 并且其核心技术是完全自主研发的。七牛是公司, 是全世界首个提出用存储、加速以及数据处理这三个词汇来描述云存储服务的, 为能更好地服务于平台上的用户, 七牛运用KODO对象存储服务、融合CDN管理平台、DORA就近计算平台、PILI直播云服务这四大产品重新对云存储进行了定义, 其志向是成为最为开放、最为完备的数据服务提供商。从成立开始到如今的4年时间内, 七牛已经服务了超过28万的企业用户, 其中存在不少重量级以及明星企业。比方说, 在新型创业范畴之内的美图, 穷游, 豌豆荚这类, 还有在传统企业范畴之中的顺丰, PPTV, 步步高, OPPO, 海康威视, 平安科技这类。以下是9月16日CTO讲堂现场完整速记主持人说道, 今日的嘉宾乃是七牛云存储首席架构师李道兵, 要求其进行一番自我介绍。李道兵说道, 嗨, 诸位好人, 我乃七牛的李道兵, 于七牛担当首席架构师一职。我自07年始参加工作, 先后于金山、盛大、七牛工作。于金山之时加入了金山实验室, 主要从事的方向是存储以及爬虫。加入盛大之后先后参与了盛大网盘以及盛大云项目。某一年, 在一个创业公司.ORG工作过, 随后, 就加入了七牛。主持人: 那是在怎样的情形之下, 您进入了七牛团队, 开启了那段创业团队的历程呢?七牛CEO老许在2013年时, 向李道兵发出邀请, 李道兵收到邀请后, 与老许一同吃了顿饭, 其间还进行了一番交谈。商讨结束之后, 内心认为七牛所从事的事务正是自己期望去做的之事, 我发觉云的现身不应该仅仅是为了缩减采购时期, 提升利用效率, 而应当着重于怎样借助云为开发者以及运维搭建一个更为优质的平台, 怎样去提升开发者与运维的效能。所以随后便辞去了之前的工作, 投身加入了七牛。节目之中担任主持工作者: 请针对当前七牛云存储当下所处情形以及技术团队方面内部人员所形成的组成样式这两部分进行清楚说明。李道兵称, 七牛已有差不多4年时间, 不过于一家面向企业的公司而言仍较为年轻, 如今有200多人, 围绕数据这一核心组建了多个产品, 诸如存储、分发、富媒体处理、大数据以及通用计算平台等, 当前前三项已正式向外部推出, 其余则处在内部测试阶段。技术团队的构成情况是这样的, 大概200多人中有一半人左右属于一线的研发团队, 和许多互联网公司相同, 我们有着超扁平的结构, 团队规模小的有5个人, 团队规模大的有10来个人, 并且所有的研发团队相互之间都是平行的, 统一直接汇报给CEO。主持人说道, 让您把云存储行业目前的具体情形以及未来的发展前景给介绍一下。李道兵云存储这几年发展迅速我觉得主要是几个方面的原因主持人可否从案例角度来介绍一下七牛的产品服务应用场景李道兵: 拿个具有代表性的短视频应用来讲。先是上传, 一个时长约10秒的视频大小有1至2MB, 时长60秒的视频大概在10MB左右, 这种大小的文件从手机直接上传成功率较低, 所以就得用到咱们的分片上传技术以及就近上传技术, 前者能够提升成功率, 后者可提高上传速度。因为存在硬件方面的缘由, 并非每一个视频的编码格式都是一致相同的, 举例来说音频就存在像mp3、aac等样式的格式, 那么将其转变为一致一样的格式, 接着打上水印便成为必要不可或缺的了, 而这就需要我们所供应以及提供的视频转码相关技术。每一个视频都要有一个封面, 封面一般是从视频里抽取出来的, 所以运用我们所提供的抽帧服务还要加上图片裁剪服务, 效果就挺不错。视频是要进行审核的, 而这个要借助我们的转码服务去提供一个非常小的视频用以审核。就接着是视频分享过后要展开分发, 此时便能够借助我们所供应的融合CDN去达成最为优良的覆盖、速度以及性价比。当然除此之外还有数据的分析, 只是尚处于内测的阶段。主持人: 七牛当下的产品以及服务都包含什么? 和别的公司相似的产品相比, 其竞争力体现于哪些地方?李道兵员, 七牛以数据平台此概念打造了一系列产品, 涵盖存储、转码、分发等方面业务, 将来, 我们会朝着怎样让用户更便利地管理数据, 怎样让用户的数据价值实现最大化等几个路径去开发更多产品。如同我先前所说的, 我们与诸如 AWS 等云服务存在的最大差异在于终极目标不一样。AWS 的目标朝着围绕减低采购周期, 提升使用率这个方向展开发展, 而我们更多是从怎样提升软件工程师以及运维工程师的生产率方面加以考量。因此, 我们会首先引入在URL里指定转码规格这一功能, 支持URL转码管道运作, 支持具备灵活性的回调策略, 拥有分片上传、镜像存储等功能。并且售卖前我们的人员也会尽力和客户一同去制定解决方案, 协助解决接入时碰到的各类问题。主持人说道, 咱来谈论一下今儿个的主题, 就公司而言, 为啥有必要去考量高可用可伸缩, 其必要性到底体现在哪些个层面?李道兵称, 如今各类应用的用户量增长速度极快, 尤其是面向个人用户的娱乐业相关应用, 像逗拍, 仅一个春节期间用户量就迅速增长, 小咖秀这类应用的用户量增长速度同样很快。用户量的增长本应使你距离成功迈进一大步, 然而倘若此时因单机出现故障致使应用无法使用又或者是由于系统容量不足而导致响应不顺畅, 那么你的用户也会迅速与你背离而去?更是如此, 其实我们能够瞧见, 处于高可用的状况下, 在它可伸缩的情形之际, 都是存在着一定规律可以遵循的, 并且成本也并非高昂的那种情况。主持人提出, 怎样去构建那种具备高可用性以及可伸缩性的架构吗, 存在着哪些属于关键性质的技术节点, 存在着哪些难点挑战呢。李道兵表示, 他认为首要的一点是将控制流与数据流相分离, 当然, 如果你的应用并不涉及富媒体或者别的大流量的数据, 那么便能够跳过这一步。这么做所具有的好处主要在于, 控制流实际上流量并不高, 如此一来我们就能够租用 8 线 BGP 的机房, 以此来提升动态请求的响应速度以及覆盖率, 毕竟好的机房昂贵之处在于流量成本, 而非机架成本。而数据流的高可用以及可伸缩的技术门槛较高, 运维成本也不低, 所以最好迁移到云上。在控制流这一方面, 我们能够较为轻易地将相应的需求分散于入口子模块, 以及业务子模块, 还有数据库子模块, 再加缓存子模块, 另外还有消息队列子模块之中。并且分解的过程也能够相对简单地去推进。主持人说道, 云存储作为一种服务端的业务, 在达成高可用以及可伸缩之际有着其自身何种特点呢?李道兵表示, 云存储属于服务端的业务范畴, 因而上面所提及的各个要点都必须予以考量, 当然数据流是不能再另行分离的了。此外, 储存方面还得额外考量几个要点, 那便是为何要优化数据流, 怎样去降低此类数据流在内网里的传递次数, 进而降低引发内网拥塞的可能性, 与此同时还能够提升响应性。另外还有一点, 即如何防止突发的大规模数据对服务器产生冲击, 换言之就是怎样避免出现性能上好似刚长出来的小刺一般的状况。作为主持人, 七牛为提升用户体验付出了怎样的努力, 针对用户反馈又是怎样及时予以解决的?李道兵针对用户体验我们是从两个方面来优化的。七牛的支持团队相当不得了, 绝大部分工单能够使客户获取到中意的回应, 少量相对较深入的问题会径直转给开发团队, 让开发团队予以一个深度研究分析。围绕问题的解决速率, 这属于支撑团队的一项关键考核指标范畴, 而我们所面对的客户, 着实对这种响应的速率, 有着较为强烈且密切的关注之意。主持人, 看到您简历里, 一直处于深钻技术的最前沿, 根据您的切实感受, 跟我们讲一讲, 一名合格的架构师要是什么样的呢?李道兵之前在知乎回答过一个类似的问题我就直接贴过来吧那本《设计模式》能让我从程序员的视野往外走那么一点儿, 《企业应用架构模式》和《领域驱动设计》, 又比《设计模式》更深一些, 并且它们应对更现实的问题来解决 诸如《人件》、《人月神话》、《梦断代码》这类作品, 能帮着理解软件工程为何会遭遇失败 QCon 所具备的就挺不错, 存在不少架构相关的 PPT 当拿着一份 PPT 时, 在对方讲完问题之后, 自己去思索, 自己的解决方案会是什么? 多去瞅瞅各个企业的架构演变历程, 多去瞧瞧基础组件的设计理念想法, 就好比MySQL、Nginx等等, 去做点算法类型的题目, 并非是单纯为了练习算法, 而是图让你思考能够更加缜密细致些, 毕竟只要少考虑那么一个要点了, 肯定那就没办法AC了, 对于不同的组件而言, 要自己去开展测试, 施加压力, 切实测量一下容量, 压到极限无法承受为止, 看清瓶颈实际上究竟位于何处? 去到生产线上, 去看一看你的系统, 哪些部分响应迟缓, 不太稳定。哪些资源消耗的程度极为严重, 需要进行优化或者扩充容量。还要多找些人去聊天, 把你的想法给说出来, 等着别人来反驳, 从别人的反驳当中去吸取知识, 然后再去做验证。主持人您在提升七牛技术团队方面有哪些思考呢李道兵表示: 首先是招聘这一环节, 对于校招而言, 就要看这个人是不是聪明, 之前有没有努力, 之前努力所得有无成果, 性格方面是否适配这个团队, 这个团队能不能给他恰当的成长空间。而社招的话, 需要考量这个人能不能给你的团队带来新的知识、新的理念、新的方法, 能不能让你的团队实现进一步成长。其次是学习, 团队要是忙于工作而没有时间学习, 这是行不通的, 当然仅仅是存在时间去学习, 这也是不够的, 该如何去创建一个氛围, 营造出让大家心甘情愿去学习的环境, 这同样是非常重要的, 所以我们每一周的周五都会安排分享讲座活动。并且, 在每人基于的季度OKR里面, 也都必须得有关于怎样提升自己的相关内容。我们期望大家能够实现成长, 同时也期望大家要以极为严肃认真的态度去看待这份工作, 而并非仅仅是为了敷衍地混日子。主持人: 七牛的技术团队所呈现出的氛围到底是怎样的一种状况? 在公司进行招人这个流程期间, 对于新人而言, 比较看重新人身上的哪些独特的特质?李道兵表示, 首先存在平等这一情况, 具体来讲大家各自所承担的角色都是相对比较类似的, 架构设计并非是上面做出决策然后下面去执行, 而是转变为大家共同一起来展开讨论。首先, 大家都认为成长较为迅速, 这或许和我们的peer机制产生了一定关联, 每个人都必须借助他人的代码, 同时自身的代码也得交由他人处理, 如此一来, 你能够快速学到一些极具实用性的技巧, 而且自身代码的缺陷也极易被别人指出, 进而得以迅速改正。这里面有担当, 担当可是我们所在公司相当推崇的词汇, 身为一名出色的工程师, 还得具备良好的推进能力, 终究怎样才可以把一件事情彻彻底底地跟进到位, 这是一项必须得掌握的能力。刚才新人提过问题, 新人主要是聪明, 新人努力, 新人还有努力沉淀下来的成果。主持人, 对于那些想要在技术架构路线方面走向更远地方去的技术人而言, 您是否有着什么建议呢李道兵、早前知乎的那个链接所阐述的内容大致已完备、最后会再送上夫子的一句话、“学而不思则罔、思而不学则殆”、当然就我自身而言、思我会将其领会成展开思考另外加上进行讨论、。将互动环节设置为: 怎样去优化数据流, 把数据流在内网的传递次数给降下来, 使内网拥塞的可能性得以降低, 与此同时还能够提高响应性----------针对业务交互比较多的平台而言, 数据流在内网传递的次数是非常繁多的, 我想要去进行咨询, 在这一块有着怎样的优化经验呢?李道兵, 其一, 控制流无需担忧传递次数过多这件事情、状况, 将服务分解得更为细致一些是属于好的事情、情形其二, 对于数据流而言, 一方面是要减少其中的环节, 另一方面是要运用控制流去替代数据流。问服务分解细节点就很多李道兵提到, 像是数据径直发往缓存节点, 接着将缓存节点的 URI 径直向下传递。节点数量众多, 然而每个节点的功能之内聚且单一, 这对于您服务的稳定性而言是件好事, 再借助 etcd 这类工具来降低部署难度便可。互动环节, 您是否有接触过呢?李道兵称, 原本这算得上是一种开源的AWS实现。尤其是在其中主要的虚拟机、存储以及EBS这几个部分。就存储这个部分而言, 其实现相当糟糕, 不仅性能欠佳, 而且运维难度颇高, 内部还存在不少bug。然而最近有好多人依靠ceph进行相关的存储操作, 如此一来倒也不错。要是您接触过的话, 我想要跟您去请教一番, 关于控制节点主机的高可用情形, 都存在怎样极为成熟具备可行性的的方案呢?李道兵说道, 抱歉, 这个快的情况不太熟悉, 要是让我来进行设计, 通常来讲就是两种方案, 要是存在内存一致性方面的需求, 那么就模仿或者直接去使用 /etcd。在互动环节, 他提及有个问题想要请教, 想问问大家有没有那种需要跨机房数据实时同步的场景, 如果有的话, 又该如何去保证数据的实时性以及一致性?李道兵讲, 存在这样的情况, 我们所采用的方案倾向于保守, 首先, 要是存在多个机房需共用同一套数据, 那么就得确保仅有一个节点能够进行写入操作, 对于其他机房而言, 要在业务逻辑层面重新施行主机房的操作, 并且依照业务逻辑对缓存予以清理, 只要确保你所采用的缓存形式满足以下两点要求, 其一, 能够依据单条数据来实施清理, 其二, 列表类的缓存具备有效期, 而且不会致使业务出现差错便可。互动环节: 传统ERP每日有多达5万多条销售流水, 持续不断地进行插入操作, 采购以及其他业务会频繁查看历史销售记录, 一查往往要查两三年的销售情况, 还要开展各种计算, 尤其是客户销售品类繁多且杂乱无章, 计算方法更是各式各样、稀奇古怪, 即便做了一些优化, 然而效果并不显著。请问您有什么良好的建议?先说李道兵, 每天五万条的话, 实际上qps是很低的, 其峰值应当是低于5qps的。计算的时候, 需要有独立的数据库, 并非在线的数据库。数据库要有admin处理大家的慢请求, 要不就加索引又或是禁止, 再不然迁移到/hive这类适合慢请求的平台。互动环节提出, 能否介绍一下纠删码在七牛存储里是如何实现的?李道兵称, 纠删码在七牛存储的实现情况是, 其细节不方便透露, 不过, EC也并不是一个特别新颖的事物, 就像说内存, RAID都曾经有过相关实现, 你能够去查看一下它们的实现情况。互动环节中, 有人问能不能问一个偏向业务方面的问题, 又比如几万人去进行10个产品的秒杀活动, 要怎样做架构才能够保证不出问题以及性能实现稳定呢?李道兵: 进行秒杀时, 最为常见的做法是采用两段式, 第一段是接收秒杀请求, 接着将其投入队列之中, 此步骤仅仅只需确保入口以及队列的容量达到相应要求便可。第二段是由后台从队列获取请求, 应用于数据库, 随后通知用户, 仅有的一个步骤就是依据数据库的容量以有序的方式去执行就行。关于互动环节来讲: 诸多网站的登录域名与首页并非同一个域名, 这究竟是为何? 此为jd的登录域名, 众多网站皆是如此, 这与分布式架构存在关联, 还是存在其他方面的原因?下面是改写后的内容: 李道兵称, 由于分拆能够将单个模块的那种诸如开发以及维护相关的难度予以降低, 尤其是当你的开发工作被划分到多个团队之后, 要是出现多个团队去维护一个模块的状况那会是相当可怕的, 当然, 不同的域名存在着不一样的部署需求, 在进行分拆之后部署会变得更加灵活。在互动环节里则是这样的问题, 在mysql集群、处于水平分表场景的情形下, 存在着几种能够自动生成表的ID主键且保证不会重复的方式, 目前你们是采用怎样的办法来处理的?李道兵提到好些办法, 其一为运用UUID, 其二是针对每个数据库采用各异的数列, 像第一个采用1,4,7,10, 第二个采用2,5,8,11, 第三个采用3,6,9,12, 其三是当然也能借助外部的主键生成器。互动环节中询问, 可有提供一种mysql集群架构的形式呢?李道兵称, 数据库的那些文档相对而言是比较容易寻觅找到的。譬如, 有一种情况属于, How To Set Up MySQL -。要是渴望跟业界那些大咖进行没有丝毫距离感的交流互动, 那就赶紧来加入CTO讲堂微信群, 进而参与CTO讲堂吧分享时间地点每周一期, CTO讲堂群加入方式扫描二维码加“C粉儿小助手”好友申请入群。欢迎各公司技术负责人, 只要还不是CTO俱乐部成员的, 立即加入俱乐部: 。