云计算与大数据第一章揭秘云计算[文字可编辑].pptVIP

L.A.M.P Docker （ dotCloud ） CoreOS AWS EC2 Cloud Foundry Mesos （ Amazon ） （ EMC ） （ Mesosphere/ASF ） Eucalyptus OpenShift Kubernetes （ HP ） （ RedHat ） （ Google ） CloudStack OpenStack Unikernels （ Citrix/ASF ） （ Rackspace ） （ Docker ） 图 1-49 云计算发展历程 LAMP→IaaS→PaaS→CaaS （ 4 ）面向 API 的协作模式。 面向 API 的协作模式是在完成向微服务架构、 12 要素应用建设、自服务 敏捷基础架构三大模式转变过程中必然出现的新型协同工作模式。传统的协 同开发模式是基于应用部件间的方法调用（ Method Calls ），而在云架构 中，更多的是通过调用某种 APIs 的方式来实现组件间的通信，而 API 版本之 间的兼容关系通过版本号来定义与协调， REST APIs12 就是一种非常流行的 方式——它也是整个 WWW 的软件架构标志性风格——无独有偶， REST 的作者 Roy Fielding 在他的博士答辩论文中对 RESTful API 进行了定义，而他同 时也是 HTTP/1.113 的主要作者。 （ 5 ）面向故障。 面向故障（ Anti-fragile-Design for Failure ）是云计算弹性与敏 捷性的终极体现，在遵循微服务架构、 12 要素、自服务、面向 API 的设计原 则下，云本地应用可以做到零下线时间，也就是说在故障甚至灾难发生时系 统有足够的冗余来确保服务保持在线。业界最著名的面向故障的实践案例是 Netflix 工程师为了测试他们在亚马逊 AWS 上的服务的健壮性而开发的一套 叫作 Chaos Monkey14 的开源软件——它会发现并随机终止系统中的云服 务，以此来测试系统的自我恢复能力。 云的发展过程就像一次旅程（见图 1-40 ）。为了提供云服务，就需要 改造现有的数据中心（传统数据中心， Conventional Data-Center ）。在 传统数据中心内，计算、网络和存储等资源通常专供各个业务单元或应用程 序使用，这会导致管理复杂以及资源非充分利用。 1-40 云之旅：从传统 DC 到 SDDC 图 在本小节最后，我们再从云的形态入手来分析云的演变历程，通常一条 完整的进化曲线（见图 1-41 ）是：从数据中心（无论是场内还是场外）到私 有云，再到公有云，最终演化为混合云。不同的机构和组织进入云的切入点 可能会因需求与能力的差异而不同，无论是从相对原始的传统数据中心开始 还是从私有云或公有云服务切入，获取云服务通常不会以一种单一的云形态 来获得，个中原因值得深思。 图 1-41 云的演进历程：私有 → 公有 → 混合 1.4.3 开源 开源技术栈 所谓 LAMP 是 B/S （ Browser/Server ）和 C/S （ Client/Server ）技术的 四大代表性开源技术的首字母连写，鉴于 LAMP 技术是如此重要，我们在此要 对它们做个概览。 图 1-42 全球 Web 服务器市场份额 Jan 2016 图 1-43 数据库流行趋势：商业 vs. 开源 图 1-44 编程语言流行趋势（ 2004 — 2016 年） 图 1-45 LAMP 体系架构概览 图 1-46 AWS EC2 的十年增速发展历程 开源 vs. 闭源 自打亚马逊在 2006 年打开了云计算的“潘多拉之盒”，整个 IT 行业过去 十年的发展可以用风起云涌来概括，大到行业巨头，小到初创公司太多人投 身其中。笔者梳理了云计算的十年旅程，发现由开源与闭源（商业）两大阵 营的博弈贯穿始终，对两大阵营的厂家与云产品按照“神奇四象限”（ Magic Quadrant ）的分类把它们放置于商业 + 巨头、商业 + 小散（中小企业）、开源 + 小散以及开源 + 巨头四个象限之内，如图 1-47 所示。这张图囊括了云计算领 域里产品非常具有代表性的厂家。 图 1-47 云计算厂家（及产品）魔力四象限 由图 1-47 还可以看出云计算的玩家主要集中在右上角的第一象限—它 们的产品与服务的形态以大公司推出的商业化产品 + 服务（无论是否依赖开 源项目）为主；而第二、三、四象限则略显冷清（稍后我们来分析为什么开 源与中小企业在云计算领域往往流于雷声大雨点小）。如果我们再换个维度 来看云计算生态系统的演变，会发现业界的收购与联盟从来没有停止过（见 图 1-48 ）。 图 1-48 云计算生态系统演变：收购、