建站
咨詢
售后
建站咨詢
新聞中心
如果組織一直在以某種方式開發(fā)或采用應(yīng)用程序架構(gòu)，那么在過去幾年中會看到很多變化。雖然組織采用許多不同類型的架構(gòu)和技術(shù)，但有時卻很難跟蹤它們，因此需要回顧應(yīng)用程序架構(gòu)的應(yīng)用，還要了解其未來的發(fā)展方向。
我們提供的服務(wù)有：成都做網(wǎng)站、網(wǎng)站建設(shè)、微信公眾號開發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認證、吳起ssl等。為上1000家企事業(yè)單位解決了網(wǎng)站和推廣的問題。提供周到的售前咨詢和貼心的售后服務(wù)，是有科學(xué)管理、有技術(shù)的吳起網(wǎng)站制作公司
本文將對應(yīng)用程序架構(gòu)在過去幾年如何演變，以及每次演變的驅(qū)動因素進行分析和探討，還將討論單體架構(gòu)、面向服務(wù)架構(gòu)(SOA)、微服務(wù)，以及事件驅(qū)動架構(gòu)(EDA)。
單體架構(gòu)
在以往，一切都是單一的架構(gòu)。很多組織通常采用單一的應(yīng)用程序完成多個事項。單體架構(gòu)允許組織的開發(fā)團隊快速地將原型與可以完成所有工作的應(yīng)用程序組合在一起。由于不需要依賴其他團隊，因此維護成本較少。但是，隨著應(yīng)用程序投入生產(chǎn)并持續(xù)增長，事情很快就會失控。
例如，典型的單體應(yīng)用程序可能涉及多個層，例如用戶界面層、業(yè)務(wù)邏輯層、數(shù)據(jù)界面層以及數(shù)據(jù)存儲層。該應(yīng)用程序?qū)⒔邮沼脩糨斎耄瑢ζ溥M行處理，采用業(yè)務(wù)邏輯，使用一些現(xiàn)有數(shù)據(jù)對其進行擴充，然后將其存儲在關(guān)系數(shù)據(jù)庫中以供以后進行處理。
單體架構(gòu)存在三個主要缺點：部署緩慢、可擴展性差、相互依賴。由于單體應(yīng)用程序很難調(diào)試和更新，大型應(yīng)用程序需要花費大量時間和精力來識別問題并推出更新，而在推出這些更新時，用戶需求可能已經(jīng)發(fā)生了變化。
單體應(yīng)用程序的第二個缺點是可擴展性差。單體應(yīng)用程序所做的事情十分有限。在當今世界，計算資源的成本比過去低得多，通過簡單地向它們投放計算資源來實現(xiàn)計算并行化變得更加容易。而以往在功能強大但成本極其昂貴的服務(wù)器上運行的單體應(yīng)用程序現(xiàn)在可以輕松地在商用硬件上作為較小的應(yīng)用程序并行運行。此外，成本高昂的硬件也使其快速擴展變得更加困難。
此外對于大型應(yīng)用程序，每一個微小的變化都可能影響應(yīng)用程序的一個或多個其他部分。這增加了潛在破壞重要功能的額外風(fēng)險。例如，用戶界面層中的錯誤可能會影響整個應(yīng)用程序的運行。
例如一個組織正在開發(fā)一個應(yīng)用程序，該應(yīng)用程序提供對跨資產(chǎn)市場數(shù)據(jù)(股票、外匯、商品等)的訪問，并為用戶推出了一項新功能，但由于這個應(yīng)用程序是單一的，其微小改動可能破壞其用戶使用的應(yīng)用程序的一個非常重要的功能。而這兩個功能是完全獨立的，但因為它們是同一個代碼庫的一部分，所以會有一些共享資源。但用戶對此卻并不滿意。
敏捷方法vs.瀑布方法
很多組織很快意識到需要找到一種更好的方法來構(gòu)建他們的應(yīng)用程序。與此同時，敏捷方法變得越來越流行。很多組織以往使用瀑布方法開發(fā)應(yīng)用程序，這意味著收集大量需求、極端規(guī)劃、覆蓋所有邊緣情況，然后小心謹慎地一次性發(fā)布具有所有功能的最終產(chǎn)品。
對于某些行業(yè)來說，由于每次迭代和法規(guī)要求所涉及的成本，采用瀑布方法是唯一的辦法。而對于其他行業(yè)來說，敏捷方法更有效。敏捷方法就是在快速迭代中發(fā)布最小可行產(chǎn)品(MVP)。項目失敗得越快，知道是什么不起作用就越好。敏捷方法已經(jīng)存在了一段時間，并在2011年變得非常流行，而敏捷認證和敏捷教練變得無處不在。
面向服務(wù)的架構(gòu)(SOA)
隨著敏捷方法的采用，擁有可以輕松更新和擴展的較小應(yīng)用程序顯然具有更高價值的優(yōu)勢。這就引出了面向服務(wù)的架構(gòu)(SOA)。在單體架構(gòu)中，一個應(yīng)用程序可以完成所有事情，而在面向服務(wù)的架構(gòu)(SOA)中，一個應(yīng)用程序根據(jù)其用例被分解為幾個較小的服務(wù)。
正如IBM公司所指出的：“面向服務(wù)的架構(gòu)(SOA)的核心目的是通過格式良好、易于使用、同步的接口(例如Web服務(wù))公開隱藏在記錄系統(tǒng)中的數(shù)據(jù)和功能?！?/p>
回到單體應(yīng)用程序示例，它可以分解為多個較小的服務(wù)：
- 用戶界面服務(wù)。
- 業(yè)務(wù)邏輯服務(wù)。
- 數(shù)據(jù)集成服務(wù)。
- 數(shù)據(jù)存儲服務(wù)。
這些服務(wù)中的每一個服務(wù)都負責(zé)一個特定的用例。它們都獨立存在，并通過基于簡單對象訪問協(xié)議(SOAP)的同步API相互通信。但是，隨著組織中服務(wù)數(shù)量的增加，為每個服務(wù)編寫接口以與其他所有服務(wù)進行通信將變得更加困難。這是組織將從使用企業(yè)服務(wù)總線(ESB)中受益的時候。企業(yè)服務(wù)總線(ESB)允許開發(fā)人員解耦他們的服務(wù)(見下圖)并使整體架構(gòu)更加靈活。
解耦服務(wù)
面向服務(wù)的架構(gòu)(SOA)有很多好處：
- 快速推出。
- 更易于調(diào)試。
- 可擴展。
- 明確的職責(zé)分配。
- 減少對其他服務(wù)/組件的依賴。
有了如此顯著的好處，大多數(shù)組織開始采用面向服務(wù)的架構(gòu)和敏捷方法，但他們不知道的是，云計算革命即將來臨。
微服務(wù)
面向服務(wù)的架構(gòu)最終為微服務(wù)架構(gòu)鋪平了道路，微服務(wù)架構(gòu)有許多相似之處，但在一些方面有所不同。
導(dǎo)致微服務(wù)架構(gòu)出現(xiàn)的最重要因素是成本低廉并且靈活的基礎(chǔ)設(shè)施。由于在集群上水平擴展基礎(chǔ)設(shè)施和運行服務(wù)非常容易，因此鼓勵開發(fā)人員編寫可以輕松地在集群上并行運行的軟件。與此同時，能夠處理大數(shù)據(jù)的分布式應(yīng)用程序和框架激增，例如推廣了map-reduce編程模型的Hadoop。
此外，AWS云平臺在2015年開始得以廣泛應(yīng)用?；A(chǔ)設(shè)施即服務(wù)(IaaS)的概念真正開始流行，并且由于價格低廉啟動EC2實例變得非常方便。初創(chuàng)公司就是第一批采用IaaS的公司，中小公司也緊隨其后。在經(jīng)過觀望和等待之后，大公司最終接受了IaaS，并決定采用混合云方法。
雖然云平臺上運行分布式基礎(chǔ)設(shè)施很出色，但也存在一些問題，而在分布式云基礎(chǔ)設(shè)施上以穩(wěn)健的方式運行應(yīng)用程序絕非易事，很多事情都可能出錯。應(yīng)用程序?qū)嵗蚣荷系墓?jié)點可能會失敗，那么如何確保應(yīng)用程序在出現(xiàn)這些故障時仍能繼續(xù)運行?答案是微服務(wù)。
微服務(wù)是一個非常小的應(yīng)用程序，負責(zé)一個特定的用例，就像面向服務(wù)的架構(gòu)一樣，但完全獨立于其他服務(wù)。它可以使用任何語言和框架進行開發(fā)，并且可以部署在任何運營環(huán)境中，無論是在內(nèi)部部署數(shù)據(jù)中心還是在公共云上。此外，它們可以輕松地在不同區(qū)域的多個不同服務(wù)器上運行，以提供并行化和高可用性。例如，一個小型數(shù)據(jù)應(yīng)用程序可以在計算集群中的5個實例上運行，這樣如果一個實例出現(xiàn)故障，其他4個實例將確保數(shù)據(jù)應(yīng)用程序繼續(xù)運行。
將一個服務(wù)分解為多個微服務(wù)意味著它們需要相互通信。與依賴于企業(yè)服務(wù)總線和同步API的面向服務(wù)架構(gòu)不同，微服務(wù)利用消息代理和異步API。
容器化
就像面向服務(wù)架構(gòu)的轉(zhuǎn)變是由敏捷方法推動的一樣，微服務(wù)運動是由容器化推動的。行業(yè)專家Hacker Noon在其撰寫的一篇文章中很好地描述了容器化：“容器化涉及將應(yīng)用程序與其所有相關(guān)的配置文件、庫和依賴項捆綁在一起，以便在不同的計算環(huán)境中以高效且無錯誤的方式運行。”
Docker最初于2013年推出，是當時最受歡迎的容器平臺。如今，幾乎所有現(xiàn)代軟件都可以通過Docker運行。隨著云計算基礎(chǔ)設(shè)施的興起，Docker變得極其重要，可以確保組織可以在新環(huán)境中運行軟件，尤其是在云平臺上。
隨著微服務(wù)變得越來越流行，服務(wù)網(wǎng)格的概念也越來越流行，它允許服務(wù)主要使用請求/回復(fù)消息模式并保持連接。
Nginx公司在博客上對服務(wù)網(wǎng)格有一個很好的解釋：“服務(wù)網(wǎng)格是一個可配置的、低延遲的基礎(chǔ)設(shè)施層，旨在使用應(yīng)用程序編程接口(API)處理應(yīng)用程序基礎(chǔ)設(shè)施服務(wù)之間的大量基于網(wǎng)絡(luò)的進程間通信?！?/p>
2014年，谷歌公司開源了Kubernetes，它允許用戶編排微服務(wù)。有了Docker和Kubernetes，組織在云平臺上部署和管理分布式微服務(wù)變得更加容易。在過去的幾年中，這兩種技術(shù)得到廣泛應(yīng)用。如今，大多數(shù)新的初創(chuàng)公司都編寫了通過Docker輕松部署并采用Kubernetes進行編排的云原生微服務(wù)，許多大型公司正在與Pivotal等公司合作，以輕松地將他們的應(yīng)用程序遷移到云中。
云計算基礎(chǔ)設(shè)施和分布式微服務(wù)的興起導(dǎo)致了大量初創(chuàng)公司的出現(xiàn)，它們提供服務(wù)來監(jiān)控微服務(wù)(它們消耗了多少內(nèi)存)、自動化(自動跨服務(wù)器持續(xù)部署微服務(wù))、資源管理(競標價格最低的AWS資源)等。
事件驅(qū)動架構(gòu)(EDA)
隨著繼續(xù)捕獲越來越多的數(shù)據(jù)，組織需要尋找創(chuàng)造性的方法來使用它。隨著物聯(lián)網(wǎng)(例如Alexa Microwave))和可穿戴設(shè)備(例如Apple Watch)的興起，出現(xiàn)了大量的時間序列數(shù)據(jù)或事件。
智能手機、智能手表、平板電腦、筆記本電腦等如今可以立即推送通知，組織發(fā)現(xiàn)事件驅(qū)動架構(gòu)非常重要，這是因為他們的用戶希望在發(fā)生重要事件時收到實時通知。例如，當航班延誤或開始登機時，航空公司應(yīng)用程序會實時通知乘客。它不會等待人工檢查或定期檢查事件。
在這個全新的事件驅(qū)動世界中，微服務(wù)是圍繞事件設(shè)計的，它正在迅速在各行業(yè)領(lǐng)域得到應(yīng)用。
結(jié)論
本文展示了應(yīng)用程序架構(gòu)在過去幾年中是如何受到不同技術(shù)和需求的影響和演變的。如今大多數(shù)組織都在采用微服務(wù)和云計算，還有一些組織則采用了事件驅(qū)動架構(gòu)。而在可預(yù)見的未來，以事件驅(qū)動的方式設(shè)計的微服務(wù)將會大量涌現(xiàn)。
當前名稱：組織的應(yīng)用程序架構(gòu)是如何演變的？
轉(zhuǎn)載源于：http://m.5511xx.com/article/cdocsej.html
