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层架构：主机层、调度层及排程层，最上层则是包含应用程式的业务层。底层的混合云基础架构则架设了专线，打通微博内部资料中心以及阿里云。
当业务A多馀的运算资源导入溷合云共享池时，此时爆量的业务C，可从共享池调度业务A的运算资源，而度过峰值事件后，便可以把多馀的运算资源归还至共享池。
王关胜表示，目前微博的溷合云系统在今年10月完成，目前开启的Container数量约是3,000个。不过，王关胜表示，在今年的双11，微博也用此系统进行实地演练，也达成微博所设定每次水平扩充时间低于5分钟的目标。
本文转自d1net（转载）