本文讲的是2015年容器技术峰会学习笔记（二），
【编者的话】这是2015容器技术峰会学习笔记的第二篇，在这里，作者继续讲述有关容器的诸多轶事，华尔街之狼? 开源巨头? 初创团队? 让我们一起去看看他们是怎么玩的容器的吧!
@Container容器技术大会将于2016年1月24日在北京举行，来自爱奇艺、微博、腾讯、去哪儿网、美团云、京东、蘑菇街、惠普、暴走漫画等知名公司的技术负责人将分享他们的容器应用案例。
昨天我们发布了这次容器技术峰会笔记的 第一部分 。今天继续！我们将给大家分享更多其他的在现场听到的有趣见闻。
在这里，你可以听到华尔街的老兵、开源巨头以及一些敏捷的初创团队的有趣故事。
华尔街之狼的容器玩法?
Jake Loveless， LuceraJake是Lucera的CEO，Lucera是一家专注于为华尔街提供IaaS服务的公司。Lucera 最开始是一家高频交易所。Loveless 表示在这里速度真的很重要。他们为此做了大量的优化。Lucera 很快便意识到他们也许可以在基础设施服务的世界里大有可为，因而开始了转型之路。
Jake喜欢把IaaS服务看成是一个构建赛道的过程。Lucera 已然实现了100%完全基于容器构建的基础设施服务，而这也正好贴合了本次峰会的主题。为了达成这一目的，他们选择了SmartOS以及一些Joyent技术栈里的其它组件。
为了追求更快的速度，Lucera尝试了很多不同的策略。更好的托管节点，性能更好的虚拟机等等。很多时候他们需要在成本和性能两方面做出权衡和取舍。或者说至少他们曾经做出过妥协，直到Jake开始尝试去使用容器。
在这个时候，大屏幕上投射出了一个铁三角的图像。这个铁三角中的每一个节点分别是可靠性、性能以及安全性。Jake声称一旦一家企业对其中任意一个点做的不够，那么其他另外两个也将会受到影响。
那么，容器在这里的铁三角中扮演着怎样的角色呢？原来，它们正是Lucera一直以来苦苦追寻的"救世良药"。
可靠性
>如果你不能在你的系统运行的时候调试它的代码，那么就别指望自己能写出安全可靠的软件。Jake随即做了一次Dtrace的现场demo，以显示在Lucera的技术栈上调试代码是如何的方便。他补充道，“除了实际生产的一些情况没办法做到完全的模拟，其他的你都可以办到。”
作为背景，Loveless指出在峰值情况下，他的服务器每秒需要发送数以千万计的消息。
安全性
Lucera是 EAL4 认证的企业。这是由 CCRA 通过的商业软件所能达到的最高级别的安全认证。性能
高性能被公认为是Lucera成功的关键因素之一。为了进一步说明这一点，Jake分享了一个瑞士央行（SNB）有关的案例。这也许是我个人在这次峰会里最喜欢的一个案例分享了。案例分析
Jake 首先从一个简短的背景故事开始讲起。这个故事的关键便是 一价定律 。粗略地讲，那就是这个世上根本不存在套汇的可能。在货币国际化的背景下，一美元换算成欧元又换算成英镑最终回到美元的价值必定是相同的。如果一种货币的价格发生了变化，那么所有货币的价格必须随之依次改变以消除套汇盈利的可能。如果出现失败的情况，那么整个市场自然会发生动荡。
Jake 还介绍到投资者们历来觉得瑞士法郎是一个很好的避险资产。换句话说，买入他们的话你至少能保证你的钱袋子是安全的。
介绍完背景后，Jake继续深入到故事的核心。在2011年经济危机的时候，大量的资金被兑换成瑞士法郎。这引发了法郎相对价值（译者注：即保值属性）的急剧下跌。为了应对这种情况，瑞士央行推出了 固定汇率政策 。它定下来欧元兑瑞士法郎最低为1.2。这意味着一旦它跌破1.2倍率，政府将会参与进来并买入大量货币。
多亏有这个政策，到2014年，瑞士央行已经积累了价值约4800亿美元的外国货币，这笔钱相当于瑞士GDP的70%。直到1月15号美国东部时间早上4点30分，瑞士央行觉得差不多赚够了。在没有任何事先通告的情况下，他们取消了固定汇率政策。此举旨在帮助释放次贷危机所带来的经济泡沫。
用Jake的话来说便是，“这就像4年以来积蓄的压力被瞬间释放一样。” 对于那些有心人来说，机会是显而易见的。这正是一个千载难逢的套汇的机会。为了能够更加清晰的展现当时的场面，Loveless 指出当天甚至有少数银行因此遭遇了他们史上最糟糕的一次在线交易体验。
就Jake本人的亲身经历来说，早上4点35分的时候他如常收到了他的CTO打来的电话。“你一定要看看这个。”
Jake登陆上了Lucera的系统然而并没有看到任何的报错或是告警。系统难道有宕机过吗? 在他继续在看板上筛选之后，他发现有200多个CPU超分极限的实例。CPU超分极限是SmartOS的一个特性，它在一个CPU完全爆棚的情况下向相邻的机器实例租借60s的CPU时间片。这里的确冒烟了，不过还没有任何起火的迹象。
Jake 继续把目光聚焦在当天接下来所发生的事情上。在其他的地方，他们早就乱成一团。强如华尔街的基础设施也开始了坍塌。这导致剩下来的交易所的负载急剧增长，而结果又引发了他们之中的众多系统再次崩溃。在那天，人群效应给其中大量的企业敲响了丧钟。
至于Lucera? 直到那天结束，他们也没看到任何一个单点故障。事实证明，他们的基础设施能够在混乱的形势下依然稳定的提供服务。而作为为数不多的仍然能提供服务的企业之一，收获的回报无疑也是无比丰厚的。Jake指出许多他们的客户都表示当天的交易足以抵得上平常期间一个月的交易量。
Type-C Hypervisor
Dustin Kirkland，CanonicalType-C Hypervisor 是什么? 为了解答这个问题，Dustin Kirkland 把我们带回到了1973年，特别是第四次ACM研讨会上关于操作系统原理的讨论。更具体一些的话，便是作为这次研讨会结果发表的一篇论文。
在“关于第三代可虚拟架构的形式化要求描述”这篇论文里，作者提出了一系列重要的正式定义，关于需要采取哪些措施来创建一个hypervisor + 虚拟机。
自那以后，世上便多了两种类型的hypervisor。类型1承载于本地的裸机之上。类型2 便是一台拥有一个真实操作系统的机器，在这里hypervisor更多的只是扮演一个应用的角色。
符合类型1定义的像Vmware的vSphere和Xen。
而符合类型2的有KVM以及virtualbox。
LXD便是引入的第三种类型即Type C的hypervisor程序。在Type C中，每个容器共享宿主机上相同的一套操作系统。
我们再回到1973年的这篇论文。这里面有一些对于一台虚拟机简单的要求：
- 效率
- 资源控制
- 等价性（你在客户端机器上做的任何事情理应都可以在宿主机上完成，反之亦然）
这里还有一个挺有意思的第4个要求：虚拟机可以递归的运行。换句话说，如果一切都实现了虚拟化，那就没有理由不能在虚拟机里跑虚拟机。
Dustin随后问了一个很重要的问题，“这跟Docker有什么不同之处吗?” Docker是一个应用容器，它解决了一个重要的问题，“我应该如何提供一个二进制文件，并且在一个容器里运行它呢? 我应该如何像一个静态的二进制文件那样打包一个应用，又怎么才能像二进制文件那样随意迁移？”
与之相反，LXD它算是Linux容器（ LXC ）的一个扩展。LXD应当看做是一台机器的容器。他们和虚拟机扮演着非常相似的角色。一台机器的容器的优势在于它在硬件上封装的更细致，启动的更快，与此同时它在根本上与一个完整成熟的操作系统一样的运转自如。
在幻灯片的最后，Dustin切换到了对LXD（以及它满足的1973年那篇论文里所列出的各项特性）的一个现场演示。在所有的基准测试中，Dustin的机器显示LXD与本地运行的脚本相应的测试结果总体上大致持平。
如果你想进一步了解更多有关LXD的知识，欢迎访问 Linuxcontainers.org 。
容器生态系统标准：需求和进展
Brandon Philips，CoreOS当容器峰会上大多数其他的演讲嘉宾纷纷翻到几十年前去回顾历史的时候，CoreOS的Brandon Phillips选择的是着眼于当下。他谈到了容器近一年来的发展状况。
作为铺垫，Phillips 指出在Docker的世界里，容器的标准和需求在很大程度上仍然是一个开放性的话题。怎样才能更好的满足用户的需求呢？这是一个在他开始着手去定义一个标准的时候经常会问自己的问题。
一个比较有说服力的答案便是它需要从码农们入手。对于这帮实际去创造东西的人来说易用性实在是一个很大的问题。
是什么让Docker变得如此有价值? Phillips回过头来问了一些反问句，“我们已经使用LXC和tar压缩包这么多年了，但是我们可从来没有一起开会讨论过它。”
那么为什么我们现在又频频提到容器呢？
首先，我们需要有一个加密摘要算法来识别不同的容器。这个线上的容器有何不同又或者跟我这个本地的完全一样? 如果Alice构建了它，我应该也能够通过一串类似密钥的东西来验证它是否真的就是Alice所创建的那个容器。其二，仅仅有一个加密认证还是不够的，因为人们大都比较反感记忆这些琐碎的东西。我们需要的是一些人类可读的名字。Brandon指出，尽管他个人不是很喜欢他们，然而类似DNS风格的名字确实起的不错. 例如，“Com.example.app”。
第三，容器必须建立一套标准。无论它是Rkt还是Docker，你理应都可以在任意一个地方运行容器。他借着现实世界的集装箱的例子打了一个比方。集装箱能够托运在船上，同样也应该可以放到火车上，或者拖车上等等。
appc 标准
随着解答完需求的问题之后，Brandon又回过头来介绍了一下过去一年 appc标准 的发展情况。它在发布时搭配了一些代码作为一个实际实现例子的demo。自那以后，这才有了Rkt。他指出在CoreOS刚发布这一标准的时候，他希望可以看到大量基于这一标准实现的具体实例。一个标准最有意思的事情莫过于它可以推动人们围绕着它来构建各式各样的系统。 没有理由单单只是为了促成其中的一个实现方案成为容器的统一标准。
一个好的标准同样也必须具备易于定位的特点。我怎么使用一个人类可读的名字来找到这个东西？
Brandon一本正经的指出这样的约定对于人们来说大有帮助。
在appc刚发布的时候，它的宏愿是希望社区能够联合起来组建一套事实上的容器标准。欢呼！事实上，appc的确引起了不小的轰动。这虽然已经是旧闻。自那以后，appc、CoreOS、Docker和许多其他公司走到一起共同提出了一个 开放容器倡议标准 。
你可以关注如下链接获取它的最新动态: github.com/opencontainers/spec 。
Brian在演讲的最后还不忘提醒大家通读一下该标准规范。为了确保他和开放容器项目的其他人员做出更加正确的选择，从我们（开发人员）这里获取反馈是必不可少的。
（完）
原文链接：2015 container summit notes and learnings part 2 （翻译：吴佳兴）
原文发布时间为：2015-11-09
本文作者：colstuwjx
本文来自云栖社区合作伙伴DockerOne，了解相关信息可以关注DockerOne。
原文标题：2015年容器技术峰会学习笔记（二）
