哈希映射的负载因子_将工作负载映射到云

哈希映射的负载因子

当团队采用云技术时，他们通常会在技术和项目计划讨论中大意扔掉术语“ 工作量” 。 问题在于该术语对具有不同角色的人而言意味着不同的事物，从而导致分歧和不正确的期望。 本文探讨了这些不同的观点。 它提供了有关如何精确定义工作负载所需的各个角度（包括业务，体系结构，用户交互和数据等）的指南。 本文的第一部分概述了定性定义工作负载的一组核心属性和相关属性。 本文的第二部分从将工作负载迁移到云和混合云的角度解决了这些注意事项。

有关该术语的一些历史

术语“ 工作量”在信息技术（IT）领域并不是新事物。 这个术语是在大型机时代的1960年代初创造的。 那么，为什么我们现在尝试在五十年后再次讨论它？

随着越来越多的采用云计算 ，不提及工作负载一词就很难进行对话。 例如，开发团队可能会谈论将其工作负载迁移到云中，努力将其工作负载移动到云中，在私有云中运行其工作负载或将其工作负载更改并适应云。 该术语通常带有不同的含义，常常导致歧义和错误传达。

计算机科学和IT领域中通常定义的术语“ 工作负载”主要是从系统资源使用或容量的角度来表征的，因此具有很大的局限性。 在UNIX平台上，工作负载是在UNIX主机上运行的进程数的上下文中引用的。 UNIX操作系统可以提供正常运行时间命令。 该命令为系统管理员提供了一种方便的方法，使其可以检查系统上当前正在运行的工作负载，并且可以评估系统上的负载是增加还是减少。

展望未来，随着组织制定其云战略并采用相关技术和实践（例如微服务和容器），必须对工作负载一词进行更全面，更全面的定义。 别忘了， 工作负载是为组织提供竞争价值的关键资产，并且是IT存在的主要原因。 因此，在这种新的云环境下，对构成工作负载概念的内容进行更具包容性和全面的描述是必不可少的，也是本文的目标。

工作负载的基本部分

与我们有关工作量一词的问题有关的一个寓言是大约七个盲人。 每个人都触摸大象身体的不同部位，并从有限的角度争论他们对动物的解释。 总的教训是，尽管各个观点在某种程度上是正确的，但整个事实是这些观点的总和。

要了解什么是工作负载（即我们的类比），您首先需要了解基本的工作负载模型和构建它的服务。

工作量模型

例如，无论您是开发人员，测试人员还是管理员，您通常只对部分工作量具有可视性，这些部分适用于您的角色，或者更确切地说，是您的一小部分。 但是，从更广泛的组织角度来看，其他组件从业务功能，运行时执行，部署，安全性和管理角度构成工作负载。 下图概述了工作负载的七个关键属性，下一部分将对其进行说明。

该应用程序代表工作负载的核心部分。 一个应用程序通常由三个组件组成-用户界面，业务逻辑（业务和集成服务）和数据服务。 应用程序组件实现工作负载的功能要求 。 部署，安全和治理组件通常代表工作负载的非功能需求 。

API背后的抽象服务

服务是工作负载的基本构建块。 它是一个无状态软件组件，可以独立包装，部署，保护，以自助服务方式使用，并且有可能以自动化方式进行管理。 下图说明了服务的示意图。

更广泛地说，工作负载是一组既满足预期功能要求又满足非功能要求的相互关联的服务的系统集合。 同时，工作负载可提供建议的总体业务价值。 这个概念的核心是在应用程序编程接口（API）之后抽象业务服务和基础结构服务的想法。

工作负载的七个关键属性

如上一节所述，工作负载具有七个关键属性。 此处将对每个详细说明。

战略企业架构

每个工作负载都有战略要务和业务驱动力。 通过了解它们，您可以进一步推动或验证许多体系结构和部署决策。 关键任务是为手头的工作量开发企业架构视图。 该视图提供了对关键用例，客户端和渠道如何与工作负载进行交互，所提供的服务以及如何在高层次上协调服务以实现当前业务功能的见解。 下图以分层架构说明了这一概念。

与任何分层体系结构一样，战略企业体系结构具有控制权的分离。 每一层专注于为其上方的层提供特定的功能，并使用其下方的层的服务。 通道层表示对企业所需的各种通道的支持。 API Services层为特定业务流程的执行提供了编程入口。 业务和流程服务要求业务服务运行任何特定的自定义逻辑或转换。 域服务通常代表需要读取或保留到企业数据存储中的特定实体数据。 通过使用通用的便携式连接器框架，持久性可以发生在传统的数据库系统或其他企业系统上。

但是，要完全了解工作负载，您必须映射各种请求如何进入系统，如何处理它们以及服务请求需要哪些外部系统交互。 考虑一个典型的示例，其中客户在呼叫中心呼叫代理商。 呼叫中心代理以一种形式输入用户信息，然后启动业务流程以从外部客户关系管理（CRM）系统检索客户数据。

企业架构师通常提供或创建战略企业架构。 然后，业务线（LOB）主管，应用程序架构师和其他利益相关者使用它来讨论工作负载的总体业务和技术目标。 他们可以使用这个无所不包的体系结构图来讨论组织的业务方面和技术方面。

应用架构

该应用程序代表工作负载的功能需求 ，并具有三个关键组成部分：用户界面，业务逻辑和数据。

业务逻辑包括通用业务服务和集成服务。 应用程序的这种表示在IT中并不是新事物。 但是，随着行业创新的发展，这些部件的组成，暴露，分布和连接方式已经随着时间而改变。 代表性状态转移（REST）是关键启用技术的常见示例，该技术允许这些不同层中的组件进行互操作。

过去，应用程序是作为一个整体打包和部署的，并在单个主机（例如大型机）上运行。 随着PC的增长，客户端/服务器计算变得越来越有吸引力。 它要求将用户界面，业务逻辑和数据组件分开。 然后，随着Internet，Web和面向服务的体系结构（SOA）的出现，多层计算得到了发展。 最近，应用程序正在采用围绕微服务的更新范例，并使用基于Web的技术来快速开发应用程序。 图6表示通用的四层分布式应用程序体系结构。

定义应用程序时，需要了解以下特征：

• 端到端应用程序体系结构和体系结构样式，例如：SOA，多层或微服务
• 编程模型，例如：Java企业版（Java EE），Microsoft .NET，Spring或开源MEAN堆栈
• 如何公开业务流程和公共服务，例如：SOAP，REST或套接字
• 用于各层之间的访问和互操作性的协议，例如：远程方法调用（RMI），HTTP，TCP / IP或Java消息服务（JMS）
• 企业集成资源和连接性，例如：数据库，SAP，大型机，排队或CRM

我们使用术语polyglot来描述用于实现应用程序各个组件的各种特性。

应用程序的UI服务

用户界面（UI）表示应用程序如何与外部世界交互，并且由于众所周知的原因而成为关注的焦点。 它规定了如何接收输入以及如何呈现响应。 UI服务应支持上一节中描述的战略企业体系结构。

该应用程序取决于通道，例如浏览器，绿屏或移动设备。 因此，定义应用程序时需要了解以下特征：

• UI组件模型
• 基于企业架构需要支持的协议范围
• 所采用的主要框架
• UI服务如何与后端支持服务交互
• 应用程序是否支持API

Java EE应用程序通常使用JavaServer Pages（JSP）或JavaServer Faces（JSF），其中使用HTML5，JavaScript和移动框架构建移动通道。 集成和使用基于REST的后端服务的AngularJS前端正变得越来越普遍。

为了完整起见，并非所有工作都是通过直接用户交互来启动的。 越来越多的企业通过使用API​​公开其服务。 例如，批处理应用程序由调度程序触发，并且不需要用户界面。 通过使用消息传递进行集成的B2B应用程序是另一类基于事件的应用程序。 它们以编程方式集成，因此不需要用户界面。

应用程序的业务和集成服务

业务和集成服务（也称为业务逻辑 ）是应用程序的核心部分。 关键业务流程作为服务提供给渠道和其他消费者。

关键业务流程通常是从用户请求触发的，用户请求从那里接收驱动业务流程的必要输入。 从一个简单的流程到一个非常复杂的流程（需要多个后端资源来完成执行），业务流程的复杂度可能会有所不同。

在检查工作负载时，必须了解业务流程和支持的公共服务之间的依赖关系。 服务和层的数量将因一个应用程序而异。 您必须分析如何将这些服务从逻辑体系结构映射到物理部署拓扑。 另外，您必须全面记录每种方案所需的后端企业资源依赖关系。

该领域的典型示例是基于业务流程执行语言 （BPEL）的流程来提交保险索赔。 在执行过程中，此过程可能会在后端大型机系统中检索并存储信息。 BPEL流程与基于SOAP的Web服务进行通信，而该Web服务又通过UNIX上托管的基于Java的服务与大型机进行通信。

应用程序数据服务

如您先前观察到的，业务和集成服务需要依赖基础数据服务来存储和检索数据。 基础数据存储或域模型可以根据数据驻留的方式和位置而有所不同。 大多数情况下，数据会保存到高度规范化的关系数据库系统中。 但是，许多企业数据存在于大型机上的分层数据库系统中。 最近，NoSQL数据存储变得越来越流行。

因此，通常有一个多语言持久性环境。 在这种环境中，某些数据位于关系系统中，例如Oracle，某些数据位于大型机CICS系统中，而某些数据在键值存储中，例如IBM®WebSphere®eXtreme Scale或Redis。

其他重要考虑因素围绕事务完整性，机密性，分区和延迟。 这些注意事项可以从技术角度入手，但它们是完整性的必要考虑因素。 一些用例对数据一致性要求有些宽容，而其他用例则对准确性和可靠性有严格的法规要求。 某些数据模型允许数据分区支持高级别的并发性和最终一致性，以容忍网络故障。 从合规性，延迟，安全性和性能的角度来看，数据放置是另一个重要的考虑因素。

在过去十年中，最流行的数据访问模式是基于Java数据库连接（JDBC）架构的。 数据访问服务通常使用持久性框架构建，例如Hibernate和Java Persistence API（JPA）体系结构。 用于大型机，SAP，Siebel或其他类似企业系统的数据服务利用Java EE连接器体系结构（JCA）连接器与它们进行通信。

数据服务中的一个相关考虑因素是，通过在数据网格中进行缓存来加速数据访问，从而加速应用程序访问。 这种方法主要在更快的响应时间，增强的用户体验，卸载后端系统以及节省数据库基础结构成本方面带来了很多好处。 WebSphere eXtreme Scale，Redis，Cassandra和MongoDB是一些流行的NoSQL数据存储。

部署模型

部署模型是软件到硬件的映射。 它表示从应用程序体系结构到运行工作负载所需的适当生产运行时体系结构的映射。 这种映射通常称为拓扑 。 下图说明了应用程序服务器部署的简单拓扑。

该拓扑表示应用程序组件，与基础架构相关的组件的支持类型及其相对位置。 基础结构组件的示例包括负载平衡器，代理服务器，防火墙，Web服务器，目录和安全服务器。

选择适当的拓扑以满足工作负载的功能和非功能需求需要仔细计划。 在决定正确的拓扑时，请考虑以下因素：

• 业务势在必行。 需要高度隔离和控制的关键任务工作负载
• 高可用性（HA）。 由HA要求控制的组件冗余度
• 灾难恢复。 达到恢复点目标和恢复时间目标
• 安全要求 。 沿着请求路径的各个点放置安全控件
• 性能。 拓扑满足指定响应时间和吞吐量指标的能力
• 可扩展性。 优雅和尽可能线性地支持不断增长的工作负载的能力
• 可管理性。 提供，自动化和部署应用程序和基础架构的能力

安全模式

考虑到应用程序（尤其是基于移动和Internet的应用程序）的高度分布式性质，您必须清楚地了解工作负载的安全模型。 在更细粒度的级别上，以下元素共同定义了工作负载的安全模型：

• 身份验证。 建立身份的机制，例如：约翰真的是约翰吗？
• 授权。 访问控制，例如：John是否有权执行操作Y？
• 保密。 数据隐私，例如：是否允许John查看数据元素Z？
• 数据的完整性。 确保数据在发送后未被未经授权的用户修改
• 不可否认。 用以证明执行操作的用户以后无法拒绝它的机制
• 审核。 维护感兴趣的安全级别事件的记录或日志

下图说明了Java工作负载安全模型的这些元素。

所使用的特定安全服务通常取决于容器提供的基础编程模型和安全服务。 下图说明了请求流的示例，该请求流通过相关的Java EE安全语义集进行了扩充。

工作负载的安全性不仅仅包含应用程序层。 如上图的部署模型所示，请求的数据和关联的数据通常流经多个中介。 因此，从端到端的角度，您必须了解安全要求。 也就是说，您必须沿请求路径（从源到目标再到回）指定安全配置要求，如上图所示。 要了解工作负载的安全模型的端到端语义，还必须为所有中间组件指定所有安全要求。

治理模式

治理与领导力和问责制有关。 在工作负载的上下文中，这是确保业务目标与工作负载管理之间进行战略调整的过程。 治理采用适当的机制，以确保工作负载可预测地执行并可以可靠地实现业务目标。 因此，治理过程负责建立以下功能：

• 根据关键绩效指标衡量工作负载绩效。
• 跟踪，执行和报告服务级别协议（SLA）管理。
• 聚合，分析和综合系统中的各种日志。
• 提供基于业务标准的高可用性计划。
• 阐明灾难恢复计划和过程以测试故障转移计划。
• 确保定义了恢复点目标（RPO）和恢复时间目标（RTO）。
• 确保符合安全标准。

治理是产品和流程的良好结合。 必须为任务使用正确的工具。 IBM提供了一套IT服务管理产品，您可以将其用于应用程序监视和SLA管理。 高可用性计划和灾难恢复计划通常是过程文档，描述了这些事件发生时应遵循的步骤。

云环境中的工作负载

关于将工作负载移动到云的决策有几个因素。 其中一些因素本质上是组织，财务，监管和技术方面的。 对于没有现有应用程序的公司或初创公司，计算平台的选择通常会更简单。 基于云的公司不必处理与较旧且通常更封闭的系统的迁移和集成。 对于他们来说，迁移或适应云计算相对容易。 这些工作负载被恰当地称为“在云中出生”或“云本机应用程序”。

较老的企业在将工作负载迁移和集成到云中时没有那么容易。 他们必须首先为云重构或启用其许多现有工作负载。 在确定工作负载已准备好云之后，他们需要做出以下决定：

• 什么是最合适的云服务模型？
• 最佳的云部署模型是什么？

下图说明了将工作负载映射到云时需要做出的两个决策。

为工作负载选择适当的云服务模型

七个工作负载特征共同帮助确定目标云服务模型。 下图突出显示了三种云服务模型：软件即服务（SaaS），平台即服务（PaaS）和基础架构即服务（IaaS）。

以下各节重点介绍决定云服务模型之间的主要因素。

IaaS模型

IaaS通过使用自助服务模型提供计算资源。 您可能出于以下原因选择IaaS模型，其中包括：

• 您的工作负载具有严格的吞吐量和响应时间保证。
• 您的工作负载至关重要，需要管理可用性风险。 它还具有严格的RPO和RTO。
• 您的工作负载需要云的好处，例如按需容量和快速自助服务配置。 它还需要在配置管理和性能调整优化方面的灵活性和控制能力。

PaaS模型

PaaS可帮助您在云中为云开发由云管理的应用程序。 您可能出于以下原因选择PaaS模型，其中包括：

• 企业希望摆脱对开发，测试和运行时环境的管理。
• 工作负载是主要基于创新的基于云的服务的集合。 API被大量用于内部集成和外部合作伙伴集成。
• 您可以使用平台服务来开发，运行和维护云中的工作负载。
• PaaS平台的可用性通常取决于基础IaaS平台的可用性和可靠性。 将应用程序部署到PaaS平台时，必须了解这些依赖性及其对服务质量（例如RPO，RTO，吞吐量和响应时间）的影响。

SaaS模型

SaaS提供可以通过Internet使用的专用应用程序。 您可能出于以下原因选择SaaS模型：

• 使工作负载作为SaaS产品可用是一项前期业务决策：使软件和功能作为基于订阅的服务可用，可以通过使用浏览器，Web API或同时使用这两者来进行访问。
• SaaS产品的提供商必须使用基础平台并将所有配置元素构建到软件中，以确保易于使用，部署，打补丁，管理和使用它。
• 您想保留对其配置，打包，部署，分发，管理和使用方式的控制。

为您的工作负载选择最佳的云部署模型

您需要确定是将工作负载部署到公司防火墙后的私有云还是将其托管在云服务提供商的防火墙后的公共云中。 要做出此决定，您需要考虑关键数据点。

在较高的级别上，私有或公共之间的选择由工作量的要求所决定，这些需求取决于必需的控制级别以及可以容忍的隔离或共享的程度。 成本绝对是一个考虑因素。 但是，当您做出此关键决定时，您需要考虑相关的组织风险。

例如，您的工作负载部署在基于IaaS的基础架构（例如Amazon Web Services）上托管的PaaS平台上。 在这种情况下，工作负载的整体可用性和SLA与底层IaaS基础架构的性能和可用性紧密相关。 对于高吞吐量，关键任务应用程序，此模型可能不可接受。

私有云的标准

如果工作负载满足以下条件，则可以将工作负载部署到私有云：

• 它是一种高容量，关键任务的工作负载，需要高水平的吞吐量和延迟。
• 它具有有关安全性，隐私性，机密性和数据资产放置的法规要求。
• 您的环境具有组织私有的云所需的组织IT成熟度，技能和硬件资产。
• 它需要确定性的 RPO和RTO才能实现高可用性和灾难恢复。
• 它需要定制和特定于平台的优化。
• 它是现有的工作负载，无法轻松启用以供公共云使用。

适合此模型的工作量示例包括核心银行系统，医院管理系统，股票交易网站，大批量商务站点，票务系统或交通控制系统。 您还可以将这些工作负载托管在公共云中。 但是，像所有事物一样，您需要在计划中考虑风险。

公共云的标准

如果工作负载满足以下条件，则可以将工作负载部署到公共云：

• 它使用云经济学，例如公用事业定价的可用性和较低的前期资本支出。
• 它通过相对较大的订阅进行标准化。
• 它是临时的，临时的或季节性的，需要动态的即时容量配置。
• 它可以容忍偶尔的延迟，并且没有严格的SLA来保证可用性。

适合此模型的工作负载示例包括测试工作负载，电子邮件系统，协作系统，存储工作负载，分析或批处理工作负载。 Netflix和Uber是广泛使用的公共云示例。 奥巴马总统大选竞选活动展示了一个临时工作负载的示例，该工作负载已在云上进行了配置，扩展了导致选举的能力，然后在选举后立即取消了配置。

混合云方案

最近，公共云和私有云之间的鸿沟越来越明显。 大多数企业拥有现有的IT资产，因此在进行云计算之旅时需要依靠这些投资。 因此，从实际角度看，大型企业最有可能部署混合云方案，这些方案要求将应用程序和数据组件最佳地放置在私有云或公共云中。 云服务和平台提供商提供了必要的连接器，网关，适配器等，以支持各种应用程序和数据集成混合云架构。

为了帮助您了解工作负载如何在混合云体系结构中运行，我们重点介绍了三种情况，如下图所示：

• 方案1.表示层和业务逻辑层在公共云中运行，而数据位于私有云中。
• 方案2。一个应用程序（通常是一个参与系统）完全在公共云中运行。 此方案的关键特征是支持该应用程序的相关数据被实时过滤并从私有云复制到公共云。
• 方案3。一个基于云的应用程序聚合来自私有云中托管的后端系统和本地数据中心中的数据源（例如大型记录系统）的数据。

从根本上讲，混合云实施是功能的平台或生态系统。 总体而言，它们使工作负载能够分布在异构环境中，例如公共或私有云或现有的传统数据中心。

结论

本文提供了一个描述工作量的综合模型。 该模型包含七个关键属性，这些属性共同阐明了企业应用程序的体系结构目标以及功能和非功能方面。 该模型对于将现有工作负载迁移到云或将新工作负载映射到基于云的体系结构很有用。 这些概念提供了一种结构，用于促进围绕与新兴云环境中的工作负载相关的架构问题进行更系统的讨论。

---

翻译自: https://www.ibm.com/developerworks/library/mw-1609-fernandes-trs/index.html

哈希映射的负载因子