微服務架構是一種架構模式，它提倡將單一應用程序劃分成一組小的服務，服務之間互相協調、互相配合，爲用戶提供最終價值。每個服務運行在其獨立的進程中，服務於服務間採用輕量級的通信機制互相溝通（通常是基於 HTTP 的 RESTful API）。每個服務都圍繞着具體業務進行構建，並且能夠被獨立地部署到生產環境、類生產環境等。另外，應儘量避免統一的、集中式的服務管理機制，對具體的一個服務而言，應根據業務上下文，選擇合適的語言、工具對其進行構建。
軟件架構的進化
所有的應用全都是混合在一起的
形成了如JDBC等獨立組件
多層的模式
仍然是一單體模式的形式存在
單體模式的優勢
單體模式的不足
微服務架構
重新設計一下開始所提到的傳統應用
微服務架構的特性
單一職責
微服務架構中的每個服務，都是具有業務邏輯的，符合高內聚、低耦合原則以及單一職責原則的單元，不同的服務通過“管道”的方式靈活組合，從而構建出龐大的系統。
輕量級通信
服務之間通過輕量級的通信機制實現互通互聯，而所謂的輕量級，通常指語言無關、平臺無關的交互方式。
對於輕量級通信的格式而言，我們熟悉的 XML 和 JSON，它們是語言無關、平臺無關的；對於通信的協議而言，通常基於 HTTP，能讓服務間的通信變得標準化、無狀態化。目前大家熟悉的 REST（Representational State Transfer）是實現服務間互相協作的輕量級通信機制之一。使用輕量級通信機制，可以讓團隊選擇更適合的語言、工具或者平臺來開發服務本身。
獨立性
每個服務在應用交付過程中，獨立地開發、測試和部署。
在單塊架構中所有功能都在同一個代碼庫，功能的開發不具有獨立性；當不同小組完成多個功能後，需要經過集成和迴歸測試，測試過程也不具有獨立性；當測試完成後，應用被構建成一個包，如果某個功能存在 bug，將導致整個部署失敗或者回滾。
在微服務架構中，每個服務都是獨立的業務單元，與其他服務高度解耦，只需要改變當前服務本身，就可以完成獨立的開發、測試和部署。
敏捷性
因爲把每一個代碼都分到了每一個微小的服務當中，所以，代碼的運行速度更快，也帶來了更短的反饋週期。
簡化了使用方法，因爲每一個微服務功能都非常單一，非常的簡單，使用起來非常方便。
同時，可以非常快速的應對變化，當發生一個新的需求的時候，可以很快的應對這種需求的變化。
接受新技術
因爲微服務是分散式的管理方式，開發過程中可能每一個組或者團隊只負責自己的服務，
如果需要做一些技術上的調整，只需要在組內得到同意即可。
同時，每一個微服務可以使用自己獨立的技術，只需要保持對其他服務提供API的接口不變就可以。
這樣的架構使之非常易於接受新事物，使重構服務變的可行。
高效的團隊
每一個團隊只需要負責自己的功能模塊，責任明晰，邊界清楚。
如果團隊發生重組的時候，可以圍繞業務功能進行組織，非常靈活。
進程隔離
單塊架構中，整個系統運行在同一個進程中，當應用進行部署時，必須停掉當前正在運行的應用，部署完成後再重啓進程，無法做到獨立部署。
有時候我們會將重複的代碼抽取出來封裝成組件，在單塊架構中，組件通常的形態叫做共享庫（如 jar 包或者 DLL），但是當程序運行時，所有組件最終也會被加載到同一進程中運行。
在微服務架構中，應用程序由多個服務組成，每個服務都是高度自治的獨立業務實體，可以運行在獨立的進程中，不同的服務能非常容易地部署到不同的主機上。
SOA與 微服務
單塊架構
對不同層的代碼而言，經過編譯、打包和部署後，所有的代碼最終還是運行在同一個進程中。而這，就是所謂的單塊架構。
單塊架構的優缺點
優點：
易於開發： 開發方式簡單，IDE 支持好，方便運行和調試。
易於測試： 所有功能運行在一個進程中，一旦進程啓動，便可以進行系統測試。
易於部署： 只需要將打好的一個軟件包發佈到服務器即可。
易於水平伸縮： 只需要創建一個服務器節點，配置好運行時環境，再將軟件包發佈到新服務器節點即可運行程序（當然也需要採取分發策略保證請求能有效地分發到新節點）。
缺點
維護成本大： 當應用程序的功能越來越多、團隊越來越大時，溝通成本、管理成本顯著增加。當出現 bug 時，可能引起 bug 的原因組合越來越多，導致分析、定位和修復的成本增加；並且在對全局功能缺乏深度理解的情況下，容易在修復 bug 時引入新的 bug。
持續交付週期長： 構建和部署時間會隨着功能的增多而增加，任何細微的修改都會觸發部署流水線。
新人培養週期長： 新成員瞭解背景、熟悉業務和配置環境的時間越來越長。
技術選型成本高： 單塊架構傾向於採用統一的技術平臺或方案來解決所有問題，如果後續想引入新的技術或框架，成本和風險都很大。
可擴展性差： 隨着功能的增加，垂直擴展的成本將會越來越大；而對於水平擴展而言，因爲所有代碼都運行在同一個進程，沒辦法做到針對應用程序的部分功能做獨立的擴展。
理想中的微服務架構
沒有什麼東西是完美的，網站架構也是這樣的，只有「比之前好一點」的架構或「目前最好的實現方式」，不存在理想中的架構，那麼理想中微服務架構應該是怎麼樣的呢，我覺得至少應該有如下幾個特點：
能支持當前業務需求，當然這只是最最基本的條件；
每個微服務都要去中心化，不存在單點故障；
每個微服務都要實現高可用、高負載，不會因爲一個服務不可用而影響了整套業務流；
每個微服務都要高度通用化，即多種終端都可調用，不分語言和平臺；
服務部署或升級簡單，不會消耗大量人力並且部署過程不易出現人爲錯誤；
微服務具有快速註冊與自動發現功能（例如dubbo框架）
當然，這只是其中能想到的幾點，實際環境中用到的微服務框架有可能會根據實際業務需求優化出更加個性化的功能，也可能有些功能是不需要的。還是那句話，架構是服務於業務的，能快速方便的滿足業務需求的架構纔是好的架構，纔是好的微服務架構。