單塊架構應用：功能集中，程式碼和資料中心化，一個釋出包部署後執行在同一個程序中的應用程式

單塊架構的優勢：

1）易於開發

2）易於測試

3）易於部署

4）易於水平伸縮(所有的功能都會打成一個包，在叢集中新建一個節點，配置好節點的執行環境，複製軟體包到響應的位置，保證負載均衡的分發策略有效分發到當前節點即可)

面臨的挑戰：

1）維護成本增加，程式碼量過大，不利於快速定位問題

2）持續交付週期長：構建 部署和測試的實際都會隨著程式碼量的增加而成倍的增長

3）新人培養週期長：業務熟悉和環境部署都會有很大的難度

4）技術選型成本高：較大規模的系統，最初的選型會影響新技術的使用

5）可擴充套件性差：

  a 垂直擴充套件：增加伺服器

  b 水平擴充套件：在叢集中新增節點，使用負載均衡(若應用有一部分是需要記憶體密集型快取大量資料，有一部分是需要CPU密集型，需要進行大量運算，那麼每次擴充套件新的節點都需要足夠的記憶體和CPU來滿足需求)

6）構建全功能團隊難：會出現功能的擴充套件需要跨團隊溝通

微服務架構：

是一種架構模式，提倡將單一應用程式劃分為一組小的服務，服務之間相互協調，相互配合，為使用者提供最終價值，每個服務執行在獨立的程序中，服務間採用輕量級的通訊機制相互溝通(通常是基於http的restful api)，每個服務圍繞自己的具體業務構建，可以獨立部署，應儘量避免統一的，集中式的服務管理機制，對於具體的一個服務而言，應根據業務上下文，選擇合適的語言 工具來進行構建，也就是：

通過對特定業務領域的分析和建模，將複雜的應用分解成小而專一的，耦合度低並且高度自治的一組服務，每一個服務都是一個小的應用

編譯語言有良好的語言型別約束和編譯期檢查，但程式碼比較複雜

動態語言靈活性高，執行時可以改變其記憶體結構，無型別檢查，無需寫交較多型別相關的程式碼，但不方便除錯

開發 測試 部署完全獨立，語言獨立

服務與服務之間相互獨立，相互隔離

在單塊架構中，應用程式的程式碼雖然被分成邏輯上的3層或者4層，但並非物理上的分層，所有的功能經過編譯，打包，部署後還是會執行在同一個程序中，這就意味著對應用部署時必須停掉正在執行的服務，部署完成後再重新啟動程序，無法獨立部署

一般為了程式碼的重用性，會把重複的程式碼封裝成元件(可獨立升級，獨立替換掉的部分)，傳統架構中，通常是共享庫，比如jar包或者是win下的dll等

但在微服務架構中，應用程式由多個服務組成，每個服務都是一個具有高度自治的獨立業務實體，每個服務可以執行在一個獨立的程序中，不同的服務可以輕易的部署到不同的主機上

理論上可以把不同的服務部署到同一個節點上，執行到不同的程序裡，但是不推薦，既然是微服務，最好保證高度的自治性和隔離性，執行在同一個節點上，雖然省去了節點的開銷，卻增加了部署和擴充套件的複雜度，部署某一個新的服務時，可能會對該節點的原有服務造成影響，另外隨著業務的發展，可能某些業務需要水平擴容，有些不需要，如果不能有效的組織服務，可能會給服務的水平擴容帶來不必要的麻煩

docker：

1）可以更快的交付和部署，開發者可以使用一個標準映象來構建映象，開發完成之後，運維人員可以直接使用這個映象來部署

2）可以更輕鬆的遷移和擴充套件，包括物理機，虛擬機器和公有云，私有云等，這種相容性可以很方便的將應用程式從一個平臺直接遷移到另一個

3）更簡單的管理，使用docker，所有映象的修改都可以用增量的方式釋出和更新，從而實現自動化和高效的管理

可以有效的解決微服務架構下，服務粒度細，服務數量多導致的開發環境搭建，部署以及運維成本高等的問題

微服務的本質通常包括：

1）服務作為元件

2）圍繞業務組織團隊

3）關注產品而非專案

4）技術多樣性

5）業務資料獨立

6）基礎設施自動化

7）演進式架構

對應解釋：

1）服務作為元件

在傳統領域，我們通常把公用的部分抽離出來，構建出共享庫，從而達到解耦和複用，但，共享庫是平臺和語言相關的，並且要和應用程式執行在統一程序中，也就是共享庫的更新，意味著整個應用要被更新，需要重新部署，如果有多個共享庫元件組成，任何庫的變更都將導致應用需要重新部署

微服務也可以認為是一種元件，執行在不同的程序中，每個服務的變更僅需要重新部署自身服務即可，可以跨平臺，跨語言

當然，微服務也有它的不足之處，就是分散式呼叫比程序內通訊需要消耗更多的時間，並且嚴重依賴網路的穩定性和可靠性

2）圍繞業務組織團隊

傳統架構裡，我們通常會按照技能去劃分團隊，懂伺服器的運維人員，使用者體驗設計師，DBA，後端開發人員，當團隊按照這個維度去劃分後，某些簡單的需求變更，可能都會出現跨組織跨團隊的協作，溝通的成本高

微服務是主張以業務為核心來組織團隊，團隊中的成員具有多種多樣的技能

3）關注產品而非專案

專案模式就是專案啟動後企業或者組織會從不同的技能資源池中抽調不同的資源，組成團隊並完成專案，專案完成，團隊解散，這種模式的弊端在於團隊成員缺乏主人翁意識，難以制定有效的獎懲機制，團隊成員也缺乏成就感

4）技術多樣性

在微服務架構中，由於彼此相互獨立，可以針對不同的業務特徵進行不同的業務選型，有針對性的解決業務問題，比如要求快速開發的模組可以使用php python等，對效能有較高要求的模組可以使用C  C++等，對於單塊架構，切換語言或者框架，難度就會比較大，若沒有完整的功能測試集，就很難平滑替換，且系統規模越大，風險越高

而對於微服務架構，我們可以挑選風險較小的訪問作為嘗試，快速得到反饋後再判斷是否適用於其它服務，這樣一項新技術的嘗試失敗並不會影響到整個產品的發展

5）業務資料獨立

在微服務中可以使用不同的資料庫型別來管理不同的資料，比如

在一個複雜的CRM系統中，產品資料種類繁多，更新也比較頻繁，可以使用monogo這類文件資料庫，它可以靈活地根據需求動態的調整

對於使用者訪系統時產生的臨時會話資訊，可以使用redis等鍵值系統進行儲存

報表資料的結構變化不大，而且要求資料一致性，可以使用傳統的mysql資料庫

在採用微服務架構後原先一次就能部署完成的，現在可能需要每個部分單獨部署，每個服務都需要部署帶來的健康監控，錯誤回滾，日誌分析等成本會明顯增加，自動化部署的要求也就越來越高，可以使用雲  devOps  docker

單一的大而全的平臺已經沒辦法滿足我們的需求，單一的技術平臺已經無法適應市場的快速變化，組織應該隨著業務的發展不斷去嘗試新的架構設計，真正去做到業務驅動架構，架構服務於業務

微服務的優勢：

1）獨立性 2）單一職責 3）技術多樣性

部署需要注意的問題：

1）分散式系統的複雜度 2）運維成本 3）部署自動化 4）devOps與組織架構 5）服務間依賴測試 6）服務間依賴管理

分散式系統的複雜性：

1）效能  由於是跨程序跨網路的呼叫，因此必須要考慮網路延遲以及頻寬帶來的影響

尤其是多個服務相互協作時，響應時間及效能對系統的影響

2）可靠性 由於網路，頻寬，節點等自身可靠性因素的影響，任何一次元件間的遠端呼叫，都可能失敗，且微服務數量很多時，潛在更多的單點故障，所以 保證系統的可靠性，降低由於網路，元件引起的單點故障率，也成了構建系統的挑戰

3）非同步  由於誇網路呼叫，需要考慮非同步的通訊機制，這樣出現問題時的除錯就會變得很麻煩

4）資料一致性 為了保證資料一致性，我們通常考慮分散式事務管理，但是它會涉及到跨多個節點來保證資料的瞬時一致性，比起傳統的事務成本就會高很多，通常，也會用最終的資料一致性來解決資料瞬時一致帶來的系統不可用

5）工具  IDE工具，並沒有為分散式呼叫提供良好的支援

有效的構建組動畫部署流水線，降低部署成本，提高部署頻率，是微服務架構的下一個跳戰，傳統的系統被拆分成多個相互協作的獨立服務後，隨著微服務個數的增多，如何清晰有效的展示服務之間的依賴關係，逐漸成為挑戰

微服務強調的就是一種獨立開發 獨立測試 獨立部署 獨立執行的高度自治的架構模式，也是一種更靈活更開放和更鬆散的演進式架構

任務拆分：

1）同一時間聚焦一個任務

2）能夠對每次完成的部分做持續整合

3）整體的進度容易追蹤