|
|
|
|
|
在云计算技术架构中，由数据中心基础设施层与ICT资源层组成的云计算“基础设施”和由资源控制层功能构成的云计算“操作系统”，是云计算相关技术的核心和发展重点，如下图所示。
|
|
|
|
|
|
|
|
云计算“基础设施”是承载在数据中心之上的，以高速网络（如以太网）连接各种物理资源（服务器、存储设备、网络设备等）和虚拟资源（虚拟机、虚拟存储空间等）。云计算基础设施的主要构成元素基本上都不是云计算所特有的，但云计算的特殊需求为这些传统的ICT设施、产品和技术带来了新的发展机遇。如数据中心的高密度、绿色化和模块化，服务器的定制化、节能化和虚拟化等；而且一些新的ICT产品形式将得到长足的发展，并可能形成新的技术创新点和产业增长点，如定制服务器、模块化数据中心等。
|
|
|
|
云计算“操作系统”是对ICT资源池中的资源进行调度和分配的软件系统。云计算“操作系统”的主要目标是对云计算“基础设施”中的资源（计算、存储和网络等）进行统一管理，构建具备高度可扩展性，并能够自由分割的ICT资源池；同时向云计算服务层提供各种粒度的计算、存储等能力。
|
|
|
|
|
|
|
|
云计算“基础设施”关键技术包括服务器、网络和数据中心相关技术。
|
|
|
|
（1）服务器相关技术。服务器是云计算系统中的基础节点。为了实现云计算的低成本目标，云计算系统中多采用X86服务器，并通过虚拟化提高对服务器资源的利用率。
|
|
|
|
X86服务器的虚拟化技术比较成熟。虚拟化主要有裸金属虚拟化和寄居虚拟化两种方式，其中裸金属虚拟化在性能、资源占用等方面具有综合优势，是应用最为广泛的一种虚拟化方式。
|
|
|
|
（2）云计算相关网络技术。云可以看作是一个庞大的网络系统。一个云内可以包含数千，甚至上万台服务器，虚拟化技术的普遍采用使实际网络节点的数量更加巨大，因此用于连接云内各个节点（云元）的网络就成为实现高效的计算和存储能力的关键环节之一。
|
|
|
|
|
|
①虚拟机流量的接入与控制。由于虚拟机的引入，虚拟机间流量的交换可能深入到网卡内部进行，使得原本服务器与网络设备之间在网络接入层比较清晰的界限被打破。
|
|
|
|
②数据中心内部横向流量的承载。在云计算数据中心中，出于对虚拟机“热迁移”的需要，汇聚层仍然采用二层网络组网，这使得汇聚层二层网络规模大大增加，原有生成树协议的阻塞模式将造成链路的大量浪费。
|
|
|
|
③数据、存储网络的融合。传统数据中心中存在两类网络：连接服务器的以太网，连接服务器和存储设备的光纤存储网（FC）。两张网络的并存提高了建设和运行管理成本，为了适应云计算低成本的需要，数据网络和存储网络的融合成为一种趋势。
|
|
|
|
（3）数据中心相关技术。云计算使数据中心向大型化发展，也带来节能的迫切需求。据统计，2010年数据中心能耗已经占全球总能耗的1.3%，绿色化刻不容缓。
|
|
|
|
在数据中心的能耗中，IT设备、制冷系统和供配电系统占主要部分，因此数据中心的节能技术主要围绕这三个方面。对于IT设备而言，其节能技术发展重点是在相同负载下，通过虚拟化、处理器降频、自动休眠和关闭内核等技术，使设备在获得更好性能的同时降低耗电量。对制冷系统来说，一方面可通过尽量采用自然冷却（Free Cooling）的方式降低能耗；另一方面，可通过热管理技术（冷热风道设计、送风和会风路径设计等）改善数据中心气流组织，实现制冷量的精确供给和按需分配，从而节省制冷系统的能耗。对供配电系统来说，主要节能技术包括选用高效率的、模块化的UPS电源；进行合理的IT设备与供电设备布局，减少供电线路损耗；采用高压直流提高供电可靠性和电源使用率、降低电量损耗并增强系统可维护性。
|
|
|
|
|
|
云计算“操作系统”的主要关键技术包括实现底层资源池化管理的“资源池”管理技术和向用户提供大规模存储、计算能力的分布式任务和数据管理技术。
|
|
|
|
（1）“资源池”管理技术。“资源池”管理技术主要实现对物理资源、虚拟资源的统一管理，并根据用户需求实现虚拟资源（虚拟机、虚拟存储空间等）的自动化生成、分配、回收和迁移，用以支持用户对资源的弹性需求。
|
|
|
|
云计算“资源池”管理技术与传统IT管理软件的主要区别是实现了虚拟资源的“热迁移”，即在物理主机发生故障或需要进行维护操作时，将运行在其上的虚拟机迁移至其他物理主机，同时保证用户业务不被中断。
|
|
|
|
“热迁移”的重要前提是物理服务器使用共享存储器，并且虚拟机的迁移与网络配置的迁移同时进行。
|
|
|
|
（2）分布式任务和数据管理技术。云计算对分布式任务和数据管理的需求主要来源于业界对“大数据”的处理需求。分布式任务管理技术要实现在底层大规模ICT资源上进行分布式的海量计算，并对大量结构化与非结构化的数据进行存储与管理。
|
|
|
|
|
|
|
|
计算多样化的时代，数据的爆炸愈演愈烈，人工智能、虚拟现实等技术的突飞猛进对高性能计算的需求陡然剧增，CPU性能增速放缓，由CPU和GPU构成的异构加速计算体系，成为整个计算领域的必然趋势，GPU在高性能计算领域的作用愈发明显。
|
|
|
|
AI基础设施市场爆发，GPU用量猛增。近几年，国家政策的导向与资本市场的推动造就了人工智能产业的快速发展，生态逐渐趋于完善，在一定程度上拉动了对基础设施的算力需求。GPU服务器的超强并行计算能力与人工智能相得益彰，得到长足发展。
|
|
|
|
GPU云化可大幅缩减交付周期与使用成本，降低使用门槛。GPU服务器势头强劲的同时也伴随一些问题，服务器造价高昂、交付实施周期长、配置复杂等限制了GPU的使用范围。GPU云化成为破解这一症结的有效方案，GPU云主机可以实现小时级的快速交付，更及时地响应用户需求，灵活的计费模式实现真正的按需计费，大大减少了使用成本。GPU云服务使GPU的强大算力向更宽广的范围蔓延，深度赋能产学研领域。
|
|
|
|
GPU云服务可针对不同应用场景优化配置，易用性大幅提升。根据中国信息通信研究院的可信云GPU评估结果显示，国内主流云服务商的GPU产品均针对特定的使用场景进行了优化，对科学计算、图形渲染、机器学习、视频解码等热门应用领域分别推出不同规格的实例，更加贴合应用；预先集成的GPU加速框架，免除了纷繁复杂的配置工作。
|
|
|
|
|
|
（1）微服务架构技术发展愈加成熟。微服务作为一种崭新的分布式应用解决方案在近两年获得迅猛发展。微服务指将大型复杂软件应用拆分成多个简单应用，每个简单应用描述着一个小业务，系统中的各个简单应用可被独立部署，各个应用之间是松耦合的，每个应用仅关注于完成一件任务并很好地完成该任务。相比传统的单体架构，微服务架构具有降低系统复杂度、独立部署、独立扩展、跨语言编程等特点。与此同时，架构的灵活、开发的敏捷同时带来了运维的挑战。应用的编排、服务间的通信成为微服务架构设计的关键因素。目前，在微服务技术架构实践中主要有侵入式架构和非侵入式架构两种实现形式。
|
|
|
|
（2）微服务架构行业应用深入，侵入式架构占据主流市场。微服务架构在行业生产中得到了越来越广泛的应用，例如Netflix已经有大规模生产级微服务的成功实践。而以SpringCloud和Dubbo为代表的传统侵入式开发架构占据着微服务市场的主流地位。侵入式架构将流程组件与业务系统部署在一个应用中，实现业务系统内的工作流自动化。随着微服务架构在行业应用中的不断深入，其支持的业务量也在飞速发展，对于架构平台的要求也越来越高。由于侵入式架构本身服务与通信组件互相依赖，当服务应用数量越来越多时，侵入式架构在服务间调用、服务发现、服务容错、服务部署、数据调用等服务治理层面将面临新的挑战。
|
|
|
|
（3）服务网格推动微服务架构进入新时代。服务网格是一种非侵入式架构，负责应用之间的网络调用、限流、熔断和监控，可以保证应用的调用请求在复杂的微服务应用拓扑中可靠地穿梭。服务网格通常由一系列轻量级的网络代理组成（通常被称为SideCar模式），与应用程序部署在一起，但应用程序不需要知道它们的存在。服务网格通过服务发现、路由、负载均衡、健康检查和可观察性来帮助管理流量。自2017年初第一代服务网格架构Linkerd公开使用之后，Envoy、Conduit等新框架如雨后春笋般不断涌现。2018年初Google、IBM和Lyft联合开发的项目Istio的发布，标志着服务网格带领微服务架构进入新的时代。
|
|
|
|
|
|
近年来，互联网服务从最早的物理服务器托管、虚拟机、容器，发展到如今的函数即服务（FaaS），即无服务架构。无服务架构是一种特殊类型的软件体系结构，在没有可见的进程、操作系统、服务器或者虚拟机的环境中执行应用逻辑，这样的环境实际上运行在操作系统之上，后端使用物理服务器或者虚拟机。它是一种“代码碎片化”的软件架构范式，通过函数提供服务。函数即一个可以在容器内运行的小的代码包，提供的是相比微服务更加细小的程序单元。具体的事件会唤醒函数，当事件处理完成时完成调用，代码消失。
|
|
|
|
2014年，AWS推出首个业界云函数服务Lambda。随后几年，各大云计算厂商相继推出自己的云函数服务，不同厂商的函数计算服务所支持的编程语言和函数触发的事件源各有不同。随着无服务架构的兴起，越来越多的开源项目如OpenWhisk、OpenFaaS、Kuberless等开始参与其中，并凭借各自特点正在影响着无服务架构的技术走向。
|
|
|
|
无服务架构将服务器与应用解耦，降低了运维成本，带动了规模经济效益。无服务架构的横向伸缩是完全自动化高弹性的，由于只调用很小的代码包，调用和释放的速度更快了，用户只需为自身需要的计算能力付费，计费粒度可细化至秒级。服务器部署、存储和数据库相关的所有复杂性工作都交由服务商处理，软件开发人员只需专注于与核心业务相关的开发工作，更有效地贯彻敏捷开发理念。同时，服务商运营管理着预定义的应用进程甚至是程序逻辑，当同时共用同一服务的用户达到一定量级将会带来较大的规模经济效益。
|
|
|
|
无服务架构促进持续部署成为新常态。无服务架构可以用来实现业务灵活性的持续部署。通过全自动化的基础设施堆栈的配置和代码部署，让任何并入主干中的代码更改都自动升级到包括生产环境在内的所有环境，可以对任何环境进行应用或回滚变更。当前主流技术架构下持续部署对许多公司仍旧难以实现，无服务技术可以有效弥补用户运维水平的不足，将持续部署带来的红利惠及更广范围。
|
|
|
|
无服务架构打破了以往的惯性思维，并提供了一个极具成本效益的服务。无服务架构仅有两年的历史，目前仍处于起步阶段。但在未来这个领域还会有更大的进步，它将带来软件开发和应用程序部署的一种全新体验。
|
|
|
|
|
|
（1）IT运维从基础运维向平台运维、应用运维转型升级。随着云计算的发展，IT系统变得越发复杂，运维对象开始由运维物理硬件的稳定性和可靠性演变为能够自动化部署应用、快速创建和复制资源模板、动态扩缩容系统部署、实时监控程序状态，以保证业务持续稳定运行的敏捷运维。同时，开发、测试、运维等部门的工作方式由传统瀑布模式向DevOps（研发运营一体化）模式转变。从软件生命周期来看，第一阶段开发侧需运用敏捷实践处理内部的效率问题，第二阶段需基于持续集成构建持续交付，解决测试团队、运维上线的低效问题，第三阶段持续反馈需使用可重复、可靠的流程进行部署，监控并验证运营质量，并放大反馈回路，使组织及时对问题做出反应并持续优化更改，以提高软件交付质量，加快软件发布速度。
|
|
|
|
（2）DevOps提升软件生命周期效率。DevOps被定义为一组过程、方法与系统的统称，强调优化开发（Dev）、质量保障（QA）、运维（Ops）部门之间的沟通合作，解决运维人员人工干预较多、实时性差等痛点，变被动运维为主动运维，通过高度自动化工具链打通软件产品交付过程，使得软件构建、测试、发布更加快捷、频繁和可靠。据中国信息通信研究院的DevOps能力成熟度评估结果显示，金融机构核心业务仍采用集中式管理方式为主，但外围业务已经开始或已使用了分布式架构，自动化、智能化运维推动金融行业的业务创新。而运营商向云化转型则更注重对云管理平台的需求，如能够支持资源的动态分配和调度、业务监控、故障分析预警、数据库监控以及日常运维的全流程。随着非结构化数据数量激增，运营商通过数据挖掘和分析技术，以提升客户满意度和业务效率是未来的发展目标。DevOps实践贯穿软件全生命周期，提升了传统行业整体效率。
|
|
|
|
（3）智能化运维将成未来发展趋势。DevOps拉通了运维管理体系，海量数据计算、存储、应用和安全等多种需求出现，运维需借助先进的自动化运维管理模式来实现大体量下的系统管理。在大数据技术的背景下，智能运维AIOps被提出，即Artificial Intelligence for IT Operations。AIOps是将人工智能应用于运维领域，通过机器学习的方式对采集的运维数据（日志、监控信息、应用信息等）做出分析、决策，从而达到运维系统的整体目标。目前，AIOps主要围绕质量保障、成本管理和效率提升三方面逐步构建智能化运维场景，在质量保障方面，保障现网稳定运行细分为异常检测、故障诊断、故障预测、故障自愈等基本场景；在成本管理方面，细分为指标监控、异常检测、资源优化、容量规划、性能优化等基本场景；在效率方面，分为智能预测、智能变更、智能问答、智能决策等基本场景。AIOps虽然在互联网、金融等行业有所应用，但仍处于发展初期，未来智能化运维将成为数据分析应用的新增长点和发展趋势。
|
|
|
|
|
|
边缘计算是指在靠近物或数据源头的网络边缘侧，融合网络、计算、存储、应用核心能力的开放平台，就近提供边缘智能服务，满足行业数字化在敏捷联接、实时业务、数据优化、应用智能、安全与隐私保护等方面的关键需求。
|
|
|
|
边缘计算与云计算互为补充。在当今物联网迅猛发展的阶段，边缘计算作为物联网的“神经末梢”，提供了对于计算服务需求较快的响应速度，通常情况下不将原始数据发回云数据中心，而直接在边缘设备或边缘服务器中进行数据处理。云计算作为物联网的“大脑”，会将大量边缘计算无法处理的数据进行存储和处理，同时会对数据进行整理和分析，并反馈到终端设备，增强局部边缘计算能力。
|
|
|
|
边缘计算与云计算协同发展，打造物联网新的未来。在边缘设备上进行计算和分析的方式有助于降低关键应用的延迟、降低对云的依赖，能够及时地处理物联网生成的大量数据，同时结合云计算特点对物联网产生的数据进行存储和自主学习，使物联网设备不断更新升级。以自动驾驶汽车为例，通过使用边缘计算和云计算技术，自动驾驶汽车上的边缘设备将传感器收集的数据在本地进行处理，并及时反馈给汽车控制系统，完成实时操作；同时，收集的数据会发送至云端进行大规模学习和处理，使自动驾驶汽车的AI在可用的情况下从云端获取更新信息，并增强局部边缘的神经网络。
|
|
|
|
|
|
云网融合已经成为ICT发展的趋势。伴随着互联网进入大流量、广互联时代，业务需求和技术创新并行驱动加速网络架构发生深刻变革，云和网高度协同，不再各自独立。云计算业务的开展需要强大的网络能力的支撑，网络资源的优化同样要借鉴云计算的理念，随着云计算业务的不断落地，网络基础设施需要更好的适应云计算应用的需求，更好的优化网络结构，以确保网络的灵活性、智能性和可运维性。
|
|
|
|
云间互联是云网融合的一个典型场景。以云间互联为目标的网络部署需求日益旺盛。随着云计算产业的成熟和业务的多样化，企业可根据自身业务需求和实际成本情况选择不同的云服务商提供的云服务，这也形成了丰富的云间互联业务场景，如公有云内部互通、混合云和跨云服务商的公有云互通。据中国信息通信研究院的混合云评估结果显示，当前混合云的组网技术主要以VPN和专线为主，而SD-WAN由于其快速开通、灵活弹性、按需付费等特性也逐渐被人们所关注。在云间互联场景下，云网融合的趋势逐渐由“互联”向“云+网+ICT服务”和“云+网+应用”过渡，云间互联只是过程，最终目的是达成云网和实际业务的高度融合，包括服务资源的动态调整、计算资源的合理分配以及定制化的业务互通等。
|
|
|
|
云网融合的另一个场景是电信云。电信云基于虚拟化、云计算等技术实现电信业务云化，基于NFV、SDN实现网络功能自动配置和灵活调度，基于管理与编排实现业务、资源和网络的协同管理和调度。电信云与云间互联不同，它更关注的是运营商网络的云化转型，包括核心网、接入网、传输网以及业务控制中心等多个层面的网元都可以按云化的方式部署，最终实现运营商网络的软化和云化。
|
|
|
|
|
|
如今，开源社区逐渐成为云计算各巨头的战场，云计算厂商开始纷纷拥抱开源技术。
|
|
|
|
（1）容器方面。2017年，微软、AWS等云计算巨头厂商先后以白金会员身份加入Linux基金会旗下的云原生计算基金会（CNCF），以加强对Kubernetes开源技术的支持。阿里云更是在2017年两度晋级，从黄金会员到白金会员。截至2018年3月，CNCF白金会员的数量达到18家，黄金会员数量8家，银牌会员的数量148家。
|
|
|
|
（2）虚拟化管理方面。以全球最大的云计算开源社区OpenStack为例，截止到2018年7月，共有白金会员8家，黄金会员20家，合作伙伴104家。其中，我国企业占据了一半的黄金会员席位。同时，华为、九州云、烽火通信、EasyStack、中兴等厂商在OpenStack各版本贡献中持续处于全球前列。此外，OpenStack基金会的会员还包括Intel、Red Hat、Rackspace、爱立信等国际巨头厂商。
|
|
|
|
|
|
|
|
与传统IT系统相比，云计算面临的风险点发生变化，主要体现在如下几个方面：
|
|
|
|
（1）传统安全边界消失。传统自有IT系统是封闭的，对外暴露的只是网页服务器、邮件服务器等少数接口。因此，传统IT系统以“边界”为核心，利用防火墙、入侵防御等手段可以有效阻挡攻击。而在云计算环境下，云暴露在公开的网络中，虚拟化技术使得安全边界概念消失，基于物理安全边界的防护机制难以在云计算环境中得到有效的应用。
|
|
|
|
（2）用户具有动态性。云计算环境下，用户的数量和分类变化频率高，具有动态性和移动性强的特点，静态的安全防护手段作用被削弱，安全防护措施需要进行动态调整。
|
|
|
|
（3）更高的数据安全保护要求。云计算将资源和数据的所有权、管理权和使用权进行了分离，资源和数据不在本地存储，用户失去了对资源和数据的直接控制，再也不能像传统信息系统那样通过物理控制、逻辑控制、人员控制等手段对数据的访问进行控制。面对用户数据安全保护的迫切诉求和庞大的数据规模，云计算企业需要具有更高的数据安全保护水平和更先进的数据保护手段，以避免数据不可用、数据泄露等风险。
|
|
|
|
（4）合规检查更难。云计算企业必须符合广泛的、不断变化的法律法规要求。随着信息领域的迅速发展，各国、各行业都在加强相关的法律法规建设，云计算企业合规清单不断壮大，涉及网络、数据、信息等方方面面。由于云计算可能存在数据存储位置未知、数据来源难追溯、安全控制和责任缺乏透明性等问题，使得云计算企业和云客户在面临合规性检查时存在困难。如今年生效的欧盟《一般数据保护条例》（GDPR），首次对数据处理者的数据保护能力进行严格要求，赋予数据主体更多的权利，适用范围也大幅扩张。对于云服务商来说，在欧盟境内设立分支机构或服务于欧盟客户时应满足GDPR要求，而即使服务于非欧盟客户，非欧盟客户又服务于欧盟客户时，云服务商也适用GDPR。不仅适用场景繁多，云服务商为满足GDPR要求所开展的工作也更加复杂。数据遍布于云环境，如何提高数据掌控与保护能力，满足用户多种权利，如何快速识别数据泄露事件，及时上报监管部门，都是云服务商合规的难点。
|
|
|
|
（5）多种外部风险。云计算企业搭建云平台时，可能会涉及购买第三方厂商的基础设施、运营商的网络服务等情况。基础设施、网络等都是决定云平台稳定运行的关键因素。因此，第三方厂商和运营商的风险管理能力将影响云计算企业风险事故的发生情况。同时，云计算企业在运营时，可能将数据处理与分析等工作分包给第三方合作企业，分包环节可能存在数据跨境处理、多方责任难界定等风险。
|
|
|
|
如下图所示云计算安全风险架构，对于云计算平台，IaaS层主要考虑基础设施相关的安全风险，PaaS层需要保证运行环境和信息的安全，SaaS层从应用、Web、网络、业务、内容、数据等方面保证应用安全。在云平台的运营过程中，涉及复杂的人员风险、管理流程风险和合规风险。同时，云计算开源技术使用率不断攀升，开源风险也成为云计算领域的关注重点。
|
|
|
|
|
|
|
|
|
|
不同云计算企业提供云服务的侧重点不同，企业在使用云服务时，可能会涉及与多个云服务商的合作。任何一个云服务的参与者都需要承担相应的责任，不同角色的参与者在承担各自责任的同时，还需要与其他参与者协同合作，共同规避云平台风险事件的发生。
|
|
|
|
云计算责任共担模式在业界已经达成共识，但还没有统一的责任共担模型。已有部分厂商根据业务特点，建立了自己的责任共担模型。以亚马逊AWS为例，AWS作为IaaS+PaaS为主的服务提供商，负责管理云本身的安全，即保护运行所有AWS云服务的基础设施。客户负责“云内部的安全”，即业务系统安全。这种模式对于国内市场来说，可能会有局限性。在国内，尤其对于SaaS模式，很多用户仍会有“上云，安全就由云服务商负责”的误解。实际上，SaaS模式下数据安全应由云服务商和客户共同负责，云客户应提高安全使用SaaS服务的能力，避免发生误删数据等风险事故。同时，不少信息技术水平较弱的客户，在接触云计算初期，安全风险防控能力不够强，购买SaaS服务后，会使用而不懂如何去进行安全防护，云服务商需要建立更强大的生态以保障云客户安全。
|
|
|
|
云服务提供商应基于云客户的需求，提供云主机等服务和相应的安全策略，同时负责维护云平台的高可用，在出现风险事件时，对基础环境、主机环境、网络环境甚至是应用环境进行故障定位、处置和总结。针对国内市场，在SaaS模式下，云服务商应充分考虑云客户安全防护能力水平，提前告知服务使用方法，在云客户存在疑问时，及时提供解答和帮助，避免发生不必要的安全事故。
|
|
|
|
云客户应基于云服务提供商提供的服务产品使用和安全说明，正确使用服务或产品，避免因为误操作、疏忽等因素造成云平台的风险，同时云客户应按照本公司风险管理要求，对云上信息系统进行风险评估与治理。
|
|
|
|
数据保护贯穿数据使用的整个生命周期，需要云客户与云服务提供商共同维护数据安全。
|
|
|
|
|
|
传统IT系统在进行风险管理时，主要通过安全厂商进行安全检查、基于安全软件实现安全防护，而随着云计算风险点和风险责任的变化，除安全厂商外，云计算风险管理需要联动社会多方以提高风险管理能力，包括保险企业、第三方认证机构、监督管理机构等。
|
|
|
|
云计算风险管理手段主要包括：通过事前评估规避风险、事中监控发现风险、事后处置解决风险，建立完善的风险评估体系，全方位保障云平台稳定运行；以金融带动风险管理发展，通过云保险分担事故带来的损失；联合云计算企业、云客户、安全厂商多方建立云计算风险信息共享平台，实现企业互惠共赢。
|
|
|
