容器这玩意是个啥（容器漫谈之一）

前几天正好看到一篇文章，【携程容器云实践详解】，这篇挺有意思，分享给诸君看看，内容我就不再复述。

https://mp.weixin.qq.com/s/-7SDafpUNnXuCCWq0YvCag

其实关注这个这个文章，是因为两年前发生了一起整个行业都在关注的事情，2015年5月28日，携程网站发生大规模故障，上午11:09发现携程官网及APP出现故障，到28日23:29全面恢复，整个过程耗费12个多小时。事发之后，整个行业都在讨论原因是什么，为什么要花费这么长的时间才能恢复，为什么小范围的故障会导致这么大范围的服务中断？当然，各位有兴趣可以去扒一扒旧闻。这两个事情关联起来看才是最有趣的，你看到这两年携程做了什么，也可以想想为什么要这么做。

一般来说，类似携程这样的大型网站承载着繁多业务，其后台是一个由SOA（面向服务）架构组成的庞大服务器集群，看似简单的一个页面背后由成百上千个应用子系统以及众多Web Service组成，而每个应用子系统和每个Web Service之间都存在着相互调用的依赖关系，所以。。。恩，打住，这么说太技术，估计又要云里雾里了。

抛开携程的技术问题，我们单看事情的实质是什么呢，你开了个电商网站，可能会有用户、商品、订单、物流、财务、ERP等多个子系统，当你下单买双鞋子的时候，你看到就是那么几个网页，但实际上整个流程中，所有的子系统一股脑全上了，他们互相调用，互相依赖。这下事情就清楚了，一旦一个关键系统故障，整个事情就做不下去了。

当然，这世上聪明人很多，这么明显的问题大家看不出来？既然绑定有问题，我们就解耦呗，于是开发团队就祭出“拆”字打法，我就不要业务系统了，把大的业务系统拆成小的【微服务】，并朝着分布式无状态的方向发展。你压力大，我就并行生成一堆服务，负载均衡；你单个服务出了故障，我也不怕，直接生成一个新的，把业务接管过来，当然前提是微服务要足够小，生成调用要足够快。这方法，我们老祖宗是不是早就想到了，孙悟空拔出一把毫毛，每个都变成一个小猴子，不就是这么回事？

直白的说，这就是【云原生应用】这个概念的意义，是不是看起来很美，灵活可伸缩，这么做就好了，天下太平是吧。但正所谓福祸相依，微服务的思想是对的，但带来的问题更为突出，你想想以前你只要管几十台服务器，虚拟化出来之后，你要管几百个上千个虚拟机，这个时候已经很崩溃了，然后改成微服务，你要管几万几十万或者更多的微服务，基本上传统的IT运维就可以失业了，根本管不过来。因此DevOps的呼声就越来越高，自动化编排的需求也爆发性的增长，有种说法叫 Operation as a code 即是如此。这个话题也许下一篇我们再讨论一下，扯回来看类似携程的事件，如果是技术原因导致的，那可能并非是架构落后，而是在架构演进的过程中产生了混乱，由于自动化大规模使用，一个小的故障（不论是否人为）被放大成了大的故障，且回滚时间非常长，还造成了数据丢失。这种问题其实在现在最火的公有云，AWS和Azure，演进过程中也发生过。

当然，这只是猜测，但其中的重点是微服务技术的实施过程中，成败的关键是如何更好的规划微服务的管理和运维。其实容器这个东西很早就有了，应该说容器就是微服务的一种具体实现，它把应用的最小化部件打包到容器这个单元内。早期容器面临的问题是一样的，基本还停留在“法术”阶段，Docker也是容器技术的一种，它的火爆背后实际上是Docker提供了有效的工具和方法去管理容器。但Docker也不是完整的方案，这也是现在K8S突然大家这么关注的原因，当然这又是另外一个故事。

好吧，最后收一下，回到最开始的话题，我们可以看看Docker和Openstack，你可以发现这两者并不是对立的，无论是哪个都不代表云的全部，相反这两者结合也许才是云的一种未来形式，需要担心的只是【服务器虚拟化】这个技术而已。

                                                                                                                                             作者|张翼

【版权声明】本文为华为云社区用户原创内容，转载时必须标注文章的来源（华为云社区），文章链接，文章作者等基本信息，否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件至：hwclouds.bbs@huawei.com进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容。