揭秘云计算| 08· 云向何处去？

时间：2023-03-13 03:22:01 | 来源：电子商务

时间：2023-03-13 03:22:01 来源：电子商务

了解云计算服务、产品与解决方案的演进历程可以从服务提供方或需求方入手。

以服务需求方为例，业务需求出发点的不同导致选择云计算解决方案的切入点不同，我们以不同类型的XaaS作为切入点，对于某些用户而言提供远程桌面、瘦客户端（取代现有PC主机、笔记本电脑）是日常办公云化的第一步，而其他用户，特别是一些对于流程较注重的公司可能会从购买SaaS化的办公自动化系统、CRM或ERP系统入手。研发型机构或IT公司接入云的方式则更有可能是直接购买虚拟化的IaaS资源，如云主机、云数据库服务等（当然，对于部门内、部门间协同工作要求较高的机构，也可能会从类似于白板、通信录、日历、库存、订单管理、共享桌面等服务切入。这一类服务都被冠以“科研云”的名头，实质上是不折不扣的SaaS服务）。

无论是从底层的IaaS还是从上层的SaaS接入云，它们都会向中间层的PaaS平台演进。 PaaS提供的核心服务可以分为两大类：

集成化的服务（部署、维护、升级、兼容性管理、服务目录等）；
l一体化开发+运维（DevOps）、持续集成、持续部署（CI/CD）。

DevOps的概念本身于2008年9被正式提出，但是业界巨头如Yahoo!等早在2004年就已经广泛采用DevOps的模式运营笔者在Yahoo!工作的时候印象最深刻的就是每个开发人员都要轮流佩戴BB机一周，“24×7”值班，发生问题时远程登录主机依然不能解决的问题就需要亲自去机房排查物理机问题。DevOps对于开发人员是一种典型的一身兼数职（对细化分工的一种逆向操作），而对于测试与运维而言则是意味着弱化甚至消灭这些工种。

如果从云的基本属性角度出发，云服务提供商（建设者）与云的客户（使用者）的诉求有不同的演进阶段。前者通常把基础架构、平台、服务与应用的弹性放到第一位，而后系统健壮性，再之后是各项性能指标的提高，最后会提高安全性；而对于后者通常在进入云初期，低成本是第一考量，弹性、敏捷性、可伸缩性紧随其后，再之后是健壮性与安全性。两者的优先级看似有很大差异，实则对立统一。（如下图所见）

此外，老孙一再强调安全问题！早在2018年，Gartner（全球最具权威的IT研究与顾问咨询公司）就提出过“安全性将成为云计算考量的首要因素正是云逐渐趋于成熟的标志之一”的论断，现在看来，确实如此——在性价比、弹性、敏捷性、健壮性、性能这些难题都已经被攻克后，安全问题已经被提上了议事日程。

很多时候，云的安全问题，尤其是公有云安全，比大家想象的要严重的多。曾经有家公司在某公有云上面部署了公司的代码管理服务器以及全部开发服务器，但是赫然发现某天多台系统宕机，并发现有该云服务商方面的root账户登录。该公司随即把所有的代码及服务器下线并迁移回公司内网。类似的事件让云的安全性和可信任问题显得格外突出。

对于云的弹性（Elasticity）有几个重要的衡量指标：

提供资源所需的时间（Provisioning Time）。
提供可伸缩资源的全面性—左右水平、上下垂直、计算、网络、存储、服务及应用等。
对于弹性资源的监控粒度。传统的监控方式的颗粒度是基于物理机或虚拟机的资源组件（如Nagios、Ganglia等），但是在云计算框架下对于一个可能跨越了多个物理机、虚机或容器的应用或服务而言，对其监控的复杂度大增，需要在对整个应用或服务的各项指标做综合甚至是加权计算后呈现给用户。
资源供应的准确性，避免过度供应（Over-Provisioning）或供应不足（Under- Provisioning）。

云的性能评测（Performance Benchmark）可以从多个维度展开：

传统指标的评测：CPU/VCPU、网络、磁盘吞吐率指标。
云化工作负载（Workloads）性能评测：如数据库、大数据或某个具体应用的性能（吞吐率、启动速度等）评测。
其他功能的支持及指标：如是否支持实时的块数据复制（SAN Replication）、系统的IOPS（每秒读写操作次数）、对传统应用向云迁移的支持、云内及跨云数据迁移速度等。

谈到云的性能，其核心就是云上工作负载的性能，在这里，我们需要引入和澄清一个重要的概念：云本地应用、云原生应用（Cloud Native Application，CNA）。并非所有的应用都是为云而生的，传统应用的一个重要特点是Monolithic （独立性、封闭性），而在云基础架构上运行应用分为两类：传统应用的云化迁移与创建云本地应用。传统应用通常对底层硬件有很多需求，因此迁移并非是像搬箱子（Lift-n-Move）那么简单的事情，通常需要对其进行虚拟机或容器封装（有些甚至需要在符合规格的裸机上直接运行才能保证效率，如大数据类应用），并且这些传统应用很难进行弹性扩展，如此一来它们的云化迁移更多的是为了云化而云化。

云原生应用（Cloud Native Applications）又被称为云本地应用。

云原生应用具有五大特点：

（1）MSA（Micro-Service Architecture，微服务架构）：

MSA是云本地应用的最重要的特点，它源自于SOA（Service Oriented Architecture，面向服务的架构），可以认为是SOA整体框架中的一部分，在云化的过程中逐渐演变为各个云组件之间通过可独立部署的服务接口来实现通信。图1-39形象地展示了传统独立应用与微服务架构应用间的差异。独立应用是一个“大包大揽”的整体，每一个应用进程（Process）会把多个功能集成在一起，独立应用的扩展也是以应用进程为单位扩展到多台主机上；而微服务的最大区别在于把每一个功能元素作为一个独立的服务，这些服务可以部署在不同的主机上，每个服务只要保证通信接口不变，它们可以各自独立进化。从DevOps的角度出发，MSA架构也具有非常明显的优势——一个服务的故障不至于会导致整个应用下线，而在独立应用架构中，任何一个单一功能的维护、升级都要求整个应用进程下线、重启……
然而，一味鼓吹MSA的以上的优势，并不等于MSA可以通吃，或者说毫无缺点可言，在HPC（高性能计算）的很多场景中，关注每一微秒的吞吐率、时耗的时候，MSA平日里灵活、健壮的优势就无法体现了，相对而言，更紧耦合的系统（例如更少的网络层数据交换）的性能可能会更好。

（2）云应用12要素：

12-Factor Application（云应用12要素）是业界被广泛引用的CNA类型应用的通用特点，由Adam Wiggins在2012年提出10。他总结了CNA的12要素：单代码库多次部署、明确定义依赖关系、在环境中存储配置、后端服务作为附加资源、建设发布及上线运行分段、以无状态进程来运行应用、通过端口绑定来暴露服务、通过进程模型扩展来实现并发、通过快速启动与优雅终止来实现最大化健壮性、开发环境=线上环境、日志=事件流、后台管理任务=一次性进程。以上12要素在业界被广泛引用，有些人甚至称之为建设与运行云应用最佳实践的金标准。

（3）自服务敏捷基础架构：

自服务敏捷基础架构（Self-Service Agile Infrastructure）的概念最早由笔者的同事Matt Stine在他2015年的Migrating to Cloud-Native Application Architectures11一书中提出，自服务敏捷架构的另一个叫法是PaaS（平台即服务），它帮助程序员完成四件事情：
· 自动化、按需的应用实例伸缩（Automated & On-demand Scaling）；
· 应用程序健康管理（Health Management）；
· 对应用实例访问的自动路由与负载均衡（Routing&Load-Balancing）；
· 对日志与度量数据的集结（Aggregation）。

（4）面向API的协作模式：

面向API的协作模式是在完成向微服务架构、12要素应用建设、自服务敏捷基础架构三大模式转变过程中必然出现的新型协同工作模式。传统的协同开发模式是基于应用部件间的方法调用（Method Calls），而在云架构中，更多的是通过调用某种APIs的方式来实现组件间的通信，而API版本之间的兼容关系通过版本号来定义与协调，REST APIs12就是一种非常流行的方式——它也是整个WWW的软件架构标志性风格——无独有偶，REST的作者Roy Fielding在他的博士答辩论文中对RESTful API进行了定义，而他同时也是HTTP/1.113的主要作者。REST与HTTP之间有如此千丝万缕的联系，以至于很多人将二者混为一谈，在这里需要做一下简单的澄清，区别如下：
· HTTP是传输层协议；REST是一组架构约束条件（Constraints），它可以使用HTTP或任意其他传输层协议来实现。
· HTTP API与REST API间存在本质区别。任何使用HTTP作为传输层协议的API，如SOAP，都是HTTP API，而REST API则遵循REST的约束条件，它更多的是一种围绕资源的设计风格而不是标准。

（5）面向故障：

面向故障（Anti-fragile-Design for Failure）是云计算弹性与敏捷性的终极体现，在遵循微服务架构、12要素、自服务、面向API的设计原则下，云本地应用可以做到零下线时间，也就是说在故障甚至灾难发生时系统有足够的冗余来确保服务保持在线。业界最著名的面向故障的实践案例是Netflix工程师为了测试他们在亚马逊AWS上的服务的健壮性而开发的一套叫作Chaos Monkey14的开源软件——它会发现并随机终止系统中的云服务，以此来测试系统的自我恢复能力。

云的发展过程就像一次旅程（如上图所见）。为了提供云服务，就需要改造现有的数据中心（传统数据中心，Conventional Data-Center）。在传统数据中心内，计算、网络和存储等资源通常专供各个业务单元或应用程序使用，这会导致管理复杂以及资源非充分利用。CDC所存在的限制促使了虚拟化数据中心（Virtualized Data-Center，VDC），在虚拟化进程中一般遵循的是计算虚拟化、网络虚拟化、存储虚拟化分阶段实施。持续的IT成本压力以及业务的按需数据处理需求最终催生了云数据中心，我们也称之为软件定义的数据中心（SDDC，Software-Defined Data-Center）——它的核心机制是以服务和应用为导向——在硬件层面并没有和前面的VDC与CDC有本质区别，主要的飞跃通过软件工程的高度发展来实现，也就是我们前面提到CNA的5大原则——MSA、12-factor、Self-Service Agile、API Collaboration与Anti-fragile。

老孙再从云的形态入手分析一下云的演变历程：

通常一条完整的进化曲线（如下图所见）是从数据中心（无论是场内还是场外）到私有云，再到公有云，最终演化为混合云。

不同的机构和组织进入云的切入点可能会因需求与能力的差异而不同，无论是从相对原始的传统数据中心开始还是从私有云或公有云服务切入，获取云服务通常不会以一种单一的云形态来获得，个中原因值得深思。

以中小企业为例，最先使用的云服务可能是公有云的虚拟主机，而后逐步演进到使用公有云的存储服务、数据库服务、网络服务，直至大数据服务，但是，有多重原因可能会造成该企业考虑其他云服务提供商或云形态，如云计算的如下隐藏成本可能会让你拿到账单的时候大吃一惊：

·过度部署（Over-Provisioning）；
·缺少实时审计（Auditing）导致的空转与浪费；
·存储浪费（不同热度的数据访问代价差异巨大）；
·一切免费都是有代价的（互联网推广本性所致）；
·复杂的计费方式；
·进场免费离场代价高昂（数据迁移高代价）；
·高昂的故障修复成本；
·不可定制。

另外，当公有云的成本达到一定阶段或某些任务无法在现有云服务目录中得到满足（老孙与同事做过一些市场调查，发现很多企业把每年100万美元在公有云上的消费作为一条警戒线，一旦达到或超过就会开始把部分业务向私有云环境迁移。

最典型的是那些对于单机配置与性能要求高的大数据分析类业务，这些业务更适合直接在物理机上运行，而且运行时间较长，在公有云环境中通常很难获得足够高的配置，也很难保证长时间运行的业务不被强行中断—云计算、大数据服务之丰富如亚马逊AWS也不能保证所有的业务需求都可以被满足，那种One-Stop-Shop的观念老孙以为对于需求单纯的初创企业可行，对于业务需求日渐丰富、复杂化的组织而言，很难做到。

也就是说，通常需要异构的数据中心或两种以上的云、虚拟化环境来满足业务需求），大多数企业的CIO会考虑通过迁移一部分任务到其他云来实现成本控制和完成任务。至此，我们也达到了云旅程的一个稳定状态—混合云，老孙深以为混合云将会是未来相当长一段时间内大多数云旅程的主要趋势，而作为业务部门和IT部门而言，这也意味着更复杂的面向多云环境的业务管理与运维。

·END·

往期回顾：