- 下载
- Android app
个人简介 陈剑豪(Cipher),现任青云QingCloud云计算基础平台开发部研发工程师,QingCloud资源协作服务的作者,主要方向是SDN(软件定义网络)。在加入QingCloud之前,曾在泰捷视频从事架构开发工作。对优雅的代码有偏执追求。
ArchSummit全球架构师峰会是InfoQ中国团队推出的重点面向高端技术管理者、架构师的技术会议,50%参会者拥有8年以上工作经验。 ArchSummit聚焦业界强大的技术成果,秉承“实践第一、案例为主”的原则,展示先进技术在行业中的最佳实践,以及技术在企业转型、发展中的推动作用。旨在帮助技术管理者、CTO、架构师做好技术选型、技术团队组建与管理,并确立技术对于产品和业务的关键作用。
陈剑豪: 大家好,我叫陈剑豪,目前是青云IaaS Team的研发工程师,IaaS Team是青云非常核心的团队。IAAS层是云计算最底层的基础设施,它包括了计算、存储、网络以及调度等模块,青云的IAAS Team有一个特点,每个人不仅仅负责自己某一方面的事情,我们要对所有的模块都有所了解。我现在的主要方向是SDN,目前正在做LB Cluster的升级版,LB Cluster也就是我们说的负载均衡器,它是一个集群系统,那么LB Cluster作为用户暴露在公网业务的第一层,它的稳定性和可靠性都非常重要。我们的LB是Cluster模式的,并且运行在公网,现在我正在把它做成能够同时运行在私网内部。
陈剑豪: SDN又叫做Software Defined Network,它其实是一种以软件定义网络的方式。自青云成立以来,我们一直都是沿着SDN的思路去构建整个网络的,比如2012年以来的SDN 1.0版本,其实是以NFV的方式实现的,也就是说我们会参考物理设备,用软件的方式去实现这些虚拟的物理设备,比如说虚拟的路由器、虚拟的交换机,但我们发现他们的性能还是不太行,已经是很早以前的版本了,在面对一些小流量的时候绰绰有余,但是对于超大流量其实是不够用。于是我们就自研了SDN 2.0,SDN 2.0通过把控制平面和数据平面分开,让控制平面可编程,并且引入了一个概念叫做分布式虚拟网关,通过分布式虚拟网关在不同的分布式节点中同步路由规则、ARP规则等,使SDN 2.0能够承载超大规模集群,比如我们的VPC,VPC能承载六万多个节点,这些节点可以同时运行在几百台、几千台宿主机上都没问题。SDN 2.0的表现非常好,目前已经在公有云跟私有云、混合云运行了好几年,非常稳定,这是SDN 2.0。像我们今天聊的是Region,Region是构建在SDN 2.0之上的,它是为了解决企业客户对双活或者多活灾备等的需求,我们基于SDN 2.0之上做了一些优化跟改进。这些因为不在上午的主题里,我们并没有提,比如SDN 2.0基于分布式虚拟网关,它是纯软件的,构建在 Linux 操作系统之上,Linux操作系统有非常多的好处,比如说,稳定性非常强,定制化能力非常高,社区也很活跃,性能也非常好,但就是有一个缺点,它的性能远远比不上专用的物理设备。比如看一个指标叫PPS(包转发率),随便拿一台专业的设备都能把一台高配的服务器给干趴下,所以我们觉得对接硬件网关还是很有必要的,SDN 3.0不仅仅有分布式的虚拟网关,还对接了集中式的硬件网关。这些有什么用呢?分布式的虚拟网关主要解决的是VxNet私网内的点对点通讯,硬件网关主要是解决VXNet之间或者跨区的VPC之间的通讯。之前这些通信,需要通过隧道去打通,需要走公网、走隧道,通过对接硬件网关我们可以让多个区之间的VPC互联,不需要走隧道,这样性能就能变得非常好。以上是我们SDN几个版本的演进过程。
陈剑豪: 多区域数据中心架构出名的有几种,同城双活、多活、同城灾备、异地灾备等等,这些概念从字面上都非常好理解,同城还是异地,灾备还是双活。还有一种更复杂的情况叫做两地三中心,比如说我们可以一个Region在多个可用区之间部署同城双活的架构,并且在两个异地的Region之间做灾备,这简单来说就是个两地三中心。但是它的实现肯定没有这么简单。
5. 那如何做到多区域数据中心的高可用?
陈剑豪: 高可用其实是一个方向和概念,它不是一个具体办法。如果有一个商人跟你说,你只要用了我这个产品,你就能一定能实现高可用,你的业务永不宕机,这是绝对不可能的。高可用一定得根据具体的业务做出很具体的优化,做出具体的架构上的调整。比如说我们假设有一个大数据分析的业务,那么我们可以认为它最核心的在于数据,这个时候只需要实现数据层的高可用。还有一种情况,比如说现在大概三点钟,然后感觉有点困了,我要点杯咖啡,我拿起手机下个单,这个请求一旦发到APP所在的服务端,服务端会经过各种解析和业务逻辑的处理,最后会根据一些状态说这个人已经下单了,需要做哪些处理,这整个就是一个典型的互联网消息流。那么对于一个互联网应用而言,其实每一层都需要考虑到高可用。比如说我们刚刚说的,请求发到服务端,这一层的高可用方案我们可以用Region级别达到LB Cluster,可以以Region的方式部署在多可用区,结合我们的公网IP(EIP)可以让DNS没有这么麻烦,因为我们可以保证EIP绑定在LB Cluster的时候总是有用的。这是第一层。那么其它层呢?比如说缓存层或者数据层,要做高可用,就要把多个区之间打通。之前的办法是通过隧道,但通过隧道去同步数据非常依赖隧道的质量,如果说通过Region,因为Region多个可用区之间延时非常小,并且默认是二层互通的,所以延时比较有保证,质量也有保证;数据层也可以选择部署在我们的VxNet,或者说用我们AppCenter里面成熟的MySQL Plus、 MongoDB 、RandomDB等等软件。我们提供给客户的是Region,是让用户能够选择更多解决办法去构建自己的高可用。
6. 您刚刚说的多可用区指的是什么?
陈剑豪: 多可用区简单来说就是,比如说我们在一个城市,构建三个数据中心,第一,多可用区在物理上要把这三个区连起来,形成一个环网。第二,形成环网还远远不够,不止要做物理上的打通,我们还需要提供软件层面解决方案的种种办法,比如我们刚刚说的VPC、LB Cluster,还有运行在整个Region上的VxNet数据层。通过种种Region级别的软件,我们才能说这对用户而言是一个多可用区的解决方案。
陈剑豪: Region推出不仅仅是为了做同城多活。为什么我们不说异地多活?因为多活对延时的要求特别高,比如对一个抽象的业务而言,它最关键的一层就是数据层,数据层如果能够做到多活,那么上层的Web层或业务层、相关的层做多活也非常简单。对于数据层,它能不能容忍两个区之间的延迟呢?比如,我们同城两个区的延迟可以在1.5毫秒以内,这个时间对于一个数据库的企业请求而言是可以接受的,但如果这两个区是异地,可能隔着几百几千公里,延迟会非常大,达到几十毫秒,这个时间对于写操作来说是不能容忍的。所以不是说我们不能提供异地多活,而是用户基于异地能不能容忍这个延迟。我们现在也有一些解决办法,就是拉专线,我们在主要的几个大区,北京广东上海这三个区都互相有专线,这些专线的质量会比较稳定,这是一个解决办法。
陈剑豪: 对于小企业而言它的痛点非常明显,它缺钱。比如说我们需要自建一个机房,它跟云打通,这个机房就非常花钱。对大企业而言,它不缺钱,但是他需要解决建机房耗时、费力、跟运营商打交道去拉专线等等问题,等这些东西做完之后,这个专线还得通过隧道去打通,这也是一个软的方式,不仅费时费力,性能也不那么好。云其实就是为了解决我们刚刚说的这种小企业以及大企业,对于IT资源、对于CT资源交付的更快速要求。
陈剑豪: 其实答案就在问题里。因为一个Region以多可用区的方式部署,必然带来延迟,问题不是怎么减少延时,而是说我们在决定一个业务要上云的时候,是否有必要以Region的方式去部署,我要做多可用,还是不要做多可用,区别在这里。用户有一种情况,举个例子,比如说它的缓存如果能允许一定时间内的延迟,那么就可以在多个区都独立部署缓存节点,这个时候缓存不需要与集群通讯,就能避开延时问题,因为它是单点运行的。主要还是在于业务的选择,因为物理距离就在那里,我们只能尽量减少,但是总是会有传输时间。
陈剑豪: 其实就是要决定好这个业务到底需不需要。当然还有一种,刚刚举的例子是缓存,缓存可以不要求实时性,假设请求分散到各区的时候,不要求请求结果完全一致,这个时候缓存就可以不需要Region的方式。还有一种,我们说Web层,如果设计成无状态,那么简单粗暴的说,它就是一堆代码,可以无限地水平扩展,这个时候也是不需要部署Region的。
陈剑豪: 资源协作不是一个IaaS层产品,它属于云管理平台的产品,它是为了让用户对自己在云上的资源有更好的权限的管理。以一个场景为例,早期我们提供给客户的是青云账号加密码,客户会把自己的资源都部署到这一个账号下面。对于小型企业来说,其实一个账号就够了,因为它的研发和运维可能是在一块的,资源也是统一进行管理。但对于一个大型企业来说,这是一个企业级的账号,如果把资源都部署到这个账号底下,而企业有不同的独立项目要分开来管理,这种时候就有问题了。假设这个项目组的运维需要一台新机器,而企业只有账号密码,运维就必须得拿着这个账号密码,这个时候就意味着整个企业所有的云资源都暴露在这个同事的眼下了。并不是说这个企业不信任这位员工,但是资源的隔离是非常有必要的,资源协作正是基于这么一个场景开发出来的产品。它可以让管理员划分出一个组,然后把相关的组,比如按照项目的概念去划分,再把资源都放到组里面,并且定义一些权限,比如项目里面的资源的读权限、写权限,通过这些权限的集合把项目分发给不同的用户。比如研发对于云的资源可能更多的是关注资源到底有没有性能瓶颈,监控怎么样,那他们对这个资源所需要的就是读权限。而对于运维来说,他们不仅仅需要看,有可能还需要创建,需要扩容,这是写的需求。所以资源协作就允许把增删查改,以及更细粒度的权限分发给不同的运维人员或者工作人员。资源协作它并不是一个新鲜品,但它是一个必需品。
陈剑豪: 经验不敢说,当然书籍是有不少的。比如最经典的砖头书叫《代码大全》,程序员在写代码之前都应该看一看这本书,翻一翻。当然我相信没有几个人能全部看完,但是看一看是很有必要的。对于我自己而言,我有一个挺好玩的判断标准,就是我在写代码的时候,我会想一想,这个代码过了几个月、几年,如果后来的人看到这个代码,或者说他要重构这个代码,他看到这个代码时候,会不会有一种冲动想找到我的联系方式,然后冲过来打我,如果不会,那我就认为这个代码是比较友好的。
InfoQ: 以上是所有的采访问题,非常感谢老师接受我们的采访。
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:- 从 “挖光缆” 到 “剪网线”:蚂蚁金服异地多活单元化架构下的微服务体系
- 稳定性相关异地多活
- 无需公网IP就能异地组网?
- OPPO异地多活实践——缓存篇
- OPPO 异地多活实践:缓存篇
- 异地多活:MySQL实时双向(多向)复制实践
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
阿里巴巴Java开发手册
杨冠宝 / 电子工业出版社 / 2018-1 / 35
《阿里巴巴Java开发手册》的愿景是码出高效,码出质量。它结合作者的开发经验和架构历程,提炼阿里巴巴集团技术团队的集体编程经验和软件设计智慧,浓缩成为立体的编程规范和最佳实践。众所周知,现代软件行业的高速发展对开发者的综合素质要求越来越高,因为不仅是编程相关的知识点,其他维度的知识点也会影响软件的最终交付质量,比如,数据库的表结构和索引设计缺陷可能带来软件的架构缺陷或性能风险;单元测试的失位导致集......一起来看看 《阿里巴巴Java开发手册》 这本书的介绍吧!