8亿用户、单日活跃人数超过1亿人、每日超过600亿次的API调度、超过1兆次远端程序呼叫，甚至连Log记录档每天都爆增100TB，这是新浪微博平台维运架构师王关胜所面对的挑战，他得设计出一个有能力胜任这些考验的微博系统的新一代架构，而且高层给他的要求是，系统反应时间不得超过50ms。

王关胜表示，微博如此大规模的业务，除了面临系统快速更新的任务，各种不同系统元件间的依赖关系也相当复杂。而当国际事件、名人丑闻等高关注度的议题发生时，经常导致微博的业务量遽增，使得系统流量达到顶峰。

尤其遇到大型节日或活动时，如元旦、春晚、圣诞节还有红包飞等大型活动，同样也会为微博带来巨大的流量挑战。王关胜表示，位于三节的日子，微博的系统流量，会在3个小时内冲上顶峰，而红包飞则是带来瞬间的峰值流量，在两个小时内就达到最高点。过去面对此样的峰值事件，微博需要调度大量硬体设备。而如此做法，除了成本高外，系统在进行水平扩充时，也必须耗费更多的时间。

过长的前置作业时间为微博带来营运痛点

而繁琐扩充流程所花费的时间，为微博带来了营运痛点。过去当峰值事件出现时，首先，维运团队必须申请实体机器，将其登入组态管理资料库（CMDB），在机房安装妥当后，交予第一线作业人员进行初始化，并开始进行部署作业，如环境部署、监控部署、服务部署及流量导入等流程。

王关胜表示，过去的水平扩充的方法，也可能因为各个服务间的系统环境差异，无法充分使用硬体资源，即使有多余的伺服器也无法灵活调度。然而，在设备充足的状况下，完成正常的设备申请程序也必须花上一天，甚至可能碰上没有足够设备的状况，使得系统进行水平扩充花上更多时间。

另外，微博也有许多使用率不高、閒置在各丛集跟服务池的实体基础设施，而微博过去在应付红包飞、三节爆增流量的作法，会预先在各个业务的伺服器丛集，準备多余硬体设备，用来因应峰值突发的事件。而预先準备多余设备，则包含采购周期过长、机房空间不足所带来的高营运成本外等缺点。

而设备申请时间周期长、使用率不高的閒置设备，则对新浪微博带来庞大的成本压力。而因为面临这些挑战、痛点，「我们要建构有弹性的混合云系统。」王关胜表示，微博的新做法是，导入公有云并结合过去的私有云，集结各业务丛集多余的运算设施，构建混合云的系统架构。

他表示，混合云架构除了妥善集成内部硬体资源，解决内部的弹型需求外，当系统面临流量剧增的峰值事件，亦可以将过多的流量引导至外部公有云，减轻内部系统的压力。

王关胜分析了采用混合云作法的好处，他表示，内部私有云具备安全性高、掌握度高的特性，也可以因应内部需求，对硬体配置进行优化，适合处理固定的工作负载。而公有云的设备则具有标準化、自动化的特性，可以快速因应临时需求，在爆增流量的状况下，让企业具备水平扩充工作负载的能力。企业也可以利用公有云按照使用流量的付费机制，减低固定的营运成本，而采用混合云架构，可以兼具私有云以及公有云的优点，「可以同时拥有安全性与弹性扩充能力」，使系统工作负载可以在丛集间进行迁移，让低负载的丛集配置较少的设备，反之，负载高的丛集则必须準备足够的设备。而将Docker导入混合云的架构，也使微博服务稳定度高上许多。

透过三大关键，实现Docker混合云

微博混合云系统不单只是一般的混合云，而是导入了Docker，透过Docker Container快速部署的特性，解决爆量事件对微博系统带来的压力。过去企业在面对爆量事件，一般采取的作法是，首先评估需要多少额外设备，并向外部公有云申请机器分摊流量。然而，除了可能低估应付爆量所需的设备外，即使事先準备了足够的VM，其部署时间成本也远高于Docker，无法即时帮助企业分摊过多外部请求。

而王关胜表示，微博Docker Container平台的混合云核心设计思想，主要是借镜银行的运作机制。他表示，民众可以把钱存在银行，而需要使用金钱的时候，只需要提领一部分，剩余的存款银行可以拿去进行投资。而微博则借镜银行的这一套运作模式，在内部设立一个硬体资源共享池外，还导入了外部公有云。

而要微博实现高弹性调度资源的混合云架构，其中实现的关键则是Docker。王关胜表示，刚开始他们思考该要使用裸机还是VM架构，作为Docker Container的基础设施。后来，考量如果要采用VM，内部机房架构要进行许多改造。所以，目前微博的内部私有云使用裸机部署，而外部公有云则采用阿里云弹性计算服务（ECS）的VM架构。

王关胜也揭露微博构成Docker Container平台基础架构的3大关键，包含Docker在裸机上的部署架构、自主开发的Docker Registry以及网页伺服器Nginx Upsync模块。

第一是Docker Container的裸机部署方案，透过IP位址以及Port定义一个唯一的Container服务，而每台伺服器上则可以开启多个Container，各个具有不同的功能。

例如，每一个Container服务所产生的行为日志，会经由一个名为Scribe的Container集中收集。而集中后的数据则可进行用户行为分析。

此外，如果要进行Container的运作监控，则是透过建立Cadvisor Container，将Container运行产生的资料，传送至Elasticsearch、Logstash及Kibana这3种开源监控软体，进行分析。或是，搭配开源测量工具Graphite，监控系统的运作状况。

第二则是Docker Registry，王关胜表示，微博使用Docker官方提供的Docker Registry，构建了私有的映像档储存库Registry Hub，并且透过这个映像档储存库调度Docker Container需要的映像档。

在今年，微博开发出了第2版本的Registry Hub，将储存引擎改为使用分散式开源储存平台Ceph，并且在Docker Registry前端结合Nginx，实作负载平衡功能。王关胜表示，在升级过程中必须让系统能够兼容新旧版本的Registry Hub，而前端Nginx可以分析系统需求，辨別要从新版本或是旧版本映像档储存库下载映像档。

而外部公有云，微博则是透过映像档快取，不必像私有云一样，部署完整的映像档储存库。微博位于阿里云映像档快取架构，总共包含3层架构。包含最底层作業系统、中间层的运作环境如Java、Tomcat，及最上层的Container。而在调度Container时，透过使用dockerignore指令，减少不必要的文件、目录，借此减低映像档的容量。在映像档标签命名上，微博则禁止使用「Latest」做为映像档标签。王关胜表示，由于不同使用者对于标签的理解不一，可能会误以为是代表映像档最新的版本。

而第三则是微博开发的Nginx Upsync模块，王关胜表示，去年微博开始使用Container时，必须透过Container将Nginx掛载至前端，执行负载平衡的任务。而Nginx部署完成后，必须透过重启reload指令重启Nginx。王关胜发现，Nginx对于特別大的流量会发生运作不稳定的情形。所以微博也直接开发了Nginx Upsync模块，不需要透过reload指令重启，也可以保持系统稳定运作。而微博也针对两种模块进行比较，发现流量大时，未修改的Nginx模块会比Nginx Upsync模块多上10％的请求。

目前微博开发的Docker Container平台系统，主要包含4层架构：主机层、调度层及排程层，最上层则是包含应用程式的业务层。底层的混合云基础架构则架设了专线，打通微博内部资料中心以及阿里云。

混合云系统设计核心：自动化、弹性调度

微博混合云系统的设计理念，总共包含4个核心概念：弹性伸缩、自动化、业务导向以及专门为微博订制。王关胜表示，混合云系统必须有弹性调度的运算能力。而微博混合云系统并不是对外公开的产品化服务，必须以业务需求出发，因此会有包含许多微博自我订制的功能。

目前微博开发的Docker Container平台系统，总共包含3层架构：主机层、调度层及排程层。王关胜解释，主机层的核心是要调度运算资源。目前微博也设计了资源共享池、Buffer资源池及多租户管理机制，借此实现弹性调度资源。此外，底层的混合云基础架构，也架设了专线，打通微博内部资料中心以及阿里云。

而调度层则透过API，使用调度工具将API进行包装，而微博4种常用的调度工具组合包含：Docker、Swarm、Mesos及微博自主开发的Dispatch。

而最上层的排程层则是负责负载平衡。目前，微博的后端服务全部是Java环境，而个人电脑端则是使用PHP撰写，行动装置端则是透过调度API。编排层也导入了大资料工具Hadoop，执行大资料分析。

当业务A多馀的运算资源导入溷合云共享池时，此时爆量的业务C，可从共享池调度业务A的运算资源，而度过峰值事件后，便可以把多馀的运算资源归还至共享池。

微博引入阿里云做为第3机房，实现弹性调度架构

然而，王关胜也在思考，依照微博目前的技术框架，採用溷合云的架构是否可行。目前微博机房的部署架构总共分为3层，依序是最上层域名以及负载均衡层。中间则是Web层，包含各种前端框架以及中介软体（Middleware）。而最下层则包含MySQL、Redis、HBase等资料库架构，而底部资源的中介软体，则部署于中间Web层。

微博内部总共有2个机房，两者互相做为灾难备份用途，而第3个机房则採用外部阿里云。王关胜表示，溷合云架构总共有2种部署方桉。第1种部署方桉，将阿里云视为资料中心，底层架构与微博内部机房一样部署Redis。内部机房採用Linux虚拟伺服器，做为负载平衡层，但外部公有云则採用伺服器负载平衡SLB。而外部机房的中间Web层则与内部机房架构一致。不过，王关胜表示，由于微博有资料安全性的考虑，仍然把阿里云做为应付大量峰值的备桉，储存永久性资料的MySQL、HBase资料库架构并不会部署于阿里云。

而第2种部署方式则不将阿里云视为完整资料中心，仅是把内部机房应付爆量事件需要的弹性计算能力，迁移到阿里云。王关胜表示，第2种部署方桉困难之处，需要把微博的内部业务进行改造，让微博中间Web层，直接对阿里云机房进行远端程序呼叫。他表示，此种方桉部署结构相较比较简单，也让溷合云架构具有实现可行性。

而这2种方桉都会仰赖VPC网路，王关胜表示，如果有没有专线，想实现公有云的弹性计算能力几乎是不可能。因为公网调度资源的延迟时间太高，无法应付微博大量的业务。

因此，微博与跟阿里云合作，在两边建立了内部专线，让阿里云机房与微博的机房互通。最早微博机房跟阿里云建立一个1G专线，用于日常峰值，在春节则是透过10G的专线应付。

但是后来微博发现，如果只有一条专线，在峰值爆量的状况下也很难弹性调度运算计算资源。因此微博也在另一个机房中，开启了另一条专线。透过建立私有云及公有云间的专线，「目前微博已经达到高可用性的目标。」王关胜表示。

三大步骤完成大规模丛集操作自动化

微博Docker Container平台设计思维，核心目标就是透过自动化操作大规模丛集，进行弹性调度资源的任务，要完成此任务，必须经过3个流程：设备申请、设备初始化及系统水平扩展。

王关胜表示，弹性扩充任务所需要的设备来源是内部的丛集以及外部的阿里云。而申请到足够设备后，也必须对伺服器进行初始化、架设环境及配置管理。最后一步则是将伺服器上线，开始执行Container调度以及弹性扩充的任务。

第1步骤则是申请设备，而设备申请借镜于银行机制的概念。王关胜分析，私有云的设备来源，主要来自离线丛集、低负载丛集以及错峰时间空出的多馀设备。他解释，离线丛集并不是时时刻刻都在执行运算，即使稍微减少硬体资源，也不会对业务产生重大影响，而工作负载较低的丛集，如果有多馀的资源也可以进行调度。此外，微博有上百个业务线，每个业务线峰值出现的时间点都不一样，而在此种状况下，各业务也可以互相支援，共享多馀的硬体资源。

而不同业务的丛集则各自独立，并且具有独立的资源池。丛集内可以自由调度资源，例如，缩小A服务的规模，将多馀的运算资源分派给B服务。若丛集要调度外部资源，微博另外也有设计配额制度，控制每个丛集分配到的资源。在丛集外，必须看Buffer池是否有足够的资源，如果足够的话，可以直接将Buffer池内的设备初始化，进行使用。

反之，如果Buffer池内的资源不足，也必须查看是否有足够的配额，可以直接申请机器。当设备申请完成，登入Buffer池后，随即被纳入溷合云系统中，而调度硬体的程序也都会经由Buffer池。

而正常运作的设备，会从未初始化状态，历经初始化、Container启动以及Container上线等程序。不过，王关胜表示，设备异常的状况也十分常见。如果设备异常就必须就要下线，如果重启后运作正常，则可以重新回到Buffer池供人调度。但若出现硬体错误，则迳行走向报修程序。

第2步骤则是设备初始化，王关胜表示，藉由DHCP机制，微博可以达到作业系统升级自动化、系统操作API化。而伺服器所依赖的基础环境、需要的软体等环境配置，透过组态管理工具Puppet，将需要的配置撰写在模组中，完成组态自动化设定，并使用RPM机制打包，进行安装。

在初始化流程中，必须要支援软体反安装模式，例如，当A业务单位要调度设备时，其他单位在交付设备前，必须要先透过反安装程序，将要设备恢复为最原始的状态。

而目前业界中的一些做法也可以免去初始化的流程。例如导入为Container而生的作业系统，像是CoreOS、RancherOS或Red Hat Atomic。不过，王关胜表示，虽然此种做法的可维护性高，但是缺点在于迁移设备的成本较高。

第3步骤则是利用完成初始化的设备，开始进行服务水平扩充。王关胜表示，目前第一线的作业人员，只要在系统页面上输入服务池名称、服务类型、Container类型、需要Container数量以及映像档位址等参数，而在水平扩充完成后，系统也会产出完整的报告，列出扩充程序中，执行的事项，以及每件任务的成功、失败状况。

导入Docker溷合云，不怕爆量事件

为了确保微博Docker溷合云平台系统的高可用性，微博也成立了技术保障团队。王关胜表示，技术保障团队最重要的任务，就是要保障产品的稳定性，让系统在三节、红包飞等尖峰时段系统运作无误。王关胜表示，微博会优先调度内部的共享池资源的运算资源。而储存节点、永久性资料放在微博内部，确保资料的安全性。但是在红包飞、春晚时，则必须调度外部的运算资源。平日的正常状况下，阿里云只需提供1,000个运算节点，并且在5到10分钟内完成部署任务。但是，面对春晚、红包飞的爆增流量，则要提供3,000个节点。王关胜表示，这种与阿里云租借公有云的做法，只需要应付临时的爆增峰值事件，因此，也可以大大降低微博的日常运作成本。

目前微博的Docker溷合云系统，才在今年10月完成，开始启用不满3个月，开启的Container数量约是3,000个。不过，王关胜表示，在今年的双11，微博也用此系统进行实地演练，也达成微博所设定每次水平扩充时间低于5分钟的目标，并完成一日内10次的水平扩展的任务。「有这样的弹性调度能力时，系统面对大型活动的峰值压力就小很多。」王关胜表示。

王关胜表示，目前微博的溷合云系统在今年10月完成，目前开启的Container数量约是3,000个。不过，王关胜表示，在今年的双11，微博也用此系统进行实地演练，也达成微博所设定每次水平扩充时间低于5分钟的目标。

====================================分割线================================
文章转载自 开源中国社区[http://www.oschina.net]