微信號：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、微服務架構模式使得每個服務獨立擴展。
你可以根據每個服務的規模來部署滿足需求的規模。甚至於，你可以使用更適合於服務資源需求的硬件。