WHY:微服務(wù)架構(gòu)可以更快的交付軟件，有更多機(jī)會(huì)嘗試新技術(shù)。技術(shù)決策上有極大的自由度。軟件更新可以很頻繁。

WHAT:一個(gè)微服務(wù)就是一個(gè)獨(dú)立的實(shí)體，專注于做好一件事。可以獨(dú)立部署在paas平臺(tái)。服務(wù)之間通過(guò)API進(jìn)行通信，避免緊耦合。因此需要考慮好什么應(yīng)該暴露，什么應(yīng)該隱藏。

HOW微？一個(gè)微服務(wù)應(yīng)該可以在兩周內(nèi)完全重寫?；蛘吣悴徽J(rèn)為代碼庫(kù)過(guò)大。

核心原則:高內(nèi)聚低耦合。

好的微服務(wù):限界上下文尋找技術(shù)接縫，將微服務(wù)與這些技術(shù)邊界相匹配。

弊:管理大量微服務(wù)會(huì)復(fù)雜。需要一個(gè)“架構(gòu)師”來(lái)確保團(tuán)隊(duì)有共同的技術(shù)愿景。

正告1:如果想要得到一條通用準(zhǔn)則，微服務(wù)是一個(gè)錯(cuò)誤的選擇。

正告2:走捷徑會(huì)引人技術(shù)債務(wù)。

如果使用客戶端方式，千萬(wàn)不要把與目標(biāo)服務(wù)相關(guān)的邏輯放到客戶端庫(kù)中。

每個(gè)微服務(wù)都有各自的源代碼庫(kù)和CI構(gòu)建。

當(dāng)發(fā)現(xiàn)脆弱的測(cè)試時(shí)，應(yīng)該竭盡全力去解決這個(gè)問(wèn)題。否則，我們對(duì)出錯(cuò)會(huì)變得習(xí)以為常。當(dāng)不能立即修復(fù)時(shí)，需要把他們記錄下來(lái)（比如提個(gè)ec），并從測(cè)試套間中移除。

實(shí)際上，有些不必要的測(cè)試可以被刪掉。刪除測(cè)試往往令人擔(dān)憂，這可以理解。但這樣可以避免每個(gè)故事都端到端交付導(dǎo)致大量重發(fā)測(cè)試用例，使得測(cè)試庫(kù)臃腫，反饋周期太長(zhǎng)的缺點(diǎn)。當(dāng)然，這里也是從周期時(shí)間和低風(fēng)險(xiǎn)之間做取舍。

賦予團(tuán)隊(duì)更多的服務(wù)所有權(quán)，會(huì)提高自治和交付速度，激勵(lì)團(tuán)隊(duì)創(chuàng)建易于部署的服務(wù)。大面積采用特性團(tuán)隊(duì)后，容易出現(xiàn)很少有人下意識(shí)的做守護(hù)者。

服務(wù)相當(dāng)成熟很少改變的時(shí)候，才是開(kāi)源讓別人貢獻(xiàn)代碼的時(shí)候。