平臺框架

當我在十年前以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請求的形式發送到服務器。 由于我們完全控制應用程序的構建方式，因此我們選擇讓事件先發送回應用程序服務器，然后再路由到事件跟蹤服務器。 這種方法更加方便和強大。

知識門戶

過去，應用程序從數據庫或內部文件存儲庫訪問數據。 但是，為了能夠更好地擴展，我們收集了所有知識以構建知識門戶。 我們還構建了查詢語言來從該門戶檢索知識。 這種方法為知識檢索過程增加了一層，但對我們來說幸運的是，我們的系統不需要提供實時數據。 因此，我們可以利用緩存來提高性能。

結論

以上是我們在遷移到云時轉換軟件架構的一些經驗。 請與我們分享您的經驗和意見。

翻譯自: https://www.javacodegeeks.com/2014/07/from-framework-to-platform.html

平臺框架

總結

以上是生活随笔為你收集整理的平台框架_从框架到平台的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。