平台框架_从框架到平台

平台框架

当我在十年前以Java开发人员的身份开始职业生涯时，该行业正经历着革命性的变化。 2003年发布的Spring框架Swift流行，并成为庞大的J2EE平台的严重挑战者。经过过渡时间后，我很快发现自己赞成使用Spring框架而不是J2EE平台，即使是早期版本的Spring，声明bean也非常乏味。

接下来发生的是对J2EE标准的改进，该标准后来被重命名为JEE。尽管如此，在这个时代占主导地位的仍然是在Sun提出的平台上使用开源框架。这种做法使开发人员可以完全控制他们使用的技术，但会扩大部署规模。慢慢地，当云应用程序成为现代应用程序的规范时，我观察到了将基础架构服务再次从框架迁移到平台的趋势。但是，这次，它不是受Cloud应用程序的驱动。

框架与平台

我从未听说过或不得不在学校使用任何框架。但是，在加入该行业后，如果没有任何框架的帮助，就很难构建可扩展和可配置的软件。

据我了解，任何应用程序都包含实现业务逻辑的代码以及其他一些用作帮助程序，实用程序或设置基础结构的代码。在许多项目中重复使用的与业务逻辑无关的代码可以被概括并提取出来以供重用。此提取过程的输出是框架。

简而言之，框架是与业务逻辑无关但有助于解决应用程序中常见问题并适合重用的任何代码。

如果遵循此定义，则MVC，依赖注入，缓存，JDBC模板，ORM都是框架。

平台类似于框架，因为它也有助于解决应用程序中的常见问题，但是与框架相反，该服务是在应用程序外部提供的。因此，公共服务端点可以同时为多个应用程序提供服务。 JEE应用程序服务器或Amazon Web Services提供的服务是平台的示例。

比较这两种方法，平台比框架更具扩展性，更易于使用，但控制量也较少。由于这些优势，在构建Cloud Application时，平台似乎是更好的方法。

我们什么时候应该在框架上使用平台

迈向平台并不能保证开发人员会摆脱框架。相反，平台仅是构建应用程序时对框架的补充。但是，在某些特殊情况下，我们可以选择使用平台或框架来实现最终目标。我个人认为，在满足以下条件时，平台比框架更好：

框架使用和维护都很繁琐
该服务具有一些在实例之间共享的公共信息。
可以利用其他硬件来提高性能。

在办公室中，我们仍在应用程序中使用Spring框架，Play框架或RoR，并且这不会很快改变。但是，为了进入云时代，我们将一些现有产品从内部托管迁移到了Amazon EC2服务器。为了充分利用Amazon基础设施并提高软件质量，我们对当前的软件架构进行了一些重大重构。

以下是一些我们要将产品集成到的平台：

Amazon Simple Storage Service（Amazon S3）和Amazon Cloud Front

我们发现，Amazon Cloud Front对于提高应用程序的平均响应时间非常有用。以前，我们在英国和美国的内部服务器场中托管大多数应用程序。这导致其他大洲客户的响应时间显着增加。幸运的是，亚马逊拥有更强大的基础架构，其服务器场遍布全球。无论客户身在何处，这都有助于确保包裹的交货时间恒定。

当前，由于手动为应用程序设置新实例，我们认为Amazon Cloud Front的最佳用途是使用静态内容，该内容与Amazon S3中的应用程序分开托管。这种做法使CDN提供了更一致的交付时间，同时在浏览器中为静态内容提供了单独的连接计数，从而为我们带来了性能上的双重好处。

亚马逊弹性缓存

在集群环境中缓存从未如此轻松。 “群集”一词意味着您的对象将不会被存储或从系统内存中检索。相反，它是通过网络发送和检索的。过去，此任务非常棘手，因为开发人员需要将记录从一个节点同步到另一个节点。不幸的是，并非所有的缓存框架都自动支持此功能。最佳的分布式缓存框架是Terracotta 。

现在，我们求助于Amazon Elastic Cache，因为它便宜，可靠并且为我们节省了设置和维护分布式缓存的巨大精力。值得强调的是，分布式缓存决不是要取代本地缓存。性能上的差异表明，仅当用户需要访问实时临时数据时，才应在本地缓存上使用分布式缓存。

数据分析的事件记录

过去，我们使用Google Analytics（分析）来分析用户行为，但后来决定建立内部数据仓库。动机之一是能够同时从浏览器和服务器跟踪事件的能力。事件跟踪系统使用MongoDB作为数据库，因为它允许我们快速存储大量事件。

为了简化事件的创建和检索，我们选择JSON作为事件的格式。由于浏览器无法防止跨域攻击，因此我们不能简单地将此事件直接发送到事件跟踪服务器。因此，Google Analytic将事件以对静态资源的GET请求的形式发送到服务器。由于我们完全控制应用程序的构建方式，因此我们选择让事件先发送回应用程序服务器，然后再路由到事件跟踪服务器。这种方法更加方便和强大。