去年我们曾报道过， Arjuna Technologies （HP 事务服务技术的初创者，现在 Red Hat/JBoss 的一部分）又把注意力转向了容错的网格基础设施。这篇文章在当时引起了极大的兴趣，即使当时并没有什么东西可供人们来尝试。然而，事隔一年之后，Arjuna 发布了更加实在的东西： Arjuna Agility 联邦云计算平台。这里有必读的白皮书和网络研讨会（事实上非常不错），但是关于 Agility 最重要的是现在可供访问了。再加上
[Agility] 是一个‘联邦云计算平台’，它被设计成可通过更灵活的基础设施来提高业务敏捷性。联邦，是因为 Agility™是由分配给企业内外自治、合作的业务组织的 IT 资源构成的。
该文章继续描述道： > 在组织间资源共享的真正障碍往往是信任和权限，Agility™提供了一种可掌控的方式使得企业能有机地壮大它们的‘内部云服务’。资源的所有者可对所分配的资源附加一定的策略用以描述在哪种情况下资源可以被 Agility™共享，通过这种方式，资源所有者保有了对资源的控制权。一旦（资源）被分配并遵从于策略，Agility™就可以动态地配置资源池并提供服务以满足业务对 IT 变化的需求。
像其它的云计算平台一样，完成这一供应（provisioning）所需的服务和工具可能超出现有的基础设施投资。然而，要交付其承诺的益处，Agility 最终需要获得对整个云架构的掌控：
虽然 Agility™也可以部署于现有的基础设施而不需作出折衷的更改，但在增量地向其分配 IT 资源时 Agility™的威力才能真正的体现出来。
将这一新平台与现有解决方案对照得出的差别会非常有益，然而它显然还处于开发的早期阶段。尽管如此，最新的白皮书还是给了我们一些线索：
和其它的途径不同，Agility 不会强制企业的 IT 基础设施和应用作出“大爆炸”般的转变。
这一点初看起来和之前 Agility 需要完全控制的陈述似乎是相矛盾，但对于这种化圆作方（即不可能）的事，Agility 作出了许多努力。实际上，据现有消息来看，Agility“不要求现有基础设施进行任何更改或重组”，也“不要求资源进行共享，除其所有者允许的情况之下”。这种无侵害的方式支持用户进行全面的扩展，甚至利用其服务时都不需要了解 Agility 的存在。
从该平台的表现来推断，应该是基于 ESB 的，因为有很多相关参考指出其“基于服务并包含支持多种访问协议的协议网关”。尽管它包括一些你所知道的关于云服务平台的常见疑虑，比如跨越管理边界的服务共享控制以及动态的服务配置与供给等等，但它还有一些新颖出彩的地方，这令它显得更加有趣：
- Agility 通过策略定义的方式获取服务和资源，例如，某种策略使得在特定环境下其他用户可获得其资源，比如在业务关键时刻，其它基础设施都已经超负荷的情况下。遗憾的是，Agility 没有明显说明策略到底是如何定义的，WS-Policy 吗？实际上所有关系都是通过服务协议来表示的。这表明云计算将可能向着更加注重 SOA 治理的方向前进吗？
- 接下来他们还提供了虚拟部署描述语言（Virtual Deployment Description Language），它是描述服务和服务所需软硬件资源，以及服务之间关系的一种高级语言。这和 SOA 治理的某些方面以及服务依赖图的相关工作是类似的。但从云计算的角度看来，这却是一种很新颖的手段。如果不是这样的话，在这方面可能会需要进行标准化，来消除对特定供应商的锁定问题。
但考虑到 Arjuna 的背景，Agility 里将如何融合其容错技术呢？
……通过在检测到失效时支持动态地重新部署资源，依赖性得以改善。失效之后，随着服务需求与 IT 基础设施之间解耦，Agility 可以确定能够满足服务需求的替代资源，并重新配置系统来使用这些资源，以保证可持续地满足服务的需要。
目前还没有迹象表明 Agility 使用的是现有失效探测机制还是其自已的技术。在缺少一个详尽架构描述的前提下，很难作出相应的判断。但看似有一件事是确定的：这一次事务处理没有被包含进整个宏图中（除非它们已经隐含为基础设施的一部分）。
查看英文原文： Agile Cloud Computing?
暂无签名
腾讯大规模云原生技术实践案例集
本案例集详细阐释了 QQ、腾讯会议、和平精英、小红书、斗鱼、微盟等十多个亿级用户产品背后的大规模云原生...
评论