新浪微博在2016年Q3季度公布月活跃用户（MAU）较上年同期增长34%，至2.97亿；日活跃用户（DAU）较上年同期增长32%，至1.32亿，总注册用户达8亿多。PC主站作为重要的流量入口，承载几乎所以PC端产品的落地,面对业务的高速增长，与之对应的技术架构也面临着新的挑战。在新的时代下，微博都面临着哪些挑战？对于这些挑战，又都是怎么应对的呢？本次分享，将会为你一一道来。

在第一天下午高可用架构的A会场，新浪微博主站研发负责人侯青龙发表了一场《新时代下的微博LNMP架构》的演讲。演讲结束后，记者采访了侯青龙，他与记者分享了他和新浪微博的技术团队关于新时代下的LNMP架构的一些部署经验，以及在新时代中遇到的一些挑战。此外他还从弹性角度介绍了新浪微博LNMP平台在开发时的思路和收获。

用新的思路规避传统架构弊端
新浪微博作为一个重要的社交平台，经常会遇到一些突发事件，海量转发给服务架构带来极大的考验。传统做法存在一些不足之处，例如传统设备采购申请周期长、扩缩容繁琐、设备运营成本高。当面临流量压力时，常规做法是IT设备会做一部分冗余，但不能无限冗余，毕竟还需要考虑到成本问题。侯青龙以CPU为例，一般情况下，CPU利用率可能在20%~ 30%这个区间，是一种常态，新浪内部有要求，每台服务器CPU要运行到40%左右才不会被认为是闲置。但如果CPU运行到了60%，那技术团队可能就需要考虑扩容。
面对流量压力，还有一个常规做法是服务降级，将那些不是很重要的功能模块依次关闭，保证最主要功能运行无虞。但是这样做的弊端是，在最严重情况下，微博很多模块不再显示，用户体验非常不好。
在这样的情况下，新浪微博的技术团队开始思索如何既降低设备运营成本，又能增强业务的弹性扩容部署。侯青龙告诉记者，最终新浪微博选择了基于混合云平台的PHP弹性扩容部署方案，搭建了DCP平台，既可以实现业务的弹性调度，基础设施又可以跨云操作，非常好地解决了突发流量的问题。

之前在会场，有一位与会者问了一个问题：如果流量突然之间暴增，那么临时去扩容也存在一定时间差，这时该如何处理，确保服务无损?侯青龙表示这时候就需要去做提前预判。如果CPU在60%的运营状态就处于危险边缘，那么在50%的时候就应该提前去做扩容处理，如果时间紧张，那就先进行降级处理，因为我们降级比较方便，后台很多级只需要动个按钮就可以完成，优先去进行一个降级，等到扩容完成立刻恢复，尽量缩短降级的时间。
DCP的价值
那么，新浪的这个DCP平台究竟是如何解决弹性扩容和跨云问题的呢?

侯青龙告诉记者，弹性扩容是把所有环境差异通过容器化镜像进行打包，尽量让底层主机变得透明。为什么要这么做呢?是因为之前部署PHP服务器还有Java服务器，各自操作系统的选择和业务环境的部署差异非常大，即使处于冗余状态，也无法使用。但是通过DevOps Community化的技术，把这些技术全部分流到镜像中去，部署一模一样的Docker引擎，当新浪微博需要部署某个服务时，可以快速地将镜像下载下来并立即启动。
而基础设施跨云，其实等于抹平了主机的差异，让用户不再关心扩容需要多少服务器，减轻了过去在基础设施环节的工作量。

在侯青龙看来，DCP的价值在于把所有的行为在事前都以系统的方式组织起来，当需要去部署某一个服务或打包某个镜像时，都可以基于系统通过按钮的方式快速完成，细节的东西完全做到了自动化。
DCP带来的另外一个明显的好处是降低了运维的难度，因为运维人员不再需要精通技术，只需要懂得操作系统就可以了，所有技术化的东西都已经被隐藏在后端，前端呈现的就是自动化的操作界面。
为什么选择Docker?
侯青龙透露，其实以前他们也考虑过不用Docker技术，用虚拟机来代替，新浪微博在做一个开发机或者测试环节时，实际上已经有了一套纯虚拟机，完全可以直接使用。而如果基于Docker，那就意味着所有的接入方式必须以Docker方式接入。
但是最后技术团队认为，他们更希望新的服务架构对于开发的同事而言是没有感知差异的，不希望内部有两套体系，因为同一个配置实际上可以部署到弹性扩容平台，也可以部署到传统的平台，没有差异，所以最终选择了Docker技术。

此外，新的服务架构也遇到了一些难题。因为弹性扩容时代码随时会删，环节比较复杂，最稳妥的做法是全量部署，但由于PHP代码和Java代码不一样，Java代码是本地打包完了以后，直接把那个打包文件推送就行。而PHP文件完全是散的，传统方式是通过rsync去推送，但是Docker化之后，他们发现，每次全量部署都需要重新推送，哪怕代码只改动了一个指令。后来经过一些测试，他们发现镜像部署特别好，1G的镜像可能几十秒钟就下载完了，全量部署比想象中快很多。
经验分享：如何让架构变得有弹性?
侯青龙介绍到，新浪微博的业务系统都是基于PHP开发，技术团队过去做镜像、做优化时，大多都会进行单独部署，单独做成一个镜像。但当遇到需要扩容的时候，系统运行的时间就变得非常慢。原因在于过去编辑镜像的时候，技术人员会针对每一个镜像做一个打包，相当于每个镜像都包含一个操作系统，假设一个操作系统600兆大小，那么即便是镜像安装100兆大小的PHP加起来也有700兆，下载特别慢。
后来他们把这个镜像打成镜像包，所有的组件都共用一个操作系统，大小被压缩了好多，下载速度也更快。这样部署新系统功能时，以前可能要半个小时，现在只需几分钟就搞定。
在采访结束时，记者询问侯青龙对于服务架构未来发展趋势的一个预测，他表示，从宏观角度看，当企业在发展初期时，服务架构的宗旨就是怎么方便怎么做，但是当企业已经具备了一定规模，这时候服务架构就需要去考虑如何用工具解决所有问题，尽量用自动化的角度解决问题，这是他的经验分享，希望能够对大家有所帮助。