精华内容
下载资源
问答
  • 云计算简介

    万次阅读 2018-03-27 21:16:44
     (3)、CCRA的分层框架包括4 层,以及一个跨越各层的跨层功能集合。四层分别是:用户层、访问层、服务层、资源层。跨越各层的功能称为跨层功能。  云计算的7类主要支撑技术 :  (1)、系统虚拟化:是指将一台物理...

            什么是”云”:迁移至云端。在云中运行。在云中存储。从云端访问----当今时代,似乎一切都在"云"中进行。但是,"云"究竟是一个什么样的概念?简单来说,云就是互联网连接的另一端,你可以从云端访问各种应用程序和服务,也可以在云端安全存储你的数据。"云"之所以如此强大,有以下三个原因:你不需要对"云"进行维护或管理;云端可以有效扩容至无限大,因此你无需担心云容量不够用;你可以随时随地访问基于云的各种应用程序和服务,而你只需要一台可以连接互联网的设备即可。借助云应用程序,你只需打开浏览器并登录,即可开始工作。

            云是网络、互联网的一种比喻说法。过去在图中往往用云来表示电信网,后来也用来表示互联网和底层基础设施的抽象。因此,云计算甚至可以让你体验每秒10万亿次的运算能力,拥有这么强大的计算能力可以模拟核爆炸、预测气候变化和市场发展趋势。用户通过电脑、笔记本、手机等方式接入数据中心,按自己的需求进行运算。

            云计算(Cloud Computing)的定义

            (1)、云计算是一种将可伸缩、弹性、共享的物理和虚拟资源池以按需自服务的方式供应和管理,并提供网络访问的模式。云计算模式由关键特征、云计算角色和活动、云能力类型和云服务分类、云部署模型、云计算共同关注点组成。

            (2)、云计算是一种基于互联网的计算方式,通过这种方式,共享的软硬件资源和信息可以按需求提供给计算机各种终端和其它设备。

            (3)、云计算是一种按使用量付费的模式,这种模式提供可用的、便捷的、按需的网络访问,进入可配置的计算资源共享池(资源包括网络,服务器,存储,应用软件,服务),这些资源能够被快速提供,只需投入很少的管理工作,或与服务供应商进行很少的交互。

            云计算是分布式计算(Distributed Computing)、并行计算(Parallel Computing)、效用计算(Utility Computing)、网络存储(Network Storage Technologies)、虚拟化(Virtualization)、负载均衡(Load Balance)、热备份冗余(High Available)等传统计算机和网络技术发展融合的产物

    云计算的关键特征

            (1)、广泛的网络接入:可通过网络,采用标准机制访问物理和虚拟资源的特性。这里的标准机制有助于通过异构用户平台使用资源。这个关键特性强调云计算使用户更方便地访问物理和虚拟资源:用户可以从任何网络覆盖的地方,使用各种客户端设备,包括移动电话、平板、笔记本和工作站访问资源。

            (2)、可测量的服务:通过可计量的服务交付使得服务使用情况可监控、控制、汇报和计费的特性。通过该特性,可优化并验证已交付的云服务。这个关键特性强调客户只需对使用的资源付费。从客户的角度看,云计算为用户带来了价值,将用户从低效率和低资产利用率的业务模式转变到高效率模式。

            (3)、多租户:通过对物理或虚拟资源的分配保证多个租户以及他们的计算和数据彼此隔离和不可访问的特性。在典型的多租户环境下,组成租户的一组云服务用户同时也属于一个云服务客户组织。在某些情况下,尤其在公有云和社区云部署模型下,一组云服务用户由来自不同客户的用户组成。一个云服务客户组织和一个云服务提供者之间也可能存在多个不同的租赁关系。这些不同的租赁关系代表云服务客户组织内的不同小组。

            (4)、按需自服务:云服务客户能根据需要自动,或通过与云服务提供者的最少交互,配置计算能力的特性。这个关键特性强调云计算为用户降低了时间成本和操作成本,因为该特性赋予了用户无需额外的人工交互,就能够在需要的时候做需要做的事情的能力。

            (5)、快速的弹性和可扩展性:物理或虚拟资源能够快速、弹性,有时是自动化地供应,以达到快速增减资源目的的特性。对云服务客户来说,可供应的物理或虚拟资源无限多,可在任何时间购买任何数量的资源,购买量仅仅受服务协议的限制。这个关键特性强调云计算意味着用户无需再为资源量和容量规划担心。对客户来说,如果需要新资源,新资源就能立刻自动地获得。资源本身是无限的,资源的供应只受服务协议的限制。

            (6)、资源池化:将云服务提供者的物理或虚拟资源进行集成,以便服务于一个或多个云服务客户的特性。这个关键特性强调云服务提供者既能支持多租户,又通过抽象对客户屏蔽了处理复杂性。对客户来说,他们仅仅知道服务在正常工作,但是他们通常并不知道资源是如何提供或分布的。资源池化将原本属于客户的部分工作,例如维护工作,移交给了提供者。需要指出的是,即使存在一定的抽象级别,用户仍然能够在某个更高的抽象级别指定资源位置。

            云能力类型:是根据资源的使用情况,对为云服务客户提供的云服务的功能进行的分类。有三类不同的云能力类型:应用能力类型、基础设施能力类型和平台能力类型。这三类能力类型有不同的关注点,即相互之间的功能交叉最少。这些云能力类型不应与云服务类别混淆。

            (1)、应用能力类型:云服务客户能使用云服务提供者的应用的一类云能力类型。

            (2)、基础设施能力类型:云服务客户能配置和使用计算、存储和网络资源的一类云能力类型。

            (3)、平台能力类型:云服务客户能使用云服务提供者支持的编程语言和执行环境,部署、管理和运行客户创建或客户获取的应用的一类云能力类型。

             云服务类别:是拥有相同质量集的一组云服务。一种云服务类别可对应一种或多种云能力类型。典型的云服务类别包括:

            (1)、通讯即服务(CaaS):为云服务客户提供实时交互与协作能力的一种云服务类别。

            (2)、计算即服务(CompaaS):为云服务客户提供部署和运行软件所需的配置和使用计算资源能力的一种云服务类别。

            (3)、数据存储即服务(DSaaS):为云服务客户提供配置和使用数据存储相关能力的一种云服务类别。

            (4)、基础设施即服务(Infrastructure as a Service, IaaS):为云服务客户提供云能力类型中的基础设施能力类型的一种云服务类别。使用IaaS时,你以即用即付的方式从服务提供商处租用IT基础设施,如服务器和虚拟机(VM)、存储空间、网络和操作系统。IaaS的优点:无须自己投资硬件;可按需扩展基础设施规模,以便支持不断变化的工作负载;灵活、创新而且按需提供的服务。

            (5)、网络即服务(NaaS):为云服务客户提供传输连接和相关网络能力的一种云服务类别。

            (6)、平台即服务(Platform as a Service, PaaS):为云服务客户提供云能力类型中的平台能力类型的一种云服务类别。PaaS是指云计算服务,它们可以按需提供开发、测试、交付和管理软件应用程序所需的环境。PaaS旨在让开发人员能够更轻松地快速构建Web或移动应用,而无需考虑开发所必须的服务器、存储空间、网络和数据库基础设施进行设置或管理。PaaS的优点:开发应用,更快地打入市场;只需数分钟,就可以将新的Web应用程序部署到云中;使用中间件即服务,降低复杂性。

            (7)、软件即服务(Software as a Service, SaaS):为云服务客户提供云能力类型中的应用能力类型的一种云服务类别。在”软件即服务”的服务模式当中,用户能够访问服务软件及数据。服务提供者则维护基础设施及平台以维持服务正常运作。SaaS使得企业能够借由外包硬件、软件维护及支持服务给服务提供者来降低IT营运费用。另外,由于应用程序是集中供应的,更新可以即时的发布,无需用户手动更新或是安装新的软件。SaaS是通过Internet交付软件应用程序的方法,通常以订阅为基础按需提供。使用SaaS时,云提供商托管并管理软件应用程序和基础设施,并负责软件升级和安全修补等维护工作。用户(通常使用电话、平板电脑或PC上的Web浏览器)通过Internet连接到应用程序。SaaS的优点:你可以注册并快速开始使用创新的业务应用;在任何已连接的计算机上都可以访问应用和数据;如果你的计算机出现故障,数据也不会丢失,因为数据在云中;这种服务可以根据使用需要进行动态扩展。SaaS的缺陷在于用户的数据是存放在服务提供者的服务器之上,使得服务提供者有能力对这些数据进行未经授权的访问。

            典型的云计算部署模式:云计算有四类典型的部署模式:”公有云”、”私有云”、”社区云”和”混合云”。具体描述如下:

            (1)、公有云:云基础设施对公众或某个很大的业界群组提供云服务。公有云服务可通过网络及第三方服务供应者,开放给客户使用,”公有”一词并不一定代表”免费”,但也可能代表免费或相当廉价,公有云并不表示用户数据可供任何人查看,公有云供应者通常会对用户实施使用访问控制机制,公有云作为解决方案,既有弹性,又具备成本效益。公有云为第三方云服务提供商所拥有和运营,他们通过Internet提供其计算资源(如服务器和存储空间)。在公有云中,所有硬件、软件和其它支持性基础设施均为云提供商所拥有和管理。使用Web浏览器访问这些服务和管理你的账户。

            (2)、私有云:云基础设施特定为某个组织运行服务,可以是该组织或某个第三方负责管理,可以是场内服务(on-premises),也可以是场外服务(off-premises)。私有云具备许多公有云环境的优点,例如弹性、适合提供服务,两者差别在于私有云服务中,数据与程序皆在组织内管理,且与公有云服务不同,不会受到网络带宽、安全疑虑、法规限制影响;此外,私有云服务让供应者及用户更能掌控云基础架构、改善安全与弹性,因为用户与网络都受到特殊限制。私有云是指专供一个企业或组织使用的云计算资源。私有云可以实际位于公司的现场数据中心之上。某些公司还向第三方服务提供商付费托管其私有云。在私有云中,在专用网络上维护服务和基础设施。

            (3)、社区云:云基础设施由若干个组织分享,以支持某个特定的社区。社区是指有共同诉求和追求的团体(例如使命、安全要求、政策或合规性考虑等)。和私有云类似,社区云可以是该组织或某个第三方负责管理,可以是场内服务,也可以是场外服务。社区云由众多利益相仿的组织掌控及使用,例如特定安全要求、共同宗旨等。社区成员共同使用云数据及应用程序。

            (4)、混合云:云基础设施由两个或多个云(私有云、社区云或公有云)组成,独立存在,但是通过标准的或私有的技术绑定在一起,这些技术可促成数据和应用的可移植性(例如用于云之间负载分担的cloud bursting技术)。这个模式中,用户通常将非企业关键信息外包,并在公有云上处理,但同时掌控企业关键服务及数据。混合云通过允许在公有云和私有云之间共享数据和应用程序的技术将它们绑定到一起。通过允许数据和应用程序在私有云和公有云之间移动,混合云为企业提供更大的灵活性和更多的部署选项。

            云计算参考架构(Cloud Computing Reference Architecture,简称CCRA):CCRA从四个不同的视角描述了云计算:用户视角、功能视角、实现视角、部署视角。

            (1)、用户视角涉及云计算活动,角色和子角色,参与方,云能力类型和云服务类别,云部署模型和共同关注点等云计算概念。其中,角色是一组具有相同目标的云计算活动的集合。其中云计算的角色包括:云服务客户,云服务提供者,云服务协作者。共同关注点指的是需要在不同角色之间协调,且在云计算系统中一致实现的行为或能力。共同关注点包含可审计性,可用性,治理,互操作性,维护和版本控制,性能,可移植性,隐私,法规,弹性,可复原性,安全,服务水平和服务水平协议等。

            (2)、CCRA认为云计算功能架构用一组高层的功能组件来描述云计算。功能组件代表了为执行与云计算相关的各种角色和子角色的云计算活动的功能集合。功能架构通过分层框架来描述组件。在分层框架中,特定类型的功能被分组到各层中,相邻层次的组件之间通过接口交互。功能视图涵盖了功能组件,功能层和跨层功能等云计算概念。

            (3)、CCRA的分层框架包括4 层,以及一个跨越各层的跨层功能集合。四层分别是:用户层、访问层、服务层、资源层。跨越各层的功能称为跨层功能。

            云计算的7类主要支撑技术

            (1)、系统虚拟化:是指将一台物理计算机系统虚拟化为一台或多台虚拟计算机系统。每个虚拟计算机系统(简称虚拟机)都拥有自己的虚拟硬件(如CPU、内存和设备等),来提供一个独立的虚拟机执行环境。通过虚拟化层的模拟,虚拟机中的操作系统认为自己仍然是独占一个系统在运行。每个虚拟机中的操作系统可以完全不同,并且它们的执行环境是完全独立的。这个虚拟化层被称为虚拟机监控器(Virtual Machine Monitor,简称VMM)。

            虚拟机可以看作是物理机的一种高效隔离的复制。虚拟机具有三个典型特征:同质、高效和资源受控。同质指的是虚拟机运行环境和物理机环境在本质上需求是相同的,但是在表现上有一些差异。高效指的是虚拟机中运行的软件需要具有接近在物理机上直接运行的性能。资源受控指的是VMM需要对系统资源有完全控制能力和管理权限,包括资源的分配、监控和回收。

            VMM对物理资源的虚拟可以归结为三个主要任务:CPU虚拟化、内存虚拟化和I/O 虚拟化。CPU虚拟化是VMM中最核心的部分,决定了内存虚拟化和I/O虚拟化的正确实现。CPU虚拟化包括指令的模拟、中断和异常的模拟及注入和对称多处理器技术的模拟。内存虚拟化一方面解决了VMM和客户机操作系统对物理内存认识上的差异,另一方面在虚拟机之间、虚拟机和VMM之间进行隔离,防止某个虚拟机内部的活动影响到其他的虚拟机甚至是VMM本身,从而造成安全上的漏洞。I/O 虚拟化主要是为了满足多个客户机操作系统对外围设备的访问需求,通过访问截获、设备模拟和设备共享等方式复用外设。

            按照VMM提供的虚拟平台类型可以将VMM分为两类:完全虚拟化和半虚拟化。完全虚拟化下,VMM虚拟的是现实存在的平台。在客户机操作系统看来,虚拟的平台和现实的平台是一样的,客户机操作系统觉察不到运行在一个虚拟平台上。这样的虚拟平台无需对现有的操作系统做任何修改。半虚拟化下,VMM虚拟的平台在现实中是不存在的。这样的虚拟平台需要对客户机操作系统进行修改使之适应虚拟环境。操作系统知道自己运行在虚拟平台上,并且会主动去适应。

            当前主流的虚拟化技术实现结构可以分为三类:Hypervisor模型、宿主模型和混合模型。在Hypervisor模型中,VMM可以看作是一个扩充了虚拟化功能的操作系统,对底层硬件提供物理资源的管理功能,对上层的客户机操作系统提供虚拟环境的创建和管理功能。与Hypervisor不同,宿主模型中,VMM作为宿主操作系统独立的内核模块。物理资源由宿主机操作系统管理,VMM提供虚拟化管理。宿主模型和Hypervisor模型的优缺点恰好相反。宿主模型的最大优点是可以充分利用现有操作系统的设备驱动程序以及其它功能,缺点是虚拟化效率较低,安全性取决于宿主操作系统。而Hypervisor模型虚拟化效率高、安全,但是需要自行开发设备驱动和其它一些功能。混合模型集成了上述两类模型的优点。混合模型中,VMM让出大部分I/O设备的控制权,将它们交由一个运行在特权虚拟机中的特权操作系统来控制。因此,混合模型下CPU和内存的虚拟化由VMM负责,而I/O虚拟化由VMM和特权操作系统共同合作完成。

            (2)、虚拟化资源管理:是云计算中最重要的组成部分之一,对虚拟化资源的管理水平直接影响云计算的可用性、可靠性和安全性。虚拟化资源管理主要包括对虚拟化资源的监控、分配和调度。

            云资源池中应用的需求不断改变,在线服务的请求经常不可预测,这种动态的环境要求云计算的数据中心或计算中心能够对各类资源进行灵活、快速、动态的按需调度。云计算中的虚拟化资源与以往的网络资源相比,有以下特征:数量更为巨大;分布更为离散;调度更为频繁;安全性要求更高。

            通过对虚拟化资源的特征分析以及目前网络资源管理的现状,确定虚拟化资源的管理应该满足以下准则:所有虚拟化资源都是可监控和可管理的;请求的参数是可监控的,监控结果可以被证实;通过网络标签可以对虚拟化资源进行分配和调度;资源能高效地按需提供服务;资源具有更高的安全性。

            在虚拟化资源管理调度接口方面,表述性状态转移(Representational State Transfer,简称REST)有能力成为虚拟化资源管理强有力的支撑。REST实际上就是各种规范的集合,包括Http 协议、客户端/服务器模式等。在原有规范的基础上增加新的规范,就会形成新的体系结构。而REST 正是这样一种体系结构,它结合了一系列的规范形成了一种新的基于Web的体系结构,使其更有能力来支撑云计算中虚拟化资源对管理的需求。

            (3)、分布式数据存储:分布式数据存储技术包含非结构化数据存储和结构化数据存储。其中,非结构化数据存储主要采用文件存储和对象存储技术,而结构化数据存储主要采用分布式数据库技术,特别是NoSQL数据库。下面分别阐述这三方面的技术:

            1)、分布式文件系统:为了存储和管理云计算中的海量数据,Google提出分布式文件系统GFS(Google File System)。GFS成为分布式文件系统的典型案例。Apache Hadoop项目的HDFS实现了GFS的开源版本。

            Google GFS是一个大规模分布式文件存储系统,但是和传统分布式文件存储系统不同的是,GFS在设计之初就考虑到云计算环境的典型特点:结点由廉价不可靠PC构建,因而硬件失败是一种常态而非特例;数据规模很大,因而相应的文件I/O单位要重新设计;大部分数据更新操作为数据追加,如何提高数据追加的性能成为性能优化的关键。相应的GFS在设计上有以下特点:

            A、利用多副本自动复制技术,用软件的可靠性来弥补硬件可靠性的不足。

            B、将元数据和用户数据分开,用单点或少量的元数据服务器进行元数据管理,大量的用户数据结点存储分块的用户数据,规模可以达到PB 级。

            C、面向一次写多次读的数据处理应用,将存储与计算结合在一起,利用分布式文件系统中数据的位置相关性进行高效的并行计算。

            GFS/HDFS非常适于进行以大文件形式存储的海量数据的并行处理,但是,当文件系统的文件数量持续上升时,元数据服务器的可扩展性面临极限。以HDFS为例,只能支持千万级的文件数量,如果用于存储互联网应用的小文件则有困难。在这种应用场景面前,分布式对象存储系统更为有效。

            2)、分布式对象存储系统:与分布式文件系统不同,分布式对象存储系统不包含树状名称空间(Namespace),因此在数量增长时可以更有效地将元数据平衡地分布到多个结点上,提供理论上无限的可扩展性。

            对象存储系统是传统的块设备的延伸,具有更高的”智能”:上层通过对象ID来访问对象,而不需要了解对象的具体空间分布情况。相对于分布式文件系统,在支撑互联网服务时,对象存储系统具有如下优势:

            A、相对于文件系统的复杂API,分布式对象存储系统仅提供基于对象的创建、读取、更新、删除的简单接口,在使用时更方便而且语义没有歧义。

            B、对象分布在一个平坦的空间中,而非文件系统那样的名称空间之中,这提供了很大的管理灵活性:既可以在所有对象之上构建树状逻辑结构;也可以直接用平坦的空间;还可以只在部分对象之上构建树状逻辑结构;甚至可以在同一组对象之上构建多个名称空间。

            Amazon的S3就属于对象存储服务。S3通过基于Http REST的接口进行数据访问,按照用量和流量进行计费,其他的云服务商也都提供了类似的接口服务。很多互联网服务商,如Facebook等也都构建了对象存储系统,用于存储图片、照片等小型文件。

            3)、分布式数据库管理系统:传统的单机数据库采用”向上扩展”的思路来解决计算能力和存储能力的问题,即增加CPU处理能力、内存和磁盘数量。这种系统目前最大能够支持几个TB 数据的存储和处理,远不能满足实际需求。采用集群设计的分布式数据库逐步成为主流。传统的集群数据库的解决方案大体分为以下两类:

            A、Share-Everything(Share-Something):数据库结点之间共享资源,例如磁盘、缓存等。当结点数量增大时,结点之间的通信将成为瓶颈;而且处理各个结点对数据的访问控制也为事务处理带来麻烦。

            B、Share-Nothing:所有的数据库服务器之间并不共享任何信息。当任意一个结点接到查询任务时,都会将任务分解到其他所有的结点上面,每个结点单独处理并返回结果。但由于每个结点容纳的数据和规模并不相同,因此如何保证一个查询能够被均衡地分配到集群中成为一个关键问题。同时,结点在运算时可能从其他结点获取数据,这同样也延长了数据处理时间。在处理数据更新请求时,Share-Nothing数据库需要保证多结点的数据一致性,需要快速准确定位到数据所在结点。

            云计算环境下,大部分应用不需要支持完整的SQL语义,而只需要Key-Value形式或略复杂的查询语义。在这样的背景下,进一步简化的各种NoSQL数据库成为云计算中的结构化数据存储的重要技术。

            Google的BigTable是一个典型的分布式结构化数据存储系统。在表中,数据是以”列族”为单位组织的,列族用一个单一的键值作为索引,通过这个键值,数据和对数据的操作都可以被分布到多个结点上进行。

            在开源社区中,Apache HBase使用了和BigTable类似的结构,基于Hadoop平台提供BigTable的数据模型,而Cassandra则采用了亚马逊Dynamo的基于DHT的完全分布式结构,实现更好的可扩展性。

            (4)、并行计算模式:并行计算模型是提高海量数据处理效率的常用方法。常用的并行计算模型主要包括两类:一类是面向高性能计算的,如MPI(Message Passing Interface)模型;另一类是面向互联网数据密集型应用的并行编程模型,如Google的MapReduce模型、微软的Dryad模型。第二类并行计算模型更适用于云计算环境。云计算下把海量数据分布到多个结点(通常是廉价不可靠的PC机)上,将计算并行化,利用多机的计算资源,加快数据处理的速度。

            云计算下的并行处理需要考虑以下关键问题:任务划分,使得任务能更加优化的被分解和并行执行;任务调度,操作尽量本地化,以保证在网络资源有限的情况下,最大程度地将计算任务在本地执行,减少通信开销;自动容错处理机制,保证在结点失效的情况下处理任务仍然能够正确地执行。下面分别阐述这三方面内容。

            1)、任务划分:在MapReduce或Dryad中,数据以块的形式存储在集群的各个结点上,每个计算任务只需处理一部分数据,这样自然地实现了海量数据的并行处理。这种简单的根据存储位置进行任务划分的方式,只适用于不存在数据依赖关系的计算。而对于存在依赖关系的计算,MapReduce将复杂的计算转化为一系列单一的Map/Reduce计算,串联起来完成多个Map/Reduce任务来实现复杂计算。转化有两者方式:手工转化和利用Pig、Hive等工具进行自动转化。Dyrad将存在依赖关系的复杂计算表示为一个有向无环图,利用图论对计算自动进行依赖性分析和优化,最后转化为高效的子任务执行。

            2)、任务调度:一个集群系统的存储和计算资源有两种组织方式:一是将存储和计算资源部署在相同结点上;另一种是存储和计算结点分开部署。MapReduce和Dryad采用前者,MPI采用后者。MapReduce和Dryad在调度任务时认为”移动计算比移动数据更合算”,优先把计算任务调度到数据所在的结点或者就近的结点,这样在进行计算时,大部分的输入数据都能从本地读取,减少了网络带宽的消耗,提高了整个系统的吞吐量。另外,MapReduce对于由于各种原因(例如硬盘出错)造成执行非常慢的子任务采用了备用任务的机制,当MapReduce操作接近完成时,调度备用任务进程来执行剩下的执行非常慢的子任务。

            3)、自动容错处理机制:常用恢复机制有两类:任务重做(Task Re-execute)和检查点(Checkpoint)回滚方式。这两种机制各有优缺点,前者实现非常简单,但是重做的代价比较大;后者实现较复杂,需要周期性地记录所有进程状态,但是恢复较快。MapReduce和Dryad主要采用任务重做的方式来处理结点的失效,而MPI通常采用检查点回滚的机制。

            (5)、用户交互技术:随着云计算的逐步普及,浏览器已经不仅仅是一个客户端的软件,而逐步演变为承载着互联网的平台。浏览器与云计算的整合技术主要体现在两个方面:浏览器网络化与浏览器云服务。

            国内各家浏览器都将网络化作为其功能的标配之一,主要功能体现在用户可以登录浏览器,并通过自己的帐号将个性化数据同步到服务端。用户在任何地方,只需要登录自己的帐号,就能够同步更新所有的个性内容,包括浏览器选项配置、收藏夹、网址记录、智能填表、密码保存等。

            目前的浏览器云服务主要体现在P2P下载、视频加速等单独的客户端软件中,主要的应用研究方向包括:基于浏览器的P2P下载、视频加速、分布式计算、多任务协同工作等。在多任务协同工作方面,AJAX(Asynchronous JavaScript and XML,异步JavaScript和XML)是一种创建交互式网页应用的网页开发技术,改变了传统网页的交互方式,改进了交互体验。

            (6)、安全管理:安全问题是用户是否选择云计算的主要顾虑之一。传统集中式管理方式下也有安全问题,云计算的多租户、分布性、对网络和服务提供者的依赖性,为安全问题带来新的挑战。其中,主要的数据安全问题和风险包括:

            1)、数据存储及访问控制:包括如何有效存储数据以避免数据丢失或损坏,如何避免数据被非法访问和篡改,如何对多租户应用进行数据隔离,如何避免数据服务被阻塞,如何确保云端退役(at rest)数据的妥善保管或销毁等等。

            2)、数据传输保护:包括如何避免数据被窃取或攻击,如何保证数据在分布式应用中有效传递等。

            3)、数据隐私及敏感信息保护:包括如何保护数据所有权、并可根据需要提供给受信方使用,如何将个人身份信息及敏感数据挪到云端使用等。

            4)、数据可用性:包括如何提供稳定可靠的数据服务以保证业务的持续性,如何进行有效的数据容灾及恢复等。

            5)、依从性管理:包括如何保证数据服务及管理符合法律及政策的要求等。

            相应的数据安全管理技术包括:

            1)、数据保护及隐私(Data Protection and Privacy):包括虚拟镜像安全、数据加密及解密、数据验证、密钥管理、数据恢复、云迁移的数据安全等。

            2)、身份及访问管理(Identity and Access Management,简称IAM):包括身份验证、目录服务、联邦身份鉴别/单点登陆(Single Sign on,简称SSO)、个人身份信息保护、安全断言置标语言、虚拟资源访问、多租用数据授权、基于角色的数据访问、云防火墙技术等。

            3)、数据传输(Data Transportation):包括传输加密及解密、密钥管理、信任管理等。

            4)、可用性管理(Availability Management):包括单点失败(Single Point of Failure,简称SPoF)、主机防攻击、容灾保护等。

            5)、日志管理(Log Management):包括日志系统、可用性监控、流量监控、数据完整性监控、网络入侵监控等。

            6)、审计管理(Audit Management):包括审计信任管理、审计数据加密等。

            7)、依从性管理(Compliance Management):包括确保数据存储和使用等符合相关的风险管理和安全管理的规定要求。

            (7)、运营支撑管理:为了支持规模巨大的云计算环境,需要成千上万台服务器来支撑。如何对数以万计的服务器进行稳定高效地运营管理,成为云服务被用户认可的关键因素之一。下面从云的部署、负载管理和监控、计量计费、服务水平协议(Service Level Agreement,简称SLA)、能效评测这五个方面分别阐述云的运营管理。

            1)、云的部署:包括两个方面:云本身的部署和应用的部署。如前所述,云一方面规模巨大,另一方面要求很好的服务健壮性、可扩展性和安全性。因此,云的部署是一个系统性的工程,涉及到机房建设、网络优化、硬件选型、软件系统开发和测试、运维等各个方面。为了保证服务的健壮性,需要将云以一定冗余部署在不同地域的若干机房。为了应对规模的不断增长,云要具备便利的、近乎无限的扩展能力,因而从数据存储层、应用业务层到接入层都需要采用相应的措施。为了保护云及其应用的安全,需要建立起各个层次的信息安全机制。除此之外,还需要部署一些辅助的子系统,如管理信息系统(MIS)、数据统计系统、安全系统、监控和计费系统等,他们帮助云的部署和运营管理达到高度自动化和智能化的程度。

            云本身的部署对云的用户来说是透明的。一个设计良好的云,应使得应用的部署对用户也是透明和便利的。这依赖云提供部署工具(或API)帮助用户自动完成应用的部署。一个完整的部署流程通常包括注册、上传、部署和发布四个过程。

            2)、负载管理和监控:云的负载管理和监控是一种大规模集群的负载管理和监控技术。在单个结点粒度,它需要能够实时地监控集群中每个结点的负载状态,报告负载的异常和结点故障,对出现过载或故障的结点采取既定的预案。在集群整体粒度,通过对单个结点、单个子系统的信息进行汇总和计算,近乎实时地得到集群的整体负载和监控信息,为运维、调度和成本提供决策。与传统的集群负载管理和监控相比,云对负载管理和监控有新的要求:首先,新增了应用粒度,即以应用为粒度来汇总和计算该应用的负载和监控信息,并以应用为粒度进行负载管理。应用粒度是可以再细分的。粒度甚至精细到API调用的粒度。其次,监控信息的展示和查询现在要作为一项服务提供给用户,而不仅仅是少量的专业集群运维人员,这需要高性能的数据流分析处理平台的支持。

            3)、计量计费:云的主要商业运营模式是采取按量计费的收费方式,即便对于私有云,其运营企业或组织也可能有按不同成本中心进行成本核算的需求。为了精确的度量”用了多少”,就需要准确的、及时的计算云上的每一个应用服务使用了多少资源,这称为服务计量。

            服务计量是一个云的支撑子系统,它独立于具体的应用服务,像监控一样能够在后台自动地统计和计算每一个应用在一定时间点的资源使用情况。对于资源的衡量维度主要是:应用的上行(in)/下行(out)流量、外部请求响应次数、执行请求所花费的CPU时间、临时和永久数据存储所占据的存储空间、内部服务API调用次数等。也可认为,任何应用使用或消耗的云的资源,只要可以被准确的量化,就可以作为一种维度来计量。实践中,计量通常既可以用单位时间内资源使用的多少来衡量,如每天多少字节流量;也可以用累积的总使用量来衡量,如数据所占用的存储空间字节大小。

            在计量的基础上,选取若干合适的维度组合,制定相应的计费策略,就能够进行计费。计费子系统将计量子系统的输出作为输入,并将计费结果写入帐号子系统的财务信息相关模块,完成计费。计费子系统还产生可供审计和查询的计费数据。

            4)、SLA:是在一定开销下为保障服务的性能和可靠性,服务提供商与用户间定义的一种双方认可的协定。对于云服务而言,SLA是必不可缺的,因为用户对云服务的性能和可靠性有不同的要求。从用户的角度而言,也需要从云服务提供商处得到具有法律效力的承诺,来保证支付费用之后得到应有的服务质量。从目前的实践看,国外的大型云服务提供商均提供了SLA。

            一个完整的SLA 同时也是一个具有法律效力的合同文件,它包括所涉及的当事人、协定条款、违约的处罚、费用和仲裁机构等。当事人通常是云服务提供商与用户。协定条款包含对服务质量的定义和承诺。服务质量一般包括性能、稳定性等指标,如月均稳定性指标、响应时间、故障解决时间等。实际上,SLA的保障是以一系列服务水平目标(Service Level Object,简称SLO)的形式定义的。SLO是一个或多个有限定的服务组件的测量的组合。一个SLO被实现是指那些有限定的组件的测量值在限定范围里。通过前述的对云及应用的监控和计量,可以计算哪些SLO被实现或未被实现,如果一个SLO未被实现,即SLA的承诺未能履行,就可以按照”违约的处罚”对当事人(一般是云服务提供商)进行处罚。通常采取的方法是减免用户已缴纳或将缴纳的费用。

            5)、能效评测:云计算提出的初衷是将资源和数据尽可能放在云中,通过资源共享、虚拟化技术和按需使用的方式提高资源利用率,降低能源消耗。但是在实际应用中,大型数据中心的散热问题造成了大量的能源消耗。如何有效降低能源消耗构建绿色数据中心成为云服务提供商迫切需要解决的问题之一。

            云计算数据中心的能耗测试评价按照不同的维度有不同测试手段和方法。针对传统的数据中心它有显性评价体系和隐性评价体系两个方面。

            显性的能耗测试评价可以参照传统数据中心的评价体系,具体包括:能源效率指标、IT 设备的能效比、IT设备的工作温度和湿度范围、机房基础设施的利用率指标。能源效率指标用于评估一个数据中心使用的能源中有多少用于生产,还有多少被浪费。在这方面,绿色网格组织的电能利用率(Power Usage Effectiveness,简称PUE)指标影响力较大。PUE值越小,意味着机房的节能性越好。目前,国内绝大多数的数据中心PUE值为3左右,而欧美一些国家数据中心的PUE平均值为2左右。

            隐性能耗测试评价包括云计算服务模式节省了多少社会资源,由于客户需求的不同,云吞吐量的变化节省了多少IT设备的投资和资源的重复建设。这些的测试评价很多时候是不能量化或者不能够进行精准地评价。

            为了实现对数据中心能源的自动调节,满足相关的节能要求,一些IT厂商和标准化组织纷纷推出节能技术及能耗检测工具,如惠普公司的动态功率调整技术(Dynamic Power Saver,简称DPS)、IBM的Provisioning软件。

            云计算应用

            (1)、云教育:教育在云技术平台上的开发和应用,被称为”教育云”。云教育从信息技术的应用方面打破了传统教育的垄断和固有边界。通过教育走向信息化,使教育的不同参与者----教师、学生、家长、教育部门等在云技术平台上进行教育、教学、娱乐、沟通等功能。同时可以通过视频云计算的应用对学校特色教育课程进行直播和录播,并将信息储存至流存储服务器上,便于长时间和多渠道享受教育成果。

            (2)、云物联:物联网是新一代信息技术浪潮的生力军。物联网通过智能感知、识别技术与普适计算广泛应用于互联网各方面。物联网作为互联网的业务和应用,随着其深入的发展和流量的增加,对数据储存和计算量的要求将带来对云计算的需求增加。并且在物联网的高级阶段,必将需要虚拟云计算技术的进一步应用。

            (3)、云社交:是一种虚拟社交应用。它以资源分享作为主要目标,将物联网、云计算和移动互联网相结合,通过其交互作用创造新型社交方式。云社交把社会资源进行测试、分类和集成,并向有需求的用户提供相应的服务。用户流量越大,资源集成越多,云社交的价值就越大。目前云社交已经具备了初步模型。

            (4)、云安全:是云计算在互联网安全领域的应用。云安全融合了并行处理、网络技术、未知病毒等新兴技术,通过分布在各领域的客户端对互联网中存在异常的情况进行监测,获取最新病毒程序信息,将信息发送至服务端进行处理并推送最便捷的解决建议。通过云计算技术使整个互联网变成了终极安全卫士。

            (5)、云政务:云计算应用于政府部门中,为政府部门降低成本提高效率做出贡献。由于云计算具有集约、共享、高效的特点,所以其应用将为政府部门降低20%至80%的成本。所以在电子商务延伸至电子政务的背景下,各国政府部门都在着力进行电子政务改革,研究云计算普遍应用的可能性。伴随政府改革的进行,政府部门也开始从自建平台到购买电信运营商的服务,这将为促进云计算的进一步发展并为电信运营商带来商机。

            (6)、云存储:是云计算的一个新的发展浪潮。云存储不是某一个具体的存储设备,而是互联网中大量的存储设备通过应用软件共同作用协同发展,进而带来的数据访问服务。云计算系统要运算和处理海量数据,为支持云计算系统需要配置大量的存储设备,这样云技术系统就自动转化为云存储系统。故而,云存储是在云计算的概念的延伸。

            如果没有云计算,生活将会非常不同。云计算已经成为我们日常生活中不可或缺的一部分,大多数人甚至在没有意识到的情况下就在使用它了。事实上,如果没有云平台的存在,人们的生活将会无法想像:没有云,就不会有Facebook、Twitter、Gmail和Spotify。

            “云”为何会如此强大

            (1)、部署速度快:如果你曾参与过新应用程序的部署,你就会知道,从安装到运行要耗费几个月甚至是几年的时间。而有了基于云端的应用程序,这一切变得不再那么复杂。在多数情况下,你可以即刻登录并开始使用应用程序。至于各企业通用的大多数应用程序,则在几天或几周内就可以完成部署和运行,不再需要几个月或几年的时间。

            (2)、无需预付费:在过去,部署新的应用程序要支出高额费用购置新设备,另外还要支付许可证费用、集成费用,并且不可避免的还要支付顾问咨询费。而有了云计算软件,这些费用会大幅下降,甚至完全不需要支付此类费用。你只需按月支付固定的服务费用即可使用。如此一来,原本无法预期的巨额支出旋即转变为可预测的运营费用。

            (3)、即时可扩展:随着时间的推移,你可以根据需要的变化选择增加或减少使用云应用程序的用户数量。这意味着,你按需付费即可,而且不必再担心云端容量不足。

            (4)、用户无需维护:你的IT员工每个月都需要花费几天的时间来修补、升级和测试应用程序,但使用云应用程序之后,则不必再执行这些操作。这是因为一切都由我们在云端处理,从而让你的员工有更多的时间从事新项目和进行创新。

            (5)、随时随地访问:云应用程序的设计,旨在让人们随时随地都可通过任何设备安全访问。

            (6)、更具安全性:据2010年的一项研究发现,企业平均每年会遗失263台笔记本电脑。如果电脑中包含机密数据,每一次遗失都会带来严重的安全隐患。但使用云应用程序后,你的数据安全地被存储在云中。因此,遗失笔记本电脑只是会带来不便,并不会带来潜在灾害。

            云计算面临的挑战:缺乏统一的技术标准;缺乏统一的运营服务标准;服务的可用性问题;运营管理问题;能效管理问题;信用和安全管理;海量数据的产生。

            云计算的隐私安全问题主要包括

            (1)、在未经授权的情况下,他人以不正当的方式进行数据侵入,获得用户数据。

            (2)、政府部门或其他权利机构为达到目的对云计算平台上的信息进行检查,获取相应的资料以达到监管和控制的目的。

            (3)、云计算提供商为获取商业利益对用户信息进行收集和处理。

            以上内容主要摘自: 《云计算标准化白皮书》、维基百科Salesforce 

    展开全文
  • 图2.3 CCRA功能组件图 2.5 容器技术的关键技术内容 2.5.1 镜像 容器的镜像通常包括操作系统文件、应用本身的文件、应用所依赖的软件包和库文件。为了提高容器镜像的管理效率,容器的镜像采用分层的...

    内容摘要

    近年来,容器技术及相关应用得到了国内外越来越多的关注度,研发和应用推广发展势头迅猛。在国外,容器技术已经形成了较成熟的生态圈;在国内,金融企业、互联网企业、IT企业积极投入容器技术研发和应用推广,发展势头迅猛。为了积极引导我国容器技术和应用发展,我们编写本白皮书。其主要内容包括:

    • 一、针对容器技术现状进行研究和分析。一是梳理了容器技术从开始到现在的发展历程,对现有容器发展的生态结构进行分析,其中包括开源社区、产业联盟、解决方案厂商等;二是对容器技术框架进行了详细的描述,对技术框架各层涉及的技术点进行了介绍;三是结合已发布的国家和国际标准,将现有容器技术对于参考架构的实现情况进行分析;四是分析了容器技术与大数据、物联网、SDN之间的关系。
    • 二、容器技术发展路线及技术架构。通过列举容器技术典型4个应用场景,包括PaaS平台建设、软件定义数据中心、容器即服务、持续集成和发布等,分析了容器技术在各种场景下的关键成功因素。
    • 三、容器未来发展趋势。结合容器发展现状和应用场景应用情况,分析了容器技术在应用过程中面临的问题,同时提出了容器今后发展的生态图,对未来容器技术发展进行了展望。

    一、概述

    1.1 背景

    继虚拟化技术出现后,容器技术逐渐成为对云计算领域具有深远影响的变革技术。容器技术的发展和应用,将为各行业应用云计算提供了新思路,同时容器技术也将对云计算的交付方式、效率、PaaS平台的构建等方面产生深远的影响,具体体现在以下几个方面:

    简化部署:容器技术可以将应用打包成单一地址访问的、Registry存储的、
    仅通过一行命令就可以部署完成的组件。不论将服务部署在哪里,容器都可以从根本上简化服务部署工作。 
    快速启动:容器技术对操作系统的资源进行再次抽象,而并非对整个物理机资源进虚拟化,通过这种方式,打包好的服务可以快速启动。 
    服务组合:采用容器的方式进行部署,整个系统会变得易于组合,通过容器技术将不同服务封装在对应的容器中,之后结合一些脚本使这些容器按照要求相互协作,这样操作不仅可以简化部署难度还可以降低操作风险。 
    易于迁移:容器技术最重要的价值就是为在不同主机上运行服务提供一个轻便的、一致的格式。容器格式的标准化加快交付体验,允许用户方便地对工作负载进行迁移,避免局限于单一的平台提供商。 
    为更好地推进容器及相关技术在中国的落地与实践,推动容器技术在国内的落地,并建立顺应国际技术发展趋势、符合中国本地化特征的容器标准体系,中国开源云联盟容器工作组开展了本白皮书的研制工作,白皮书立足于容器技术发展的演进路线图,分析容器技术在应用过程中的应用场景以及面临的具体问题和关键成功因素,描绘容器技术未来的发展趋势和方向。本白皮书的发布,旨在与业界分享我们在容器技术领域的研究成果和实践经验,呼吁社会各界共同关注容器技术的同时,共同推动容器技术的发展,提升容器技术在云计算领域中实践和服务能力。

    1.2 相关术语

    • 表1.1 术语
    术语定义/解释
    镜像系统文件及其应用文件以特殊的文件形式进行备份制作成单一的文件。
    微服务架构微服务架构是一种特定的软件应用程序设计方式——将大型软件拆分为多个独立可部署服务组合而成的套件方案。
    开发运维一体化可定义为是一种过程、方法、文化、运动或实践,主要是为了通过一条高度自动化的流水线来加强开发和其他IT职能部门之间的沟通和协作,加速软件和服务的交付。
    运行时引擎指用户用来运行容器镜像的软件系统

    1.3 缩略语

    • 表1.2 缩略语
    术语解释
    CI/CDContinuous Integration/Continuous Delivery,持续集成和持续交付
    CaaSContainer as a Service ,容器即服务
    CCRACloud Computing Reference Architecture,云计算参考架构
    CLIcommand-line interface,命令行界面
    DC/OSDataCenter Operating System,数据中西操作系统
    DevOpsDevelopment and Operations,开发运维一体化
    DNSDomain Name System,域名系统
    IaaSInfrastructure as a Service,基础设施即服务
    PaaSPlatform as a Service,平台即服务
    SaaSSoftware as a Service,软件即服务
    SDNSoftware Defined Network,软件定义网络
    LXCLinux Container,Linux容器
    OCIOpen Container Initiative,开放容器组织
    VPSVirtual Private Server,虚拟机专有服务
    VMVirtual Machine,虚拟机

    二、容器技术现状

    2.1 容器技术发展演进路径

    • 图2.1 容器技术演变路径

    这里写图片描述

    容器技术最早可以追溯到1979年UNIX系统中的chroot,最初是为了方便切换root目录,为每个进程提供了文件系统资源的隔离,这也是OS虚拟化思想的起源。2000年,BSD吸收并改进了chroot技术,发布了FreeBSD Jails。FreeBSD Jails除文件系统隔离,还添加了用户和网络资源等的隔离,每个Jail还能分配一个独立IP,进行一些相对独立的软件安装和配置。2001年,Linux发布了Linux Vserver,Linux VServer依旧是延续了Jails的思想,在一个操作系统上隔离文件系统、CPU时间、网络地址和内存等资源,每一个分区都被称为一个 security context,内部的虚拟化系统被称为VPS。2004年原SUN公司发布了Solaris Containers,Solaris Containers作为Solaris 10中的特性发布的,包含了系统资源控制和zones提供的二进制隔离,Zones 作为在操作系统实例内一个完全隔离的虚拟服务器存在。2005 年SWsoft公司发布了OpenVZ,OpenVZ和Solaris Containers非常类似,通过打了补丁的 Linux 内核来提供虚拟化、隔离、资源管理和检查点。OpenVZ 标志着内核级别的虚拟化真正成为主流,之后不断有相关的技术被加入内核。2006 年Google 发布了 Process Containers,Process Container 记录和隔离每个进程的资源使用(包括CPU、内存、硬盘I/O、网络等),后改名为cgroups(Control Groups),并在2007年被加入Linux内核2.6.24版本中。2008年出现了第一个比较完善的LXC容器技术,基于已经被加入内核的cgroups和Linux namespaces 实现。不需要打补丁,LXC就能运行在任意vanila内核的Linux上。2011年,CloudFoundry发布了Warden,和LXC不同,Warden可以工作在任何操作系统上,作为守护进程运行,还提供了管理容器的API。2013年Google公司建立了开源的容器技术栈lmctfy,Google开启这个项目是为了通过容器实现高性能,高资源利用率,同时接近零开销的虚拟化技术。目前 Kubernetes 中的监控工具 cAdvisor就起源于lmctfy项目,2015年Google将lmctfy的核心技术贡献给了 libcontainer。2013年Docker诞生,Docker最早是dotCloud(Docker公司的前身,是一家PaaS公司)内部的项目,和Warden类似,Docker最初也用了LXC,后来才自己写了 libcontainer 替换了 LXC。和其它容器技术不同的是,Docker 围绕容器构建了一套完整的生态,包括容器镜像标准、容器Registry、REST API、CLI、容器集群管理工具Docker Swarm等;2014年CoreOS创建了rkt,为了改进Docker在安全方面的缺陷,重写的一个容器引擎,相关容器工具产品包括:服务发现工具etcd和网络工具flannel等。2016年微软公司发布基于Windows 的容器技术Hyper-V Container,Hyper-V Container原理和Linux下的容器技术类似,可以保证在某个容器里运行的进程与外界是隔离的,兼顾虚拟机的安全性和容器的轻量级。

    2.2 容器技术发展生态

    随着容器技术的演进,越来越多的机构开始重视并参与到容器技术的探索中来。从最初的以Unix或Linux项目到开源社区,到各种类型的容器技术创业公司、IT 企业及产业联盟,容器技术的发展生态也在逐渐得到发展与丰富。在开源社区方面,附录A中列出了国际上的OCI和CNCF(Cloud Native Computing Foundation,简称CNCF,下同),容器的开源项目也在附录B中列出;在国内的IT 企业和创业公司方面,还提供了多个行业应用案例,这些行业应用案例在附录 D 中列出;产业联盟方面包括国际包括 CNCF,国内包括中国开源云联盟(COSCL)。容器的开源社区、创业公司、IT 企业、产业联盟共同构成容器技术发展的生态圈。

    2.3 容器技术框架

    通过研究、梳理和分析现有的容器技术,形成容器相关技术的技术架构,如图2.2所示。

    这里写图片描述
    图2.2 容器技术框架

    2.3.1 服务器层

    当运行容器镜像时,容器本身需要运行在传统操作系统之上,而这个操作系统既可以是基于物理机,也可以是基于 VM。服务器层包含了这两种场景,泛指了容器运行的环境,同时容器并不关心服务器层如何提供和管理,它的期望只是能获得这些服务器资源。

    2.3.2 资源管理层

    资源管理包含了服务器、操作系统等资源的管理。其中如果是物理服务器的话,需要涉及物理机管理系统(例如Rocks等);如果是虚拟机的话,需要使用虚拟化平台。此外,无论是物理服务器还是虚拟机,都需要对其中的操作系统加以管理(例如:Chef、Puppet、Ansible和SaltStack等)。而传统的存储和网络管理也包含在资源管理层。由于存储,网络两者选择众多,不一而足,因此不再列举。

    总而言之,资源管理层的核心目标是对服务器和操作系统资源进行管理,以支持上层的容器运行引擎。

    2.3.3 运行引擎层

    容器运行引擎层主要指常见的容器系统,包括 Docker、rkt、Hyper、CRI-O。这些容器系统的共通作用包括启动容器镜像、运行容器应用和管理容器实例。运行引擎又可以分为管理程序和运行时环境两个模块。 需要注意的是,运行引擎是单机程序,类似虚拟化软件的KVM和Xen,不是集群分布式系统。引擎运行于服务器操作系统之上,接受上层集群系统的管理。
    相关开源项目包括:
    ——资源隔离:Cgroup、Hypervisor;
    ——访问限制:Namespace、Hypervisor;
    ——管理程序:Docker Engine、OCID、hyperd,RKT、CRI-O;
    ——运行时环境:runC(Docker)、runV(Hyper)、runZ (Solaris)

    2.3.4 集群管理层

    可以把容器的集群管理系统类和针对 VM 的集群管理系统划等号,都是通过对一组服务器运行分布式应用。而这两者的细微区别在于,VM 的集群管理系统需要运行在物理服务器上,而容器集群管理系统既可以运行在物理服务器上,也可以运行在 VM 上。 常见的容器集群管理系统包括:Kubernetes、Docker Swarm、Mesos。这三者各有特色,但随着时间推移,三者的融合将越发明显。Kubernetes 在这三者中比较特殊,它的地位更接近 OpenStack。围绕这 Kubernetes,CNCF 基金会已经建立了一个非常强大的生态体系,这是Docker Swarm和Mesos都不具备的。而CNCF基金会本身也正向着容器界的OpenStack基金会发展,值得大家重点关注。
    集群管理层涉及到的相关开源软件项目包括:
    ——指挥调度:Docker Swarm、Kubernetes、Mesos等
    ——服务发现:Etcd、Consul、Zookeeper,DNS
    ——监控:Prometheous
    ——存储:Flocker
    ——网络:Calico、Weave、Flannel

    2.3.5 应用层

    泛指所有运行于容器之上的应用程序,以及所需的辅助系统,包括:监控、日志、安全、编排、镜像仓库等等。
    ——监控模块,相关开源项目包括:Prometheous、cAdvisor、Sysdig等;
    ——日志,相关开源项目包括:Fluented、LogStash等;
    ——安全,包括容器镜像的安全扫描,运行环境的安全隔离,集群环境的安全管理等功能;
    ——编排,相关开源项目包括:Docker Compose、CoreOS Fleet等;
    ——CI/CD,相关开源项目包括:Jenkins、Buildbot、Gitlab CI、Drone.io;
    ——镜像仓库:Docker Hub、VMware Harbor、Huawei Dockyard。

    2.4 容器技术对参考架构的实现情况

    国家标准GB/T 32399-2015《信息技术 云计算 参考架构》(简称CCRA,修改采用ISO/IEC 17789)是2015年发布的国家标准,描述了云计算的利益相关者,云计算系统的基本特征,云计算的基本活动和功能组件,我国是该国际标准的立项推动国之一,积极参与了该国际标准的编制,该标准的诞生标志着国际三大标准化组织ISO、IEC和ITU首次在云计算领域统一认识并达成一致,是国际国内云计算领域的最重要的基础性标准。在该标准中描述了云计算的功能架构,功能架构包含了支撑云计算活动所需的功能,如图2.3。图中标蓝色的部分是现有容器技术已经实现的内容。

    这里写图片描述
    图2.3 CCRA功能组件图

    2.5 容器技术的关键技术内容

    2.5.1 镜像

    容器的镜像通常包括操作系统文件、应用本身的文件、应用所依赖的软件包和库文件。为了提高容器镜像的管理效率,容器的镜像采用分层的形式存放。容器的镜像最底层通常是Linux的rootfs和系统文件,再往上则是各种软件包层。这些文件层在叠加后成为完整的只读文件系统,最终挂载到容器里面。在运行过程中,容器应用往往需要写入文件数据,容器引擎为此需再创建一个可写层,加在镜像的只读文件系统上面。使用分层的容器镜像之后,镜像的下载和传输更加便利,因为只需要在宿主机上把缺少的镜像文件层次下载即可,无需整个镜像传送。

    在Linux中,联合文件系统UnionFS能够把多个文件层叠加在一起,并透明地展现成一个完整的文件系统。常见的联合文件系统有AUFS(AnotherUnion File System),btrfs,OverlayFS和DeviceMapper等。

    2.5.2 运行时引擎

    容器运行时引擎和容器镜像两者的关系类似于虚拟化软件和虚拟机镜像的关系。容器运行时引擎的技术标准主要是由OCI基金会领导社区进行制定。目前OCI已经发布了容器运行时引擎的技术规范,并认可了runC(Docker公司提供)和runV(Hyper公司提供)两种合规的运行引擎。

    2.5.3 容器编排

    容器编排工具通过对容器服务的编排,决定容器服务之间如何进行交互。容器编排工具一般要处理以下几方面的内容:
    1) 、容器的启动。选择启动的机器、镜像和启动参数等;
    2) 、容器的应用部署。提供方法对应用进行部署;
    3) 、容器应用的在线升级。提供方法可以平滑地切换到应用新版本。
    容器的编排一般是通过描述性语言YAML或者JSON来定义编排的内容。目前主要的编排工具有Docker compose和基于Google的Kubernetes helm等。

    2.5.4 容器集群

    容器集群是将多台物理机抽象为逻辑上单一调度实体的技术,为容器化的应用提供资源调度、服务发现、弹性伸缩、负载均衡等功能,同时监控和管理整个服务器集群,提供高质量、不间断的应用服务。容器集群主要包含以下技术:
    资源调度:主要以集中化的方式管理和调度资源,按需为容器提供 CPU、内存等资源;

    服务发现:通过全局可访问的注册中心实现任何一个应用能够获取当前环境的细节,自动加入到当前的应用集群中;

    弹性伸缩:在资源层面,监控集群资源使用情况,自动增减主机资源;在应用层面,可通过策略自动增减应用实例来实现业务能力的弹性伸缩;

    负载均衡:当应用压力增加,集群自动扩展服务将负载均衡至每一个运行节点;当某个节点出现故障,应用实例重新部署运行到健康的节点上。

    2.5.5 服务注册和发现

    容器技术在构建自动化运维场景中,服务注册和发现是重要的两个环节,一般通过一个全局性的配置服务来实现。其基本原理类似公告牌信息发布系统,A 服务(容器应用或者普通应用)启动后在配置服务器(公告牌)上注册一些对外信息(比如IP和端口),B服务通过查询配置服务器(公告牌)来获取A注册的信息(IP和端口)。

    2.5.6 热迁移

    热迁移(Live Migration),又称为动态迁移或者实时迁移,是指将整容器的运行时状体完整保存下来,同时可以快速地在其他主机或平台上恢复运行。容器热迁移主要应用在两个方面:一是有多个操作单元执行任务,热迁移能迅速地复制与迁移容器,做到无感知运行作业;二是可以处理数据中心中集群的负载均衡,大量数据涌来无法运行计算时,可利用热迁移创建多个容器处理运算任务,调节信息数据处理峰谷,配置管理负载均衡比例,降低应用延迟。

    2.6 容器技术与相关技术的关系

    2.6.1 容器与云计算

    虚拟化是云计算的重要基础,容器定义了一套从构建到执行的标准化体系,改变了传统的虚拟化技术,深度影响了云计算领域,容器是云计算的未来。以Docker 为代表的容器技术越来越深刻地影响云计算,也改变我们的日常开发、运维和测试。相比于虚拟机,容器的轻量、快速启动和低开销,以及基于此的按业务打包和微服务模式,这些特点被用来改进 DevOps,很多场景下更适合做大规模集群管理和搭建灵活的分布式系统。通过深度整合了IaaS、PaaS 及容器技术,提供弹性计算、DevOps 工具链及微服务基础设施等服务,帮助企业解决IT、架构及运维等问题,使企业更聚焦于业务,构建了新一代的云计算生态体系。

    2.6.2 容器与大数据

    大数据平台如果能采用容器方式发布,与Spark、Hadoop、Cassandra等相关技术的集成与对接,可降低整个系统的搭建难度,缩短交付和安装周期,减少安装失败风险。容器化后,各类大数据平台组件可以轻松实现迁移的目的,也能实现多复本控制和高可用。

    2.6.3 容器与物联网

    物联网(IoT)技术发展日新月异,而容器技术刚好遇到这样的机遇,将在几个方面促进物联网的发展。

    首先,运用容器技术后,可通过容器封装,可简化下载、安装部署、启动和后续应用更新。这将大大加速物联网应用开发部署。其次,容器技术还可以满足物联网在自动监控,集中式维护管理方面的需求。最后,数据采集端环境千变万化,如果需要手动适配工作量巨大,如果采用容器化技术,只要打包几类典型的容器镜像,如ARM,X86,x86_64等,就可以事半功倍实现终端的发布工作。

    2.6.4 容器与SDN

    随着容器部署规模的增大,跨主机、跨网络的容器迁移成为常态。而容器更多地关注于轻量化本身,对于网络架构并没有太多关注。过于复杂的体系结构和管理过程,容易让整个容器网络和系统陷入不可控的非稳定状态。通过SDN和Overlay网络结合,将控制转发分离、集中控制管理理念应用于容器网络,还可以最大程度增强容器网络的弹性伸缩能力和简化网络管理。

    另外,SDN与容器的配合,是相得益彰、互相促进的。业界的SDN控制器和系统一般都比较庞大,安装、运行都极为复杂。通过Docker技术,能够实现SDN控制器的轻量级快速部署、安装、运行。

    展开全文
  • 容器技术及其应用

    2018-12-20 11:15:00
    图6 CCRA功能组件图 7. 容器技术的关键技术内容 7.1 镜像 容器的镜像通常包括操作系统文件、应用本身的文件、应用所依赖的软件包和库文件。为了提高容器镜像的管理效率,容器的镜像采用分层的形式存放。容器的...

    一、容器技术及其应用

    1. 内容摘要

    近年来,容器技术及相关应用得到了国内外越来越多的关注度,研发和应用推广发展势头迅猛。在国外,容器技术已经形成了较成熟的生态圈;在国内,金融企业、互联网企业、IT企业积极投入容器技术研发和应用推广,发展势头迅猛。其主要内容包括:

    1.1针对容器技术现状进行研究和分析

    一是梳理了容器技术从开始到现在的发展历程,对现有容器发展的生态结构进行分析,其中包括开源社区、产业联盟、解决方案厂商等;

    二是对容器技术框架进行了详细的描述,对技术框架各层涉及的技术点进行了介绍;

    三是结合已发布的国家和国际标准,将现有容器技术对于参考架构的实现情况进行分析;

    四是分析了容器技术与大数据、物联网、SDN之间的关系。

    1.2 容器技术发展路线及技术架构

    通过列举容器技术典型4个应用场景,包括PaaS平台建设、软件定义数据中心、容器即服务、持续集成和发布等,分析了容器技术在各种场景下的关键成功因素。

    1.3 容器未来发展趋势

    结合容器发展现状和应用场景应用情况,分析了容器技术在应用过程中面临的问题,同时提出了容器今后发展的生态图,对未来容器技术发展进行了展望。

    2. 容器技术对云计算领域的深远影响

    继虚拟化技术出现后,容器技术逐渐成为对云计算领域具有深远影响的变革技术。容器技术的发展和应用,将为各行业应用云计算提供了新思路,同时容器技术也将对云计算的交付方式、效率、PaaS平台的构建等方面产生深远的影响,具体体现在以下几个方面:

    2.1 简化部署

    容器技术可以将应用打包成单一地址访问的、Registry存储的、仅通过一行命令就可以部署完成的组件。不论将服务部署在哪里,容器都可以从根本上简化服务部署工作。

    2.2 快速启动

    容器技术对操作系统的资源进行再次抽象,而并非对整个物理机资源进虚拟化,通过这种方式,打包好的服务可以快速启动。

    2.3 服务组合

    采用容器的方式进行部署,整个系统会变得易于组合,通过容器技术将不同服务封装在对应的容器中,之后结合一些脚本使这些容器按照要求相互协作,这样操作不仅可以简化部署难度还可以降低操作风险。

    2.4 易于迁移

    容器技术最重要的价值就是为在不同主机上运行服务提供一个轻便的、一致的格式。容器格式的标准化加快交付体验,允许用户方便地对工作负载进行迁移,避免局限于单一的平台提供商。

    为更好地推进容器及相关技术在中国的落地与实践,推动容器技术在国内的落地,并建立顺应国际技术发展趋势、符合中国本地化

    2.5 相关术语

    术语

    定义/解释

    镜像

     系统文件及其应用文件以特殊的文件形式进行备份制作成单一的文件。

    微服务架构

     微服务架构是一种特定的软件应用程序设计方式——将大型软件拆分为多个独立可部署服务组合而成的套件方案。

    开发运维一体化

    可定义为是一种过程、方法、文化、运动或实践,主要是为了通过一条高度自动化的流水线来加强开发和其他IT职能部门之间的沟通和协作,加速软件和服务的交付。

    运行时引擎

    指用户用来运行容器镜像的软件系统

    表2.5 术语

    2.6 缩略语

     

     

    表2.6 缩略语

    3. 容器技术现状

    容器技术发展演进路径

     

     

    图3.1 容器技术演变路径

    容器技术最早可以追溯到1979年UNIX系统中的chroot,最初是为了方便切换root目录,为每个进程提供了文件系统资源的隔离,这也是OS虚拟化思想的起源。

    2000年,BSD吸收并改进了chroot技术,发布了FreeBSD Jails。FreeBSD Jails除文件系统隔离,还添加了用户和网络资源等的隔离,每个Jail还能分配一个独立IP,进行一些相对独立的软件安装和配置。

    2001年,Linux发布了Linux Vserver,Linux VServer依旧是延续了Jails的思想,在一个操作系统上隔离文件系统、CPU时间、网络地址和内存等资源,每一个分区都被称为一个 security context,内部的虚拟化系统被称为VPS。

    2004年原SUN公司发布了Solaris Containers,Solaris Containers作为Solaris 10中的特性发布的,包含了系统资源控制和zones提供的二进制隔离,Zones 作为在操作系统实例内一个完全隔离的虚拟服务器存在。

    2005 年SWsoft公司发布了OpenVZ,OpenVZ和Solaris Containers非常类似,通过打了补丁的 Linux 内核来提供虚拟化、隔离、资源管理和检查点。OpenVZ 标志着内核级别的虚拟化真正成为主流,之后不断有相关的技术被加入内核。

    2006 年Google 发布了 Process Containers,Process Container 记录和隔离每个进程的资源使用(包括CPU、内存、硬盘I/O、网络等),后改名为cgroups(Control Groups),并在2007年被加入Linux内核2.6.24版本中。CGroup是Linux内核提供的一种可以限制、记录、隔离进程组(process groups)所使用的物理资源(如:cpu,memory,IO等等)的机制。

    2008年出现了第一个比较完善的LXC容器技术,基于已经被加入内核的cgroups和Linux namespaces 实现。不需要打补丁,LXC就能运行在任意vanila内核的Linux上。

    2011年,CloudFoundry发布了Warden,和LXC不同,Warden可以工作在任何操作系统上,作为守护进程运行,还提供了管理容器的API。

    2013年Google公司建立了开源的容器技术栈lmctfy,Google开启这个项目是为了通过容器实现高性能,高资源利用率,同时接近零开销的虚拟化技术。目前 Kubernetes 中的监控工具 cAdvisor就起源于lmctfy项目,2015年Google将lmctfy的核心技术贡献给了 libcontainer。

    2013年Docker诞生,Docker最早是dotCloud(Docker公司的前身,是一家PaaS公司)内部的项目,和Warden类似,Docker最初也用了LXC,后来才自己写了 libcontainer 替换了 LXC。和其它容器技术不同的是,Docker 围绕容器构建了一套完整的生态,包括容器镜像标准、容器Registry、REST API、CLI、容器集群管理工具Docker Swarm等;

    2014年CoreOS创建了rkt,为了改进Docker在安全方面的缺陷,重写的一个容器引擎,相关容器工具产品包括:服务发现工具etcd和网络工具flannel等。

    2016年微软公司发布基于Windows 的容器技术Hyper-V Container,Hyper-V Container原理和Linux下的容器技术类似,可以保证在某个容器里运行的进程与外界是隔离的,兼顾虚拟机的安全性和容器的轻量级。

    Docker for Windows 是在 Windows 上运行一个 Linux 虚拟机,里面跑 Linux Docker。

    而 Docker on Windows 是将 Docker 引擎移植到 Windows,提供 Docker API, 直接在 Windows 系统上通过移植后的 Docker Engine,来运行Windows容器,在里面跑的是 Windows 程序,运行于 Windows 内核(而不是Linux程序运行于Linux内核)。由于使用 Docker API,可以支持 Compose, Swarm 等。

    4. 容器技术发展生态

    随着容器技术的演进,越来越多的机构开始重视并参与到容器技术的探索中来。从最初的以Unix或Linux项目到开源社区,到各种类型的容器技术创业公司、IT 企业及产业联盟,容器技术的发展生态也在逐渐得到发展与丰富。在开源社区方面,附录A中列出了国际上的OCI和CNCF(Cloud Native Computing Foundation,简称CNCF,下同),容器的开源项目也在附录B中列出;在国内的IT 企业和创业公司方面,还提供了多个行业应用案例,这些行业应用案例在附录 D 中列出;产业联盟方面包括国际包括 CNCF,国内包括中国开源云联盟(COSCL)。容器的开源社区、创业公司、IT 企业、产业联盟共同构成容器技术发展的生态圈。

    5. 容器技术框架

    通过研究、梳理和分析现有的容器技术,形成容器相关技术的技术架构,如图2.2所示。

    图2.2 容器技术框架

     

     

    5.1 服务器层

    当运行容器镜像时,容器本身需要运行在传统操作系统之上,而这个操作系统既可以是基于物理机,也可以是基于 VM。服务器层包含了这两种场景,泛指了容器运行的环境,同时容器并不关心服务器层如何提供和管理,它的期望只是能获得这些服务器资源。

    5.2 资源管理层

    资源管理包含了服务器、操作系统等资源的管理。其中如果是物理服务器的话,需要涉及物理机管理系统(例如Rocks等);如果是虚拟机的话,需要使用虚拟化平台。此外,无论是物理服务器还是虚拟机,都需要对其中的操作系统加以管理(例如:Chef、Puppet、Ansible和SaltStack等)。而传统的存储和网络管理也包含在资源管理层。由于存储,网络两者选择众多,不一而足,因此不再列举。

    总而言之,资源管理层的核心目标是对服务器和操作系统资源进行管理,以支持上层的容器运行引擎。

    5.3 运行引擎层

    容器运行引擎层主要指常见的容器系统,包括 Docker、rkt、Hyper、CRI-O。这些容器系统的共通作用包括启动容器镜像、运行容器应用和管理容器实例。运行引擎又可以分为管理程序和运行时环境两个模块。 需要注意的是,运行引擎是单机程序,类似虚拟化软件的KVM和Xen,不是集群分布式系统。引擎运行于服务器操作系统之上,接受上层集群系统的管理。 

     相关开源项目包括: 

      ——资源隔离:Cgroup、Hypervisor; 

      ——访问限制:Namespace、Hypervisor; 

      ——管理程序:Docker Engine、OCID、hyperd,RKT、CRI-O; 

      ——运行时环境:runC(Docker)、runV(Hyper)、runZ (Solaris)

    5.4 集群管理层

    可以把容器的集群管理系统类和针对 VM 的集群管理系统划等号,都是通过对一组服务器运行分布式应用。而这两者的细微区别在于,VM 的集群管理系统需要运行在物理服务器上,而容器集群管理系统既可以运行在物理服务器上,也可以运行在 VM 上。 常见的容器集群管理系统包括:Kubernetes、Docker Swarm、Mesos。这三者各有特色,但随着时间推移,三者的融合将越发明显。Kubernetes 在这三者中比较特殊,它的地位更接近OpenStack。围绕这 Kubernetes,CNCF 基金会已经建立了一个非常强大的生态体系,这是Docker Swarm和Mesos都不具备的。而CNCF基金会本身也正向着容器界的OpenStack基金会发展,值得大家重点关注。 

    集群管理层涉及到的相关开源软件项目包括: 

      ——指挥调度:Docker Swarm、Kubernetes、Mesos等 

      ——服务发现:Etcd、Consul、Zookeeper,DNS 

      ——监控:Prometheous 

      ——存储:Flocker 

      ——网络:Calico、Weave、Flannel

    5.5 应用层

    泛指所有运行于容器之上的应用程序,以及所需的辅助系统,包括:监控、日志、安全、编排、镜像仓库等等。 

      ——监控模块,相关开源项目包括:Prometheous、cAdvisor、Sysdig等; 

      ——日志,相关开源项目包括:Fluented、LogStash等; 

      ——安全,包括容器镜像的安全扫描,运行环境的安全隔离,集群环境的安全管理等功能; 

      ——编排,相关开源项目包括:Docker Compose、CoreOS Fleet等; 

      ——CI/CD,相关开源项目包括:Jenkins、Buildbot、Gitlab CI、Drone.io; 

      ——镜像仓库:Docker Hub、VMware Harbor、Huawei Dockyard。

    6. 容器技术对参考架构的实现情况

    国家标准GB/T 32399-2015《信息技术 云计算 参考架构》(简称CCRA,修改采用ISO/IEC 17789)是2015年发布的国家标准,描述了云计算的利益相关者,云计算系统的基本特征,云计算的基本活动和功能组件,我国是该国际标准的立项推动国之一,积极参与了该国际标准的编制,该标准的诞生标志着国际三大标准化组织ISO、IEC和ITU首次在云计算领域统一认识并达成一致,是国际国内云计算领域的最重要的基础性标准。在该标准中描述了云计算的功能架构,功能架构包含了支撑云计算活动所需的功能,如图6图中标蓝色的部分是现有容器技术已经实现的内容。

     

     

    图6 CCRA功能组件图

    7. 容器技术的关键技术内容

    7.1 镜像

    容器的镜像通常包括操作系统文件、应用本身的文件、应用所依赖的软件包和库文件。为了提高容器镜像的管理效率,容器的镜像采用分层的形式存放。容器的镜像最底层通常是Linux的rootfs和系统文件,再往上则是各种软件包层。这些文件层在叠加后成为完整的只读文件系统,最终挂载到容器里面。在运行过程中,容器应用往往需要写入文件数据,容器引擎为此需再创建一个可写层,加在镜像的只读文件系统上面。使用分层的容器镜像之后,镜像的下载和传输更加便利,因为只需要在宿主机上把缺少的镜像文件层次下载即可,无需整个镜像传送。

    在Linux中,联合文件系统UnionFS能够把多个文件层叠加在一起,并透明地展现成一个完整的文件系统。常见的联合文件系统有AUFS(AnotherUnion File  System),btrfs,OverlayFS和DeviceMapper等。

    7.2 运行时引擎

    容器运行时引擎和容器镜像两者的关系类似于虚拟化软件和虚拟机镜像的关系。容器运行时引擎的技术标准主要是由OCI基金会领导社区进行制定。目前OCI已经发布了容器运行时引擎的技术规范,并认可了runC(Docker公司提供)和runV(Hyper公司提供)两种合规的运行引擎。

    7.3 容器编排

    容器编排工具通过对容器服务的编排,决定容器服务之间如何进行交互。容器编排工具一般要处理以下几方面的内容: 

    1)容器的启动。选择启动的机器、镜像和启动参数等; 

    2)容器的应用部署。提供方法对应用进行部署; 

    3)容器应用的在线升级。提供方法可以平滑地切换到应用新版本。 

    容器的编排一般是通过描述性语言YAML或者JSON来定义编排的内容。目前主要的编排工具有Docker compose和基于Google的Kubernetes helm等。

    7.4 容器集群

    容器集群是将多台物理机抽象为逻辑上单一调度实体的技术,为容器化的应用提供资源调度、服务发现、弹性伸缩、负载均衡等功能,同时监控和管理整个服务器集群,提供高质量、不间断的应用服务。容器集群主要包含以下技术:

    资源调度:主要以集中化的方式管理和调度资源,按需为容器提供 CPU、内存等资源; 

    服务发现:通过全局可访问的注册中心实现任何一个应用能够获取当前环境的细节,自动加入到当前的应用集群中;

    弹性伸缩:在资源层面,监控集群资源使用情况,自动增减主机资源;在应用层面,可通过策略自动增减应用实例来实现业务能力的弹性伸缩;

    负载均衡:当应用压力增加,集群自动扩展服务将负载均衡至每一个运行节点;当某个节点出现故障,应用实例重新部署运行到健康的节点上。

    7.5 服务注册和发现

    容器技术在构建自动化运维场景中,服务注册和发现是重要的两个环节,一般通过一个全局性的配置服务来实现。其基本原理类似公告牌信息发布系统,A 服务(容器应用或者普通应用)启动后在配置服务器(公告牌)上注册一些对外信息(比如IP和端口),B服务通过查询配置服务器(公告牌)来获取A注册的信息(IP和端口)。

    7.6 热迁移

    热迁移(Live Migration),又称为动态迁移或者实时迁移,是指将整容器的运行时状体完整保存下来,同时可以快速地在其他主机或平台上恢复运行。容器热迁移主要应用在两个方面:一是有多个操作单元执行任务,热迁移能迅速地复制与迁移容器,做到无感知运行作业;二是可以处理数据中心中集群的负载均衡,大量数据涌来无法运行计算时,可利用热迁移创建多个容器处理运算任务,调节信息数据处理峰谷,配置管理负载均衡比例,降低应用延迟。

    8. 容器技术与相关技术的关系

    8.1 容器与云计算

    虚拟化是云计算的重要基础,容器定义了一套从构建到执行的标准化体系,改变了传统的虚拟化技术,深度影响了云计算领域,容器是云计算的未来。以Docker 为代表的容器技术越来越深刻地影响云计算,也改变我们的日常开发、运维和测试。相比于虚拟机,容器的轻量、快速启动和低开销,以及基于此的按业务打包和微服务模式,这些特点被用来改进 DevOps,很多场景下更适合做大规模集群管理和搭建灵活的分布式系统。通过深度整合了IaaS、PaaS 及容器技术,提供弹性计算、DevOps 工具链及微服务基础设施等服务,帮助企业解决IT、架构及运维等问题,使企业更聚焦于业务,构建了新一代的云计算生态体系。

    8.2 容器与大数据

    大数据平台如果能采用容器方式发布,与Spark、Hadoop、Cassandra等相关技术的集成与对接,可降低整个系统的搭建难度,缩短交付和安装周期,减少安装失败风险。容器化后,各类大数据平台组件可以轻松实现迁移的目的,也能实现多复本控制和高可用。

    8.3 容器与物联网

    物联网(IoT)技术发展日新月异,而容器技术刚好遇到这样的机遇,将在几个方面促进物联网的发展。

    首先,运用容器技术后,可通过容器封装,可简化下载、安装部署、启动和后续应用更新。这将大大加速物联网应用开发部署。其次,容器技术还可以满足物联网在自动监控,集中式维护管理方面的需求。最后,数据采集端环境千变万化,如果需要手动适配工作量巨大,如果采用容器化技术,只要打包几类典型的容器镜像,如ARM,X86,x86_64等,就可以事半功倍实现终端的发布工作。

    8.4 容器与SDN

    随着容器部署规模的增大,跨主机、跨网络的容器迁移成为常态。而容器更多地关注于轻量化本身,对于网络架构并没有太多关注。过于复杂的体系结构和管理过程,容易让整个容器网络和系统陷入不可控的非稳定状态。通过SDN和Overlay网络结合,将控制转发分离、集中控制管理理念应用于容器网络,还可以最大程度增强容器网络的弹性伸缩能力和简化网络管理。

    另外,SDN与容器的配合,是相得益彰、互相促进的。业界的SDN控制器和系统一般都比较庞大,安装、运行都极为复杂。通过Docker技术,能够实现SDN控制器的轻量级快速部署、安装、运行。

    9. 容器应用

    9.1 容器技术应用场景

    9.1.1 PaaS平台建设

    最早的PaaS平台方案初步解决了很多客户对于应用弹性的需求,但是在容器技术之前,构建一套PaaS平台面临着组件多、量级大、改造成本高等挑战,而且对于运行在不同 PaaS 平台上的应用,很难避免应用对平台的深度依赖。譬如,不同的PaaS平台对弹性、高可用、性能、监控、日志、版本更新等的实现方式不同,则对其上应用的架构要求也不同;另外,在编程语言和技术栈方面,也会导致应用对平台供应商的深度绑定。总之,在传统PaaS平台面前,我们在开发应用时不得不配合平台的要求。

    而容器技术的出现,很好的解决了上述问题。容器是以应用为中心的虚拟化环境,与编程语言、技术栈无关,比传统PaaS灵活;对应用的支撑也比底层平台多,可以发挥微服务架构的优势。同时,容器是基于轻量级虚拟化的技术,天生具有高密度的特性,可以更加高效地使用资源。

    9.1.2 软件定义数据中心

           互联网和海量数据正以前所未有的增长趋势冲击着整个数据中心行业,随着互联网、电子商务、社交网络、移动办公等互联网应用的迅速发展,传统数据中心逐渐难以满足新业务的发展需求,传统数据中心面临不匹配业务的灵活变化、能耗高、运维难、密度低、不满足云和虚拟化弹性伸缩场景,也面临着应用的快速、批量、移动部署慢等问题。 

           软件定义数据中心负责将存储、计算、网络资源依据策略进行自动化调度与统一管理、编排和监控,同时根据用户需求形成不同的服务并提供计费等功能。容器技术可充分利用底层的各项计算、存储和网络资源,灵活构建容器应用,实现具备应用轻量级的容器承载能力、应用集群的松耦合和资源动态弹性伸缩的能力、实现可视化运维和自动化管控的能力、实现平台自动化部署和升级的能力,从而解决了容器平台对基础设施资源调用的需求,容器平台将数据中心转化成为一个更加灵活高效的业务应用平台,其开放性和兼容性契合了数据中心对异构、大规模、可移植、互操作等方面的需求,容器技术为云计算的实施提供了强有力的支撑。

    9.1.3 容器即服务

           传统IaaS在应用过程中面临运维方面的问题,传统IaaS服务没有从根本上加速企业内部的开发运维效率,更多的主要是体现对于IT部门的技术优化和提升一定的运维能力,运维和开发人员之间依然存在传统IT手段同样的沟通成本。容器技术三个方面的优势可以有助于解决传统IaaS面临的问题。首先,容器的本质是一种操作系统级别的虚拟化,启动一个应用容器其实就是启动一个进程,因此使得容器占用空间小、资源利用率高、本身非常轻,执行起来效率较高。这些是容器技术与传统虚拟机技术的最大差别。其次,容器技术使用镜像方式能够将应用程序和它依赖的操作系统、类库以及运行时环境整体打包,统一交付,使得运维压力大大降低。最后,容器技术与底层所使用的平台无关,容器可以在Linux平台各发行版上兼容,这意味着应用架构一旦转换为容器化并且迁移部署之后,就可以在任何云平台之间无缝迁移。

    9.1.4 持续集成和发布(CI/CD)

           传统软件架构特性是单体应用,开发周期至少以月为单位进行发布和升级,代码一般使用一种语言开发,不同的组件紧耦合,经常依赖于公共的库,部署周期以月为单位,部署依赖人工操作,组件版本复杂,操作风险高,时间管理成本均居高不下。 

           将容器技术引入到开发和运维环节具有以下几个方面的优势:一是提供了交付环境一致性。从开发到运维的工作流程中,由于基础环境的不一致造成了诸多问题,但通过使用容器技术在不同的物理设备、虚拟机、云平台上运行,将镜像作为标准的交付物,应用以容器为基础提供服务,实现多套环境交付的一致性;二是提供了快速部署。工具链的标准化将DevOps所需的多种工具或软件进行容器化,在任意环境实现快速部署。三是轻量和高效。与虚拟机相比,容器仅需要封装应用及相关依赖文件,更加轻量,提高资源利用率。因此企业通过容器技术进行DevOps的实践,可较好的缩短软件发布周期,提升产品交付迭代速度,提高生产效率。

    9.2 容器技术优势分析

    9.2.1 从运维者维度看容器技术优势

             快速部署:

             使用容器能够利用镜像快速部署运行服务,能够实现业务的快速交付,缩短业务的上线周期,极大地方便运维人员的上线部署工作。

             弹性伸缩:

             使用容器技术,当遇到高并发、高流量的大活动,容器做到根据业务的负载进行弹性扩容,以提供更好的服务。当访问量降低后,容器平台能够自动缩容,及时释放空闲资源。

             可移植性:

             容器可以运行于Linux、Unix、Window的操作系统之上,可以利用容器将服务移植到不同的操作系统环境下运行。

             轻量:

            相比传统虚拟机,容器更加轻量,资源消耗更低,镜像体积更小。

            高可用:

            容器运行的业务通常由一组容器来提供服务,容器平台的服务发现功能可以保证容器实例的副本数量即使在某个主机宕机的情况下也能维持不变。保证服务能够正常提供服务。

            资源利用率高:

            容器较传统虚拟化有更低资源使用粒度,在一台物理机上可运行上百个容器服务,从而提高服务器硬件资源的利用率。

    9.2.2 从开发者维度看容器技术优势

    快速构建开发环境:

    开发应用除去自身编码工作之外,还需要额外的数据库、缓存或消息队列等组件在本地进行测试,使用容器技术可以快速完成构建,省去了设备申请、采购的流程,简化了开发者组件安装工作,提高了开发效率。

    提供一致性的开发环境:

    采用容器镜像技术,只需要一次构建就可以实现在不同的项目成员之间快速复制出一套完全一致的开发环境,从而消除因环境异构而导致的不一致性,降低软件缺陷出现的概率。 同时,在开发环境和测试环境中使用同样的镜像,也能保证开发和测试环境的一致性,提前发现软件缺陷,减少对因环境不一致而导致的缺陷的调查成本。

    方便开发环境版本管理:

    通过对应用程序镜像的版本化管理,可以实现同一套应用程序的多版本共存,尤其是存在对某些组件多版本支持的情况下,通过容器技术,可以轻松支持该组件的多个版本。 对应用程序容器的版本化,在应用程序本身存在多版本的情况下,开发者还能在快速进行版本回溯,提高问题调查和缺陷修复的效率;在发布失败时,也能快速回滚。

    9.2.3 容器技术与其他技术的集成

    容器技术与在应用过程中需要与以下几个方面技术进行集成才能在各应用场景中进行应用。一是与IaaS管理平台集成。如果容器选择在VM中运行,就需要与VM的管理平台进行对接。在私有云场景下需要对接例如OpenStack(容器技术与OpenStack技术集成具体可参考附录C)、VMware产品;在公有云场景下,需要与公有云服务提供商,例如阿里云、百度云、AWS等公司提供的VM进行集成。二是与开发工具集成。开发工具相关技术的集成是构建持续集成、持续发布以及DevOps环境的必须条件,目前比较常用的开发工具包括Jenkins、Shippable(for Docker)等。三是与网络进行集成。不同的应用运行于容器集群时有网络的互通需求,因此容器技术在具体场景应用时需要与网络二层或三层功能模块进行集成,以达到互通。四是与存储管理模块集成。存储是应用数据存储的必备,不同的存储在性能、存储空间、易用度等方面差别较大,如果要支持更多的应用,容器平台需要内置外部存储管理插件,与存储平台进行集成。

    10.未来发展趋势

    10.1 容器技术问题分析

    容器技术拥有快速扩展、灵活性和易用性等诸多优势,但在容器应用过程中会遇到以下几个方面的问题:一是兼容性方面,容器版本在快速更新中,以Docker 相关技术为例,每隔1-3个月左右就有版本的升级,一些核心模块依赖于高版本内核,运维时存在版本兼容问题。二是目前容器技术没有统一的标准,例如:在容器层面有Docker Container、Mesos Container、rkt、CRI-O等众多容器技术产品;此外,Google 虽然在联合容器业界相关的厂商制定标准,但目前也未在容器方面进行完全的统一。三是管理容器环境和应用也较为复杂,不仅需要多类技术支撑,包括容器管理、编排、应用打包、容器间的网络、数据快照等,还需要增加对容器的监控。四是容器在应用过程中还需要考虑在容器间、容器与系统间的性能隔离,内核共享带来的安全隔离问题。五是在使用习惯角度上,容器使用习惯会有别于主机或虚拟机,容器技术在应用过程中大部分用户需要逐步引导才能适应容器的使用方式。

    10.2 容器技术未来生态图及展望

     

     

    转载于:https://www.cnblogs.com/malukang/p/10148230.html

    展开全文
  • IBM SOA 标准

    千次阅读 2013-10-09 10:12:38
    三个支持服务消费(业务流程、消费者和集成),而其他(信息架构、服务质量、集成和治理)支持一个更具辅助性的(有时称为非功能的或补充的)横切关注点。SOA RA 作为一个整体提供框架来支持...

        本文介绍 IBM 如何开发和使用 SOA 参考架构,帮助客户增加业务灵活性和 IT 灵活性。SOA RA 参考架构被用于帮助组织通过业务集成(特别是符合其独特 SOA 服务目标的服务集成)来实现高级业务敏捷性和 IT 灵活性。IBM 还结合使用 SOA 参考架构和 Cloud 参考架构来帮助组织定义其云解决方案。

    简介

    面向服务架构 (Service Oriented Architecture, SOA) 促进灵活的、可重用资产的创造,实现端到端的业务解决方案。随着公司逐渐接受世界各地不同行业不同类型项目的 SOA 原则以及与 SOA 相关的技术时,参考架构的需求就会越来越明显。SOA 参考架构的使用是 SOA 价值主张实现的一个关键因素。

    新 Open Group SOA Reference Architecture (SOA RA) 标准为面向服务解决方案架构(包括云解决方案架构)中的架构、设计和实现决策提供了方针指南和选择。SOA 参考架构标准的目标是为创建和评估架构提供一个蓝图。此外,它还提供洞察力、模式和构建块,来将 SOA 的基本元素集成到一个解决方案或者企业架构中。

    SOA 的价值

    该架构风格就是众所周知的面向服务架构 (Service Oriented Architecture, SOA),而不是大家所熟知的组件实现,只有提供的服务能够发布,且消费者与供应商底层实现细节完全隔离。实质上,整体结构就是:通过松耦合服务使用者使用的服务接口与服务提供者的实现以及解耦实现与绑定,将接口与实现的解耦从编程级别提升到架构级别。

    SOA 通过一组与业务保持一致的 IT 服务协议(由合同组成)使业务和 IT 集中起来,共同支持一个组织的业务流程和业务目标。它不仅提供灵活的可重用解耦功能,还提供可在声明规范(比如,WS-Policy 以及相关标准)中具体化服务质量变化的机制。该松耦合功能可使软件解决方案中的软件组件组合更加灵活。此种组合可使应用程序开发人员更为快速地修改其解决方案来响应业务需求的变化,可使用同一组成结构(即重用之前应用程序中创建的组件)快速交付新解决方案以满足新业务需求。可将组件设计的更佳符合不同场景的业务需求。

    SOA 的关键业务效益

    作为一个灵活的、可扩展的架构框架,SOA 有以下定义功能:

    • 减少成本:在利用现有资产的同时提供从废弃或成本日益增加的应用程序合并多余应用程序功能以及解耦功能的机会。
    • 敏捷性:根据一组业务和 IT 服务构造业务解决方案,以这种方式促进业务流程和使用这些流程的解决方案的快速构建和重新配置。
    • 增加竞争优势:提供进入新市场的机会,并以创新方法,通过使用一系列松耦合 IT 服务利用现有业务功能。通过提供更好的新业务服务增加市场份额和业务价值。
    • 即时上市:通过允许业务决定解决方案的关键驱动力,以及允许 IT 快速支持和实施此方向,来更加快速地交付与业务保持一致的解决方案。
    • 合并:跨竖井 (silo) 解决方案和组织集成,减少系统的物理数,在从遗留 spaghetti 依赖项 “优雅过度” 到一个有组织的、集成的共存系统程序之下实现平台的合并。
    • 一致性:使组织能够更好地将业务目标和 IT 保持一致,使企业能够将其与一个组织想要实现的功能联系起来,与其策略计划保持一致,实现持久的敏捷性和重用性。

    参考架构的目标和使用

    参考架构的目标是提供解决方案,而企业架构一个标准化蓝图从而为其业务架构解决方案。如图 1 所示,架构(比如参考架构)存在于一个连续体 (Continuum) 中,从非常抽象的连续体(其中架构决策和假设均未识别或制定)到非常具体的连续体(其中大多数假定和架构决策均制定)。

    伴随着这个连续体,还存在的领域、行业、企业和解决方案参考架构。要全面地理解这一图表,您可以参考 Navigating the SOA Open Standards Landscape Around Architecture 白皮书,可在http://www.opengroup.org/soa/source-book/stds/index.htm 中找到。

    图 1. 参考架构连续体
    参考架构连续体

    参考架构可用于设置架构的上下文环境,来为供应商和客户提供理解的基础,实现以图定做产品和为解决方案设计服务以及清晰阐释一组构建块。

    对于 SOA,架构师可将参考架构用于各种场景,包括那些采用 SOA 迅速启动的组织,帮助继承者在 SOA 构建中提供服务,帮助 SOA 产品供应商构建一个 SOA 组件以一种可被客户理解的标准方式呈现其产品,以及帮助组织构建其他 SOA 规范和标准。

    标准化 SOA 参考架构的价值

    SOA RA 的标准化提供一个行业认可的、供应商中立的起点来实现客户创建 SOA 解决方案。这样可用于多个企业共同合作的场景,尽管供应商或系统集成商等存在变更。SOA RA 提供一种常见的分类系统和术语表来设计、构建和描述 SOA 解决方案。这不仅省时省钱而且也可以改进结果。

    对采用 SOA 的组织,SOA RA 可以帮助创建业务流程驱动的解决方案、业务工具、消息交换、服务集成、数据访问以及封装遗留软件和组件。当架构师应用 SOA 建模和交付方法论时,一个已被识别的 SOA 的每个元素被映射回 SOA RA,来提供 SOA 解决方案如何进行的视图。这也为特定企业或行业中的业务和 IT 利益相关者提供一个非常有用的通讯工具。

    SOA RA 也被用于定义解决方案的功能和灵活性。这是通过一个关键元素检查清单实现的,架构一个 SOA 解决方案时必须考虑到这些关键元素,SOA RA 是通过一个层定义以及这些层上的架构构建块来实现的。甚至在这些层中此概念更推进一步,设计决策点和交互模式的架构构建块可以帮助定义该 SOA 解决方案。例如,从技术角度来说,架构师需要回答这些问题:

    • 生成一个 SOA 解决方案的因素和准则是什么?
    • 使用相互连接的架构和转换功能如何将一个 SOA 解决方案组织为一个架构框架?
    • 如何以最大化资产重用的方式设计一个 SOA 解决方案?

    为了解决这些问题,Open Group SOA Reference Architecture 标准提出了一种基于 SOA 解决方案的参考架构。它提供了 SOA 分区和分解到层的高度抽象,每一层都提供一组 SOA 解决方案所需的功能。每一层处理 SOA 中与独特价值主张相关的特征和职责的一个特定子集。

    分层架构的基础是一个元模型,它是由层、功能、架构构建块 (ABB)、交互模式、选项和架构决策以及功能、ABB 和层之间的关系构成。这些将指导架构师创建和评估架构。

    在真实世界中使用 SOA 参考架构会发生什么?

    在采用服务和 SOA 的路上通常需要组织处理独特项目目标和约束。很多组织试用 Web 服务(通过包装现有应用程序),作为探索服务集成领域的一种方法,以结果决定如何超越初始阶段。许多组织参与一个企业范围的业务转型,还有一些组织则定义其路线图、愿景、策略和准则实现评估和治理。对于那些组织而言,有一个目标标准是非常有用的,可帮助衡量当前服务和 SOA 成熟度,并可创建一个达到理想成熟度级别的路线图,这不仅是出于对成熟度的考虑,还能实现不同的业务成果,这些业务成果可通过达到具体的成熟度级别得以实现。

    IBM 认证和引导的特定技术分离方法,比如将 Web 服务从 SOA 中分离作为一个解决方案和业务架构。有了成千上万的客户和政府在组织的参与,IBM 就可以在 SOA 解决方案开发领域建立世界级行业领导权,并能提供产品来保证那些解决方案的实现。IBM 已经开发了行业领先的资产来支持这些约定。其中一些关键的、经过实践检验的资产已经作为近来关于治理、成熟度模型、术语的 Open Group SOA 标准,目前称为 SOA Reference Architecture。这里还有一些文章可供参考,介绍了 IBM 如何帮助开发和支持这些 治理 服务采纳 标准。本文主要介绍 Open Group Standard SOA Reference Architecture 的 IBM 支持。可在这里找到 (http://www.opengroup.org/projects/soa-ref-arch/)。

    SOA 参考架构概述

    SOA RA 由一组抽象概念构成,共同提供一个 SOA 逻辑设计。因此,它将会回答 “什么是 SOA”,通过提供一组架构构建块来对这个问题进行详细介绍。在架构评估阶段,或者解决方案架构或企业架构设计阶段,SOA RA 允许架构使用其内容,比如构建块,作为一个元素检查清单:架构构建块以及他们与每层之间的关系、可用选项,以及需要在每层制定的决策。层为构建 SOA 所必需的分离关注点 (separated concerns) 提供一个起始点。每组分离关注点均在其自己的 “层” 中呈现。

    SOA RA 设计提供架构以及蓝图,包括软件开发生命周期中所用的模板和指南。这将促进并最终实现自动化,并简化建模以及记录架构层流程,这些功能以及其中的 ABB,层和 ABB 选项,产品到 ABB 的映射以及架构和设计决策,都将有助于 SOA 的创建。

    SOA RA 旨在支持组织采纳 SOA,产品供应商构建 SOA 基础架构组件,集成者参与 SOA 解决方案的构建,标准机构参与进一步开发 SOA 规范。

    图 2. SOA RA 逻辑解决方案视图
    SOA RA 逻辑解决方案视图

    SOA 组合功能是在操作系统层和组件层实现。公开的界面则是由服务层提供。注意,这些层中包含一些横切关注点 (cross cutting concerns),比如集成、信息、服务质量和治理,作为注意事项包含在上述各层中。其中三个层处理实施和服务界面(操作系统层、服务组件层和服务层),三个层支持服务消费(业务流程层、消费者层和集成层),而其他四个层(信息架构层、服务质量层、集成层和治理层)支持一个更具辅助性的(有时称为非功能的或补充的)横切关注点。SOA RA 作为一个整体提供框架来支持所有 SOA 元素,包括支持服务及其交互的所有组件。

    在图 2 所示的每个层中均有架构构建块 (ABB),代表可重用功能的一个基本元素,以及此层关键责任的实现。驻留于一个层中的每个 ABB 都支持此功能,且每个都有其责任。ABB 也可跨层相互连接,且在层之间提供自然结合。如果始终要在 ABB 之间采用一个特定连接来解决一个特定问题,那么就需要在架构构建块之间定义一种 ABB 模式以及有效交互序列。

    除了 ABB 之外,还支持一些其他功能。其中一个功能就是 The Open Group 在 TOGAF 9 中定义的,称为 “组织、个人或系统所拥有的能力”。因此,进一步扩展该定义,ABB 提供技术资源来使组织、个人或系统够提供其定义的功能,一个 ABB,为一个或多个功能提供支持,可以通过一个或多个组件或产品来实现;一个 ABB 的职责包括:服务定义、调解、路由,等等。

    层的概述:

    在 SOA RA 中定义的层列举如下:

    • 操作系统层:操作和 IT 系统层可捕获组织的基础架构、包括新的和已有的,这是在设计、部署和运行时支持 SOA 解决方案所必需的。

      该层代表实际运行时基础架构和运行在该基础架构上的其他 SOA 架构的交叉点。另外,它也是底层基础架构即服务 (Infrastructure as a Service, IaaS) 结构和广泛的云计算背景中其他 SOA 架构的交叉点。该层的关键要求将在 “功能” 小节进行介绍,其中描述了满足那些需求的功能。
    • 服务组件层:服务组件层包含软件组件,每个软件组件提供服务或者服务上操作的实施或 “实现”。该层也包含功能和技术组件,方便服务组件实现一个或多个服务。服务组件在其功能以及其管理和服务交互质量中反映它们所代表的服务定义。它们将服务合同 “绑定” 到操作和 IT 系统层的服务实现中。服务组件驻留在支持服务规范的容器中。

      服务组件层通过包装和支持松耦合实现 IT 灵活性。关注点分离就是这样,消费者假设其服务实现忠实于其出版描述(服务合规性),并且供应商保证已实现此种合规性。实现的细节对于消费者来说无关要紧。因此,供应商组织可能会决定使用一个有相同描述的组件替换另一个,而不会影响服务消费者。
    • 服务层:服务层由所有在 SOA 中定义的逻辑服务构成。该层包含在设计过程中使用/创建的服务、业务功能和 IT 表现形式的描述,以及在运行时使用的合同和描述。

      服务层是一个平行层,提供 SOA 中支持的业务功能,并介绍 SOA 中支持的服务的功能。
    • 业务流程层:业务流程层包含流程表示、构成方法和构建块,聚合松耦合服务使其成为一个与业务目标保持一致的有序流程。数据流和控制流用来支持服务和业务流程之间的交互。交互可能存在于一个企业中,也可能跨多个企业。

      SOA 参考架构中的业务流程层在连接业务水平要求和 IT 级解决方案组件中充当一个中央协调角色,通过与集成层、服务质量层、信息架构层以及服务层协作完成。
    • 消费者层:消费者层是消费者的入口,不管是人、程序、浏览器或者自动操作,以及与 SOA 相互作用都可从此切入。这使得一个 SOA 解决方案可以支持一个客户端独立的、通道不可知的功能集,通过一个或多个通道(客户端平台或设备)独立消费以及开出账单。所以说它是所有内外部交互式消费者(人类或者其他应用程序/系统)和服务(例如,B2B 场景)之间的切入点。

      该层提供快速创建前端业务流程和综合应用程序的功能,以响应市场变化。它使得通道能够独立访问那些应用程序和平台所支持的各种业务流程。消费者和其余底层 SOA 的解耦为组织提供支持敏捷性、增强重用以及提高质量和一致性的能力。
    • 集成层:集成层是一个横切关注点,支持和提供调节能力,包括变换、路由和协议转换,从服务发起者向正确服务提供者传输服务请求。它支持实现一个 SOA 所需的功能,比如路由、协议支持和转换、消息传递/交互风格、异构环境支持、适配器、服务交互、服务实现、服务虚拟化、服务消息传递、信息处理和转换。集成层也负责维护松耦合系统中存在的解决方案一致性。

      这里出现的集成主要是服务组件、服务和流程层(“功能” 层)的集成。例如,这就是流程执行的服务的绑定(否则就晚了)。这允许一个服务可以跨多个面向客户的通道长期公开。
    • 服务质量层:服务质量层也是一个横切关注点,支持 SOA 相关关注点的非功能性需求 (NFR),为在任何给定解决方案中处理它们提供一个焦点。它还提供确保 SOA 满足以下需求的方法:监测、可靠性、可用性、可管理性、事务性、可维护性、可扩展性、安全性、安全、生命周期,等等。它与传统 FCAPS(过失、配置、会计、性能、安全)范围相同,从 ITIL 到 RAS(从可靠性、可用性、适用性),保持将同种管理和监控应用到今天的商业领域,对于管理服务和 SOA 解决方案来说是非常重要的,可能需要扩展来处理面向自然的服务和许多 SOA 解决方案的跨域边界。
    • 信息架构层:信息层也是一个横切关注点,负责以统一的表示形式呈现一个组织其各方面信息,正如其 IT 服务、应用程序和系统所提供的那样,保证业务需求和流程与业务词汇(词汇表和术语)保持一致。

      该层包括信息架构、业务分析和业务智能、元数据因素,确保包括关于信息架构的关键因素,也可被用于作为通过数据集市和数据仓库实现业务分析和业务智能创建的基础。这包括存储在这一层的元数据内容。它也支持信息服务功能,使一个虚拟化信息数据层功能得以实现。这一层也使得 SOA 能够支持数据一致性和数据质量一致性。
    • 治理层:治理层也是一个横切关注点,确保一个组织中的服务和 SOA 解决方案遵守定义策略、指导方针和标准,这些均定义为一个应用于组织中的目标、策略和规章的功能,一个 SOA 解决方案将提供所需的业务价值。SOA 治理活动应该符合 Corporate、IT 和 Enterprise Architecture 治理准则和标准。治理层将被用来匹配和支持组织的目标 SOA 成熟度等级。

    服务类型:

    服务本质上就是任何面向服务架构的核心概念,意识到这里涉及的服务可能有很多不同种类非常重要的。SOA 参考架构定义了一个标准的服务分类方案。这里的服务可根据它们的行动来分类,例如,按其功能或目的(尽管分类并不相互排斥)分类,以帮助确保覆盖和共享理解。当然其他分类方案也是可行和有用的。

    将服务分区到组在一个面向服务架构中的服务和服务组合开发中是一个常见活动。服务类别和组将影响业务和 IT 查看和理解架构以及支持该架构的服务组合的方法。

    下图显示了一个功能分类方案,用于在典型企业中发现服务。

    图 3. 服务类型
    服务类型

    图 3 显示的是分解的服务类别。连接到 'Service Integration Services' 的服务,比如交互服务、流程服务、信息服务等等,均被认为是属于特定域的。这些都是特定的解决方案,要求针对于正在开发的域或解决方案独一无二的实现。特定服务域可以购买,但是通常需要进行广泛定制或扩展。

    其余服务类别则是域无关类别。这些域无关类别包括开发服务、管理服务等。这类服务可直接用于各种不同域或解决方案。域无关服务通常被用于计划、开发、支持和管理解决方案中的域特定服务。通常域无关服务可以通过购买即可使用,而无需进行扩展。

    注意,交互、流程和信息服务类别支持模式—视图—控制器 (Model-View-Controller) 模式。分离这些方面的价值在架构传统观念中仍然适用于 SOA。

    服务类别有:

    • 中介服务:负责将服务消费者与服务供应商绑定。很明显可以通过解决位置问题实现跨网络请求路由最优化,满足业务目标。中介服务通常通过一些有意义的活动增加附加价值,比如日志记录或翻译,还有连通性。
    • 交互服务:提供业务设计的表示逻辑,并支持应用程序和终端用户之间的交互。
    • 进程服务:包括各种形式的组成逻辑,特别是业务进程流。
    • 信息服务:提供业务设计的数据逻辑。实现提供业务持久化数据的存取,支持业务数据组成,并提供其自身的子架构来跨组织管理数据流。
    • 存取服务:将遗留应用程序和功能集成到面向服务的架构解决方案。
    • 安全服务:负责保护免受贯穿整个 SOA 脆弱部分的威胁。主要负责保护服务消费者和服务供应商之间的交互,以及保护所有对该架构有贡献的元素。
    • 伙伴服务:捕获在业务设计中有直观表现形式的合作伙伴互操作性语义。
    • 生命周期服务:支持管理 SOA 解决方案生命周期以及贯穿开发和管理,从策略到基础架构的所有构成元素。
    • 资产和注册表服务:提供资产访问权限,这是整个架构的一部分,包括服务描述、软件服务、策略、文档以及其他业务操作必不可少的资产和构件。
    • 基础架构服务:提供资源的高效利用,确保完善的操作环境,平衡工作负载以满足服务水平目标,隔离工作以避免干扰,执行维护,安全访问可信业务流程和数据,简化系统整体管理。
    • 管理服务:提供管理工具和度量集以监控服务流、底层系统健康状况、资源利用、中断和瓶颈的鉴定、服务目标实现、管理策略执行以及故障恢复。
    • 开发服务:支持整套架构工具、建模工具、开发工具、视觉构成工具、组装工具、方法论、调试辅助程序、基础架构工具以及构建一个 SOA 解决方案所需的探索代理。
    • 战略与规划服务:支持创建愿景、蓝图以及移交计划以提高业务成果以及处理该业务策略的服务来创建一个涵盖服务和 IT 的实现路线路。
    • 业务应用服务:实现核心业务逻辑,其中实现是在一个业务模型中特别创建的。
    • 业务服务:捕获业务功能,作为粗粒度进程服务提供给外部消费者。

    SOA RA 提供综合的范围和细节。这使得架构师在考虑服务和解决方案架构块时能够自信没有什么遗漏。基于广泛的真实项目经验,IBM 是唯一配备提供支持 SOA 及这种 SOA RA 标准所必需的广泛经验和产品的。

    IBM 如何支持 SOA RA 标准

    服务产品

    IBM 不仅拥有综合的着火测试服务产品集,还是 SOA 的市场领导者,拥有有帮助客户使用 SOA 的丰富经验。

    似乎您已经开始启动您的 SOA 转型了,但是如果想要评估进展,那您将可能面临着性能问题,而且可能是设计、基础架构或实现评估。似乎您需要帮助制定您的 SOA 解决方案标准,确保解决方案可以在最大负载下操作。IBM 服务可以帮助评估您的计划或者推荐改进,极大地提升业务价值。SOA Diagnostic 着眼于全面 SOA 策略、治理(包括安全性)、基础架构准备状态和正在进行的 SOA 开发项目。此外,我们也关注能力和性能评估,确保您的 SOA 可以满足所有业务和 IT 需求

    Open Group SOA RA 标准是基于 IBM 的 SOA 解决方案栈(一个关键资产,是上述服务的一部分)以及面向服务的建模和架构 (Service Oriented Modeling and Architecture, SOMA),IBM 用于为您的解决方案识别正确的服务的著名方法。

    现在,IBM 将利用这丰富的经验将 SOA 应用到云解决方案。请参见 http://www-935.ibm.com/services/us/index.wss/offerfamily/gbs/a1028751

    软件产品

    IBM 在这一行业拥有广泛的产品,可以为您提供合适的 SOA 解决方案。每一步都在您的路线图中,在您架构的每一层都可以使用 IBM 产品来为您 SOA 生命周期的每个阶段(即计划、开发、部署、管理)提供合适的工具和基础架构。IBM 使用以下图表作为一个架构参考模型来解释实现一个 SOA 的各个方面。

    IBM 产品和服务也可被映射到 SOA 参考架构标准化的常见服务类型:

    图 4. IBM 软件产品映射,第 1 部分
    IBM 软件产品映射
    图 5. IBM 软件产品映射,第 2 部分
    IBM 软件产品映射

    IBM 品牌支持 SOA 解决方案中的 Model/Assemble/Deploy/Manage 生命周期:

    • Rational 通过提供工具建模 SOA 解决方案和业务流程来支持 Model 和 Assemble。它还提供产品以支持开发服务。
    • WebSphere 通过为服务实现、服务客户端和业务流程提供运行时来支持 Deploy。它还提供产品以支持部署 SOA 解决方案所必需的操作服务。
    • Tivoli 通过提供服务、解决方案和基础架构的监控和操作管理来支持 Manage。它还提供产品以支持管理服务。
    • Lotus 提供工具来将人员和协作入口集成到您的业务流程。它还提供交互服务的支持。关注上述 IBM SOA 参考架构,这是可用于 SOA 各个方面的大量 IBM 产品的一个样例。
    • Information Management 通过在整个信息供应链中提供信息管理服务支持 Deploy。

    IBM 产品既为各层提供支持,也在 SOA RA 中提供服务。

    • 战略与规划服务是由 Global Business Service 的组件业务建模 (Component Business Modeling, CBM) 服务提供的,可帮助您有条不紊地检查您的业务并识别正确的业务组件和服务。面向服务的建模和架构 (SOMA) 服务以及工具可帮助您识别正确的服务以满足我们的需求。SOMA 的Rational Unified Process (RUP) 可提供最好的实践产品,使这些流程、特别是现代化遗留系统增速。此外,IBM Rational 将Rational Systems ArchitectRational Focal Point 作为工具出售给企业架构师,可以为市场驱动的产品和组合管理提供决策支持系统。Rational RequisitePro 跟踪业务需求将其作为目标,并介入服务开发生命周期。
    • 业务服务和事件帮助业务分析师捕获您的文档、遵从性、模拟和最优化的业务设计。WebSphere Business Monitor 帮助您创建仪表板来观察您的业务性能,这有助于您理解您的业务设计如何实现您的业务目标和推荐优化。Cognos Business Intelligence 提供关于您 SOA 的业务报告、分析和仪表板。WebSphere Operational Decision Management 增强 BPM 和 SOA 基础架构以及业务洞察,以及关于事件驱动业务条件的认知。
    • 开发服务由 Rational Software Architect 提供,将为 Windows、Linux、i、及 z 系统上的业务服务提供一个开发环境。Rational Team Concert 促进这些环境下的协作开发。Rational ClearCaseClearQuest 自动化和执行开发进程,实现更好的洞察、可预测性、管理和软件开发生命周期控制。为了实现这一点,IBM Integration Designer 帮助您创建了业务进程流、状态机制和业务规则。
    • 资产和注册表服务由 Rational Asset Manager 提供,可帮助创建、更改、管理、发现和重用任何类型的开发资产,包括那些用于您 SOA 解决方案的资产。WebSphere Service Registry and Repository 提供这些工具来提供注册和位置服务以支持延迟绑定到服务。
    • 服务集成服务本质上是企业服务总线 (Enterprise Service Bus) 功能,是由 WebSphere Enterprise Service Bus 支持的,提供一个基本架构实现整个企业级分布式网络的透明互联。它由WebSphere Message Broker 所扩展,为非 XML 数据类型提供消息转换,同时提供基于消息的集成。WebSphere Message Queue 使可升级的、可靠的跨不同平台消息交换。WebSphere DataPower SOA 设备可加强和促进 SOA 应用程序,特别是WebSphere DataPower Integration Appliance XI52WebSphere DataPower XML Accelerator XA35 Appliance 的无负载 Web 服务处理和 XML 处理。
    • 业务应用服务托管于 WebSphere Application Server,一个高度可用的托管环境 (hosting environment),提供基础 SOA 业务服务和一个WebSphere Portal、IBMBusiness Process Management (BPM) 以及WebSphere ESB 的平台,支持基于 SOA、SCA、SIP、Web 2.0 以及 JPA 编程模型的标准。WebSphere Application Server 可随着WebSphere eXtended Deployment (XD) 的规模而扩增,而WebSphere Network Deployment 会为普遍高终端计算需求扩展编程模式。WebSphere eXtended Deployment Compute Grid 支持跨事务和批处理范式共享业务逻辑。WebSphere eXtreme Scale 提供分布式缓存要素,实现灵活的可扩展性以及下一代 SOA 和云计算环境。业务应用程序由执行数据管理系统实现:CICS 是一个应用程序和事务服务器,IMS 是一个事务和分层数据库管理系统。CICSIMS 均已作为一个 SOA 开发启用。
    • 流程服务由 IBM Business Process Management 完全支持,这是业务进程(流和业务状态机制)的一个主要托管环境。WebSphere Operation and Decision Management 交付一个业务角色管理系统来控制和管理业务策略和流程。WebSphere Business Events 有助于业务检测、评估,以及对基于可控事件模式的探索的业务事件影响作出响应。
    • 交互服务由 WebSphere Portal 提供,这也是一个托管环境,用于 SOA 应用程序的用户交互逻辑,允许将接口聚集到一个单一用户页面。Lotus Sametime 是一个统一的通讯平台,支持业务流程中的服务创新和用户委托。IBM Mashup Center 支持您使用动态情景应用程序来连接用户与业务服务。
    • 信息服务是由数据仓储和信息集成产品提供的。相对 IBM Information Server 而言,InfoSphere Master Data Management 集中管理贯穿客户、产品和帐户域的业务关键型主数据,IBM Information Server 是复杂、异构、分布式信息的一个数据集成平台。Cognos Business Integrator 使您可以以任何组合对任何数据进行探索和交互,并生成完整的时间频谱。
    • 伙伴服务是通过 Sterling B2B IntegrationWebSphere DataPower Appliance 提供的,支持通过一个集中的、统一的贸易伙伴和事务管理平台将企业对企业与贸易伙伴集成到一起,实现流程和数据集成。
    • 存取服务由 WebSphere Adapters 支持,为各种遗留信息系统提供适配器。
    • 基础架构服务由 WebSphere Virtual Enterprise 提供,提供应用程序虚拟化来降低成本,增加灵活性、敏捷性、可用性和可靠性。虚拟软件管理 IBM 以及其他供应商的中间件和硬件的使用。IBM 是一个可信的系统、服务器和存储供应商,可满足您的业务需求,这包括时代领先的Power Systems running AIX or Linux, and BladeCenter,集成平台并内置可扩展性和可管理性。IBM 以无可匹敌的处理能力和System z Series 的高可用性而闻名。
    • 管理服务包括安全性和运行时管理。安全性由 Tivoli Identity Manager, Tivoli Federated Identity Manager, Tivoli Security Policy Manager and Tivoli Access Manager 提供,它提供了一个统一的用户管理、用户信息联合和特权管理。Tivoli Compliance Insight Manager 提供一个自动化的用户安全性遵从监控。WebSphere DataPower XML Security Gateway XS40 and XG45 将 Tivoli 的联合身份、安全性和目录服务集成到您的 SOA 网络处理。监控、预先配置和自动化则是由Tivoli Composite Application Manager (ITCAM) 提供的,这是一个集成的产品集(包括 SOA 的 ITCAM),支持跨所有 SOA RA 平台的 IT 服务管理,Tivoli Intelligent Orchestrator (TIO) 为管理和自动化您的行政管理工作流,以及初始化工作流以响应信息系统中的事件提供支持,而Tivoli Provisioning Manager 扩展 TIO 以及工作流来自动化开发环境实现软件和硬件的预先配置。如 ITIL 所述,Tivoli Change and Configuration Management DataBase (CCMDB) 是自动化和支持更改以及配置管理进程的基础。而Tivoli Application Dependency Discovery (TADDM) 交付自动化发现和配置跟踪功能来建立应用程序映射,提供对应用程序复杂性的实时监控。Tivoli Usage and Accounting Manager 评估共享计算资源的使用情况和成本。Tivoli Business Service Manager (TBSM) 提供实时服务可用性和可视性以及智能仪表板,同时可视化关键业务服务以及相关 SLA 的健康状况。IBM Systems Director 跨多系统环境提供物理和虚拟系统平台管理,使得虚拟化得以简化。
    • 生命周期服务由 Rational Method Composer 提供,是一个灵活的软件开发处理平台,拥有一个最佳实践库,可帮助您为您的项目团队提供定制的、但尚未一致的流程指南。Rational Requirements Composer 提供视觉和文本技术,帮助在一个协作环境中捕获业务目标和细化需求。Rational Build Forge 自动化和加速构建和发布流程。

    SOA 如何奠定 Cloud 基础

    SOA RA 已被 The Open Group 标准化,应用于 Cloud 架构,也是 IBM 云计算参考架构的底层架构,已提交到 Open Group (IBM CCRA)。本小节将介绍有云计算架构新因素的地方,并显示 SOA RA 是如何支持它们的。

    功能关注点:操作系统、服务组件、服务、业务流进程和消费者界面;所有这些都存在 Cloud 中且和 Clould 相关。

    图 6. Cloud 基础架构
    Cloud 基础架构

    对于 Cloud 架构,需要特别关注:

    • 操作层:基础架构是操作系统层的一部分,但是通常集中在 Cloud 架构中,因为 Cloud 将新需求强加于基础架构以确保广泛的网络访问、资源合并、快速弹性、虚拟化和可扩展性。
    • 服务层:常见云服务类型 (*aaS) 位于服务层。这些云服务类型,像其他服务,使用并有时候公开操作系统层的资产。对于云服务,公开资产类型通常是服务类型的焦点,比如,在操作系统中,硬件基础架构作为 IaaS 公开,中间件作为 PaaS 公开,而业务流程作为 BPaaS 公开。
    • 业务流程:业务流程可以加入一个 Cloud 解决方案,就像在 SOA 解决方案中那样,它们可作为一个服务 (BPaaS) 提供者或者成为服务消费者(不管它们是否是云服务)。另外,云计算供应商组织中的业务流程需要以新颖的形式重构和简化来满足更快的实时交付、实时更改以及实现成本目标。
    • 消费者层:消费者层被更严格、更仔细地从服务和服务供应商层分离,允许共享和替代云服务或供应商。

    SOA RA 中的横切关注点:集成、服务质量、信息和治理:是所有云计算基础架构和解决方案的重要关注点,就像在 SOA RA 中那样。它们是横切关注点这一事实意味着每个功能层在横切层可能拥有交互功能。

    对于 Cloud 架构,必须特别关注:

    • 服务质量 (QOS) 层:为了使按需自服务和有规则的服务要求以及关键客户需求实现弹性、安全性、性能、自动化管理、操作和业务支持,横切关注点服务质量对于 Cloud 管理和安全有更多重要需求。管理支持可作为 Common Cloud Management Platform 在 SOA RA QOS 层呈现,这包括支持操作和业务的支持服务,aka OSS 和 BSS。这对于通过交付多种基于同一基础的云服务驱动的经济规模是至关重要的。
    • 云解决方案的治理也拥有一些独一无二的需求模式,这些需求是跨组织界限支持治理所必需的。供应商和消费者通常需要就云计算供应商如何执行一个交互式治理流程进行商谈,确保云解决方案和服务适当地交付以及继续与业务需求保持一致。

    对于云生态系统,云服务消费者、供应商和创建者在云计算架构中确认为普遍的高级别角色。

    在 SOA 上下文中关注 Cloud 是很重要的,大型 SOA 解决方案中的 Cloud 解决方案支持它们。

    这些横切关注点对于集成和信息仍然是很重要的,必需在任何 Cloud 解决方案架构的开发中考虑到。然而,云计算不能将任何新准则或者关注点引入到这些横切层。

    为了使关注 Cloud 关注点更为简单,而不需要关注 SOA 关注点,我们可以将 Cloud 关注点提升到其自己的图表中,如图 7 所示。

    图 7. IBM 云计算参考架构
    IBM 云计算参考架构

    在 CCRA 中没有介绍的那些概念和架构元素仍然可以通过其自己的 SOA RA 遗产隐含和呈现。

    结束语:IBM 为您构建 SOA 解决方案的原因

    近来,Gartner 的一篇文章(Application and Integration Platforms Key Initiative Overview,2011 年 7 月 22 日)建议客户 “让 SOA 成为首要必备架构”。

    IBM 是公认的 SOA 市场占有率领导者,领先长达 7 年之久,而且将会继续。Wintergreen 最近发布他们关于 SOA 软件市场、占有率和预测的报告,报告中提到78% 的市场属于 IBM,而我们最大的竞争对手的市场占有率还不足 4%。

    IBM 拥有:

    最重要的是,IBM 的 SOA 策略是构建在一个开放标准上,即实现了互操作性也实现了标准化。在 The Open Group 中,IBM 对 SOA Reference Architecture、SOA Ontology、OSIMM 和 SOA Governance Framework 的领导权是我们致力于标准化 SOA 架构的典范。

    展开全文
  • 云计算基础概念

    千次阅读 2018-09-26 14:12:28
     (3)、CCRA的分层框架包括4 层,以及一个跨越各层的跨层功能集合。四层分别是:用户层、访问层、服务层、资源层。跨越各层的功能称为跨层功能。  云计算的7类主要支撑技术 :  (1)、系统虚拟化:是指将一台物理...
  • 2020计算机安全

    2020-09-05 10:08:27
    第5个设计原则:如何防止攻击者访问位于保护机制下面的? 隐蔽通道(隐信道) 隐蔽通道就是一个不受安全机制控制的信息流,信息通过一个隐蔽通道传输是可能的。 一个状态变量: 一次传递一个比特位信息 存储通道...
  • 下图为IBM CCRA参考架构,定义了构成云计算环境的基本架构元素: 云计算架构,有很多种描述,主要是以IBM CCRA模型为基础,每个企业在落地时有不同的特点,在此不赘述。简单来说,云计算是由计算/网络/存储等资源池...

空空如也

空空如也

1
收藏数 8
精华内容 3
关键字:

ccra四层作用功能

友情链接: Average.zip