在我从事 Java 开发的这十年来，这个行业已经发生了翻天覆地的变化。2003 年发布的 Spring 框架，以闪电般的速度攻城略地并向传统 J2EE 平台发起挑战。我经历了整个变革，而且迅速发现比起 J2EE 平台，我更喜欢 Spring 框架，即使一开始的时候用它来声明 Bean 是那么恶心。
接下来发生的就是 J2EE 规范的修整，后来改名为 JEE 了。但是，这段时间仍然是开源框架占据统治地位，Sun 主导的平台继续偏安一隅。这种方式给了开发者掌控一切的感觉，但也迅速增大了部署包的体积。慢慢地，随着云服务的兴起，我发现开始有了将基础服务重新从框架迁回平台的趋势。
当我在学校的时候，我从没听说过或者用过框架。但是，在加入这个行业后，发现不依赖框架的帮助去构建健壮的良好的程序是相当困难的。
从我的理解，任何应用都包含业务逻辑代码和帮助代码，帮助代码可能是工具类也可能是基本配置类，这些代码和业务逻辑无关，且可能在很多项目中被重复使用。于是我们可以把这部分代码精简抽取出来，抽取出来的代码就是框架。
简单的说就是，框架是一些和业务逻辑无关，能够实现普适性的功能并可以重用的代码。
如果按这个定义，那么 MVC，依赖注入，缓存，JDBC 模板，ORM 都可以被当做框架。
平台和框架类似，它也会在程序中提供普适性的功能，但和框架不同的是，它是在应用之外提供的。所以，它的一个服务终端可以同时为很多个应用提供服务。JEE 服务器或者亚马逊 WebSerivce 都是典型的平台。
把这两个作下比较就会发现，平台比框架扩展性、易用性更强，但控制性相对差。由于这些特性，在我们构建云应用的时候平台就会是一个更合适的途径。
平台化并不是指开发者抛开全部框架。相反，平台应该在构建应用的时候为框架做对应补充。当然，在某个特殊的场合下，我们为了达成目标，可能既能用平台也能用框架。从我的观点来看，当符合以下条件时平台会比框架更合适：
在工作中，我们仍在程序中继续使用 Spring 框架，Play 框架，ROR等，而且这种局面在短时间内是不会改变的。然而，为了拥抱云时代，我们已经把我们现在的部分产品从内部服务器迁移到了亚马逊 EC2 服务器上。为了更好的利用亚马逊提供的服务和提高软件质量，我们也在软件架构上做了部分重构。
这是一些我们已经融合的服务：
我们发现亚马逊的分发云服务为提升我们应用的平均响应时应时间是非常有用的。在这之前，我们所有的程序都运行在英国和美国的机房里。这无疑会令在其它地方的使用者响应时间变慢。幸运的是，亚马逊在世界各地都有机房。这样就能让使用者在任何地方的情况下都有稳定的响应时间。
现在，由于我们经常人工增加应用实例，我们能清晰感觉到亚马逊的分发云服务最合适的场景就是静态内容，这部分内容我们已经从应用拆分到了亚马逊简易存储上。通过 CDN 和浏览器端单独的网络连接使得在加载静态内容的时候获得了两倍的性能提升。
在集群环境中要实现缓存是相当困难的。“集群”意味着你的缓存对象不仅仅会在系统内存中存取。反而，它会需要被通过网络发送和接收。这项功能在过去实现会很复杂，因为这需要从一个结点到另一个结点同步数据。不幸的是，不是所有的缓存框架都能自动实现这项功能。我们用过的最好的分布式缓存是 Terracotta。
现在，我们换到了 Amazon Elastic Cache 因为它很便宜，而且非常可靠，为我们设置和维护分布式缓存节省了大量人工。需要注意的是分布式缓存从不意味着取代旧式缓存。它们性能上的差异导致我们只应该在需要实时获取缓存数据的时候才使用分布式缓存。
过去，我们使用 Google Analytics 分析用户行为，后来我们决定构建自己的数据中心。这么做的一个理由就是这样我可以同时追踪浏览器和服务器的事件。这个事件追踪系统使用了 MongoDB 作为数据库，因为它能快速存储大量事件数据。
为了简化创建和检索事件数据，我们选择了 JSON 作为事件的存储格式。我们不能简单的直接把事件信息发送到追踪服务器，因为浏览器有跨域限制。所以，Google Analytic 采用了请求静态资源的方式发送事件信息。因为我们有应用的全部操作权限，我们选择了让事件先发送到应用服务器然后中转到事件追踪服务器。这种方式更方便和强大。
过去，应用通过数据库或者内部文件存储获取数据。但是，为了更好的可扩展性，我们收集了所有的数据并组建了数据中心。我们也构建了内部检索用的查询语言。这种方式增加了一个数据访问层，但幸运的是，我们的系统不需要实际数据。所以，我们可以通过使用缓存提升性能。
以上就是我们将软件迁移到云平台的过程中的一些经验。希望你也能分享下你的经验和观点。
lzxz1234 22 July 2014