云服务架构与企业架构转型

### 云服务架构与企业架构转型 云计算的出现彻底改变了企业构建和运行业务应用程序的方式。它消除了评估、购买、配置和管理企业应用所需的所有硬件和软件的成本与复杂性，使这些应用通过互联网作为服务交付。下面将详细介绍云服务架构的各层以及企业架构向云服务转型的相关内容。 #### 数据与信息层 数据与信息层包含语义定义和数据模型。语义定义可理解为业务对象术语表，确保不同企业或云领域间的共同理解；数据模型视角则实现分布式系统间的信息交换。 为应对逻辑数据模型和物理信息交换模型的挑战，可创建通用数据模型，如分布式管理任务组（DMTF）开发的通用信息模型（CIM）。通用数据模型由业务流程管理的生命周期共享和拥有，打破传统技术依赖，确保信息、数据与应用及业务的松散耦合。它还使数据管理摆脱对应用的传统依赖，促进专有应用数据模型之上的共享信息交换，将信息和数据所有权转移到更以业务驱动的生命周期管理。企业与云集成时，数据与信息层常使用云平台即服务（PaaS）。 #### 集成层 集成层的两个主要组件包括流程和信息集成以及企业应用集成。该层实现逻辑业务、数据与信息层和技术与工具层之间的松散耦合，主要目的是通过遵循标准、减少对技术的依赖、确保可扩展性和对变化的响应能力，促进组件的互操作性。此层对面向服务架构（SOA）规则和设计原则尤为关键，是联合不同技术和为企业业务服务的云应用的核心层。 #### 技术与工具层 技术与工具层可视为整体企业视角的物理层，包括应用和技术平台两个主要组件。在云计算中，工具是重要组成部分，对云解决方案的成功至关重要。市场上虽有大量交付云解决方案的技术，但因缺乏全面、易懂的工具，这些技术往往难以实施。 在云的应用服务层，工具可为云应用开发提供环境，并提供将应用打包和部署到云基础设施的手段。不过，现有工具大多与云提供商的基础设施绑定。开放标准是使工具发挥最大功效和灵活性的关键，工具应支持应用开发、打包和部署，使项目能在多个云基础设施间移植。 在基础设施服务层，工具也有明确作用。构建云基础设施并非易事，云提供商的所有物理资产都需考虑，以确保为云分配正确的物理资源。工具应帮助企业可视化其IT资产，并为云的创建提供一定的智能支持，引导用户根据系统的预期需求特征构建云的物理结构。企业与云集成时，技术与工具层常使用云基础设施即服务（IaaS）/硬件即服务（HaaS）。 #### 企业架构风格 架构风格定义了软件系统家族的多个方面： - 架构组件交互模式 - 架构中可能存在的组件类型及其组合约束 - 组件的部署组合方式 - 工作单元的管理方式，如是否为事务性（n阶段提交） - 组件提供的功能如何组合成更高级的功能，以及如何供人类或其他系统使用 主要有两种架构风格：SOA和非SOA。SOA风格是自上而下的，强调分解到功能级别，以服务为导向而非应用为导向。它将策略作为一等架构组件，便于管理服务相关任务的透明执行，能根据用户/业务需求调整性能，而无需考虑架构细节。实施SOA可实现更好的架构分层和分解，使接口更面向业务而非数据，策略更明确且易于更改，便于使用通用基础设施进行集成和互操作。 非SOA风格是自下而上的，从基础设施角度出发构建到业务功能层。基于客户端 - 服务器、面向对象和分层架构风格构建的应用平台多采用非SOA方法。由于这些架构存在局限性，需要向SOA平台转型。 一般来说，在功能级别集成业务比在较低技术层集成更简单，因此应强调分解到功能级别，这通常由市场标准、监管约束或会计实践决定。架构风格对于编排服务和实现数千个协作企业间的可操作性至关重要，互操作性应通过在业务功能级别而非数据级别集成的架构来实现。采用SOA视角要求系统架构师或服务设计师从一开始就分离关注点，应用平台应从一开始就进行分布式设计。企业需理解如何去除计算平台中内置的业务安全和访问控制模型，以实现新一代架构要求的业务敏捷性目标。 #### 架构转型 如今企业的IT团队面临将现有或遗留的非SOA应用平台转型为能有效利用云与服务网格技术能力的SOA平台的压力。以下将探讨从非SOA（自下而上）到SOA（自上而下）的架构转型策略及可能遇到的问题。 ###