是指將系統的功能按照三層架構的思想，在邏輯上分為三層，然後將這種功能集中、**中心化、乙個發布包、部署後執行在同乙個程序的應用程式，成為單塊架構。典型的應用是j2ee的開發產品，他們的形態一般是war包或者ear包。
單塊架構的優勢
1、易於開發
2、易於測試
3、易於部署
4、易於水平伸縮
通常包括表示層、業務邏輯層以及資料訪問層。
一、微服務架構是一種架構模式，他提倡將單一應用程式劃分為一組小的服務，服務之間相互協調、互相配合，為使用者提供最終的價值。每個服務獨立執行在各自的程序中，服務與服務之間採用輕量級的通訊機制相互溝通。每個服務圍繞著具體業務進行構建，並且能夠被獨立的部署到生產環境中。應避免統一的、集中式的服務管理機制，對具體的乙個服務而言，應根據業務上下文，選擇合適的語言、工具對其進行構建。
即微服務究竟應該多微才可以？
1、根據**行數進行劃分。
2、根據服務的重寫時間進行劃分。
對於微服務而言，通過使用語言無關、平台無關的輕量級通訊機制，使服務與服務之間的協作變得更加標準化。
1、服務作為元件
將服務作為元件，在元件和元件之間定義了清晰的、語言無關的、平台無關的介面。
2、圍繞業務組織團隊
3、關注產品而非專案
4、技術多樣性
在微服務中，針對不同的業務特徵選擇合適的技術方案，有針對性地解決具體業務問題。
5、業務資料獨立
6、基礎設施自動化
7、演進式架構
1、效能
分布式系統因為元件和元件之間的呼叫是跨程序、跨網路的呼叫，因此，必須考慮網路延遲以及頻寬的影響。
2、可靠性
隨著微服務數量的增多，會出現更多的潛在故障點。
3、非同步
對於跨網路的呼叫，需要考慮非同步的通訊機制。
4、資料一致性
5、工具
微服務架構設計模式綜述
隨著微服務的大量應用，在實踐中也會遇到很多之前單體架構所沒有的問題，微服務架構設計模式也應運而生。架構方面的權威chris richardson先生從多個角度歸納了42個設計模式，我將其歸納整理如下表，以饗讀者。後面會陸續出關於微服務架構設計模式的文章，更加深入的闡述richardson先生關於微服...
微服務現狀綜述
近日，adrian cockcroft在荷蘭阿姆斯特丹舉辦的docker大會上談到，隨著組織向持續交付的不斷邁進，變更會不斷增加，但同時變更所帶來的代價 規模與風險卻在不斷降低，devops與敏捷轉換，以及容器化對於現如今的業務來說是非常有吸引力的。對於通過持續交付來加速產品開發過程的方式來說，ad...
微服務現狀綜述
近日，adrian cockcroft在荷蘭阿姆斯特丹舉辦的docker大會上談到，隨著組織向持續交付的不斷邁進，變更會不斷增加，但同時變更所帶來的代價 規模與風險卻在不斷降低，devops與敏捷轉換，以及容器化對於現如今的業務來說是非常有吸引力的。對於通過持續交付來加速產品開發過程的方式來說，ad...