从淘宝到云端的高可用架构演进

所以我们需要有一套面向云的高可用架构.在很早以前有厂商提出类似SDN的一个概念,叫SDI——软件定义基础设施,过去我们发现只有大厂可以做这个事情,设计一套很复杂的管理系统帮他实现,这里放一个路由器,这边放一台虚拟机,可以通过软件的控制流去控制这个东西.但是在云的时代,资源变得很容易获得.以阿里云为例子,可以用API随时创建新的虚拟机,新的负载均衡,或者是新的存储,都可以通过API随时创建随时销毁,这对于你的基础设施的灵活度非常有好处.

以前有的人会觉得,性能问题或者容量问题应该通过性能优化的方式解决,通过一些黑科技方式解决,加机器会觉得很low.但我觉得一个问题如果能简单用加机器来解决是很不容易的,意味着对你的整个架构的水平扩展性要求非常高,而且解决效率很高,加机器就解决了,而对一些中心化的系统来说就比较麻烦,加机器都加不了,可能要把机器关掉升配置再重新拉起来.所以我们说,在公有云上面,在资源如此容易获得的情况下要充分利用这个特性,要做一个能够做水平扩展的架构.

那么第一步要做什么,前两年很火的容器、微服务,本质上都是解决了是无状态的应用怎么做自动化的扩容这个问题.右边这个图上面,上面是一个负载均衡,中间是一个前端的服务,后端是一个无状态的后端服务,底层是MQ、对象存储、数据库这些东西,如果我们能够把前端和后端的无状态服务第一步先容器化,就可以做到当流量过来的时候,只要后端的存储没有问题,整套架构就是能够水平扩展的.

从去年公开的报道和故障来看,很多人有个误会是说云厂商的机器应该是不会挂的,我买了一台云厂商的虚拟机应该是随时可用的,即使不可用云厂商也要帮我解决热迁移的问题,热迁移在业界是很复杂的问题,不光涉及到磁盘存储的迁移,也涉及到内存是要做迁移的,可能还要用RDMA.并且对于传统的IDC来说,不管物理机还是虚拟机都是有可能挂的,对云也不例外.当我们在使用公有云服务的时候,都是会挂的,这是个心理准备.不光是机器,包括负载均衡是不是也有可能挂,下面的消息队列或者数据库是不是也有可能会挂,当你基于任何东西都可能会挂的前提设计一个系统的时候,才能真正做到这个系统在任何情况下都不会受底层云服务的故障影响.

而对于不同的云服务来说是有不同的容灾策略.比如一台虚拟机挂了,通常来说负载均衡不管是4层还是7层都会做健康检查,挂了健康检查不通自动会把流量切断.如果我的负载均衡挂了怎么办,如果DNS有健康检查那就方便了,如果没有的话可能就要设计一个旁路系统解决这个问题,发现这个已经不通了,就自动把它从DNS上摘掉.

不管是云服务发生故障还是自己应用发生故障有个大原则是如何最快速解决问题,就是一个字,切.为什么要做异地多活,为什么要把流量往各个地方引,切流量是解决问题最快的,把坏流量切到好的地方马上就解决了,如果你要等定位问题解决问题再上线客户就流失掉了.对淘宝来说也是一样,当某一个单元低于我们认为的可用性的时候,我们会把这个单元的流量引到另外一个可用的单元,当然前提是那个单元的容量是足够的.

弹性是不是万能的?所有的云服务都是弹性的,弹性其实不是万能的,容量规划仍然是有必要的,不然就没必要做双十一备战了.这里有一个你需要付出的代价,弹性的过程往往是需要时间的,那么容量规划在这个环节中起到的作用就很重要,当真的逼不得已的时候,我要扩容了,怎么保证我扩完容之前系统不雪崩?就是要结合之前的限流,尽可能保障每个客户得到他应有的服务,但是也要保障系统的稳定性.

Region和Availability Zone这两个,当实践的时候,购买虚拟机、负载均衡或者数据库,一定要选择多可能区的服务,比如阿里云买SLB是可选可用区的,有个主可用区和副可用区,如果一边挂了可以切换到另外一边,RDS也是一样的.

这幅图是一套典型基于公有云的一套架构,不叫异地多活,应该叫跨区域设计.左右两个大框是两个城市,左边是北京,右边是上海,每个里面又有不同的机房可用区去承担这个流量,假如北京的挂掉了,就切,原来是在A可用区,就切到B可用区,这时候A可用区没有流量进来,通过切换的方式能够把这个服务快速恢复.下面画了一个跨区域复制,我们在异地多活项目里,涉及到了跨城市跨数据中心的复制,比如我的北京是提供写服务的,上海要提供读服务,就要通过这种方式同步数据过去.

（编辑：厦门网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!