平臺(tái)框架

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

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

框架與平臺(tái)

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

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

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

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

平臺(tái)類似于框架，因?yàn)樗灿兄诮鉀Q應(yīng)用程序中的常見問題，但是與框架相反，該服務(wù)是在應(yīng)用程序外部提供的。 因此，公共服務(wù)端點(diǎn)可以同時(shí)為多個(gè)應(yīng)用程序提供服務(wù)。 JEE應(yīng)用程序服務(wù)器或Amazon Web Services提供的服務(wù)是平臺(tái)的示例。

比較這兩種方法，平臺(tái)比框架更具擴(kuò)展性，更易于使用，但控制量也較少。 由于這些優(yōu)勢，在構(gòu)建Cloud Application時(shí)，平臺(tái)似乎是更好的方法。

我們什么時(shí)候應(yīng)該在框架上使用平臺(tái)

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

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

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

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

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

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

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

亞馬遜彈性緩存

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

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

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

過去，我們使用Google Analytics（分析）來分析用戶行為，但后來決定建立內(nèi)部數(shù)據(jù)倉庫。 動(dòng)機(jī)之一是能夠同時(shí)從瀏覽器和服務(wù)器跟蹤事件的能力。 事件跟蹤系統(tǒng)使用MongoDB作為數(shù)據(jù)庫，因?yàn)樗试S我們快速存儲(chǔ)大量事件。

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

知識(shí)門戶

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

結(jié)論

以上是我們?cè)谶w移到云時(shí)轉(zhuǎn)換軟件架構(gòu)的一些經(jīng)驗(yàn)。 請(qǐng)與我們分享您的經(jīng)驗(yàn)和意見。

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

平臺(tái)框架

總結(jié)

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

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