本文将阿里云运维实践汇总为十八招，从云时代下的资源自动化管理，到静态、动态缓存提升网站性能的方法，再到混合云架构、互联网监控解决方案，以及Devops和云安全实践等，都是比较经典的一些干货，让大家了解阿里云最热门的运维架构技术实践。
直播视频回放，戳这里
第十招 使用动态缓存提升网站性能的四种方法
说完静态缓存，当然也有动态缓存。降云十八掌的第十招——使用动态缓存提升网站性能的四种方法。动态缓存，即asp、jsp、php等动态请求页面缓存，所以对数据展示实时性要求高的应用需要慎用。一般一些论坛帖子、用户留言等这些业务数据展示实时性要求并不高，都是可以将这些动态数据缓存。使用动态缓存提升网站性能的四种方法具体如下：
第一种方法，和前面介绍的磁盘缓存采用的技术一样。都是通过nginx的proxy_cache模块，只不过动态缓存中，如图配置，我们在nginx的location中匹配的是jsp等动态请求，然后先从缓存中取，而静态缓存中，匹配的是js、css、html等静态请求，这是它们的核心区别。
第二种方法，就是php自带的fastcgi_cache模块，能对php请求进行缓存。
第三种方法，通过nginx内置memcache模块实现动态页面缓存。我记得之前在一家电商公司做运维的时候，每次到活动量，我发现memcache缓存服务器的流量每秒高达三四百兆。按照那时候的理解，memcache存储热点数据（比如数据库访问的热点数据、或者业务临时数据）怎么会有这么高的流量。然后我通过看nginx的配置文件，发现nginx中配置了连接memcache的配置，nginx好像能对memcache直接进行读取。其实当初真没见过这种用法，我向研发总监请教了这个问题。原来这是nginx自带的memcache模块功能，后端通过业务代码，把订单的拍照图片直接存放至memcache中，前端能直接通过nginx访问memcache中存放的图片信息。
方法四，nginx通过第三方模块实现动态页面缓存的区别在于，方法三在存储图片的时候需要通过编码，将图片等静态数据写到memcache缓存中。而nginx通过第三方模块实现动态页面缓存，是通过第三方模块插件，直接将静态资源数据写到memcache或者redis缓存中。通过图中的架构图，我们也能看到这个差别。
第十一招 混合云架构最佳实践
混合云架构也是当前云端运维架构实践中主流的架构场景实践。混合云架构通过专线能将云上和企业内网、或者IDC数据中心内网打通。所以在异地容灾备份、或者企业级OA、ERP内网应用中应用广泛。
上图中架构就是一个云端客户案例，对数据安全性、对数据异地容灾有很高要求。通过VPC+专线打通两个机房，一个机房用于线下测试及预发环境，一个机房用于热备云上数据。由于云MongoDB没办法和线下做副本集，所以我们采用自建mongo副本集。
Rabbitmq采用镜像复制模式+SLB组成两台机器的高可用。由于都是内网环境，我们自建内网DNS，方便线下IDC测试预发环境及线上环境做内部业务域名定义。由于客户业务代码框架限制，及mysql需要支持myisam表等一些原因，我们在云上和线下采用自建redis及mysql高可用方案。Redis采用主从+sentinel+consul+dnsmasq做高可用。Mysql采用主从+consul+dnsmasq高可用。
第十二招 互联网监控的演变（11种监控解决方案）
监控系统是业务运维保障的眼睛，让业务出现问题、异常能第一时间发现并解决。可以没有自动化，没有DevOps，但是不能没有监控。随着云计算的发展，各种监控技术的成熟，也伴随着互联网监控体系的演变。接下来简要介绍常见的11中监控解决方案，这是降云十八掌中的第十二招。
我们先来看看，物理机体系下的三大监控方案实践
监控方案一：Shell/Python，这个监控解决方案一般用于不懂运维的研发人员，没听说过监控系统，也不知道用什么监控系统。所以就用自己擅长的开发语言，来完成日常监控需求。比如我以前做Java开发的时候，兼公司的运维、服务器的监控，就是自己写了几个shell脚本完成。
当然，这样缺点也有很多，比如在中间件、应用层监控中，在监控数据存储、数据查看等方面基本都不能做。
监控方案二：Nagios，官方称Nagios为IT基础架构监控的行业标准，主要偏向做主机系统、交换机路由器等网络设备的监控。这是一款80后监控工具，基本上90后很多人都已经不知道nagios了。很多监控的功能通过插件化来实现，对技术能力要求高，并且在图形展示、中间件方面监控较弱。
监控方案三：所以为了解决nagios在图形展示方面的问题，在实际应用中，我们一般把cacti+nagios结合起来。这也是物理机体系下的最佳监控实践。
云计算体系有四大监控方案实践，具体如下：
监控方案四：Zabbix，官网称zabbix为企业级IT监控解决方案，相比nagios官网的介绍特点，zabbix既然被称作企业级解决方案，就能看出来zabbix不仅仅能做nagios主机、网络设备层面的监控，在其他企业级其他方面监控需求也可以，比如中间件、日志等都能监控。最为核心的是，zabbix具有完善详细且成熟的API，支持企业级定制化开发，这个功能非常重要，企业可以通过api把zabbix集成在自己的运维自动化平台中，或者基于zabbix二次定制化开发适合公司业务的监控系统。
Zabbix缺点就是面对大数据的冲击，zabbix采用关系型数据库存储监控数据，已经满足不了海量监控数据的存储，还有就是zabbix对容器的支持并不是很好。
监控方案五：云监控，云监控（CloudMonitor） 是一项针对阿里云资源和互联网应用进行监控的服务。随着云平台的普及及发展，监控的趋势主要会偏向云监控。因为云平台会把常见开源环境，比如web、缓存、数据库都会封装产品化。运维人员不需要再去安装部署这些开源类中间件，只需要开通对应产品服务，一键式配置管理维护等。所以我们不需要再自建zabbix等监控需求，云监控一键式的监控设置，能满足80%~90%互联网企业的监控需求。
监控方案六：驻云监控1.0，核心主要基于Zabbix。我们主要累积了金融、电商、游戏等领域的监控模板，并且7×24的监控值班中心保障报警问题能及时触达到运维人员。我们监控值班中心差不多十个人左右7×24轮班，高大上的监控室让人看起来就觉得非常帅气，非常专业。
监控方案七：驻云监控2.0相比1.0，我们继承了云监控的站点监控等功能，弥补zabbix监控体系的不足。并且结合zabbix api，我们研发了阿尔法智能告警系统，直接砍掉了7*24值班人员的监控中心。所有告警通过智能电话，自动的通知运维。
接下来进入容器体系，主要有四大监控方案实践，包括：
监控方案八：我们知道，zabbix、nagios是1998、1999年那时候出来的技术，那时候也根本就没有容器技术之类的概念，而prometheus是如今专门为容器监控而生的。Prometheus火热程度仅次于kubernetes，是继kubernetes之后第二个加入云原生基金会的。我觉得prometheus是容器开源解决方案最佳实践，prometheus监控数据通过时序数据库存储，而时序数据库是NOSQL，能轻松解决zabbix关系型数据库面临的高并发、高存储、高扩展的三高问题。
但prometheus有两个缺点：第一个缺点，需要针对每个中间件或者监控目标都要单独安装export，有多个监控目标的话，多个监控目标对应暴露http服务端口，在维护管理等方面非常不便；第二个缺点，prometheus的监控项值只能为浮点数据类型，不能存储字符数据类型，这个限制就有点大了。为什么不能存储字符串数据类型，因为官方觉得涉及字符串类型都属于日志监控范畴。
为了解决这两个技术问题，然后就出现了我们监控方案九：TICK。
监控方案九：T是Telegraf的简称，I是influxdb、C是Chronograf、K是kapacitor。Telegraf是一个监控数据采集代理，能采集收集多个监控目标，解决了prometheus中要装多个export的问题。Influxdb作为时序数据库的老大，相比prometheus自带的TSDB存储，能存储字符数据类型。
虽然TICK解决了prometheus的两个缺点，但是带来两个新的问题。一是Chronograf监控数据展示，这方面算TICK技术栈中的弱项，相比grafana，TICK功能及图形展示效果等方面弱一些。Kapacitor报警通知这部分算TICK技术栈中的弱项，相比prometheus技术栈中的alertmanager，没有报警去重、降噪、分组等功能。
监控方案十：什么是驻云监控3.0呢？我们将 Prometheus和TICK技术栈进行了合并，利用了两套方案的优点，解决了两套方案的缺点。Telegraf + Influxdb + Prometheus + Alertmanager+ grafana解决了原生态prometheus需要安装多个export且只能存储浮点数据类型的问题，同时也解决了TICK技术栈中在监控数据图形展示、报警通知方面的缺陷。
但是驻云监控3.0架构仅解决了主机+中间件的监控问题，没办法解决云产品监控、站点监控、日志监控、代码监控方面的问题。但这些监控目标都是云监控的功能特点，所以最终我们通过api集成云监控，成为驻云3.1完整监控体系，这就是我们的监控方案十一。
第十三招 DevOps发展的四个阶段
除了监控技术外，云端当前最火的就是结合容器、集合kubernetes资源编排技术相结合的Devops相关技术了。所以，降云十八掌的第十三招就是Devops发展的四个阶段。
Devops发展经过四个阶段：人工阶段、脚本及工具阶段、平台化阶段、智能化阶段。
人工阶段，就是最为原始的劳动力阶段。都说我们IT人员是背着笔记本的农民工，我们的座右铭就是一个字：干。
到了脚本及工具阶段，我们运维通过工具、脚本尝试解决运维重复工作，这是运维自动化1.0阶段。随着业务发展，而运维自动化2.0核心就是rundeck等web图形化界面出现，研发也能通过这些web平台来进行发布代码等运维操作。
说到这里，DevOps与运维自动化有本质区别。我们知道运维和开发一直是冲突的，运维追求稳定不要变更，研发为了迭代，需要经常变更。跨部门的沟通协作，变更发布效率、质量等问题。DevOps面临及要解决的是可持续集成及可持续交付的IT体系化问题，而运维自动化仅是运维层面的自动化运维管理问题，DevOps体系其实包含运维自动化的，不是一个维度的事情。
在运维自动化2.0基础之上，出现了DevOps1.0，在DevOps1.0的核心技术是Jenkins的出现，解决了可持续集成，让代码自动化编译发布。
然后接下来平台化阶段，云本质其实是一个大的运维自动化平台，让IT运维管理一下子进入平台化及运维自动化3.0阶段。
云平台虽然能解决绝大部门企业的运维自动化诉求。但是随着业务系统变多，以及资源变多的时候，需要满足业务流程化相关联的一套独有自动化平台的时候，我们就开始需要定制自己的自动化平台。特别是未来多云平台，我们是没办法单纯用一个云厂商平台解决我们所有资源管理的问题。
容器技术的出现，让DevOps1.0走向DevOps1.0 ，最主要的是kubernetes技术引入，解决了可持续交付的问题，让业务部署发布、上线、变成秒级，以前物理机交付是天级别，现在云计算是分钟级别，然后到容器阶段变成秒级交付！
最后一个阶段便是智能化阶段，人类的科技未来肯定是人工智能，正如电影终结者中的人机大战场景一样，随着人工智能技术成熟，机器人的时代已不再遥远。所以智能化阶段，已经脱离单纯devops体系，进入AIOPS的智能化体系。AIOPS中的AI非智能，AI体现在通过算法，通过程序来实现智能发布、扩展、故障自愈等等。
第十四招 跨云平台分布式架构
结合刚才说的容器技术，未来业务跨云平台分布式架构是最主流的形态。这便是降云十八掌的第十四招。
第一个核心技术点：我们通过容器技术DOCKER+K8S，让业务部署跨平台，不依赖云平台或者底层物理环境。
第二个核心技术点：通过DNS智能解析，我们能将用户请求分别调度转发到不同平台中。说到DNS智能解析，其实CDN的就近访问核心功能就是依靠CDN的智能解析。
在跨云平台分布式架构中，最难的技术点其实就是第三个核心技术点，就是数据同步。我们把业务部署在不同平台上，这些可能在不同地域上，我们怎么样保障不同地域连接的数据库数据实时同步，保障数据一致性？阿里云有DTS成熟的同步方案，加上专线高速通道解决数据传输速度等问题，这也是这方面较成熟的解决方案。
第十五招 企业级VPC安全架构
VPC是企业级网络安全架构最佳实践，之前跟大家介绍过混合云架构的一个案例，主要做异地跨平台数据灾备。这里另外一个核心场景就是可以把公司内部所有内部应用都放在云端。企业里面，我们不需要任何一台硬件服务器，我们只需要放几个交换机、无线路由器来供给员工日常办公网络。
但这里，我们面临最多的两个技术问题挑战，一是安全性，由于内部OA、ERP都是内部敏感业务系统，放在云端不可能通过公网暴露，所以这里解决安全问题就是通过VPN IPSEC隧道技术，通过内网传输访问保障安全性；一是访问速度问题，虽然VPN IPSEC是传输加密，但是也是基于公网，网络传输质量可能得不到。为了解决这方面问题，我们通过专线，即阿里云高速通道服务来保障及解决即可。
第十六招 云端全链路安全机制
安全的话题一直是敏感的，刚才提到VPC是企业级网络安全架构最佳实践。那在云端我们如何做好安全性？我们需要在请求链路上做全链路安全机制，保障每一个环节都是安全可靠的。这就有我们的降云十八掌第十六招——云端全链路安全机制。
一个用户请求云端业务，会经过哪些链路及流程呢？
首先路由进入云机房，然后进入DDOS流量监测清洗集群（阿里云的DDOS集群系统，硬件方面采用华为赛门铁克专门定制的多板卡、多端口硬件，软件方面采用云盾自助研发的防御系统）。接着流入CDN节点，再流入WAF web应用防火墙，再流入飞天集群系统，即安全组规则中，再到SLB，然后流入ECS系统中，先进入iptables再到nginx，再到代码层，最后代码调用请求数据库。
所以为了保障安全性，我们需要对请求的每一个环节，每一条链接上都要做安全规则机制。
第十七招 云端运维安全十则
除了第十五招网络安全架构、第十六招全链路安全机制外，运维层面的安全防护规则是安全防御的最后一道防线。这是降云十八掌的第十七招——云端运维安全十则。
第一则：运维堡垒，即运维堡垒机，通过堡垒机我们需要做远程登录服务器的安全管理及审计。
第二则：运维用户管理，服务器不要直接开放root，不要用root运行进程。
第三则：密码安全管理，最好的密码规则就是不要有密码规则，用SSL证书验证。当前aws、阿里云对云服务器的登录验证，都是默认推荐使用证书的方式。
第四则：防火墙安全管理，防火墙的开启、安全端口管控，是运维安全中最有效的防护手段。
第五则，端口安全管理，数据库等敏感业务服务只绑定在内网端口上，切勿一股脑的全绑在0.0.0.0上，就对全网开放了。
第六则：openresty无缝兼容nginx，是云端开源waf最佳实践。
第七则：数据传输，要牢记SSL加密传输的原则。
第八则：运维安全性能调优，必要的性能调优，不仅能提升访问性能，也能冗余安全攻击。
第九则：通过冷备及热备进一步保障云端数据安全性，比如通过前面介绍的混合云架构做异地灾备。
第十则：加强安全巡检及安全培训管理，安全防护需要人人做起。
第十八招 千万级架构的演变
降龙十八掌中最后一招叫神龙摆尾，我跟降云十八掌中的最后一招也起了一个响亮的名字，叫化云为雨。
什么是一个好的架构？我觉得一个好的架构是靠演变而来，而不是单纯的靠设计。刚开始做架构设计，我们不可能全方位的考虑到架构的高性能、高扩展、高安全等各方面的因素。随着业务需求越多越多、随着业务访问压力越多越大，架构不断的演变及进化，因而造就了一个成熟稳定的大型架构。如淘宝网、如Facebook等大型网站的架构，都是从一个小型规模架构，不断演变及进化成为一个大型网站架构。
那么在云端，一个千万级架构是如何演变而来？
- 架构的最原始阶段：万能的单机，即一台ECS服务器搞定一切。传统官网、论坛等应用，只需要一台ECS。对应的web服务器、数据库、静态文件资源等，都部署到这台ECS上即可。
- 随着访问压力增加，到达架构基础阶段：物理分离web和数据库，这是架构最为基本的分离手段，同时也是最有效的手段。部署在一台服务器上面的web应用及数据库等服务应用，会对服务器的CPU/内存/磁盘/带宽等系统资源进行争抢。显然单机已经出现性能瓶颈，这时候我们将web应用和数据库物理分离单独部署，解决对应性能问题。
- 随着访问压力进一步增加，到达架构动静分离阶段：静态缓存+对象缓存，我们看到前端web服务出现性能瓶颈。大量的web请求被堵塞，同时服务器的CPU、磁盘IO、带宽都有压力。这时候我们一方面将网站图片、js、css、html及应用服务相关的静态资源文件存储在oss中进行集中管理，另外一方面通过CDN将静态资源分布式缓存在各个节点实现“就近访问”。通过将动态请求、静态请求的访问分离（即“动静分离”），有效解决服务器在磁盘IO、带宽方面的访问压力。
- 当访问压力继续增加，到达架构分布式阶段：负载均衡，虽然“动静分离“有效分离了静态请求的压力，但是动态请求的压力已经让服务器”吃不消”。最直观的现象是，前端访问堵塞、延迟、服务器进程增多、cpu100%，并且出现常见502/503/504的错误码。显然单台web服务器已经满足不了需求，这里需要通过负载均衡技术，增加多台web服务器。因此，告别单机的时代，转变分布式架构的阶段。
- 当访问压力持续增加，到达架构数据缓存阶段。数据库缓存，虽然负载均衡结合多台web服务器，解决了动态请求的性能压力。但是这时候我们发现，数据库出现压力瓶颈，常见的现象就是RDS的连接数增加并且堵塞、CPU100%、IOPS飙升。这个时候我们可以通过memcache、redis等数据库缓存技术，有效减少数据库访问压力，进一步提升性能。
- 访问压力继续增加，到达架构扩展阶段。垂直扩展，虽然这个时候我们可以看到通过分布式文件系统OSS，已经解决了文件存储的性能问题，虽然通过CDN已经解决静态资源访问的性能问题。但是当访问压力再次增加，这个时候web服务器和数据库方面依旧是瓶颈。在此我们通过业务拆分、读写分离、分库等垂直扩展技术，进一步切分web服务器和数据库的压力，解决性能问题。
- 最后到达架构扩展阶段：水平扩展，当达到千万级架构以*问量的时候，我们可以看到垂直扩展的架构也已经开始“山穷水尽”。比如，读写分离仅解决读的压力，面对高访问量，数据库在“写”的压力上面“力不从心”，出现性能瓶颈。另外，分库虽然将压力拆分到不同数据库中。但是，单表的数据量达到TB级别以上的时候，显然已经达到传统关系型数据库处理的极限。我们通过增加更多的web服务器、增加更多的SLB、采用分布式缓存、以及引入sharding 和nosql分布式数据库等水平扩展的技术，让架构能够进行水平扩展。满足千万级架构及更高的要求。
到这里，降云十八掌的全部内容已跟大家分享完，希望对大家能有帮助。
想和更多的运维开发者交流，识别下方二维码即可加入钉钉交流群！
演讲嘉宾：乔锐杰，驻云科技运维总监，人送外号“专家”，圈内人称“乔帮主”。阿里云资深架构师/技术专家，阿里云全球MVP获得者，《「阿里云」运维架构最佳实践》作者。
曾担任黑客讲师/Java高级讲师/Python讲师/运维高级讲师/阿里云讲师，从事过安全、研发、高级运维、架构师、运维总监/技术总监等相关职位。国内云端架构与运维实践开拓者，曾主导过电商、金融、*、视频、游戏等领域千万级云端架构，在云端分布式集群架构、云端运维、云端安全等方面有着丰富的实战经验。