當(dāng)我將近十年前作為Java開發(fā)人員開始我的職業(yè)生涯時，該行業(yè)正在經(jīng)歷革命性的變化。 Spring框架（于2003年發(fā)布）Swift發(fā)展起來，并成為龐大的J2EE平臺的嚴重挑戰(zhàn)者。 經(jīng)過過渡時間后，我很快發(fā)現(xiàn)自己贊成使用Spring框架而不是J2EE平臺，即使是早期版本的Spring，聲明bean也非常乏味。

接下來發(fā)生的是對J2EE標(biāo)準(zhǔn)的改進，該標(biāo)準(zhǔn)后來被重命名為JEE。 盡管如此，在這個時代占主導(dǎo)地位的仍然是在Sun提出的平臺上使用開源框架。 這種做法使開發(fā)人員可以完全控制他們使用的技術(shù)，但會擴大部署規(guī)模。 慢慢地，當(dāng)云應(yīng)用程序成為現(xiàn)代應(yīng)用程序的規(guī)范時，我觀察到了將基礎(chǔ)架構(gòu)服務(wù)再次從框架遷移到平臺的趨勢。 但是，這次，它不是受Cloud應(yīng)用程序的驅(qū)動。

框架與平臺

我從未聽說過或不得不在學(xué)校使用任何框架。 但是，在加入該行業(yè)后，如果沒有任何框架的幫助，就很難構(gòu)建可擴展和可配置的軟件。

據(jù)我了解，任何應(yīng)用程序都包含實現(xiàn)業(yè)務(wù)邏輯的代碼以及一些其他幫助程序，實用程序或用于設(shè)置基礎(chǔ)結(jié)構(gòu)的代碼。 在許多項目中重復(fù)使用的與業(yè)務(wù)邏輯無關(guān)的代碼可以被概括并提取出來以供重用。 此提取過程的輸出是框架。

簡而言之，框架是與業(yè)務(wù)邏輯無關(guān)但有助于解決應(yīng)用程序中常見問題并適合重用的任何代碼。

如果遵循此定義，則MVC，依賴注入，緩存，JDBC模板，ORM都是考慮的框架。

平臺與框架相似，因為它也有助于解決應(yīng)用程序中的常見問題，但是與框架相反，該服務(wù)是在應(yīng)用程序外部提供的。 因此，公共服務(wù)端點可以同時為多個應(yīng)用程序提供服務(wù)。 JEE應(yīng)用程序服務(wù)器或Amazon Web Services提供的服務(wù)是平臺的示例。

比較這兩種方法，平臺比框架更具可擴展性，更易于使用，但它提供的控制更少。 由于這些優(yōu)勢，平臺似乎是構(gòu)建Cloud Application時更好的使用方法。

我們什么時候應(yīng)該在框架之上使用平臺

轉(zhuǎn)向平臺并不能保證開發(fā)人員會擺脫框架。 相反，平臺僅是構(gòu)建應(yīng)用程序時對框架的補充。 但是，在某些特殊情況下，我們可以選擇使用平臺或框架來實現(xiàn)最終目標(biāo)。 我個人認為，在滿足以下條件時，平臺比框架更好：

• 框架使用和維護都很繁瑣
• 該服務(wù)具有一些在實例之間共享的公共信息。
• 可以利用其他硬件來提高性能。

在辦公室中，我們?nèi)栽趹?yīng)用程序中使用Spring框架，Play框架或RoR，并且這不會很快改變。 但是，為了進入云時代，我們將一些現(xiàn)有產(chǎn)品從內(nèi)部托管遷移到了Amazon EC2服務(wù)器。 為了充分利用Amazon基礎(chǔ)架構(gòu)并提高軟件質(zhì)量，我們對當(dāng)前的軟件架構(gòu)進行了一些重大重構(gòu)。

以下是一些我們要將產(chǎn)品集成到的平臺：

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

我們發(fā)現(xiàn)，Amazon Cloud Front對于提高應(yīng)用程序的平均響應(yīng)時間非常有用。 以前，我們在英國和美國的內(nèi)部服務(wù)器場中托管大多數(shù)應(yīng)用程序。 這導(dǎo)致其他大洲客戶的響應(yīng)時間顯著增加。 幸運的是，亞馬遜擁有更強大的基礎(chǔ)架構(gòu)，其服務(wù)器場遍布全球。 無論客戶身在何處，這都有助于確保包裹的交貨時間恒定。

當(dāng)前，由于手動為應(yīng)用程序設(shè)置新實例，我們認為Amazon Cloud Front的最佳用途是使用靜態(tài)內(nèi)容，該內(nèi)容與Amazon S3中的應(yīng)用程序分開托管。 這種做法使CDN提供了更一致的交付時間，同時在瀏覽器中為靜態(tài)內(nèi)容提供了單獨的連接計數(shù)，從而為我們帶來了性能上的雙重好處。

亞馬遜彈性緩存

在集群環(huán)境中進行緩存從未如此簡單。 “群集”一詞意味著您的對象將不會被存儲或從系統(tǒng)內(nèi)存中檢索。 相反，它是通過網(wǎng)絡(luò)發(fā)送和檢索的。 過去，此任務(wù)非常棘手，因為開發(fā)人員需要將記錄從一個節(jié)點同步到另一個節(jié)點。 不幸的是，并非所有的緩存框架都自動支持此功能。 最佳的分布式緩存框架是Terracotta 。

現(xiàn)在，我們轉(zhuǎn)向Amazon Elastic Cache，因為它便宜，可靠，并且為我們節(jié)省了設(shè)置和維護分布式緩存的巨大精力。 值得強調(diào)的是，分布式緩存決不是要取代本地緩存。 性能上的差異表明，僅當(dāng)用戶需要訪問實時臨時數(shù)據(jù)時，才應(yīng)在本地緩存上使用分布式緩存。

數(shù)據(jù)分析的事件記錄

過去，我們使用Google Analytics（分析）來分析用戶行為，但后來決定建立內(nèi)部數(shù)據(jù)倉庫。 動機之一是能夠跟蹤來自瀏覽器和服務(wù)器的事件。 事件跟蹤系統(tǒng)使用MongoDB作為數(shù)據(jù)庫，因為它允許我們快速存儲大量事件。

為了簡化事件的創(chuàng)建和檢索，我們選擇JSON作為事件的格式。 由于瀏覽器無法防止跨域攻擊，因此我們不能簡單地將此事件直接發(fā)送到事件跟蹤服務(wù)器。 因此，Google Analytic將事件以對靜態(tài)資源的GET請求的形式發(fā)送到服務(wù)器。 由于我們完全控制應(yīng)用程序的構(gòu)建方式，因此我們選擇讓事件先發(fā)送回應(yīng)用程序服務(wù)器，然后再路由到事件跟蹤服務(wù)器。 這種方法更加方便和強大。

知識門戶

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

結(jié)論

以上是我們在遷移到云時轉(zhuǎn)換軟件架構(gòu)的一些經(jīng)驗。 請與我們分享您的經(jīng)驗和意見。

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。