集群、分布式、微服務概念和區別
集群是個物理形態，分布式是個工作方式。
分布式：乙個業務分拆成多個子業務，部署在不同的伺服器上
集群：同乙個業務，部署在多個伺服器上
分布式中的每乙個節點，都可以做集群。而集群並不一定就是分布式的。
簡單說，分布式是以縮短單個任務的執行時間來提公升效率的，而集群則是通過提高單位時間內執行的任務數來提公升效率。
例如：乙個任務是由10個子任務組成，每個子任務單獨執行需要1小時，則在一台伺服器上執行該服務需10個小時。
採用分布式方案，提供10臺伺服器，每台伺服器只負責處理乙個子任務，不考慮子任務間的依賴關係，執行完成這個任務只需1個小時。
而採用集群方案，同樣提供10臺伺服器，每台伺服器都能獨立處理這個任務。假設有10個任務同時到達，10個伺服器將同時工作，1小時後，10個任務同時完成，這樣，整體看，還是1小時內完成1個任務。
微服務
乙個大型複雜軟體應用-由乙個或多個微服務組成。
系統中的各個微服務可以獨立部署，各個微服務之間是松藕組合的。每個微服務僅關注與完成一件任務並很好地完成該任務。在所有情況下，每個任務代表著乙個小的業務員能力。
各個微服務既可以看做乙個獨立的系統，也可以把這些微服務組合成一起看成乙個系統。
分布式是否屬於微服務？
答案是肯定的。微服務的意思就是將模組拆分成乙個獨立的服務單元通過介面來實現資料的互動。
微服務的設計是為了不因為某個模組的公升級和bug 影響現有的系統業務。微服務與分布式的細微差別是，微服務的應用不一定是分散在多個伺服器上，他也可以是同乙個伺服器。
特點：
從本質上來說，微服務是一種架構模式
是面向服務型架構（soa）的一種變體(好處是系統未來的擴充套件性變得很強)
本子上還是soa，但微服務不像soa那樣要求繫結具體的技術。微服務鼓勵用恰當的技術去
實現合適的服務，這樣系統的擴充套件性會變得很強
每個服務執行在獨立的程序中，服務與服務之間用 rest api來進行溝通，把不同的服務有機的整合成統一的系統。
每個服務都圍繞著具體業務進行構建，能夠被獨立部署到類生產環境中。
soa架構和微服務架構的區別
首先soa和微服務架構乙個層面的東西，而對於esb和微服務閘道器是乙個層面的東西，乙個談到是架構風格和方法，乙個談的是實現工具或元件。
1.soa（service oriented architecture）「面向服務的架構」:他是一種設計方法，其中包含多個服務， 服務之間通過相互依賴最終提供一系列的功能。乙個服務 通常以獨立的形式存在與作業系統程序中。各個服務之間 通過網路呼叫。
2.微服務架構:其實和 soa 架構類似,微服務是在 soa 上做的昇華，微服務架構強調的乙個重點是「業務需要徹底的元件化和服務化」，原有的單個業務系統會拆分為多個可以獨立開發、設計、執行的小應用。這些小應用之間通過服務完成互動和整合。
微服務架構 = 80%的soa服務架構思想 + 100%的元件化架構思想 + 80%的領域建模思想
對比
微服務更容易的擴充套件，它基本上是獨立的，不可分割的，更容易的發布新的版本。soa的元件一般比較大型，發布新版本一般更複雜，需要專門的運維團隊除了，微服務自己團隊就行了。(允許意見不一致)
微服務可以採用不同的技術棧進行組合，而soa架構，每個元件都需要了解通用的交流元件，一般被認為是esb。
soa中因為涉及到esb，可能會出現單點故障。而微服務每個服務故障只會影響當前的服務。
相同點：
兩者都是為了處理複雜架構而出現的分布式系統，都需要系統直接的通訊，協調
soa與微服務的主要區別在大小和範圍上，微服務一般比soa的粒度更細。soa也有可能是乙個大的元件，或者內部包含了多個微服務。
lamp（linux+apache+mysql+php）
mvc（spring+mybatis/hibernate+tomcat）
單體式架構（monolithic architecture）
單體服務結構簡單，**是乙個統一的工程，容易開發、部署和維護。但是，正由於此，各個模組耦合嚴重，當工程大到一定程度後，會帶來一系列的問題。
優點：
團隊組織結構簡單，便於集中管理
開發進度一致，統一管理，能夠避免重複開發的問題
所有的功能都在貝蒂，沒有遠端呼叫的開銷和網路損耗
缺點：
效率低維護困難
不夠靈活
穩定性不好
擴充套件性不夠
微服務架構
優點：
解決單體架構存在的一系列問題
部署、回滾變得簡單、更敏捷
每個服務都可以獨立擴容
不同的業務特徵選擇合適的技術方案，有針對性解決具體業務問題
可以運用外掛程式的形式更新新功能，不必有一點擴充，就要重新部署整個專案
自主管理相關的業務，可以隨業務的發展提供資料介面整合，而非以資料庫的方式同其他服務整合
對於業務資料可以採用介面的方式來方便未來業務員發展後的資料管理與資料遷移
缺點：
不同的子系統交由不同的團隊開發，這個會增加整個系統內部的通訊需求，也會增加不同團隊的交流通成本
對於子系統的測試來說，微服務的分布式架構大大的提高了測試的複雜度
分布式部署對於團隊的devops能力要求很高
隨著服務數量的增加，管理的複雜程度呈指數級增加
契約測試工具的思考 一
在經過了ui自動化的各種挑戰後，終於發現了實用於網際網路測試方式的分層模型，ui佔最後，也是最少的部分。介面測試佔比僅次於單元測試，且相對穩定 可以提前測試，維護的成本也不是很高，相對於ui自動化來說。前端客戶端團隊和後端服務端團隊往往節奏是不一致的。前端很多情況下需要等待後台的api開發完成後才能...
契約測試的必要性
測試是軟體流程中非常重要，不可或缺的乙個環節。一般的測試分為單元測試，整合測試，端到端的手工測試，這也是構成測試金字塔的三個層級。我們今天將要討論的話題是契約測試，它是處於單元測試和整合測試中間的乙個環節。這三個層級分別測試的場景如下 契約測試最開始的概念由martin fowler 提出，請參見這...
按契約程式設計和測試驅動開發
一直以來，我總覺得按契約程式設計是assert 巨集的延伸，不夠現代，作用和測試驅動開發不能相比。測試驅動開發能夠覆蓋設計，編碼，回歸相容測試等各個 領域。但是任何工具 方法都有它的適應面，如果不是，按契約程式設計也就不會出現了。總的來說，按契約程式設計台階較低，而測試驅動開發對開發者的要求較高。1...