您好,登錄后才能下訂單哦!
微信號:GitShare
微信公眾號:愛折騰的稻草
如有問題或建議,請公眾號留言[^1]
三層應用架構
隨著面向對象分析、面向對象設計、面向對象原則、設計模式、企業架構模式等理念以及方法論的不斷發展,根據提供的功能和軟件結構的不同,我們將應用開發分為三層(表現層、業務邏輯層和數據訪問層),俗稱三層架構。
三層應用架構的優勢
三層應用架構的出現,解決了系統間調用復雜,職責不清晰的問題,有效的降低了層與層之間的依賴關系,成為軟件架構的經典模式之一。
三層應用架構的劣勢
三層應用架構只是將系統在邏輯上分為了三層,但它并不是物理上的分層。我們最終還是將所有的代碼都耦合在一起進行編譯、打包、部署,運行在同一個進程中。
隨著業務的不斷擴大,需求功能的持續增加,單塊架構已經很難滿足業務快速變化的需求。一方面,代碼的殼維護性、擴展性、靈活性在降低;另一方面,系統的修改成本、交付周期長、技術選型成本高以及維護成本在顯著增加。
互聯網應用特點
互聯網時代的產品通常具有:創新成本低、需求變化快、用戶群體龐大的特點。
1、什么是微服務架構模式
微服務架構是一種架構模式,它提倡將單一應用程序劃分成一組小的服務,服務之間相互協調、互相配合,為用戶提供最終價值。每個服務運行在其獨立的進程中,服務與服務間采用輕量級的通信機制互相溝通。每個服務都圍繞著具體業務進行構建,并且能夠獨立的部署到生產環境、類生產環境中。另外,應盡量避免統一的、集中式的服務管理機制,對具體的一個服務而言,應根據業務上下文,選擇合適的語音、工具對其進行構建。 ——摘自馬丁.福勒先生的博客。
2、微服務與SOA
SOA實現 | 微服務實現 |
---|---|
企業級,自頂向下開展實施 | 團隊級,自底向上開展實施 |
服務由多個子系統組成,粒度大 | 一個系統被拆分成多個服務,粒度小 |
企業服務總線,集中式服務架構 | 無集中式總線,松散的服務架構 |
集成方式復雜(ESB/WS/SOAP) | 集成方式簡單(HTTP/REST/JSON) |
單塊架構系統,高耦合部署復雜 | 各個服務獨立部署 |
3、微服務應用架構
一個微服務一般完成某個特定的功能,比如下單管理、客戶管理等等。每一個微服務都是微型六角形應用,都有自己的業務邏輯和適配器。一些微服務還會發布API給其它微服務和應用客戶端使用。其它微服務完成一個Web UI,運行時,每一個實例可能是一個云VM或者是Docker容器。
這種微服務架構模式深刻影響了應用和數據庫之間的關系,不像傳統多個服務共享一個數據庫,微服務架構每個服務都有自己的數據庫。另外,這種思路也影響到了企業級數據模式。同時,這種模式意味著多份數據,但是,如果你想獲得微服務帶來的好處,每個服務獨有一個數據庫是必須的,因為這種架構需要這種松耦合。
1、通過分解巨大單體式應用為多個服務方法解決了復雜性問題。
在功能不變的情況下,應用被分解為多個可管理的分支或服務。每個服務都有一個用RPC-或者消息驅動API定義清楚的邊界。微服務架構模式給采用單體式編碼方式很難實現的功能提供了模塊化的解決方案,由此,單個服務很容易開發、理解和維護。
2、這種架構使得每個服務都可以有專門開發團隊來開發。
開發者可以自由選擇開發技術,提供API服務。當然,許多公司試圖避免混亂,只提供某些技術選擇。然后,這種自由意味著開發者不需要被迫使用某項目開始時采用的過時技術,他們可以選擇現在的技術。甚至于,因為服務都是相對簡單,即使用現在技術重寫以前代碼也不是很困難的事情。
3、微服務架構模式是每個微服務獨立的部署。
開發者不再需要協調其它服務部署對本服務的影響。這種改變可以加快部署速度。UI團隊可以采用AB測試,快速的部署變化。微服務架構模式使得持續化部署成為可能。
4、微服務架構模式使得每個服務獨立擴展。
你可以根據每個服務的規模來部署滿足需求的規模。甚至于,你可以使用更適合于服務資源需求的硬件。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。