本文将阿里云运维实践汇总为十八招，从云时代下的资源自动化管理，到静态、动态缓存提升网站性能的方法，再到混合云架构、互联网监控解决方案，以及Devops和云安全实践等，都是比较经典的一些干货，让大家了解阿里云最热门的运维架构技术实践。
直播视频回放，戳这里
想和更多的运维开发者交流，识别下方二维码即可加入钉钉交流群！
大家都知道乔峰有降龙十八掌，而这位乔帮主也有一套在云端运维技术的实践秘籍——“降云十八掌”。接下来让我们跟帮主一起来了解下这套运维神功吧！
以下是精彩内容整理：
为什么叫降云十八掌？
本文分享的核心内容主要出自我的一本书籍《「阿里云」运维架构最佳实践》，书籍包括四大篇：云端选型篇、云端实践篇、云端安全篇、以及云端架构篇，总共十八个章节，所以我更喜欢把书的内容称为云端实践秘籍：“降云十八掌”。
书籍的内容总共有四五十万字，三百幅运维架构图。其中囊括了我历时八年、累积的千家一线互联网企业在云端实践的干货以及经验，包含了云端二十余款热门产品实践、五十余项常见开源热门技术实践，以及云端最热门的：监控、DevOps/容器、智能运维等技术实践。
这本书预计在2019年下半年上架对外售卖，大家感兴趣的可以参考借鉴一下。
以下主要内容摘选自《「阿里云」运维架构最佳实践》十八个章节中的精华内容，汇总成为十八招，都是我认为比较经典的一些干货及案例，希望通过本文让大家了解阿里云最热门的运维架构技术实践及最新技术趋势。
第一招：云对技术架构的变革
第一招：云对技术架构的变革。对于这一招，我想了一个比较高大上的名字叫风起云涌。随着云计算的普及，未来对IT资源的需求都会通过云平台获取。那云对技术架构方面又有什么影响及变革呢？我们先来看看如图所示IT三大体系发展方面：
1、物理机体系阶段：传统IOE的架构其实是物理机的典型代表。对计算资源的使用需要我们去购买或者租用对应的硬件。
2、云计算体系阶段：然后到云计算体系阶段，基于传统硬件服务器基础上，通过虚拟化及分布式技术形成对应的云资源平台。对计算资源的使用，我们如同使用水和电一样，在云资源平台上按需所取即可，而我们不用再关注以及和底层物理硬件打交道。
3、容器体系阶段：最后到达容器体系阶段，我们既不用关注底层物理硬件，也不用关注云平台用的是亚马逊还是阿里云，我们业务都能无缝过渡及运行。从而让我们对计算资源的使用，脱离硬件甚至各个云平台的依赖。容器就是大家熟知的docker技术，有点类似Java的jvm，可以跨平台部署，不依赖底层环境，不管是硬件环境还是云平台等等。
那么，这三大IT体系在IT技术架构方面又有什么样的变化呢？（上图中的箭头方向就是我们技术架构演变进化的方向）
在物理机体系中经历了以下两个阶段:
（1）、单机架构的阶段：IOE架构（IBM的小型机+Oracle+EMC存储）是单机架构中典型的代表，都是高配性能的计算资源。在这个阶段的架构，业务基本都是单机部署。有时候数据库和业务代码甚至都部署在一台高配机器上，完全要靠单机的硬件性能来支持更多业务访问。
（2）、集群架构的阶段：集群架构阶段其实是单机架构的演变。集群架构典型的技术特点就是一般采用虚拟VIP技术（如Keeplived、Hearbeat）解决单点故障的问题，让架构高可用。
然后到云计算体系，云计算的普及其实也是分布式架构的普及，分布式架构下最重要的特点就是不管是业务代码还是数据库，都是通过多台服务器分布式的部署。业务压力增加时，我们增加对应的服务器资源即可。在云计算阶段，分布式的架构特别适合用云平台部署，对服务器单机的性能要求依赖不高，主要通过大量的云资源进行分布式快速部署，来满足业务发展和迭代。值得注意的是，分布式架构是集群架构的演变，有很多人把集群架构和分布式架构混为一谈，这是很大的误区。集群的虚拟VIP技术只能让一台服务器平时作为Backup热备，只有在故障的时候，才会切换到backup上让其顶上，平时都是空闲状态。而分布式架构的技术特点就是负载均衡，均衡的引入，让不同服务器来同时处理业务压力。
最后到达了容器体系下的微服务架构阶段，其实本质也是分布式架构。微服务其实是业务功能层面的一种切分，切分成单个小型的独立业务功能的微服务。多个微服务通过API Gateway提供统一服务入口，让微服务对前台透明，而每个微服务也可以通过分布式架构进行部署，这提高了我们研发的灵活性，也为业务后期迭代带来了极大的扩展性，这是我们未来软件技术架构的主流。并且微服务在云平台基础上结合Docker容器技术进行部署，能让业务、运维、架构在技术和非技术方面的稳定性、成本、效率、扩展等都达到完美。
第二招 云的优势在于分布式
云在前期发展的时候，我遇到很多客户吐槽云主机性能不如硬件服务器？那时候我们经常做的比较多的一件事情就是通过大量压测工具等，去证明其实云主机性能也并不是那么弱，让客户不用那么担心。过度的去纠结云主机的性能不如硬件服务器，如今想起这些证明及测试，在我看来意义并不是很大。
首先，云主机分为共享型、独享型，不管共享型还是独享型，都是将cpu分配给不同instance，即一台硬件服务器上肯定是会虚拟化多台云主机的（主要为了资源利用）。
再加上传统硬件服务器的多核、高频、及类似IBM小机（比如256G内存）等的恐怖高配，在性能上肯定是硬件服务器有优势。
那云的本质优势又是什么？下面通过一个分布式经典架构1+1>2的经典案例进行说明。
一台4核8G配置的主机部署着一个分布式业务，如传统电商系统。我们用单台部署，和用分布式架构思路部署，即拆分成两台2核4G配置的主机，会有什么不一样？
我们来详细看看如图所示对比的区别：
- 在成本方面，单机部署要402元，两台部署价格也差不多；
- 在性能方面，差距就开始出现差距了，带宽方面，云主机仅有200Mbps，而两台部署通过SLB对外访问，带宽有1Gbps。磁盘方面，单机部署默认40G云盘，而两台部署就是两块默认40G系统盘，就是2倍的IO性能。所以在早前还未推出SSD云盘时，那时候IO很低，为了满足业务对IO的需求，相比单机高配部署，通过分布式架构拆分成多台低配机器部署，就能获取成倍的IO性能，这招对提升IO性能非常管用；
- 安全性方面：单机部署直接暴露源ip，被黑客直接攻击源站。而两台分布式部署，隐藏后端ip避免被扫描、被直接打，甚至SLB是基于LVS，由于直接改了LVS的源码，具有一定的抗攻击功能；
- 扩展性方面：单机部署只能升级服务器配置来垂直扩展，而两台分布式部署，不仅能垂直扩展，而且只需要往SLB后面增加更多ECS就可以进行水平扩展。
稳定性方面：单机部署肯定存在单点故障，而两台分布式部署是没有单点问题的。
- 管理维护方面：通过分布式部署的唯一缺点就是在管理维护上会变复杂。不过通过ansible等自动化运维工具，这对运维来说也没多大问题。
所以，拥抱云计算，其实也是拥抱分布式，如若业务不适合用分布式架构，其实发挥不了云计算的核心优势。
第三招 云时代下的资源自动化管理
云除了分布式特点外，还有个运维架构特点，就是按量付费即按需所取。这便是降云十八掌的第三招：云时代下的资源自动化管理。其本质在于我们能通过代码控制资源的管理，这对我们以前IDC人工流程管理资源是不敢想象的。
比如图中，我们通过Python脚本，在shell命令窗口，通过参数设置服务器配置、带宽大小、登录密码，然后能快速创建出来一台服务器。接下来通过一个案例，进一步说明何为云时代下的资源自动化管理。
很多人都用过小米手机，当初红米秒杀活动便是在阿里云上做的。红米秒杀活动期间，瞬间开两百台ECS，使用两小时花费仅600元。我们在活动前，提前搭建好环境，制作好镜像，活动期间通过api秒开200台服务器，然后挂载SLB后面应付活动压力。活动结束，通过api秒释放资源。我们可以看到云时代下资源自动化管理变得更加方便、快捷、甚至更加智能。
第四招 云服务器配置模型
说到资源自动化管理，接下来我们看看服务器配置怎么来做。降云十八掌的第四招叫云服务器配置模型。
先跟大家说一下云端服务器配置选型最经典的失败案例，我曾见过一个客户使用16核64的服务器部署一个tomcat，这里要注意的是，只是一个tomcat，导致一台高配服务器资源使用严重过剩。虽然云解决了IDC硬件资源的利用、管理等问题。但是还未解决大家对服务器配置选择、甚至云产品规格型号的使用问题。资源过剩一直是IT管理中最大的问题。通过统计我们发现，80%的企业服务器的性能使用率仅在20%左右，这便是经典的资源利用82原则。
那究竟云端配置使用有什么窍门？
常见的服务器配置：不管2核4G、4核8G、8核16G、16核64G等等，我们发现一个规律，就是CPU与内存资源配比都会围绕1：1、1：2、1：4、1：8展开。大家应该没见过3核4G、4核5G的服务器配置吧。
那具体什么配置适合什么业务？
我们先来看看CPU与内存资源配比为1:1 ，适用于个人网站、官网等小型网站部署。一般在低配机器中，如1核1G，2核2G，基本上在云端实践中，我们也很少看到过用4核4G、8核8G、16核16G的ECS来运维部署。
然后CPU与内存资源1：2的配比，我称之为黄金配比，可以获得最优计算资源性价比。不管是线下IDC的物理服务器，还是云端ECS服务器的配置，1：2都为黄金比例。比如，2核4G、4核8G、8核16G、16核32G等，这都是我们实践中的黄金比例配置。1：2的配比适用绝大部分业务场景部署，尤其需要高计算资源消耗。不过在云端应用配置最多的实属当为8核16G，这也是云上服务器黄金比例配置中的最佳实践。web应用类特别适用1：2的配比，对CPU、内存都需要最优的计算资源。对于前面说的那个失败案例，Tomcat部署适用用中低配：2核4G、4核8G，特别是4核8G是最优选择。因为tomcat是单进程多线程的模式，是个轻量级且并发请求数最多只能跑到一千左右。所以单台tomcat高配的服务器并不能跑满服务器的性能，造成很大资源浪费。如果想跑满中高配服务器性能，我们常规做法就是在一台服务器上部署多台tomcat。
接下来是1：4的配比，比如2核8G、4核16G、8核32G。这类配比的配置偏向内存，特别适合部署数据库类的应用。为什么这么说？我们知道数据库对服务器性能的需求首先是IO，因为数据库是个存储类应用，涉及数据持久化，所以IO性能的要求是最高的。其次才是内存，因为高内存能有效提升数据库的缓存性能。特别是MongoDB基于内存映射，大内存配置能有效发挥出MongoDB的性能特点。最后，数据库其实对CPU的要求并不是那么高。所以偏向内存的配比配置，特别适用部署数据库类的应用。
最后是1:8的配比，比如2核16G、4核32G、8核64G，这类是高内存资源占比。尤其适用于数据库类中的内存型应用，比如redis、memcache的部署。
下面介绍一个经典案例：单个 python、squid、redis 部署在一台8核16G的服务器中？
python、squid、redis都是单进程，对多核利用不好，8核CPU这会造成性能很大的剩余。当然，如果想对多核的性能资源利用好的话，可以跟tomcat一样，在一台机器上部署多个python、squid、redis进程实例。
第五招 带宽配置估算模型
相比服务器配置，带宽配置的选择更让人抓耳挠腮。一个网站，我究竟选择怎么样的带宽配置？在云端带宽配置选择的经典失败案例中，让我印象深刻的是某一线知名大牌明星做的一个母婴用品电商平台。当初是我负责云上技术指导，我看到他们开发开了二十台8核16G 20Mbps固定带宽（一个月四五千）来跑Java应用，这是一个对带宽配置使用没有概念的极端例子。
那在云端怎么跟应用估算带宽配置？这便是降云十八掌第五招——带宽配置估算模型
配置估算的参考是依靠我们业务访问的规律：一天中有80%的请求发生在一天的40%的时间内。即用户请求访问量主要集中在白天，晚上业务请求量少，这是业务访问的一个特点，即一天的40%时间即9.6小时。那我们带宽配置估算，就可以用总请求量（80%*总PV量）除以这些总请求量所花的时间，得到每秒的请求总量，然后乘以单次请求的数据大小，便得到带宽配置。
举例某网站一天的访问量100万pv总量，假设平均页面大小20KB（实际大小，大家根据自己业务的特点来估算）。所以100万PV带宽配置为(80%100万)/(246060（一天的秒数）40%) 20KB/s = 23.1个请求/秒 20KB/s 最后折算成带宽即：3.5Mbps。
以上计算只是一个平均值，考虑请求压力的峰值波动，加上2倍或者3倍峰值，带宽配置变成7Mbps、11Mbps，所以建议用10Mbps带宽配置。同样，500万pv的业务估算带宽，跟100万pv的估算差不多，这里就不再过多介绍。
第六招 企业级负载均衡架构实践
前面也说过拥抱云计算，其实就是拥抱分布式，而分布式架构的核心就是负载均衡的引入。
互联网企业负载均衡架构流程，即用户请求，一般是先流入四层负载均衡，再流入七层负载均衡，最后请求才会流转到业务应用层。所以在互联网企业负载均衡架构实践中，我们前端一般都是硬件负载均衡或者LVS抗流量、抗并发，然后流转到后端nginx上做七层负载均衡的控制，最终流入到tomcat或者php中做业务处理。
在云端负载均衡中小型架构实践中，我们前端直接用七层SLB做虚拟主机等功能控制，证书也放在前端，直接转到后端ECS部署的tomcat及php上。而云端负载均衡中大型架构实践中，前端入口不能再用七层SLB，七层SLB性能峰值也就五万QPS，很容易被高并发打垮。所以我们前面用四层SLB来抗并发流量。然后转到后端ECS，在ECS上部署Nginx或者Apache做七层虚拟主机、rewrite等控制，最终请求才流转至tomcat或php中。值得注意的是，这时候证书放在后端ECS中的nginx上配置。通过实践我们发现，高并发场景下，七层SLB挂证书会影响10%-20%的性能。
接下来我们来看看负载均衡两个非常经典的案例，也就是降云十八掌的第七招、第八招。
第七招 通过反向代理+VPN提速跨国际网络访问
跨国际网络访问延时，一直是网络架构中的疑难杂症。比如上图中的架构，是我们一个真实的客户案例，客户在德国节点、美东节点部署了驻云的CSOS云安全审计系统，由于是跨国际网络，我们直接SSH登录这台CSOS的云主机，卡的不行。而CSOS这台主机也要跟我们部署在杭州节点的CSOS server通信，经常也是连不上杭州CSOS server。那怎么解决这个延时问题呢？
我们知道国内到香港地域的服务器延时非常低，也基本不丢包，而香港地域到德国、美东地域直接走的海外线路，延时丢包也很低。这便是我们的技术突破口。
解决办法（如图架构图），开通一台香港ECS作为代理。先SSH到香港这台机器，然后从这台机器再SSH目标服务器。这台机器做了一个类似跳板机的功能，解决了我们SSH延时的问题。然后通过VPN链路路由配置，德国、美东请求国内杭州的请求，强制通过香港代理走，这便解决了CSOS 连接国内网络延时的问题。
第八招 通过反向代理跳过国内域名备案政策
接下来给大家分享更为经典的一个案例，怎么通过负载均衡跳转国内域名备案政策。在此我要申明一下，这个分享完全是从技术原理层面的探讨，切勿用于非法目的。国内域名备案，需要遵守对应的法律法规，正常走备案政策。
我们先来看看域名备案判断依据是什么：
供应商取用户访问地址中七层http请求头的域名地址，然后跟地址库中的域名做比对，确认是否备案，如若未备案，则访问跳转上图的备案错误提示。所以突破口就在“供应商取用户访问地址中七层http请求头的域名地址”，如若我们能改掉http请求头的域名地址，原则上就能跳过域名备案的侦查了。
具体流程如下：
首先我们需要开通一台香港服务器。因为香港属于海外，部署网站不需要域名备案，不受大陆域名备案政策约束；其次，我们安装nginx，修改七层http头中包含域名的头信息为ip地址；最后，域名解析到香港这台服务器上。我们便能看到通过反向代理可以域名访问网站了，只不过请求先到香港，再流转到国内，对网站访问性能有一定损耗。
第九招 使用静态缓存提升网站性能的四种方法
接下来我们聊聊如何使用静态缓存提升网站性能，静态缓存就是js、css、html、图片等静态网站资源缓存，提升用户访问性能的一种技术，是牺牲数据访问时效性，换取性能的一种非常常见的技术手段。我们在静态缓存中有四种方法能提升网站性能，这便是降云十八掌中的第九招。
- 第一种方法：浏览器缓存，在nginx中看到这样的配置设置expires，并不是指把静态内容缓存在nginx中，而是设置客户端浏览器缓存的时间，这也是很多人误区所在。
- 第二种方法：磁盘缓存，比如通过nginx的proxy_cache模块，将静态访问请求的结果存放至磁盘中，后面用户的请求直接拿磁盘的缓存结果给到用户，提升用户请求响应速度。比如图中配置参数，设置了缓存空间、缓存目录、需要请求缓存的文件类型等。
- 第三种方法就是内存缓存，磁盘缓存是把请求静态资源缓存至磁盘中，内存缓存就是把请求静态资源缓存至内存中，用户请求访问性能会进一步提升。
- 最后一种方法就是CDN，CDN被誉为互联网高速公路最后一公里。其实结合DNS调度技术，加上磁盘缓存、内存缓存技术，让用户请求就近访问距离用户地域较近的缓存节点上的数据。所以CDN也是云端静态缓存的最佳实践。