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