云集成工具减轻部署挑战

1、云集成工具减轻部署挑战集成是几乎所有的现代应用开发方案的必需元素。多年以来，SOA以及前端Web开发的经验已经就集成教育了筹划者和架构师。早期 的虚拟 化经验更多的扩展了这一点，但是云打破了很多现代集成实 践，因此筹划 者和架构师需要通过询问为何云是不同的来开始其云集 成工程。随后，他 们需要在心里评估云集成方案。对于大多数而言， 关键的一点在于如何在 云部署环境中调节应用集成工具。在早期的应用中，开发者要么编写整体的应用，要么在一个通用的 装 载映像中紧密耦合独立的组件。大量的应用仍旧以这种方式编写，但是SOA和敏捷开发已经开始鼓励架构师构建独立的功能组件，可以利用这些组件来组件应用。 随着

2、业务应用同业务流程以及其它流程 越来越多地集成， 他们需要更为松散的耦合组件，简单地消除单一的 巨大装载映像。基于目录的集成组件已经成为一种规那么。 通过基于目录的集成，一 个 组件注册库本身在某个地方，而且通过这个注册可以分配并且发送 工作。 目录可以相当简单，比方 DNS或者是一个基于功能浏览的注 册库，理论 上SOAUDD就是。不过在所有情况下，这个目录都被期望在首次使用时创立一个加载组件或者触发器组件加载的链接。云计算从两方面对这些造成了挑战。 首先云假定了一种高水平的动 态 资源分配。组件可以放到云中的任何地方， 而且如何接触到这个组 件的 问题边界很少， 同时过去你可以假设所有的一

3、切都至少在一个固 定的数据 中心中存放。第二，云的原那么目标之一就是通过组件实例的 可扩展管理灵 活性和性能。这也意味着，很多组件必须实时共享工作 或者故障恢复。通 常创立集成到组件的链接的过程并不是瞬时的，而 且在延迟阶段，事务处 理可能受到牵连。满足这些挑战的关键是评估云计算，识别集成痛点所在。首先，要 关 注任何地方的组件可以在加载或者故障恢复情况下云资源化。此 外，要关 注云组件被云提供商重新分配以响应问题的情况。 任何这样 的场景都需要一些同其他组件和工作流的特殊集成处理。云用户表示更加偏爱基于 DNS的负载均衡，将其作为工作到云的组件的一种方式，可以实现故障恢复或者水平扩展。 在可

4、扩咱的情况 下，基 于DNS的负载均衡允许同当下的组件连接工作，同时增加一个新的，因此QoE伴随的唯一风险就是组件失败，这也是大局部公司要接受的。如果任何的宕机时间都无法忍受， 那么至少通过任何点 的两个可用组件副本和 通过DNS集成来解决。基于DNS的负载均衡的问题在于并不支持组件浏览没有WSD而且可能导致工作流到组件的状态问题。 如果出于这两个原因没有可 能使用基 于DNS的负载均衡，下一个最正确的战略就是依赖于 UDDI和WSD或者BPEL 来在组件之间进行选择。 如果管理组件链接的 应用控制流程无法为云端转 移组件负责， 就会出现潜在的问题。如果 转一个组件改变了地址，组件 就会处于未

5、链接状态。亚马逊的解决方案是弹性IP地址，让静态URL弓I用动态组件。这种地址转换的方法 也可以用在私有云中。亚马逊弹性 IP 地址模型展示了云集成的一个根本领实。有两种形 式的组件移动性 ：一是必须识别出独立的组件作为分立的元素可以链 接到 工作流中，另一个是识别出通过云流程创立的继承组件副本，非通过应用流程储藏间。如果你接受URL是逻辑组件移动和物理组件位置之间的边界的原那么的话，用标准化集成工具包括DevOps或者CAMP调节这种组合更容易。集成工具应该用于将组件带到一起，因为工作流必须直接同其单独 接 触。这个工具的目标就是直接同 URL工作，并期望这个URL随后 可以通 过独立的后端集成流程匹配资源。以地址组件改变时通过资源管理器调用工具为条件，在一个集成工 具中通过URL管理地址表达是可行的。关键问题在于不是管理这种改变，而是管理处理中的事物改变产生的影响。 允许任何静态的流来 改变根底中 流是非常危险的。会导致所谓的结束时期?因此在改变URL的目标地址之前，这对于静态工作流来报告处理中的事物的失败可能是最正确的方式。平安和法规遵从是任何集成列表上最后的元素。 工作流可能呈现为 相 对有状态的、末端平安和法规遵从问题， 但是就算组件链接可以导 致问题， 应用平安审计可能会发现。组件弹性带来了多种机遇，引