mod

极客时间专栏/赵成的运维体系管理课/云计算时代的运维实践/32 | 为什么蘑菇街会选择上云？是被动选择还是主动出击？.md

@@ -0,0 +1,123 @@
+<audio id="audio" title="32 | 为什么蘑菇街会选择上云？是被动选择还是主动出击？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/99/20/99ff16da337673576f40b3d696ae0220.mp3"></audio>
+
+2018年1月22日凌晨，我们美丽联合集团旗下的蘑菇街和美丽说的业务，整体搬迁到腾讯云，完成了从托管IDC模式，到腾讯云上混合云模式的转变。
+
+云计算发展到今天，无论是在技术、服务层面，还是在商业层面都已经相对比较成熟。当前绝大多数初创公司在基础设施上的策略一定是公有云，已经极少再有自建或托管IDC的情况，所以不会存在是否上云这样的纠结。
+
+但是对于蘑菇街这样体量的公司，搬迁上云，就必须要考虑得更全面：考虑基础设施的变化，业务的平稳过度，运维模式的转变，成本管控的调整，以及众多的细节问题。
+
+最近，有很多同行对我们为什么做这个选择比较感兴趣。因为尽管混合云模式是当下的大趋势，但真正面临抉择时，又总会被各种具体的细节问题所困扰，犹豫不决。
+
+今天，我从蘑菇街的视角，结合真实情况，聊一聊我们为什么会做出上云这个选择。
+
+## 我们所面临的问题
+
+**1.成本闲置问题**
+
+对于电商，大促已经常态化，除了“双11”“双12”以及“6·18”这样的例行大促，每个电商还会有自己的营销活动，比如我们就会有“3·21”春季促销，以及每个月不同的主题促销。这一点对于其它电商也是如此。
+
+大促，从技术层面就意味着要在短时间内应对远远超过日常的峰值流量，可能是平时的十几倍，甚至是上百倍。为了支撑这么大的流量，就需要业务系统有足够的容量支持。
+
+虽然我们会从技术和架构层面来提升容量，但是，无论如何优化，充足的硬件资源扩容是前提条件。
+
+之前，我们在应对“双11”这样的大促时，只能采购更多的设备。与此同时，我们还要在机柜成本以及资源上下架等纯人工方面进行投入，这往往要花费几千万元的成本。
+
+但是，每次大促峰值一过，这些设备基本就处于极低的负载状态。这批资源要经过将近一年时间，随着业务量快速增长才能逐步消化掉，然后再进入到下一轮大促的采购周期中。
+
+所以，这部分成本投入的收益是非常低的，基本处于闲置状态。
+
+**2.基础设施维护问题**
+
+选择租用或托管IDC模式，随着业务量增长也会遇到一系列的问题。在我以往的实践操作中，我也遇到了以下几个问题，相信你也有过相似的困扰。
+
+**IDC机房的选址**。在中国互联网八大节点所在城市的IDC资源无疑是最优的，但是这些地方的优质资源却也是最紧张的。通常会被国内各大互联网公司或云计算公司提前占据，所以很难找到相对独立且成规模的机柜区域，而零散的机柜分布对管理和维护工作来说十分不便。
+
+退而求其次，就只能选择二级或三级节点，但是这样一来在网络质量上就降了一个或多个等级。同时，因为没有BGP线路，或者线路质量不高，就需要多线接入，这对业务体验以及管理维护都会带来很大影响。
+
+**IDC机房的扩展问题**。一个机房内的机柜消耗完，想扩展就只能另找机房，但是属于同一运营商，或同一ISP服务商的同城机房资源是否充足，又是一个未知数。
+
+不同机房间是否互联互通，以及是否增加跨地域的时延，对业务访问体验的影响很大。所以扩展性不足，会大大影响业务体验，甚至影响业务发展。
+
+如果是通过第三方ISP接入的，特别是存在多个ISP服务商的时候，在互联互通时，服务商之间的沟通协调非常耗费精力，且不同机房以及多ISP之间的专线成本也会增加。当基础设施达到一定体量，这个问题会非常突出。
+
+如果你也有过这方面的经历，相信你一定深有体会。
+
+**资源利用率问题**。即使我们做了虚拟化，按照业界实际情况，CPU资源使用率一般也就在10%-15%左右。所以要想大幅提升使用率，就是要在离线的混部，也就是类似大数据消耗资源特别高的计算类业务上进行资源调配：比如，在凌晨调度到相对空闲的应用服务器上；而在白天，则将资源释放出来给业务应用。
+
+但是，想要在离线混部技术上做文章，说起来容易做起来难，因为这在实际工作中是需要非常深厚的技术积累和非常高的技术门槛的。
+
+业务层面的调度是一方面，另一方面，底层硬件、网络以及操作系统这些也需要相应的技术支持。这其中具体的复杂情况，你可以通过阿里最近在这方面的一些分享体会一下。
+
+单考虑操作系统之上的应用和业务技术是无法满足要求的，所以，这就需要我们在进行技术规划时，在开始底层建设之前就要考虑全面。
+
+我们知道，国内外超大型的互联网公司，以及各大云计算公司，在硬件选型上都有自己的定制化要求。其中一个重要原因，就是为了尽量保持几万甚至十几万硬件设备的系统架构一致，从底层硬件开始就为后续的超大规模运维做技术准备。
+
+当然，这样的定制化需求，只有在需求量足够大的情况下才会被硬件厂商接受，一般如果只有百台或千台的规模，硬件厂商基本是不会考虑的。
+
+所以这就会牵扯出下面这个问题。
+
+**3.底层技术投入和人才的问题**
+
+通常在互联网领域，越是底层的技术，技术门槛就越高、越复杂，也越离不开高端人才的投入。比如硬件资源虚拟化，就需要有懂内核、懂网络、懂OpenStack、懂分布式存储如Ceph等等的专业人才。
+
+但是真正精通的人却不多，加上要搞定整套解决方案，还需要一个完整的团队，这就难上加难，在团队组建上面临更大的困难。
+
+人才紧缺，就意味着人力成本会很高，这个就是技术投入的隐性成本。而且因为技术门槛高，一旦发生人员流动，那么，对于原有技术平台来说，无人能把控的风险就会更高。这一点往往会是最大的隐性管理成本所在。
+
+当然，在人才招揽上，我们可以加大人力成本投入，招聘最优秀的人才。但是作为像蘑菇街和美丽说这样以更加聚焦于业务，**以业务发展为生命线的公司，我们更期望能够在业务上取得创新和发展，而不是在技术上取得多么非凡的成就（这一点与公司的发展诉求是不一致的）。所以这就从根本上决定了，我们不会无限度地投入，或投入非常大的成本在这些基础技术的研究上**。
+
+对于以技术创业为主的公司，其考量的出发点就完全不同了，这里我们不展开讨论。
+
+进一步讲，论体量和规模，我们自有的底层技术无论如何是无法与专业的云计算公司相比的，这就带来另一个问题：如何为这些优秀人才提供成长和发展？因为既然在体量和规模上比不过，那我们能够提供的个人成长空间和机会，一定也比不过专业云计算公司。这种情况下，大部分人才的去向选择就显而易见了。
+
+对于大数据，分布式中间件等岗位，也会存在类似的情况，因为它们大多需要体量和规模才能体现技术挑战性和成长空间。
+
+**4.小结**
+
+到这里我们做个小结，随着基础设施体量越来越大，我们在基础设施和平台服务层面，将会投入越来越大的财力、人力和最宝贵的精力。
+
+但是这项投入的收益和成效却不明显，且在这个层面的专业性上，我们与云计算平台之间的差距越来越大，脱节也越来越严重。
+
+我们的决策过程就是，以未来3-5年，甚至更长远的视角考量，我们认为上述这些问题一定会成为我们将来业务发展的障碍，因此上云就成了我们的不二选择，并成为公司的战略决策之一。
+
+## 纵观技术发展趋势
+
+**1.从软件架构发展的趋势上看**，从最早期的物理机，到目前主流的虚拟机，再到当前非常火热的Docker，以及可能在未来会成为又一主流的Serverless，我们对于资源层面的依赖越来越少，而这个趋势恰恰是云计算不断发展带来的改变。
+
+<img src="https://static001.geekbang.org/resource/image/f2/00/f2202ade555f5d22846f53fb1ef06800.jpg" alt="" />
+
+同时，像Serverless这样的技术理念，就是在公有云平台上，为了提升资源利用率，而衍生出来的。而且从目前看，Serverless也只有在公有云平台上才有意义。在私有云，或者是自建或托管IDC中，因为资源规模问题，没有看到太多的实践价值。
+
+2017年AWS re:Invent 2017峰会上，AWS共发布了在数据库、容器、人工智能、物联网以及网络等等方面的几十项新的产品技术服务。可以说，**如果想要技术为业务带来更多的可能性，拥抱云计算是最好的选择**。
+
+**2.人工智能对云计算能力的释放**。我们当前的人工智能主要是对机器学习算法的广泛应用，这里的两个前提条件，一个是要有足够大的数据量，另一个就是要有足够充足的计算资源。
+
+我们先看一个2017年的新闻：
+
+> 
+2017年5月份，谷歌宣布麻省理工学院的数学教授安德鲁·V·萨瑟兰使用抢占式虚拟机实例，在220000个GCE核心上运行了庞大的数学工作负载。据称这是迄今为止在公共云上运行的最庞大的高性能计算集群。
+
+
+计算任务阶段性的运行对资源需求是非常庞大的，一般企业很难提前预留足够的资源来做这个事情，这时云的资源优势和弹性能力就凸显出来了。
+
+可以说，**未来人工智能的发展和应用，必然会依托于云计算**。
+
+## 没有银弹
+
+软件工程中，我们一直在讲，没有银弹。前面我们介绍了我们遇到的一些具体问题，以及云计算的优势所在，但是没有银弹这条规律，仍然也适用于云计算行业。
+
+那么，是不是有了云计算，有了公有云，上述我们所说的问题就都不存在了呢？
+
+以公有云为例，它也一样会遇到IDC建设、扩展性以及基础技术投入等等问题，可能也会给我们带来一定的影响。但是对于公有云来说，因为自身财力和人力的优势，面对这样的问题会更容易解决一些，但对于我们可能就是难以逾越的难题了。
+
+同时，公有云虽然解决了很多问题，但是，就目前这个阶段来讲，如果想要获得较高的客户满意度，仍然有很长的路要走，比如不同形态业务的差异化支持和服务问题。
+
+我想，这一点并不是云计算厂商不想做好，因为**无论在技术、产品以及服务上，它们并不是一蹴而就的，而是各方面都需要一个逐步积累、磨合和摸索的过程，这就需要云计算厂商与业务客户共同努力，朝着同一个目标前进，需要彼此多一些耐心。**
+
+我们也期望在国内见到AWS和Netflix这样的最佳组合，相互成就，共同成功。
+
+欢迎你留言与我讨论。
+
+如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
+
+

极客时间专栏/赵成的运维体系管理课/云计算时代的运维实践/33 | 为什么混合云是未来云计算的主流形态？.md

@@ -0,0 +1,107 @@
+<audio id="audio" title="33 | 为什么混合云是未来云计算的主流形态？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/74/ee/74a3d706eaf18f68921a05a4fa83bbee.mp3"></audio>
+
+爆竹声声辞旧岁，今天是大年初一，在此，祝你新春吉祥，阖家幸福！
+
+上期文章我介绍了我们蘑菇街之所以选择上云，是基于怎样的全面考量。今天我们来聊一聊，对于蘑菇街这样有着一定规模体量的产品，我们在不同时期和不同阶段，对云的使用方式是怎样的。
+
+## 关于混合云
+
+对于“混合云”这三个字，你应该不会陌生。但是，“混合云”又是比较宽泛一个概念，随着技术趋势的发展，这个概念的内涵和外延也在不断发生着变化。
+
+从字面上理解，“混合云”即私有云和公有云的混合搭配，这也是最开始对混合云最简单直接的解释。
+
+但是随着公有云服务越来越丰富，我们对公有云的应用也不再仅仅限于资源层面，而更多地体现在云服务层面。所以，不同时期、不同角色、不同团队、不同行业对于混合云的使用和理解可能都会不同。
+
+为了方便理解，我们以CDN为例。
+
+我们使用的CDN服务，其实是云服务最早被应用的典型形态。但是，在早期，更多的是专业CDN厂商提供这类服务，而不是腾讯云和阿里云这样的公有云巨头来提供，同时它跟我们实际接触到的机器资源又有很大的不同。
+
+所以在很长一段时间内，我们并没有意识到这就是云服务。但是，这种使用模式，从云的特性来讲，就是混合云模式，但是不同时期，不同背景的人对它的理解可能就完全不一样。
+
+关于CDN这一块，在后续专栏中，我将会单独撰写文章进行详细介绍。
+
+我们对混合云概念的熟知，更多的还是在公有云服务兴起之后。因为其提供了更加灵活、便捷的资源弹性能力，满足了行业内普遍的弹性需求，被应用到大量的弹性应用场景中，与业务自身所在的IDC机房形成一个整体，就有了混合云模式。
+
+对于当前新兴的创业公司，除部分因政策监管因素无法上云的业务外，基本都会将业务完整地放到公有云上运行。
+
+但是对于类似蘑菇街这样的产品，因为**在公有云蓬勃发展之前就已经建设了自有的技术体系和架构，所以在选择上云的过程中，就需要有个过渡过程，这个过程就是混合云需求存在的应用场景。**
+
+下面我就分享一下，蘑菇街上云过程中的几项基础设施，在过渡阶段以及后续建设上的思路。
+
+## 我们所经历的几个基础设施建设阶段
+
+**第一个阶段，完全托管IDC模式。**我们选择与电信运营商或者第三方ISP合作，租赁其IDC机房中的机柜。而其他主机硬件和网络设备都是我们自行采购，然后放入机房中进行托管。
+
+这种模式我在上篇文章中也介绍过，会随着业务规模体量不断增加而出现一系列问题。
+
+**第二个阶段，资源短期租赁模式。**上期文章中我曾介绍过，因为电商大促的例行化，以及峰值流量的激增，导致我们短时资源需求量庞大。如果再靠一次性采购模式，付出的成本巨大，且后期成本闲置，造成严重的浪费。
+
+我们曾跟运营商或第三方ISP谈过一些短期租赁合作，因为运营商或ISP服务商在机柜资源上相对充裕，通常在它们完全租赁出去之前，也会存在闲置情况。所以如果我们能够向它们短期租赁机柜，这对我们双方都是有益的。
+
+但是，只有机柜没有资源也是没有意义的。所以在资源上，运营商和ISP会利用其广泛的合作渠道优势，帮助我们与其自身，或与第三方达成资源上的短期租赁合作。
+
+这种合作模式，在前两年确实帮我们在资源紧张和成本优化方面，解决了很大的难题。
+
+虽然机柜和硬件资源在形态上还不能称之为云，方式上也不够灵活，但是这种模式起到的作用，很大程度上满足了我们对弹性的需求，所以我们内部戏称这种模式为“人肉云”，或者叫“人工云”。
+
+这种模式令我深有感触，顿时豁然开朗：
+
+**解决问题，有时跳出纯技术思维模式，尝试通过外部合作和沟通的模式，一样可以有很好的解决方案，甚至可以解决在技术层面解决不了的问题。**
+
+**第三个阶段，同城混合云模式。**近些年运营商和ISP服务商也在做自己的公有云体系，所以随着他们服务的不断完善，后来为了能够提升交付效率，我们也会尝试使用他们的公有云业务。
+
+这里我这所以提到同城混合云模式，主要原因是，作为运营商和ISP服务商，他们的云资源可以与我们在同一机房或同城机房。这种模式最大的优势就是可以与我们的IDC网络专线拉通，大大降低网络时延，网络质量相对稳定，同时成本也相对较低。
+
+如果是跨城甚至是跨省，就会频繁发生网络抖动、丢包这些问题。对于时延敏感的服务，是完全满足不了要求的，且微服务间频繁调用产生的大流量带宽需求，成本也是非常巨大的。
+
+所以，这种情况下，虽然公有云的各项产品和服务相对完善，但是如果在对应的城市没有公有云节点，或者距离较远，又或者专线质量不高，就基本没法满足我们规模化使用的场景。
+
+但也不是全部无法满足。后面一篇文章我会介绍通过公有云建设CDN和二级CDN体系的内容，虽然没有专线，但仍然可以满足部分业务场景。
+
+通过上面的内容，你可以看到，同城运营商和ISP服务商在公有云服务方面优势巨大，且这种优势主要体现在地域和网络资源质量上。
+
+我想，运营商的公有云业务在近期有不错的发展，这也是很重要的原因之一。
+
+**第四个阶段，公有云体系内混合云模式。**上篇文章我介绍到，从长远的角度考虑，为了能够更加全面和深入地利用好云计算的产品技术，我们整体搬迁到了腾讯云。
+
+这个阶段初期，我们使用的还是完全独立的物理机资源。这种资源使用模式与之前托管IDC模式相比，除硬件和网络外，操作系统和各项技术栈还完全是由我们自己运维。
+
+之所以这样做，还是为了保证迁移过程的平稳。因为我们自身的技术体系和架构已经非常庞大，也有较高的复杂度。
+
+要想在另外一套基础设施上将这套精密的体系部署、调测、运行起来，同时还要保证各项性能指标以及系统容量不出问题，项目难度就已经非常高了。而这样做可以很好地防止软件架构发生变化，避免各种复杂因素交织在一起所导致的业务稳定性的不可控。
+
+之前我看到有很多人批评，甚至是贬低这种公有云提供独立物理机资源的模式，认为这是换汤不换药，或者认为这是技术含量太低、技术水平不足的表现。但是我认为这种理解还是太片面。
+
+单纯从技术角度来讲，这种模式或许没有体现出公有云的特性，但是从实际业务场景和实际客户需求来讲却是必要的。而且对于类似蘑菇街这样有着大规模业务体量和复杂技术架构的产品来说，它还满足了用户的过度需求。
+
+所以，我认为腾讯云在这一方面还是体现出了“客户第一”的意识的。
+
+当然，搬迁到腾讯云之后，下一个阶段，我们必然会利用更多的云资源和云服务。比如无状态的Web服务或者微服务应用，在大促时完全可以利用云的弹性优势进行快速的资源扩缩容。
+
+但是对于数据库或大数据这样的存储类业务，因为它们本身又是支持业务运行的核心基础设施，所以短期内我们仍然还是采用独占物理机的模式。我们主要基于下面两方面进行考量。
+
+**1.技术架构匹配问题。**以数据库为例，我们自研了分布式数据库中间件和大量的工具，比如对分库分表的支持和数据迁移转换等等。还针对具体的业务场景和特性在数据库和操作系统层面做了大量的优化工作，包括但不限于各类参数的调优，以及部分特性的定制。
+
+再者，云上资源也无法规模化地满足我们对硬件的特定需求，所以我们在这种模式下，就很难一下子将云服务利用起来，而其它的分布式组件也会存在类似问题。
+
+归根结底，这还是云上的技术体系和原有的业务技术体系不匹配的矛盾所导致的，需要二者花更多的时间来磨合。同时，这也决定了在未来很长一段时间内，混合云模式才是最佳实践模式。
+
+**2.数据安全问题。**我认为一些有政策要求或政策限制的业务，需要慎重考虑这个问题。
+
+比如金融行业，或者某些ToB的业务，由于各种竞争或敏感问题，客户本身就不允许你的服务在云上，那么在数据安全问题上需要更全面地考虑，这种情况下如果采用混合云模式就会受到很大限制。
+
+但是，如果没有上面这些问题的困扰，我认为上云是最好的选择。上云前后需要建立起彼此相互之间的信任，同时也可以共同签署信息安全约定，在法律层面进行约束。
+
+**退一万步讲，即使不上云，我们的数据在自己的机房里就一定100%安全吗？**我想这才是需要我们真正考虑的问题。
+
+## 总结
+
+上面我以蘑菇街为例，分析了我们为什么会认为混合云会是未来一段时间内的主流形态，并推测了可能还会出现的其他混合模式，比如多云平台的混合、多云平台服务的混合等等。
+
+不管如何选择和使用，我们一定还是要**以满足业务场景为出发点，脱离了这一点，单纯追求技术深度和复杂度是没有意义的。**
+
+在公有云或混合云应用过程中，你曾遇到过什么问题，或者有什么好的建议，欢迎你留言与我讨论。
+
+感谢我们彼此的坚持与陪伴，新年新征程，在新的一年里，期待与你共同进步，我们下期见！
+
+

极客时间专栏/赵成的运维体系管理课/云计算时代的运维实践/34 | Spring Cloud：面向应用层的云架构解决方案.md

@@ -0,0 +1,89 @@
+<audio id="audio" title="34 | Spring Cloud：面向应用层的云架构解决方案" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/80/0e/806aa4c1f2761e85ff308a779ff3870e.mp3"></audio>
+
+上期文章我们介绍了混合云，以及在实际操作中我们常见的几种混合云模式。今天我们来聊一聊Spring Cloud如何解决应用层的云架构问题。
+
+对于Spring Cloud，你大概不会陌生，它跟Spring生态中的另一个开源项目Spring Boot，基本上已经成为国内绝大多数公司向微服务架构转型时的首选开发框架。
+
+Spring Boot可以支持快速开发单个微服务应用，Spring Cloud则提供一系列的服务治理框架，比如服务注册、服务发现、动态路由、负载均衡以及熔断等等能力，可以将一个个独立的微服务作为一个整体，进行很好的管理和维护。
+
+从业界实际使用情况和反馈来看，由于两者完美的搭配，Spring Cloud和Spring Boot确实是可以通过相对较低的技术成本，让开发人员方便快速地搭建起一套分布式应用系统，从而进行高效的业务开发。
+
+同时，优秀的服务治理能力，也为其后续在稳定性保障工作方面打下了不错的基础。
+
+（注：因为Spring Cloud必须基于Spring Boot框架才能发挥它的治理能力，所以下面我们提到的Spring Cloud是默认包含了Spring Boot框架的。）
+
+所以，通常我们更多地是把Spring Cloud作为微服务应用层面的开发框架，帮助我们提升开发效率。看起来，它貌似跟“云”这个概念没有什么直接关系。
+
+而实际上，在将应用与云平台连接方面，Spring Cloud也发挥着非常核心的作用。这也是为什么本期文章的标题没有直接定义为微服务治理架构，而是面向应用层的云架构。
+
+下面我们具体来看看。
+
+## Spring Cloud框架中云的影子
+
+目前整个Spring生态是由Pivotal这家商业公司在主导，但是Pivotal更大的目标是要为客户提供云上的端到端的解决方案。
+
+所以Pivotal最早提出了Cloud-Native（云原生）的概念，或者说是一种理念，**目的是帮企业提供云上业务端到端的技术解决方案，全面提升软件交付效率，降低运维成本。**简单来说，就是除了业务解决方案和代码，其它事情都可以交给平台处理。
+
+基于这样的理念，Pivotal打造了自己的云原生解决方案PCF（Pivotal Cloud Foundry），包括多云和跨云平台的管理、监控、发布，以及基础的DB、缓存和消息队列等等，一应俱全。
+
+我们可以看到，在PCF整体解决方案中，Spring生态是向用户的业务应用层架构拓展的非常重要的一环，帮助其进行高效的业务开发，并提供后续的稳定性保障。<br />
+<br />
+<img src="https://static001.geekbang.org/resource/image/88/17/880d3bf4d381126a0795b06de279de17.jpg" alt="" />
+
+所以，这个时候，**Spring Cloud除了提供微服务治理能力之外，还成为了微服务应用与云平台上各项基础设施和基础服务之间的纽带，并在其中起到了承上启下的关键作用。**
+
+至此，我们可以得出这样一个判断，也是本篇文章想传递的一个信息：**Spring Cloud不仅仅是微服务治理解决方案，它同时还是面向应用层的云架构解决方案。**
+
+虽然Pivotal最早提出了云原生的理念，也提供了PCF这样的云原生整体商业解决方案，但是从目前业界的实际应用情况来看，Spring Cloud这个局部解决方案的应用更为广泛。
+
+而且从图中我们看到，其与AWS的深度整合，也正反映出当前Spring Cloud在整个业界的影响力和被应用的广泛程度。
+
+插句题外话。早期阿里开源的Dubbo，其实是跟Spring Cloud类似的微服务框架，并且经过阿里大规模的应用实践，可以说是非常优秀的开源项目。早些年国内在选择微服务框架时，Dubbo基本是首选，但是近年来因为开源维护不力，很早停止了版本更新，导致大量的用户流失，促使用户纷纷涌入Spring Cloud阵营。
+
+而Spring Cloud经过近几年的发展，深入了解用户需求和痛点，不断完善改进，早已蜕变成我们所说的应用层的云架构，紧跟整个云计算发展趋势的大潮。
+
+最近Dubbo重启开源维护，与阿里云EDAS产品体系整合，很大原因就是因为在用户技术架构体系里，缺少了Spring Cloud这样的产品，再加上Dubbo原有的一些用户基础，重启维护无论从哪方面看都是值得的。但是需要多久才能重拾用户的信心，就要看Dubbo的后续表现了。
+
+以Spring Cloud为代表的云原生模式也是当前业界的主流模式。虽然它可能以解决应用层面的问题为主，尚未与云平台全面对接整合，不过它所带动起来的云原生的理念却被业界越来越广泛地接受。
+
+同时，随着容器及编排技术的发展和成熟，就出现了另外一个云原生的体系，且活跃程度非常高：它就是以Google为首的CNCF（Cloud Native Computing Foundation）。下面我们一起看一下。
+
+## CNCF
+
+CNCF设想中的云原生分层架构示意图：<br />
+<br />
+<img src="https://static001.geekbang.org/resource/image/9e/b4/9e9ced0a6e757a2349cdc1c090b4d0b4.jpg" alt="" />
+
+CNCF组织成立后，圈中大佬们纷纷加入，比如AWS、微软、思科、Pivotal等等，国内的腾讯云、阿里云和华为也参与其中，可见其影响力有多大。
+
+CNCF的核心项目除了K8S外，还有Goggle的gRPC，Docker的ContainerD，CoreOS的Rkt等重量级开源项目。同时也有与Spring Cloud类似，但更加通用的微服务治理框架，如Linkerd和Envoy，它们被称为Service Mesh（服务网格）。
+
+这些项目的优势在于，它们是与K8S集成和配套的，可以很便捷地应用于K8S生态中。虽然K8S自身也是支持服务发现、负载均衡这些基本的微服务治理的，但是在CNCF中，它显得更加包容与开放，不断吸引业界最佳实践的开源产品加入，共同打造更加开放的生态。下图为CNCF当前的项目。<br />
+<br />
+<img src="https://static001.geekbang.org/resource/image/e0/99/e08aed7839e2d337d2970a8c6739de99.jpg" alt="" />
+
+同时，因为目前K8S已实际上成为业界容器编排方面的标准，且被广泛应用，所以各大云厂商，无论公有云和私有云，都会主动支持K8S在云计算体系中的落地。
+
+因此，我们根本不用担心K8S与云平台上 的资源和各种服务的对接问题，而且它最终也会将应用与云平台很好地连接起来，让开发者能够更加专注于业务开发。至于剩下的工作，则都交由平台去做。
+
+当前，CNCF的各个项目社区非常活跃，以至于我们一提到云原生，就会联想到基于CNCF和K8S的生态体系。虽然Google和CNCF都不是云原生的提出者，但目前看来，它们都是云原生的最佳实践者。
+
+## 可以预见的技术发展趋势
+
+我们可以看到，无论是Spring Cloud、CNCF、云原生、还是K8S等等新技术或理念，究其根本，都是为了能够更快更好地支持业务需求的快速实现。
+
+从云原生的理念中，我们可以看到，跟业务无直接关系且相对通用的技术在不断地被标准化，而且标准化层面越来越高。
+
+从最底层的硬件和网络设备，到上层数据库、缓存、文件存储以及消息队列等等基础组件服务，再到Spring Cloud和Service Mesh这样的应用层面的服务管理和治理能力，都正变得越来越标准和通用。
+
+技术每被标准化一层，原来繁琐低效的工作就少一些，技术标准化的层面越高，技术门槛就会变得越低。我们可以作个大胆的预想：或许未来真的只会有业务解决方案和业务代码。
+
+对于我们技术人来说，未来更多更迫切的能力需求将会是：如何利用好业界已有的丰富的技术产品和平台，在面对更加丰富多样且复杂的业务领域需求时，能够更加专注于寻求业界解决方案，以更好地将业务和技术连接起来。找到适合业务解决方案的技术并落地实现，而不再只是专注于技术层面的造轮子。
+
+对于运维来说，我们同样要了解技术发展趋势。虽然我们不会直接参与具体的业务解决方案和代码的开发，但是，如果架构师是业务架构的设计者，那么我们应该成为技术架构的管理者，从效率、成本、稳定性这几个方面来检验架构是否合理，并为架构朝着更加健康的方向发展保驾护航。这也是运维职能转型和思路转变的一个重要方向。
+
+欢迎你留言与我讨论。
+
+如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
+
+

极客时间专栏/赵成的运维体系管理课/云计算时代的运维实践/35 | 以绝对优势立足：从CDN和云存储来聊聊云生态的崛起.md

@@ -0,0 +1,91 @@
+<audio id="audio" title="35 | 以绝对优势立足：从CDN和云存储来聊聊云生态的崛起" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/a6/c1/a6003e078ab1ae45861b8931d2b8f4c1.mp3"></audio>
+
+前面几期文章我们介绍了混合云模式，以及面向应用层的云架构解决方案的Spring Cloud。接下来，我们就以蘑菇街的两个具体案例，来分享一下基于混合云模式的具体实践。
+
+今天，我们先一起看一下我们最为熟悉的CDN和云存储建设。
+
+## CDN和云存储
+
+我们之前提到，CDN应该算是最早期、最典型的公有云服务，如果我们在业务上用到了CDN服务，其实就已经算是在实践混合云模式了。
+
+蘑菇街作为ToC的电商业务，自然会有大量的图片访问需求，其中尤以商品图片为最。为了保证用户体验，我们的产品在2011年上线之初，就应用了CDN技术，当时我们合作的都是专业的CDN厂商。
+
+当然，大量的图片访问需求会带来大量的图片存储需求，且随着业务高速发展，这个需求量必然会极速增长。
+
+图片的访问需求量往往会以几百万、几千万、几亿到几十亿、上百亿的增长态势呈现。而它所占用的存储空间也会从G扩展到T，到几十T、几百T，再到后来的P级别。
+
+所以，起初我们在业务量不大的时候，还可以把图片存在自己的硬件设备上。再往后可以利用HDFS这样的对象存储技术来实现，CDN回源的请求全部回到我们自己的机房里。
+
+但是再往后，我们在这方面的专业性就不够了。这也是我在[《为什么蘑菇街会选择上云？是被动选择还是主动出击？》](http://time.geekbang.org/column/article/3633)一文中介绍到的：**随着体量的增加，CDN对于专业技术深度的要求就越来越高，技术层面的投入也会越来越大，这个就与我们的业务发展诉求不一致了。**
+
+因为对于蘑菇街来说，我们还是期望能够把更多的人力和物力应用到业务技术层面，而不是一味耗费在专业技术研究上。
+
+在2013年左右，业界开始出现专业的云存储厂商。在专业技术层面要比我们精深很多，而且他们聚拢了一大批业界专业人才，积累了各类海量存储场景的实践经验，所以他们在产品研发和服务支持上也是能够持续深入的。
+
+基于此，我们后来就选择了将海量的图片放到专业性更强的云存储之上。
+
+到这个阶段，我们的图片访问和图片存储就近乎完全依赖外部第三方的服务，同时也形成了CDN回源访问云存储这样的云应用模式。
+
+再往后发展，随着国内两大公有云巨头腾讯云和阿里云相继杀入CDN市场，这对传统的CDN厂商和新兴的云存储业务造成了很大的冲击。但究其主要原因，我认为还是由于云生态的规模优势发挥了作用。
+
+## 云生态的优势
+
+上面讲到，我们使用的CDN是专业的CDN厂商业务，但在当时它们并不提供云存储业务。
+
+同时，专业的云存储厂商固然在存储技术上更擅长，加上它们大多属于创业公司，也没有太多的财力和人力再杀入CDN市场。
+
+所以，这两块紧耦合的业务实际是由两类不同的公司在独立发展。但是，在阿里云和腾讯云这样的公有云巨头进入市场后，就极大地改变了这样一个格局。
+
+因为阿里和腾讯各自都有遍布全球的超大规模的自有业务，在CDN、存储技术以及资源上也有很深厚的积累。当公有云蓬勃发展起来之后，这样的技术和资源积累就可以从内部通过云平台输出给公有云的用户。
+
+那么，阿里云和腾讯云这种公有云模式有哪些优势呢？我们将CDN模式与其对比来看。
+
+**1.技术层面。**CDN模式下，图片上传云存储以及CDN回源云存储，基本都是走公网网络，在国内复杂的网络条件下，传输质量就很难保障。
+
+我记得2015年我来到蘑菇街接手运维的时候，就经常会遇到网站图片展示不出来或者打开特别慢的情况。这就需要找不同的CDN厂商定位一些个例问题，非常耗时且麻烦，令人头痛。
+
+在这种形态下，因为是不同厂商间的协作，所以问题只能在小范围内优化，无法从根本上得到改善。但是，在以阿里云和腾讯云为代表的公有云模式下，这个问题就会迎刃而解。
+
+因为阿里和腾讯这两大巨头各自都有全球规模的业务体量，为了保证自身业务的访问体验，它们一定会在CDN和存储技术的优化、整合上下足工夫，因此更具备自我改进的动力。
+
+尤其是上面我们提到的上传和回源过程，在公有云模式下基本都有专线质量保障。即使没有专线，他们也会不断优化中间的线路质量。
+
+上云后我们最明显的感受，就是上传和回源图片的成功率和速度都有非常大的改善，近一年来，我很少再碰到像图片展示慢这类问题了。
+
+**2.成本层面。**主要包括三块费用：
+
+- CDN带宽费用。用户访问带来的CDN流量费用，由各CDN厂商收取。对于传统CDN厂商，之前价格相对固定和平稳，但是近两年公有云厂商入局后不断降价，在价格上有非常大的竞争优势，这也整体拉低了CDN价格。
+- 回源带宽费用。当CDN无法获取到对应图片时，回源到云存储获取，这部分回源带宽费用由云存储厂商收取。但是在云生态模式下，上面提到，CDN和云存储可以整合到某个公有云内部网络体系内，在这个生态中，这部分费用成本就变得非常低了。
+- 存储空间费用。这一项费用由云存储厂商收取，CDN和公有云这两种模式在这一点上没有太大区别。
+
+还有其他诸如裁图、HTTPS等服务，都分别会有不同的计费方式，但是这块不是主要成本。
+
+说到这里，我们从整体的商务角度看一下：如果一位客户在同一个地方购买的服务和资源越多，那么商务运作和议价空间就会越大，得到的优惠力度也会更大。这就跟我们在同一家商店买的东西越多、折扣越多是一个道理。
+
+但是，如果这些服务和资源都是不同厂商的，那就需要多方面沟通。整个过程耗时耗力，且能够得到的优惠空间也非常有限。
+
+所以，整体来看，云生态在CDN和云存储这个层面，实实在在地帮我们降低了成本。
+
+**3.生态优势，强者越强。**云生态的天然优势在于，云平台上聚集了海量的客户资源，只要进入到这个生态中，一般情况下客户都会首选生态内的产品，而不会再跳出去选择其它独立的产品服务。
+
+甚至即使之前用到了第三方的服务，客户也会逐渐转移回云平台这个生态体系中来。
+
+所以，我们现在可以看到这样一种趋势：**很多独立的技术产品，正在向云生态靠拢，选择跟公有云合作，争取让产品进入到某个云生态中，并提供相应的云上解决方案和技术支持。**
+
+同时，各大巨头也会寻找在某些特定领域，有相当深度的技术产品进行投资，让这些好的产品和解决方案进入到自己的云生态中，以便进一步为云上的客户提供更全面、灵活和多样性的支持。
+
+## 总结
+
+通过CDN和云存储这个案例，我们可以清晰地看到，随着公有云的深入发展，特别是公有云巨头的飞速进步，公有云已经形成了自有的、独特的生态体系。
+
+这不仅仅体现在技术和产品层面，而且可以预见其最终还会形成商业层面的体系闭环。
+
+所以，**利用云计算的优势，拥抱变化，才能够为我们的业务发展和创新带来更多的可能性。**
+
+以上分享的这些内容，是我在近两年的工作中真切经历过的案例和感受，希望能在思路拓展上对你有所帮助。
+
+如果你在这方面有什么好的经验和想法，欢迎你留言与我讨论。
+
+如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
+
+

极客时间专栏/赵成的运维体系管理课/云计算时代的运维实践/36 | 量体裁衣方得最优解：聊聊页面静态化架构和二级CDN建设.md

@@ -0,0 +1,105 @@
+<audio id="audio" title="36 | 量体裁衣方得最优解：聊聊页面静态化架构和二级CDN建设" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/15/98/15b3454544d4686e0642b78f1e776098.mp3"></audio>
+
+上期文章中我们介绍了CDN和云存储的实践，以及云生态的崛起之路，今天，我们继续聊一聊CDN。
+
+我们通常意义上讲的CDN，更多的是针对静态资源类的内容分发网络，最典型的就是电商的各类图片，还有JS和CSS这样的样式文件。通过CDN能够让用户就近访问，提升用户体验。
+
+但是这类文件只是以单纯的资源存在，与业务逻辑没有强关联。所以我们在技术上，可以使用业界通用的CDN和云存储解决方案。
+
+需要注意的是，本文中我们讲到的实践内容，同样是遵从**静态内容，就近访问**这个原则的。
+
+但是，因为其中包含了大量的业务逻辑，这就要求我们在面对不同的场景时，要有跟业务逻辑相关的定制化的解决方案。
+
+下面，我们就一起来看看页面静态化架构和二级CDN建设。
+
+## 静态化架构建设的业务场景
+
+我们仍然回到电商的业务场景中来。对于电商，访问量最大的无疑是商品的详情页，绝大多数用户都要通过浏览商品详情，来决定是否下单。所以单就这一类页面，就占到全站30%+的流量。
+
+那么，商品详情一般由哪些部分组成呢？我们看下面两个截图：
+
+<img src="https://static001.geekbang.org/resource/image/4c/c0/4c327a6e6525eb2f9b09777f419079c0.jpg" alt="" /><br />
+<br />
+<img src="https://static001.geekbang.org/resource/image/6e/5e/6ea58723cbdb099c464c2fefbc0c915e.jpg" alt="" /><br />
+<br />
+以上两张图就是某个商品详情页的主要组成部分。我们可以看到，商品详情大致包括了商品名称、商品描述、产品参数描述、价格、SKU、库存、评价、优惠活动、优惠规则以及同款推荐等等信息。
+
+这里我们仔细观察可以发现，其实对于商品描述类的信息，比如商品名称、商品描述、产品参数描述等等，一般在商品发布之后，就很少再变动，属于静态化的内容。
+
+而优惠活动、优惠规则、价格等等则是可以灵活调整的，库存和评价这类信息也是随时变化，处于不断的更新中。
+
+说到这里，我们会想到，如果能够把静态化的内容提取出来单独存放，业务请求时直接返回，而不用再通过调用应用层接口的方式，去访问缓存或者查询数据库，那访问效率一定是会大幅提升的。
+
+所以，我们在参考和调研了业界的解决方案之后，引入了页面静态化架构。
+
+## 页面静态化架构
+
+静态架构中，我们采用的技术方案是ATS，也就是Apache Traffic Server。
+
+ATS是一个开源产品，本质上跟Nginx、Squid以及Varnish这样的HTTP反向代理是一样的。但是它能对动静态分离的场景提供很好的支持，所以在最初，我们直接引入了这样的开源解决方案。
+
+ATS的架构示意图如下：
+
+<img src="https://static001.geekbang.org/resource/image/0a/78/0a2408b31741ee0db09e2f7483c13878.jpg" alt="" /><br />
+<br />
+关键技术点：
+
+- **动静态分离**。将页面上相对固定的静态信息和随时在变化的动态信息区分出来，静态信息直接在ATS集群获取，动态信息则回源到应用层。通过HTTP请求调用获取，最终通过ATS组装后返回给调用方，从而实现了动静态资源的分离。
+- **动态数据获取**。直接采用ATS的ESI标签模式，用来标记那些动态的被请求的数据。
+- **失效机制**。分为主动失效、被动失效和定时失效。对于静态信息来说，我们也允许它变化，但因为静态信息自身的特性，决定了它不会频繁变化。所以，我们会有一个失效中心，即Purge Center。失效消息通过HTTP的Purge方法发送给ATS，而失效中心则会通过订阅消息系统中特定的Topic，或者MySql中特定的binlong变更，执行失效。
+
+以上就是静态化建设的框架性的解决方案，这个方案在电商大促时往往能够发挥更加突出的作用。下面我就简单说明下。
+
+## 静态化架构在大促场景中的应用
+
+我们还是以业务场景作为切入点来看。以“双11”为例，参与大促的商家和商品，一般会在11月初完成全部报名。届时所有的商品信息都将确认完毕，且直到“双11活动&quot;结束，基本不会再发生大的变化。
+
+它跟平时的不同之处在于，商品在大促期间是相对固定的，所以就可以将商品的静态化信息提前预热到ATS集群中，大大提升静态化的命中率。
+
+同时，价格、优惠、库存这些动态信息在日常是会经常变化的，但是在大促阶段是必须固定的。即使有变化，也只能体现在最终的订购阶段，而在用户浏览阶段尽量保持不变。
+
+所以，这时可做静态化处理的内容就会更多。换言之，静态化架构对于后端的访问请求就会进一步减少，特别是价格、优惠和库存这样的查询计算类请求。
+
+同时，我们静态化页面的范围可以更广，不仅仅是详情页，还可以包括各类大促活动的页面、秒杀页面、会场页面，甚至是首页。
+
+因为这些页面都是提前配置好再发布的，所以我们完全可以通过静态化解决方案，来分担更大的流量。
+
+以详情页为例。在静态化方案全面铺开推广后，静态化内容在大促阶段的命中率为95%，RT时延从原来完全动态获取的200ms，降低到50ms。这大大提升了用户体验，同时也大幅提升了整体系统容量。
+
+静态化方案和应用场景我们就介绍到这里。你可能会问：既然是静态化的内容，那是不是仍然可以借鉴CDN的思路，让用户就近访问呢？
+
+我们下面就介绍一下页面静态化与公有云相结合的方案：二级CDN建设。
+
+## 二级CDN建设
+
+上面我们提到的静态化方案，仅仅是我们自己中心机房的建设方案，也就是说，所有的用户请求还是都要回到中心机房中。
+
+静态化方案提升的是后端的访问体验，但是用户到机房的这段距离的体验并没有改善。
+
+从静态化的角度，这些内容我们完全可以分散到更多的地域节点上，让它们离用户更近，从而真正解决从用户起点到机房终点的距离问题。
+
+所以，我们接下来的方案就是：选择公有云节点，进行静态化与公有云相结合的方案，也就是我们的二级CDN方案。简单示意如下：
+
+<img src="https://static001.geekbang.org/resource/image/ee/76/ee0ca7f26d73f407a0ebb3bb55284076.jpg" alt="" /><br />
+<br />
+引入了这样的二级CDN架构后，下面几个技术点需要我们多加关注。
+
+- **回源线路，公网回源转变为专线回源**。之前我们的中心机房还是托管IDC模式时，动态回源部分都是通过公网回源，同时，静态化配置的推送也是通过公网推送到公有云节点，这对成功率和访问质量上都会有一些影响。但是我们上云之后，做的第一件事情就是将公网访问模式调整成了内网调用模式，也就是动态回源直接改为专线的动态回源。这样大大提升了访问质量，且进一步节省了部分带宽费用。
+- **弹性伸缩**。利用了公有云节点之后，在大促时就可以很方便地进行动态扩缩容，以便真正地按需使用。而且自动化的扩缩容，以及日常的静态化配置推送都需要完善。
+- **高可用保障**。为了保障多节点的高可用，在单个节点故障时，要能够快速切换。当前我们的策略仍然是，当某个节点遭遇故障，直接全部切换回中心节点。这里为了能够达到快速切换的目的，需要通过HttpDNS这样切换IP的方式实现。因为DNS缓存生效周期较长，如果是通过域名切换，则造成的影响周期会比较长。
+
+## 总结
+
+今天分享的页面静态化架构方案和二级CDN方案，是我在实际工作中较早跟公有云方案相结合的实践之一，并且在我们的日常和大促活动中，起到了非常好的效果。
+
+同时也可以看到，我们的业务一旦与公有云相结合，云生态的各种优势就会马上体现出来。但是无论选择哪种方案，都要结合具体的业务场景，才能作出最优的方案选择。
+
+公有云也好，云计算也好，都不能为我们提供完美的定制解决方案。正所谓具体问题具体分析，找出问题，优化解决路径，量体裁衣，才能得到最适合我们的“定制方案”。
+
+正如我之前提到的：只有挖掘出对业务有价值的东西，我们的技术才会有创新，才会有生命力。
+
+如果你在这方面有好的实践经验和想法，欢迎你留言与我讨论。
+
+如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
+
+

极客时间专栏/赵成的运维体系管理课/云计算时代的运维实践/37 | 云计算时代，我们所说的弹性伸缩，弹的到底是什么？.md

@@ -0,0 +1,49 @@
+<audio id="audio" title="37 | 云计算时代，我们所说的弹性伸缩，弹的到底是什么？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/16/c3/166fb686c2565e2c2be661b056c077c3.mp3"></audio>
+
+现在，我们经常听到的一些高大上的词汇，比如弹性伸缩、水平扩展和自动化扩缩容等等，你能否说一说，这些技术手段的主体是谁，也就是谁的水平扩展？弹性伸缩的是什么？同时，这些名词之间又有什么关系呢？
+
+下面我们就从弹性伸缩入手一起来分析讨论。
+
+## 弹性伸缩的主体是谁？
+
+弹性伸缩，一说到这个词，我们可能很自然地会联想到资源的弹性伸缩，服务器的弹性伸缩，容量的弹性伸缩，应用的弹性伸缩以及业务的弹性伸缩等等。我想这些理解都没有错误，但是可以发现，当弹性伸缩这个动词前面增加了这么多不同的主语之后，我们一下子就不知道到底该做什么了。
+
+其实有这样的困惑很正常。我们在讲标准化的时候就提到，**做运维和做架构的思路是相通的，我们碰到问题后，一定要找到问题的主体是什么，通过问题找主体，通过主体的特性制定问题的解决方案**。
+
+**对于运维，一定要准确识别出日常运维过程中不同的运维对象，然后再进一步去分析这个对象所对应的运维场景是什么，进而才是针对运维场景的分解和开发。**
+
+这里可以看到，弹性伸缩其实是一个运维场景，但是我们并没有定义这个场景的主体是谁，所以就会出现上面这些不同的主体。我们来假设以下几种主体。
+
+- **服务器的弹性伸缩**。针对这个场景，假设业务是运行在私有云或公有云上，那我们只要能够通过云平台的API申请和释放资源，申请时初始化我们的操作系统，释放时销毁资源就可以。不过，在私有云环境下，为了能够保障弹性，我们必须自己提前采购、上架、装机、配置然后交付资源，需要大量的准备工作，公有云上就可以省去这些步骤，可以即拿即用。
+- **应用的弹性伸缩**。这个场景下其实是默认包含第一步的，就是我们首先必须要拿到应用运行的服务器资源才可以，这一步做到了，下面就是应用的部署、启动以及服务上线接入流量。
+- **业务的弹性伸缩**。我们可以再进一步思考，通常一个业务可能会包括多个应用，所以为了保障整个业务容量充足，这个时候扩容单个的应用是没有意义的，所以这时要做的就是扩容多个应用，但是这里面就会有一个顺序问题，先扩哪个，后扩哪个，哪些又是可以同时扩容而不会影响业务正常运行的，再进一步，业务承载的服务能力提升了，那网络带宽、缓存、DB等等这些基础设施需不需要也同时扩容呢？
+
+到这里，这个问题就已经变得非常复杂了，而且已经不仅仅是弹性伸缩这个词的表面含义所能覆盖的了，因为这个问题确实很复杂，所以这里暂时不做详述。
+
+好了，分析到这里，我们就可以看到针对不同的运维对象，弹性伸缩这个概念背后的含义是不一样的，所执行的动作以及制定的方案也是不一样的。通过上面的分析过程，我们在日常思考和工作开展中应该注意以下两点。
+
+**第一，一定是从实际问题出发，找到问题的主体，然后才是针对问题的解决方案**。要反复问自己和团队，我们解决的问题是什么？解决的是谁的问题？切记，一定不要拿着解决方案来找问题，甚至是制造问题。
+
+比如弹性伸缩这个概念，它就是解决方案，而不是问题本身，问题应该是：业务服务能力不足时，如何快速扩容？业务服务能力冗余时，如何释放资源，节省成本？按照这个思路来，我们自然就提炼出业务服务能力这个主体，面对的场景是快速的扩缩容，然后针对场景进一步细化和分解。
+
+**第二，如果问题处于初期，且是发散状态时，主体可能表现出很多个，这时我们一定要找到最本质的那一个，往往这个主体所涉及的运维场景就包括了其它主体的场景**。
+
+比如上面我们看到的业务的弹性伸缩，就包含了应用和服务器的弹性伸缩场景，它们只不过是子场景而已。从这个角度出发，我们的思路才能打开，方案才会全面。不然如果只是聚焦在服务器、应用、DB、网络等等这些非本质的主体上，提供出来的解决方案肯定也是片面的，而且经常会出现这样的情况，每个人都只从自己的角度出发说问题，始终无法达成一致。问题的根本还是我们没有一个共同讨论的基础，结果就是工作没少做，却始终没有解决问题。
+
+## 弹性伸缩、水平扩展和自动化扩缩容，它们之间的关系是什么？
+
+这个问题，我想已经不言自明了，找到它们的主体和要解决的问题，我们就会发现，其实它们之间的含义是一样的。
+
+## 总结
+
+今天我们以弹性伸缩为例，讨论了如何思考问题和分析问题。我们的讨论和分析归结到一点就是：**独立思考和分析的能力很重要，意识也很重要，切忌不可人云亦云随大流，反而迷失了工作的方向**。
+
+现在业界各种技术上的Buzzword（时髦词）层出不穷，让人目不暇接，但是仔细观察和思考，你会发现它们背后常常隐藏着很多共性的特点，一定要抓住它们背后所要解决的问题和本质，这样也就不会乱花渐欲迷人眼了。
+
+而且通过这样的分析，我们会更容易发现工作中还需完善的地方，从而引导我们聚焦到实际问题中来，而不是浮于表面，把一些高大上的词汇挂在嘴边，却不见效果。
+
+关于今天我们讨论的主题，你还有哪些想法和心得，欢迎你留言与我讨论。
+
+如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
+
+