混合云架构的7个规则

JP Morgenthal的这篇文章来自DZone云开发指南 - 2015年版。欲了解更多信息，包括行业专家的深度文章，PaaS，iPaaS，IaaS和MBaaS的最佳解决方案，请点击以下链接下载免费的指南。

据研究公司IDC预测，到2016年，超过65％的企业IT将致力于混合云技术。 IDC并不是唯一一家给出混合云计算企业采用率很高的预测的企业，Gartner Group也预测，到2017年，50％的企业将部署混合云。DZone的2015年云开发调查显示，目前有50％的受众使用混合云技术。

混合云架构经常被描述为“私有云和公共云共享资源”。但事实上，许多混合架构只是利用公共云资源与私有托管应用程序相结合。例如，企业可能会从公共云上的多个外部源捕获，聚合和分析数据，然后将这些结果传递给在私有托管环境中运行的应用程序。或者一个企业可能会将其公共网络存在于公共云中，但将该应用程序的数据保存在私有托管环境中。

这种公私合作会带来潜在的复杂性。本文将介绍采用混合云架构时需要考虑的七条规则。

规则1：您正在扩大您的业务足迹

部署混合云体系结构时要牢记的最重要的事情之一是，您正在扩大您的业务足迹。虽然这看起来似乎很明显，但它可能会对IT运营和开发组织产生真正的影响。请考虑以下问题：

• 哪个团队负责在公共云中运行的组件？
• 您的IT运营团队是否准备好管理另一个平台？
• 您当前的监控和运营工具是否可以与公共云提供商一起使用？
• 这个架构如何影响对服务台的呼叫？
• 公共云和数据中心之间的网络中断计划是什么？

正如您所看到的，混合架构可能会要求您聘请具有适当技能的人员在所选公共云平台上运行。同样，如果当前工具不支持所选的云平台，那么可能需要购买新的监控工具。一些组织可能会选择使用“NoOps”方式，在这种方式下，开发团队负责在公共云上运行的应用程序组件 - 这是一种可以消除IT运营负担的方法，但这需要定义新的运营业务流程。

这里关键的一点是，由于按需计算的性质，决定采用混合式可能看起来很简单，但不应该被公司轻视。

规则2：不要与YouTube和Facebook分享您的网络

请确保您与您的网络运营团队合作，这样才能确定混合应用程序周围的网络需求。有时唯一的协作是开发人员要求将端口打开到公共互联网，以便私人托管的应用程序可以接收来自公共云应用程序的请求。

如果网络运营不知道是否需要与公共云建立连接以保证服务质量，那么您的应用程序流量可能会与在Facebook上观看吸猫视频的同事共享带宽。您的网络运营团队需要成为部署混合云应用团队的一个组成部分，这样他们才能专注于合适的连接和流量管理。

规则3：避免反向重力数据

简单来说，“数据引力”是一个理论，即每个进程都应该迁移到给定相对质量的数据中。也就是说，当您考虑以TB或PB为单位运行数据时，流程会变得相当轻便简洁。但是，混合云体系结构有时会遭受“反向数据引力”的困扰，因为使用混合云意味着在私有托管环境中保留（某些）数据。也就是说，托管在公共云中的进程从私有云中提取数据。这是一个限制了风险的架构选择，但在某个时刻，公司需要确定什么是可接受的数据量。这个数据量在达到收益递减点之前可以移动。进一步影响反向数据重力是通过服务提取数据或直接连接到私有数据源的选择。后者很可能会导致更多的数据传输。

此外，由于您现在拥有在公共云上运行的应用程序组件，因此公共云和私有云上都会生成数据。具体来说，日志是通过公共云上的活动生成的 - 这就意味着需要被管理和分析的新数据。

规则4：别太信任了

这也被称为Captain Obvious规则。但事实是，有时企业为了追求简单而做出糟糕的选择。例如，一些企业实际上已经在私有云上存储了私钥，从而能够连接到私有托管环境。但这为私人环境带来了重大的风险。其实如果需要密钥，则应将其加密存储在第三方存储库中，并在需要时由进程提取，并在不再需要时进行擦除。企业这种错误的关注点大幅增加了攻击面。

以下是一些其他的最佳实践建议：

• 限制可以与数据中心建立安全连接的端点数量
• 限制公共云中启用Internet的服务器的访问
• 从公共云上离开安全区域的流量应该通过网络地址

请注意，NAT服务器通过限制访问公有云上的专用网络区域来提供更高程度的安全性。但是这也是一个流量瓶颈和单点故障，因此可能需要高可用性和负载平衡解决方案来获得必要的性能。

规则5：重新设计应用程序可能提供更好的性能

如果我们将传统的三层Web应用程序视为混合架构的良好模型，那么在公共云拥有Web界面而在私有云拥有应用程序服务器和数据库是一种自然的倾向。但是，这种架构可能无法为应用程序提供最佳的经济性或性能。

有时重新设计应用程序更利于充分使用公共云服务，同时仍然提供混合云架构的好处，所以重新设计是很有益的。如图1所示：从左向右移动，我们可以看到应用程序的各个部分开始转移到公有云。第一个过渡说明应用程序服务器的拆分，以使某些服务可以在Web服务器上本地运行，而其他服务则在数据库本地运行，如果计算功能和数据管理功能是分开的，那么这是一个很好的折衷。

最右边的例子表示将所有除数据以外的东西移动到公共端，但也有可能表示使用缓存技术或NoSQL数据库来临时存储数据，以便计算功能可以更有效地响应。这些修改可以有效减少延迟，对用户交互的响应更快，并且限制了需要传回私有端的数据量。

规则6：不要像对待其他数据中心那样对待公共云

在未知或不熟悉的领域，回到到我们所知道的方面是人性使然。对于运营人员来说，即使他们在云平台上进行了培训，他们也将对自己在过去几年的职业生涯中的运作方式非常熟悉。这样就会造成过度配置，在云计算的背景下，这就意味着您订购的虚拟机和存储器超出了您真正需要的的数量。也可能意味着他们选择部署和管理所有软件组件，而不是使用公共云提供商提供的服务，例如关系数据库和排队服务。

公共云的价值不仅仅是资源的可用性，它也让你以良好的经济价值获得这些资源。利用诸如保留折扣政策之类的东西，比按需购买所有东西更好。使用提供高可用性和故障转移选项的工具和服务可以比手动构建这些功能更有效，且成本更低。由于私有托管环境中不存在这些选项，所以操作往往被迫进入双重状态，需要不同的方法来管理资源。对于许多人来说，这种二元性可能令人不安和困惑。

规则7：测试，测试，然后，再测试

测试您的混合云架构需要了解构建分布式应用程序的常见问题。网络已经变得如此可靠，有时我们确信我们的数据包会到达目的地。但是，与网络一样可靠，由于硬件故障或流量增加，仍然会发生传输错误。关键是在面对这些故障时为您的应用程序开发适当的弹性。

应用程序开发人员花费了数年的时间来处理数据中心内的可靠性问题，这可以依靠光纤连接和高速连通性。当我们转向混合架构时，我们经常通过较慢的连接进行通信，并与其他应用程序共享带宽。因此，我们需要一些额外的测试来确定我们的应用程序将如何响应。

以下是我们为混合应用推荐的其他测试列表：

• 网络故障测试
• 增加延迟测试
• VM服务器故障测试
• 无效的消息测试（针对服务）
• 授权测试
• 认证测试

结论

正如我想说的：“混合云架构很容易...直到他们不简单。”在管理企业级、稳健的混合云部署时。许多隐藏的复杂事情都会涉及其中。对于用于构建分散的应用程序的方法和用于构建跨越公共广域网的跨地理便捷的应用程序的方法，我们不能期望它们具有相同的行为，也不能指望它们以相同的方式运行。遵循这七条规则提出的建议，我希望能够帮助您发表具有弹性的混合应用程序。