挑战有何不同！云环境中开发 vs 云环境中管理-51CTO.COM

云计算的优点已经被捧上了天，主要包括能够带来业务敏捷性、可扩展性、效率以及节省成本；而许多公司正以越来越快的步伐，迁移和构建专门面向云环境的关键任务型Java应用程序。我们最近采访了AppDynamics 公司的工程技术主管Bhaskar Sunkara——这家应用程序性能公司专注于Java和云应用程序，探讨了为云环境开发Java应用程序以及在云环境中管理这些应用程序面临的挑战。

为云环境进行开发面临哪些挑战？

为云环境进行开发面临的主要挑战之一是，了解应用程序与服务的依赖关系（application service dependencies）是如何处理的，这比了解编程语言还要重要。应用程序与服务的依赖关系包括：分布式环境中部署的数据库、消息服务器或其他服务。这些传统上是通过在部署过程中将服务引用映射到物理IP来处理的，但是云带来了一个新的变化因素，连IP地址都不是事先知道的。
那么，您如何知道所有这些依赖关系在哪里、又该如何利用它们？

从根本上来讲，当你拥有面向服务的环境时，会有许多服务彼此“会话”，并且利用众多基础架构元素。在任何一个特定的时间，你的服务可能使用所有其他这些服务。在传统的静态环境中，你很容易了解这些元素在哪里，然后编写代码。开发人员能够确认资源，会知道应用程序一旦部署下去，要使用什么资源。可是在云环境中，无法保证应用程序会使用哪种IP，也无法保证它会如何查找服务或数据。

开发人员需要深入了解如何以一种非常明智的方式来使用服务。高效找到资源的功能需要成为应用程序的一部分，谨慎地使用这项功能方面要有可重复使用的模式。使用查找模式来找到你想使用的服务，是解决这个问题的流行方法之一。如果你在构建应用程序时没有考虑到这些因素，就可能带来无法管理的扩展性和重构问题。

至于正式的规范，J2EE在部署过程中借助资源映射，在资源依赖关系方面已经做得很到位。比如说，应用程序与数据库进行联系，而你与为你提供连接的逻辑资源进行联系。当你部署应用程序时，把这个资源映射到实际的数据库IP/URL，不需要硬编码。

在J2EE开发模式中，开发人员得到JNDI命名上下文，让他们可以查找所需要的服务——这需要用可以将IP依赖关系抽取出来的可感知云的命名上下文来加以包装。这么做的话，可感知云的命名上下文是拥有“服务定位器”（Service Locator）元素的唯一元素，维护起来要容易得多。

为云环境进行开发面临的另一个问题是处理横向扩展——Java开发人员应该知道哪些东西？

云计算的一个基本前提是它能够便于横向扩展（horizontal scaling），但不是所有的应用程序天生都可以横向扩展，它们也从来没必要横向扩展。必须确保云环境中的任何应用程序都具有无状态性（Statelessness）。对于按需基础架构而言，喜欢本地保留状态的习性打破了一切。编写的应用程序必须确保：需要扩展的任何应用层都具有横向扩展的能力。在最近的几年里，我们开始看到了比较新的应用程序中出现这种情况，但这对许多开发人员来说仍是个障碍。

如果让您为从事云环境编程的Java开发人员提议一个最佳实践，那会是什么？

别对数据存储局部化！如果你这么做，这几乎如同将数据处理局部化到某一个Java虚拟机（JVM），而不是把它当作云来对待。这可能会带来局部化到JVM的依赖关系。数据管理应该总是分布式的。你一定要假设服务器会失效，而且是常常失效。关系数据库不再是云环境中的常态。由于应用程序生态系统出现了那么多的变化，应用程序必须天生是无状态的。

当然了，也不要使用物理IP或基于磁盘的定位器来查找你在应用程序中需要使用的服务。要依靠把物理IP抽取出来的位置模式或服务。

那真是个好点子。最后，开发人员将应用程序部署到云环境之前，应用程序测试方面要了解哪些东西？

如果你想测试处于开发周期的应用程序，如果你想看看它在云环境中怎样运行，就面临这个挑战：从本地开发环境迁移到云环境。想从本地开发环境进入到云环境有难度。事实上，没有办法有效地模拟一旦应用程序部署下去，云环境的外观感觉会怎么样。能处理云环境的集成开发环境（IDE）同样仍在不断成熟当中。从本地测试环境切换到云环境的过程越顺畅，开发周期的效率就越高。过去将应用程序部署到云环境上常常困难重重。现在要容易多了，但要让整个过程变得真正的高效顺畅，开发工具依然有很大的发展空间。

原文名：Developing for the cloud: How developing in the cloud is different 作者：Cameron McKenzie et al.

【本文乃51CTO精选译文，转载请标明出处！】

【编辑推荐】