IT评测·应用市场-qidao123.com

标题: 揭秘云计算 | 8、云服务与产品的演进 [打印本页]

作者: 没腿的鸟 时间: 2025-3-14 05:58
标题: 揭秘云计算 | 8、云服务与产品的演进
了解云计算服务、产品与办理方案的演进历程可以从服务提供方或需求方入手。
以服务需求方为例，业务需求出发点的差别导致选择云计算办理方案的切入点差别，我们以XaaS作为切入点（见下图1）：

图1：云服务、云产品的演进
对于某些用户而言，提供长途桌面、瘦客户端（取代现有PC主机、条记本电脑）是日常办公云化的第一步；而对于其他用户，特别是一些对于流程较注重的公司而言，他们大概会从购买SaaS化的办公主动化体系、CRM或ERP体系入手。研发型机构或IT公司接入云的方式则更有大概是直接购买虚拟化的IaaS资源，如云主机、云数据库服务等。
固然，对于部分内、部分间协同工作要求较高的机构，他们大概会从雷同于白板、通讯录、日历、库存、订单管理、共享桌面等服务切入。这一类服务都被冠以“科研云”的名头，实质上是不折不扣的SaaS。
1、DevOps

无论是从底层的IaaS还是从上层的SaaS接入云，它们都会向中间层的PaaS平台演进。PaaS提供的核心服务可以分为两大类：
(1)集成化的服务（部署、维护、升级、兼容性管理、服务目录等）；
(2)一体化开发+运维(DevOps)、持续集成、持续部署。
这里我们要对DevOps概念做一个简要的先容，它是对重视“软件开发人员(Dev)”和“IT运维技术人员(Ops)”之间进行快捷沟通协作的统称。
在研发机构中，开发、测试与运维通常作为3个差别的部分独立存在。在产品开发的生命周期中，开发部分提交半制品或制品给测试部分；测试部分查验合格后提交给运维部分；运维部分负责最终的集成、部署、实行、维护。随着业务需求、市场环境的快速变革，产品迭代的需求愈来愈强，开发—测试—运维的周期越来越短，特别是随着敏捷开发模式的推广，越来越多的公司，特别是互联网企业率先采用了让三部分高度协同，乃至一体化的DevOps模式，如下图2所示。

图2：DevOps的三位一体
在图2中，3个圆的交集部分为DevOps——DevOps的概念于2008年被正式提出，但是业界巨头（如雅虎）早在2004年就广泛采用DevOps的运营模式——令人印象深刻的是，在雅虎工作的每个开发人员都要轮流佩带一周寻呼机（又称BB机），实行“7×24h”不间断值班制，发生问题时开发人员可长途登录主机排查问题，若问题依然不能办理就需要开发人员亲自去机房排查。采用DevOps模式对于开发人员而言，意味着身兼数职（对细化分工的一种逆向操纵）；而对于测试与运维工种而言，则意味着被弱化，乃至是被消灭。
假如从云的根本属性角度出发，云服务提供方（建立者）与云的客户（需求方）的诉求有差别的演进阶段。前者通常把基础架构、平台、服务与应用的弹性放到首位，把体系的妥当性放在其次，再次是各项性能指标的进步，末了则是体系安全性的进步。而对于后者来说通常在进入云初期，其第一考量是低成本，其次是弹性、敏捷性、可伸缩性，再次是体系的妥当性与安全性。两者的优先级看似有很大差异，实则是对立统一的。云建立的演进历程：提供方和需求方对比如图3所示。

图3：云建立的演进历程：提供方和需求方对比
在云计算发展过程中，图3所示内容是从早期阶段到逐渐成熟过程中肯定经历的阶段。安全性成为云计算考量的重要因素是云逐渐趋于成熟的标志之一。在性价比、弹性、敏捷性、妥当性、性能这些难题都被攻克后，安全性相关问题肯定会被提上议事日程。
云的弹性有以下几个重要的衡量指标。
指标1：提供资源所需的时间。
指标2：提供可伸缩资源的全面性——左右水平、上下垂直、计算、网络、存储、服务、应用等。
指标3：对于弹性资源的监控粒度。传统监控方式的颗粒度是基于物理机或虚拟机的资源组件（如Nagios、Ganglia等），但是在云计算框架下，对于一个大概超过了多台物理机、虚拟机或容器的应用或服务而言，对其进行监控的复杂度大增，需要在对整个应用或服务的各项指标做综合乃至是加权计算后呈现给用户。
指标4：资源供应的准确性，避免太过供应或供应不敷。

云的性能评测可以从以下多个维度睁开。
维度1：传统指标的评测，如CPU/vCPU[插图]利用率、网络带宽利用率、磁盘吞吐量等。
维度2：云化工作负载性能评测，如对数据库、大数据或某个详细应用的性能（吞吐量、启动速度等）的评测。
维度3：其他功能的支持及指标，如是否支持实时的块数据复制、体系每秒能完成的读/写操纵次数(Input/Output Operations Per Second，IOPS)、是否支持传统应用向云迁徙、云内及跨云数据迁徙速度等。
谈到云的性能，其核心就是云上工作负载的性能。在这里我们需要引入和澄清一个重要的概念：云当地应用、云原生应用。并非所有的应用都是为云而生的，传统应用的重要特点是其独立性和封闭性，而在云基础架构上运行的应用分为两类：传统应用的云化迁徙、创建的云当地应用。传统应用通常对底层硬件有很多需求，因此迁徙并非像搬箱子那么简单，通常需要对其进行虚拟机或容器封装（有些乃至需要在符合规格的裸机上直接运行才气保证其服从，如大数据类应用），而且这些传统应用很难进行弹性扩展，如此一来它们的云化迁徙更多的是为了云化而云化。
2、云原生应用

云原生应用又被称为云当地应用，具有五大特点，如图4所示。

图4：云原生应用的五大特点
(1)微服务架构

微服务架构是云当地应用最重要的特点，它源自面向服务的体系架构(Service Oriented Architecture，SOA)。可以以为它是SOA整体框架中的一部分，在云化的过程中逐渐演变为各个云组件之间通过可独立部署的服务接口实现通讯。图5形象地展示了传统独立应用与微服务架构应用间的差异。独立应用是一个“大包大揽”的整体，每一个应用进程会把多个功能集成在一起，独立应用的扩展是以应用进程为单元扩展到多台主机上；而微服务的最大区别在于把每一个功能元素作为一个单独的服务，这些服务可以部署在差别的主机上，每个服务只要保证通讯接口稳定，它们可以各自独立进化。从DevOps的角度出发，微服务架构具有非常明显的优势——一个服务的故障不至于导致整个应用下线，而在独立应用架构中，任何一个单一功能的维护、升级都要求整个应用进程下线、重启……

图5：传统独立应用和微服务架构应用间的对比

(2)云应用十二要素

云应用十二要素是被业界广泛引用的云原生应用的通用特点，由亚伦·威金斯(Adam Wiggins)在2012年提出。作为Hevoku的创始人，他总结了云原生应用的十二要素：单代码库多次部署、明确定义依靠关系、在环境中存储设置、后端服务作为附加资源、建立发布及上线运行分段、以无状态进程运行应用、通过端口绑定袒露服务、通过进程模型扩展实现并发、通过快速启动与优雅制止实现最大化妥当性、开发环境=线上环境、日志=事件流、后台管理任务=一次性进程。有些人乃至称十二要素为建立与运行云应用最佳实践的金标准。
（3）自服务的敏捷基础架构

自服务敏捷基础架构的概念最早在2015年出书的《迁徙云原生应用程序架构》(Migrating to Cloud-Native Application Architectures)一书中被提出。自服务敏捷基础架构的另一种叫法是PaaS，它可帮助程序员完成以下4件事情。
①主动化、按需的应用实例伸缩。
②应用程序健康管理。
③对应用实例访问的主动路由与负载均衡。
④对日志与度量数据的集结。
(4)面向API的协作模式

面向API的协作模式是在向微服务架构、十二要素应用建立、自服务敏捷基础架构三大模式转变过程中肯定出现的新型协同工作模式。传统的协同开发模式是基于应用部件间的方法调用，而在云架构中，协同开发模式更多的是通过调用某种API的方式来实现组件间的通讯，而API版本之间的兼容关系通过版本号来定义与和谐。REST[插图]API就是一种非常流行的方式——它也是整个万维网(World Wide Web，WWW)的软件架构标志性风格——不足为奇，REST的作者RoyFielding在他的博士答辩论文中对RESTful API进行了定义，而他同时也是HTTP/1.1的重要作者。REST与HTTP之间有如此千丝万缕的联系，以至很多人将二者混为一谈，因此我们在这里简单澄清下二者的区别。
①HTTP是传输层协议；REST是一组架构束缚条件，它可以利用HTTP或其他传输层协议来实现。
②HTTP API与REST API之间存在本质区别。任何利用HTTP作为传输层协议的API，如简单对象访问协议(Simple Object Access Protocol，SOAP)，都是HTTP API。而REST API则遵循REST的束缚条件，更多的是一种围绕资源的设计风格而不是一个标准。
(5)面向故障的设计

面向故障的设计是云计算弹性与敏捷性的终极表现，在遵循微服务架构、十二要素、自服务、面向API的设计原则下，云当地应用可以做到零下线时间，也就是说在故障乃至劫难发生时体系有充足的冗余来确保服务保持在线。业界著名的面向故障的实践案例是Netflix公司的工程师为了测试他们在AWS上的服务的妥当性而开发的一套叫作Chaos Monkey的开源软件，该软件会发现并随机制止体系中的云服务，以此来测试体系的自我恢复能力。

云的发展过程就像一次路程，如图6所示。要提供云服务，就需要改造传统数据中心(Conventional Data Center，CDC)。在传统数据中心内，计算、网络、存储等资源通常专供各个业务单元或应用程序利用，这会导致管理复杂和资源非充分利用。传统数据中心所存在的限定促使了虚拟化数据中心(Virtualized Data Center，VDC)的产生，虚拟化进程一样寻常遵循的是计算虚拟化、网络虚拟化、存储虚拟化等分阶段实行原则。持续增大的IT成本压力及业务按需处置惩罚数据的需求最终催生了云数据中心，我们称之为软件定义数据中心，它的核心机制是以服务和应用为导向。在硬件层面，它和虚拟化数据中心与传统数据中心并没有本质区别，重要的差别是通过软件工程的高度发展来实现的，也就是我们在图1-39中所提的云原生应用的五大特点。

图6：云之旅：从传统数据中心到软件定义数据中心
在本文的末了，我们再从云的形态入手，分析云的演进历程。如图7所示，通常一个完整的云演进历程是：
从数据中心（无论是场内还是场外）到私有云，再到公有云，最终演化为混合云。差别的机构和构造进入云的切入点大概会因需求与能力的差异而差别，无论是从相对原始的传统数据中心开始还是从私有云或公有云服务切入，云服务通常不会以一种单一的云形态来获得，此中原因值得深思。

图7：云的演进历程
以中小企业为例，最先利用的云服务大概是公有云的虚拟主机，而后渐渐演进到利用公有云的存储服务、数据库服务、网络服务，直至大数据服务。有多种原因大概会造成该企业考虑其他云服务提供商或云形态，诸如太过部署、缺少实时审计所导致的空转与资源浪费，差别热度的数据访问代价差异而造成的存储浪费。看似天上掉馅饼式的免费、复杂的计费方式、高昂的故障修复成本等云计算的隐藏成本，都大概会让你在看到账单的时间大吃一惊。
别的，当公有云的成本达到肯定金额或某些任务无法在现有云服务目录中得到满足时，很多企业把每年在公有云上消费100万美元作为一条警戒线，一旦达到或超过该线就会开始把部分业务向私有云迁徙。较为典型的是那些对单机设置与性能要求高的大数据分析类业务，这些业务更适合直接在物理机上运行，而且运行时间较长，在公有云环境中通常很难获得充足高的设置，也很难保证长时间运行的业务不被强行中断——云计算、大数据服务丰富的公司（如亚马逊）也不能保证所有的业务需求都可以被满足。那种一站式的观念对于需求单纯的初创企业可行，对于业务需求日渐丰富、复杂化的构造而言，则很难满足他们的需求，也就是说，通常需要异构的数据中心或两种以上的云、虚拟化环境来满足他们的业务需求。大多数企业的首席信息官会考虑通过迁徙一部分任务到其他云来实现成本控制，完成任务。至此，我们达到了云路程的一个稳定状态——混合云。混合云是大多数云路程的重要趋势。对于业务部分和IT部分而言，这也意味着面向多云环境的业务管理与运维变得更加复杂。（文/Ricky - HPC高性能计算与存储专家、大数据专家、数据库专家及学者）

· END ·

释义：
1、DevOps 是一组过程、方法与体系的统称，用于促进开发（Development）、技术运营（Operations）和质量保障（QA）部分之间的沟通、协作与整合。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

欢迎光临 IT评测·应用市场-qidao123.com (https://dis.qidao123.com/)