云环境中开发PK云环境中管理，挑战有什么不同?

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

　　一问：为云环境进行开发面临什么挑战?

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

　　二问：那么，您怎样知道所有这些依赖关系在哪里、又该怎样利用它们?

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

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

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

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

　　为云环境进行开发面临的另一个问题是处理横向扩展——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.