针对大型集团公司的云平台架构的解析思路

在过去的二十多年中，很多国内的大型集团公司都已经建立了非常庞大的业务信息系统，包括 OA 系统、ERP 系统、CRM 系统、HRM 系统以及各种行业应用系统，为了保证这些业务信息系统的长期稳定运行，还建设了一批支撑型信息系统，如监控系统、身份认证系统、安全运行中心等。这些信息系统通常在建设期间独立招标采购、独占软硬件资源，不与其他信息系统集中招标、共享资源，导致资源浪费比较普遍，建设成本较高；运维期间则采取独立运维的方式，不与其他信息系统共享运维人员、工具和技术，导致运维成本较高和运维效率偏低。当已有信息系统的规模越来越大，新的信息系统不断增加，资源浪费、运维效率低下和成本高昂的问题就变得更加突出，因此，越来越多的大型集团公司引入私有云来解决这些问题。

然而，大型集团公司的 IT 基础设施有明显的特征，催生了相对独特的云计算需求，所以需要结合大型集团公司的 IT 现状和云计算需求来设计云平台的整体架构。本文针对大型集团公司的云计算需求，以业内标准云平台架构为基础，提出了一个具有一定适应性的云平台架构。

大型集团公司经过多年的信息化建设，其 IT 基础设施逐渐形成了以下特点：

大型集团公司在全国甚至全球设立子公司开展业务，集团层面设立总部级的信息化主管单位，子公司通常也会设立自己的 IT 部门，有些大型集团公司还会专门成立负责 IT 系统建设和运维的子公司。另外，大型集团公司多年来根据业务发展需求进行整合或拆分，IT 部门也会随着被整合或拆分。这些因素直接导致了大型集团公司的 IT 组织结构非常复杂。一般情况下，一个子公司会承建和运维多个信息系统，并为每个信息系统设立专门的项目组。

大型集团公司通常已经建成或计划建设“两地三中心”的总部级数据中心架构，并允许每个分公司就近建设区域级数据中心。总部级数据中心和区域级数据中心形成了数据中心的两级架构，两者通过广域网互连。总部级数据中心通常部署整个集团公司范围内都会用到的信息系统，地区级数据中心部署地区子公司专用的信息系统或对网络延迟敏感的信息系统。

大型集团公司已经拥有了大量信息系统，每个信息系统是在不同时期由不同的项目组完成建设，所采购的软硬件来自不同厂商的不同产品，导致大量异构 IT 资源并存。

大型集团公司中的每个信息系统的资源分配策略可能会不一样，核心系统需要采用最佳性能分配策略，非核心系统可以采用最佳使用率分配策略，有些性能要求高的应用需采用物理机部署，有些性能要求较低的应用则可以采用虚拟机部署。

大型集团公司在建设云平台之前就已经有了监控系统、ITSM 系统、CMDB、身份认证系统和安全运行中心等支撑型信息系统，这些支撑型信息系统提供的功能应当属于完整云平台的一部分，但在云平台建设之前就已经存在了，所以建设云平台时没有必要重复建设，而是要考虑如何与其进行集成。

大型集团公司 IT 基础设施具备的特点决定了对云平台的业务需求也有其相对独特的地方。

如图 1 所示，云平台架构中需要设计多级租户，根租户对应的是整个集团公司，统一管理和分配集团公司范围的所有云资源，即云平台所管理的所有资源。一级租户对应子公司级别，是信息系统的承建和管理单位，一个子公司可以管辖多个信息系统。二级租户可对应为信息系统级别，是信息系统的具体建设和运维项目组；针对大的子公司还可以将二级租户对应到其内部的部门，然后在其下面再设立对应到信息系统的三级租户。当底层租户需要资源时，应当向上级租户申请资源配额，上级租户查看本租户当前可用的资源配额，如果足够就可以分配给下级租户，如果不够就再向更上一级租户申请资源配额。根租户的资源配额即为云平台的所有可用资源的集合，如果根租户的资源配额不够的话就意味着需要及时进行资源扩容。这种多层级的租户体系结构即是设计模式中 Composite 模式的具体应用。

图 1 – 云平台租户体系

如图 2 所示，云平台需要设计两级资源管理体系，本地资源管理模块管理和控制本数据中心内的资源，将本数据中心的资源清单和资源使用情况上报全局资源管理模块，接收并执行全局资源管理模块下发的指令；全局资源管理模块收集并汇总各个本地资源管理模块上报的资源信息形成资源的全局视图，统一管理和调度位于所有数据中心的资源，下发指令给本地资源管理模块。从部署角度来看，本地资源管理模块会部署在每一个数据中心，包括总部级数据中心和地区级数据中心，而全局资源管理模块仅部署在总部级数据中心。

图 2 – 云平台资源管理体系

由于大型集团公司的异构资源非常多，资源管理模块应避免直接通过 API 或 CLI 方式去操作各种底层资源，而是在中间增加一个资源适配器，让资源适配器去适配底层各种不同厂商不同型号的资源，资源适配器为资源管理模块提供统一的资源管理 API，如图 3 所示。如果需要适配新的异构资源，只需要将资源适配器与之进行适配集成，无需修改资源管理模块的代码。这其实就是设计模式中 Facade 模式的具体应用。

图 3 – 资源适配器

云平台会内置一些常见的资源分配策略，但云平台不可能内置所有的资源分配策略，云平台要允许信息系统的管理员根据其业务需求自定义资源分配策略，因此云平台需要设计一个策略引擎模块，负责策略的定义、解析和执行。这也是设计模式中 Strategy 模式的具体应用。

云平台本身也属于支撑型信息系统，完整的云平台需要提供监控、身份认证、日志分析等功能，但往往这些功能已经存在于已有的支撑型信息系统中，设计云平台时要充分考虑复用这些已有的支撑型信息系统，保护已有 IT 投资，这就需要云平台预留各种集成接口，以便与这些系统进行数据交换和应用集成。这里面会用到设计模式中的 Adapter 模式。

针对大型集团公司的上述云计算业务需求，同时参考工业界云计算平台架构和相关国际标准，本文提出了如图 4 所示的云平台架构。

该云平台架包含资源适配器、资源池、资源管理模块（包括本地资源管理模块和全局资源管理模块）、策略引擎、流程引擎、资源编排模块、服务管理模块、门户模块、运营管理模块、运维管理模块和插件管理模块。下面的资源适配器负责适配、组织、整合底层异构 IT 资源，从而构建出各种资源池，资源适配器为上层资源管理模块提供了统一的资源管理 API。资源管理模块负责对资源池进行管理，按照资源的生命周期对资源池中的资源进行管理，根据用户的需求从资源池中分配、调度资源。

为了更灵活地分配和调度资源，该架构设计了流程引擎、策略引擎和资源编排模块。流程引擎负责将各种操作步骤串接在一起，实现各种自动化流程；策略引擎方便管理员根据业务需求自定义资源分配策略；资源编排模块负责将各种云资源进行编排和对接形成彼此关联的资源组合模板，以实现复杂信息系统的快速部署或扩展。服务管理模块按照云服务的生命周期对云服务进行管理。门户模块为云平台的用户、租户管理员和平台管理员分别提供了统一的操作界面。运维管理模块负责云平台和资源池的技术运维，遵循 ITIL v3 标准，面向机器和系统。运营管理模块负责云平台的业务运营，面向用户和租户。插件管理模块为云平台提供了插件机制，通过各种插件与已有的支撑型信息系统集成。各个业务信息系统根据业务需求识别出所需云服务，在云平台中完成服务的制作和发布，形成服务目录，并通过申请云服务完成信息系统的部署。

图 4 – 云平台架构

大型集团公司拥有大量异构网络、存储、虚拟化和物理机资源。网络资源包括来自各种厂商、各种技术规格的防火墙、负载均衡、网络交换机等；存储资源包括来自不同厂商、不同型号的存储阵列和 SAN 交换机；虚拟化资源包括来自不同厂商、不同版本的 Hypervisor；物理机资源包括来自不同厂商、不同型号的 x86 服务器或小型机。为了给云平台的资源管理模块提供统一的 API 接口，云平台架构中针对每一种类型的资源分别设计一个资源适配器，包括网络资源适配器、存储资源适配器、虚拟化适配器和物理机适配器。这些适配器为资源管理模块屏蔽了底层资源的异构性和复杂性，资源管理模块只需要调用适配器的 API，再由适配器去实际操控底层资源。另外，适配器通过适配各种异构资源对这些资源进行组织、整合、池化，形成网络资源池、存储资源池、虚拟服务器资源池、物理服务器资源池。当然，云平台需要按照一定的规则将具备相同能力和属性的资源放到同一个资源池里面，比如将性能高的存储资源放到金牌存储资源池，性能中等的存储资源放到银牌存储资源池。从资源管理模块的视角，看到的是各种资源池，不会看到底层的异构资源。

资源池之上是资源管理模块，包括本地资源管理模块和全局资源管理模块。本地资源管理模块专注于管理和控制本地数据中心的资源池，将资源池中的资源纳管到云平台，负责执行全局资源管理模块下发的资源部署命令，对所辖资源进行分配、调度、扩展和监控，并将结果反馈给全局资源管理模块，资源分配是指系统部署时为系统选择最佳的资源，资源调度是系统运行期间，按照业务量的增减对资源量进行纵向或横向伸缩。全局资源管理模块收集并汇总各个本地资源管理模块上报的资源信息形成资源的全局视图，可以按照租户、数据中心、资源类型等维度查看全局视图；全局资源管理模块统一监控、分配和调度位于不同数据中心的资源；全局资源管理模块还负责统一处理用户的资源部署请求，给各个本地资源管理模块下发资源分配和调度命令。本地资源管理和全局资源管理构成了两级资源管理体系，实现资源的集中式管控和分布式部署的有效结合。

策略引擎负责资源调配策略的定义、解析和执行，实现基于策略的自动化分配和调度，如果策略仓库中的策略不能满足业务要求，还可以允许管理员定制策略，让某个信息系统按照特定的策略进行资源的分配和调度，并可以将定制的策略存储到策略仓库中给其他信息系统复用。策略包含分配策略和调度策略，分配策略是指信息系统部署时选择最佳资源的策略，调度策略是指系统运行时，根据系统维护的要求或业务量的增减对资源进行调整和迁移的策略。

流程引擎负责将资源分配、调度、配置和运维过程中涉及的实际操作步骤进行串接，以实现操作步骤的自动流转，进一步实现复杂的自动化流程，包括服务器自动化流程、网络自动化流程、存储自动化流程等。流程引擎允许管理员定义和编排流程，在实际资源分配、调度、配置和运维过程中，流程引擎对涉及的流程进行解析并执行，并为自动化流程提供可配置的能力。管理员创建的流程可以存储到流程仓库以实现流程复用。

服务管理按照云服务的生命周期对其进行管理，允许管理员定义云服务的部署模型和功能模型，并为部署模型设置一定的自动化流程和分配策略，允许管理员设置云服务的申请界面和用户输入参数。当用户申请了所需的云服务之后，服务管理模块对其进行服务开通，将服务开通涉及的自动化流程告知流程引擎，由流程引擎对其进行解析和执行，并将服务开通涉及的资源分配策略告知策略引擎，由策略引擎对其进行解析和执行。策略引擎会将资源分配请求发到全局资源管理模块，最后返回给服务管理模块，至此完成服务开通的动作。服务开通之后，云平台要通过规范的运维保障工作确保所交付服务的 SLA 满足用户要求。

资源编排模块提供图形化的界面让管理员（租户管理员或平台管理员）对云平台中的各种云资源进行配置、组合、编排和串接，形成资源模板，以适配特定信息系统的拓扑结构。管理员定义好了资源模板后，可以发布为一个新的复合型云服务。用户申请该复合型云服务即触发该服务的开通工作，资源编排模块会解析资源模板及用户输入参数生成对资源类型、属性和数量的具体要求，然后传递给全局资源模块进行资源的分配和部署。管理员可以基于模板仓库中内置的模板进行修改以快速定义复合自己需求的资源模板，创建好的资源模板也可以存储到模板仓库以实现复用。

门户模块提供了用户门户、租户管理门户和平台管理门户。用户门户为云服务的最终用户提供了直观易用的自服务界面，在该界面中最终用户可以完成服务申请、资源查看、资源操作等工作。租户管理门户为租户管理员提供了直观易用的自助管理界面，在界面中租户管理员可以申请配额、创建用户、定义本租户可见内的服务、定义资源模板、制定适应本租户的分配策略等。平台管理门户为云平台管理员提供了直观易用的操作界面，帮助其完成系统运维和运营领域的各项工作。

运维管理模块负责云计算平台的系统运维功能，遵循 ITIL V3 标准，提供容量管理、性能管理、安全管理和日常管理等功能。容量管理通过对资源的历史运行状况进行统计分析，并按照容量预测模型对未来的资源需求进行预测。性能管理通过实时采集资源的性能指标实现对资源运行状况的监控，如果指标超过一定的阈值，则产生告警事件，并调用相应的事件处理流程。安全管理包括服务器安全、存储安全、数据安全、网络安全和虚拟化安全等方面的保障工作。日常管理包括故障管理、问题管理、配置管理、系统管理、监控管理和变更管理。如果运维管理模块中所涉及的功能在已有的支撑型信息系统中已经存在，就没有必要在新建云平台中实现该功能，而是通过插件管理模块与已有的支撑型信息系统的相应功能模块进行集成。

运营管理模块负责云计算平台的业务运营功能，包括用户管理、租户管理、配额管理、权限管理、计量与计费管理等功能。用户管理对用户进行创建、分组和授权等。租户管理负责对多级租户进行管理和配置，维护租户和租户之间的父子关系、租户和用户之间的使用关系、租户和配额之间的关联关系等。配额管理负责把资源分配给各级租户，确保各级租户对资源的使用不能超过配额。权限管理负责为用户指定操作和数据权限。计量与计费管理对租户的资源使用情况进行计量，保存计量数据，定期生成计量报告，计量信息包括资源的类型、资源的使用量及使用时间；平台管理员可为各种资源设定费率，系统可以基于计量信息及费率，产生租户的费用清单。

插件管理模块主要是为了与已有的支撑型信息系统进行集成而设计的，插件管理模块设置了插件机制，允许已有的支撑型信息系统通过插件为云平台提供必要的功能，同时也允许业务其他信息系统为云平台补充额外的功能，云平台通过各种插件与已有的支撑型信息系统和其他业务信息系统进行数据交换和应用集成，例如，云平台的运维管理模块不用实现监控功能，而是通过监控插件复用遗留监控系统中的相关功能。

总结

本文提出的云平台架构为适应大型集团公司 IT 基础设施的特点，专门设计了多级租户管理体系、两级资源管理体系、资源适配器模块、插件管理模块和策略引擎等，能够在一定程度上满足大型集团公司的云计算业务需求，但同时也增加了云平台架构的复杂性，进而增加了云平台设计和开发的难度，大型集团公司参考该云平台架构时需要详细评估涉及的工作量和技术风险。另外，该架构侧重于 IaaS 层面，未考虑 PaaS 的特殊性，据此进行 PaaS 平台架构设计时也需要补充相关的功能模块。