混合云是目前满足企业运营成本、性能指标、数据安全、风险管控等需求的折中方案。基于混合云架构的云平台设计相对于传统的云计算需要考虑更多的内容，在架构设计上也更加的复杂。 本次演讲就针对这个内容着重介绍由公私有云构成的混合云架构设计、多虚拟化平台构成的混合云架构设计以及混合云架构下云应用性能监控的设计思路及实践。

以下为演讲实录：
左坚：谢谢大家，来到这个会场很高兴，其实今天再次来到这个会场才知道去年是首届，去年参加了这个会议，今年又来跟大家做分享。其实身份不是特别一样，去年来的时候还在负责运维，用马老师的话还是很苦的阶段，今年主要负责研发。我刚才听马老师的分享还有各位的提问，其实跟我今天要讲的内容比较契合，我们到底在企业上云这件事情上应该怎样去做，到底是自建云还是用公有云，还是自建和公有云混合。并且在用户的角度怎么看待混合云，运营商又怎么看待混合云，用户怎样选择，应用怎样处理，这是我今天要分享的内容。
首先大家可能有一个疑问，这个话题AWS可以讲，青云、七牛也可以，国美为什么讲?因为国美已经成立了30周年，有30万的员工，国美在全国有1700家门店。所以今天我们就要说的是国美集团的信息化是如何建设的。
第一，一个能够支撑30万人、1700家门店零售业务的平台背后是一个怎样的业务系统?它的业务系统是怎样去构建的。
第二，国美已经不是以前的国美，所涉及到的业务有金融、保理、小额贷，这些金融业务对于实时性和可用性的要求是非常高的，那么国美是怎么解决的。

首先这张图太简单了，云计算会像水、电一样服务每个人的生活，我们今天都认为水电很简单，拧开龙头就有水，接上电闸就有电，背后真的有这么简单么?一个链路传到家里面，怎么保证家里的电压是220伏，如何算出来链路的损耗有多少。其实看起来简单的事情如果往后面去说的话，一样是非常不简单的。包括水也一样，各位用水的时候有没有考虑到，在冲马桶的时候用的是中水，做饭洗菜的时候是自来水，烧水的时候用的是过滤之后的水，这就是针对不同的业务用途所使用到了不同的产品和不同的成本。在这种场景下，当我们为一个业务去选择所运营的平台的时候也一样会遇到这个问题，到底用私有云还是公有云，还是要用混合云，在什么场景下会用到什么样的平台。
一、私有云

首先我们来看到底什么是私有云，私有云有没有它的问题。国美也是自己建的私有云，国美有一个不成文的要求，叫做数据不允许离开国美。也就是必须在内部来使用。大家看PPT上，除了国美的logo之外还有云服务的logo，国美做云服务的公司就是国美云服，我代表云服务站在这里，我既是用户，又是服务商，既是甲方又是乙方。所以在建私有云的时候，我们也走了很多的坑。
我们采用过商用产品，也用过自研的产品。大家建私有云的时候有四点是必须要考虑的，尤其是最后一点的可行性：第一你要考虑到成本的投入;第二你要考虑到团队人员的技术能力;第三要考虑到所采用的产品是商用产品还是开源产品，能否驾驭这些产品;第四，在可行性论证都没有问题之后，再考虑可扩展性、可管理性，还有可用性。
二、公有云

那么中小企业是不是就要采用公有云呢?或者说采用哪家公有云?在采用公有云的时候大家要评估以下四点：
l 应用架构设计复杂，过于依赖服务商提供的功能。一旦应用上了云，它运行的情况根本不在我的控制下，它运行的好不好，到底是程序开发的好不好，还是说公有云给我的服务好不好，这个无从得知。
l 程序的可控性差，很多公有云都是上云容易下云难，上去的时候厂商的销售跟你说得很好，可以很方便的连接、数据拷出。但是当你选择离开云的时候，或者有安全管控需求的时候，就发现公有云的厂商很难细致的达到用户真正的要求。
l 故障定位困难，真出问题的时候到底是应用问题、网络问题还是云的问题，还是运维的问题，问题很难定位。
l 数据安全无法得到有效保障。
三、混合云

私有云和公有云都有什么优势呢?私有云所有东西都在自己的控制之内;公有云初期成本很低，可以立刻把我的业务部署起来，不用投入大量的人力物力成本，只要关注业务本身就可以了。但是现在的市场环境，只有在公、私有云结合的时候才真的能满足业务需求，所以国美内部也是公私有云混合的，只不过这个公有云仍然是国美自建的。所以对于国美来说私有云是私有云，国美对外也提供公有云，国美内部的企业也是使用了私有云和公有云，只不过他所使用的公有云是由国美自建的。因此公有云可以有效降低企业运营成本，私有云可以使性能指标、数据安全有保障，风险也是可控的。
1、用户视角下的混合云

对于用户来说看到的私有云是公有云和私有云的结合，其实在国内不乏有很多使用混合云的案例，比较早的案例就是12306。各位有没有觉得虽然近几年的火车票虽然还是一样的难买，但是这个12306网站的可靠性越来越高了，网站崩溃的次数越来越少了，当然不排除12306的编程水平、技术手段越来越高，但更大的原因是12306网站把查票的环节放在了阿里云上，自己只负责售票环节。所以从这个角度来看当业务高峰来临的时候，12306把大量的业务压力甩给公有云，当然他跟阿里一定会签非常严格的SLA，如果达不到也会有很严重的罚则。
所以这就是在用户眼里怎么用好混合云，也就是私有云只保障关键业务和核心业务，只有当业务峰值来临的时候，再让公有云扛，这是一种用法。第二种用法，我的业务在我这儿，备份业务在公有云上，把数据通过加密的方式同步到公有云上，当我这边出问题的时候，直接切换到公有云上，拿它当备份和容灾使用。这是用户在用混合云的时候比较常见的场景。
2、服务商视角下的混合云

从服务商的角度公有云如何建设?前一段时间大家会听到，京东云、阿里云或者青云曾经有过一些故障，我很佩服他们运维人员的技术和手段，对我来说整个华北区断网能在半小时之内恢复是很难的。在场各位肯定有做运维的同事，这么大的故障，半个小时各位都不一定能找到故障原因，所以对于公有云的运营商要怎么去选择?
今天的阿里、腾讯以及青云，他们都选择了相对来说比较专注的一条路，就是专注于Hypervisor，因为云平台的基础一定是虚拟化。像青云的Hypervisor是KVM，亚马逊选择的是Xen，其实这两个都是开源的，无所谓谁好还是不好。他们在这个量级的时候选择的是专注，选择把一个产品做到极致。但是当它出现代码级别的核心故障的时候，如果是基于一个虚拟化平台，就会造成整个业务出现灾难性的崩溃。
所以我们建设的思路是在Portal下面多了一层Driver，并且在底下支持了多种Hypervisor，有商业的，也有开源的。这样做是有一定难度的，因为我们要在选择的这些Hypervisor中抽象出它的业务逻辑，或者说我抽象出它们的相同点，然后屏蔽掉业务的不同点，这是我在Hypervisor里面选择的;然后我统一写一套Driver，从Portal下面下发到Driver的指令是一样的，比如通过一系列的业务流程创建虚拟机之后，由这套Driver再解释成每套Hypervisor所对应的指令下发下去。所以对于用户来说，用户选择的可能是不同的价格。比如说刚才我说的100G的硬盘，选择A区就是一台机器一个月200，B区一个月400，C区一个月600，它们对应的是不同的Hypervisor，也是不同的底层硬件。底层硬件包括是全SSD的，还是用了FC后台的，用的是商业的存储、分布式存储，还是对象存储等技术。我在不同的技术、不同的成本和不同的Hypervisor上面，隐藏掉了技术细节，用户根本不不需要了解底层的技术细节，这是我们在云上面的架构设计。
3、应用架构双活核心技术
那么用了这么多的Hypervisor，要解决的问题是什么?其实我要解决的是可靠性的问题。这张图是去年我在APM的会议上分享的片子，主要介绍了我们怎么样实现了应用双活。能做到应用双活主要靠六大核心技术：
l 在两地三中心的统一运维和管理，两个地方三个数据中心统一进行管理。
l 第二，用全状态智能DNS自动分担入向业务流量，DNS会自动的查看我的应用状态、数据中心状态，能做到整个数据中心出现问题的时候，我的业务可以无状态的直接切换到另外一个数据中心。
l 全状态链路负载均衡，智能分担出向链路负载。
l 多数据中心全部都是用裸光纤，大二层打通的。
l 跨数据中心的存储双活，因为我们面对的业务主要是金融类的业务，金融业务对实时性要求很高，尤其是对互联网金融这样的业务，还有一项要求比较高的是管控，所以基于这点尤其是在存储这方面，在金融业务这块我们并没有像互联网采用的是SSD技术，或者是分布式存储等等技术，我们还是采用FC存储，当然只对这一样业务。但是这个存储可以做到跨数据中心的数据可用，即使这个数据中心损毁，对数据来说也不受影响，而且实现了本地化的读写，然后数据中心双向同步。
l 开发方向，我们采用商业、开源、自研的结合，保证了应用的可靠性。
4、混合云下的国美实践

在国美如何实现混合云的?我们本身在建的时候公有云也好，私有云也好，都是国美在建设，所以我们先建私有云，又把私有云成熟的技术、成熟的管理和运维经验对社会提供公有云。用同样的技术，所以大家可以看到我们是公有云技术的私有云。第二，我们是公有云模式的私有云，什么意思?国美云服是为国美内部提供云计算服务的，但是跟国美的产业公司之间是真金白银进行结算的。其实从公司来讲我跟我的产业公司之间就跟运营商和客户之间是一样的。所以从这个角度来讲，我们可以满足他一些定制化的要求，而不完全是公有云模板一部署。当然我们建设的是多Hypervisor的公有云，在国美来看我们的混合云就是统一调度的混合云，不管从技术还是调度、还是模式，都是混合的。
四、混合云平台下性能管理
再说应用，刚才有的同事提到，应用一旦上云之后就不归自己管控了，那么在上云之前和之后怎么能保证我应用的可靠性，应用的性能呢。可靠性是通过刚才我提到是靠国美的底层云架构来保证的，包括应用双活、云双活，还有容灾，这些都是架构保证。那么在应用层面怎么保证?是因为我们跟听云有合作，听云有几样产品，听云有App，有听云Browser、听云Server以及听云Network，听云Sys，这五个产品。

上图是我们国美开发的一套业务系统，这个业务系统在正常上生产之前一定要做压力测试的，当在做压测的时候发现TPS值非常低，因为这个业务本身就在云上应用，那么这个问题就变成了刚才各位提到的扯皮。云平台层面看没有任何的问题，应用开发卡说在局域网里没有问题，但是用户体验不好。我们这次拿出了Server这样的产品，这个server端是可以私有云部署，也可以通过SaaS类的服务。由于刚才提到的数据不许出国美，所以服务器端是直接部署到国美的云平台上的。在中间件服务器上面装了听云探针之后，就可以抓到业务的实际情况。现在大家看到的业务的波动和曲线以及不可用的情况，就是在做压测时出现的场景。在听云这边可以很直观告诉我，现在我的服务器端是什么样的状态。当然听云能够做到的是不止能提供给我状态，还能提到为什么会有这样的问题。

所以根据上图，大家可以看出问题原因是由两个组件性能相对比较差，另外还有一个SQL语句写的有问题，这个明显是个最初级的DBA写的，因为业务还没有正式上线就全库检索，如果有了业务量的这一条指令就会死人。所以从这点上通过听云Server可以直观看出到底是运维还是研发，还是云平台的问题。听云不止可以监控数据中心的状态，也不止可以给我提供性能的管理，它能帮我做到比如说移动端、浏览器端以及网络端的监控。包括听云的一些性能指标概念，如首屏时间，首包时间，建联时间等等，这些对我的业务都是非常有帮助。以上就是我对我们国美建云，以及听云产品里面的心得分享，谢谢大家。