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