摘要：清晰的分離意味著錯(cuò)誤可最大限度的定位到開發(fā)者所工作的服務(wù)。可獨(dú)立部署意味著更少的耦合使得規(guī)?；菀住２坏貌徽f明服務(wù)全面下降的原因。這通常稱為由于我們處理容器，我們需要特別關(guān)注如何處理狀態(tài)容器，因?yàn)樗麄儾粦?yīng)下降。

微服務(wù)架構(gòu)提供一個(gè)拆分大型應(yīng)用為較小可相互影響通信的服務(wù)的手段。從整體拆分，每個(gè)服務(wù)可獨(dú)立交付， 使得每個(gè)服務(wù)可獨(dú)立的部署， 升級(jí) ， 縮小， 和替代。服務(wù)間通信通常通過網(wǎng)絡(luò)連接HTTP 調(diào)研（request/response). [Web sockets](),
[message queues]() , [pub/sub](), 和 [remote procedure calls(RPC)]() 也可以被用于連接獨(dú)立組建。

每個(gè)獨(dú)立服務(wù)專注于一個(gè)單一任務(wù)， 通常按業(yè)務(wù)單元分離， 由 RESTful 協(xié)議管理。

課程目標(biāo)是詳細(xì)介紹微服務(wù)的方式開發(fā)應(yīng)用。 少談為什么， 專注怎么做。 微服務(wù)很難。 它有大量的挑戰(zhàn)和問題很難解決。 開始拆分大型應(yīng)用前記住這一點(diǎn)。

服務(wù)清晰的分離使開發(fā)更專注他們的特長領(lǐng)域，比如語言，框架，依賴， 工具和構(gòu)建管道。

例如， 一個(gè)前端 JavaScript 工程師可開發(fā)面向客戶的視圖，不需要理解后端 API 的代碼實(shí)現(xiàn)。 可自由選擇語言和框架，只需要通過 AJAX 請(qǐng)求來消費(fèi) RESTful API來與后端通信。換句話說， 因?yàn)橥ㄟ^ APIs 通信開發(fā)者可以將一個(gè)服務(wù)看作一個(gè)黑箱。實(shí)際的實(shí)現(xiàn)和復(fù)雜被隱藏。

也就是說， 這是一個(gè)好注意來創(chuàng)建一些組織標(biāo)準(zhǔn)來確保每個(gè)團(tuán)隊(duì)可以一起發(fā)揮作用。例如代碼質(zhì)量，風(fēng)格檢查，代碼檢查， API 設(shè)計(jì)。

清晰的分離意味著錯(cuò)誤可最大限度的定位到開發(fā)者所工作的服務(wù)。使你可以安排初級(jí)開發(fā)到較不嚴(yán)格的服務(wù)即使他掛掉了對(duì)應(yīng)服務(wù)， 剩余整體應(yīng)用不受影響。

可獨(dú)立部署意味著更少的耦合使得規(guī)?；菀住?也有助于消除一個(gè)團(tuán)隊(duì)堆另一個(gè)團(tuán)隊(duì)依賴完成的等待。

不需要理解整個(gè)系統(tǒng)，小代碼庫更容易理解。只要有固定的必要 API 設(shè)計(jì)， 微服務(wù)棧的應(yīng)用可以更快部署，更容易測試， 重構(gòu)， 和規(guī)?；７?wù)保持一致的開發(fā)標(biāo)準(zhǔn)很重要，開發(fā)可以更容易從一個(gè)服務(wù)到另外一個(gè)。

在微服務(wù)中，開發(fā)通常掌握應(yīng)用從立項(xiàng)到交付的整個(gè)生命周期。使團(tuán)隊(duì)不需要綁定特定的技術(shù)棧--像客戶端UI,服務(wù)端等--團(tuán)隊(duì)可以更聚焦產(chǎn)品。自己為交付應(yīng)用到用戶負(fù)責(zé)。 因此， 應(yīng)用如何在真實(shí)環(huán)境運(yùn)行更清晰可見。這加速反饋循環(huán)，更容易修復(fù) bug 和迭代。

決定拆分應(yīng)用為微服務(wù)并不是個(gè)輕松的任務(wù)。 通常在整個(gè)大項(xiàng)目更容易重構(gòu)成獨(dú)立模塊。

一旦拆分一個(gè)服務(wù)就無法回頭。

通常一個(gè)大型應(yīng)用所有事情發(fā)生于同一線程。 不需要每次調(diào)用其它服務(wù)。只要你把應(yīng)用拆分成微服務(wù)， 你會(huì)發(fā)現(xiàn)你將不得不進(jìn)行網(wǎng)絡(luò)調(diào)用， 之前你只需要調(diào)用某一函數(shù)。

這可能導(dǎo)致問題，特別是多個(gè)應(yīng)用需要和另外一個(gè)通信， 導(dǎo)致乒乓效應(yīng)。 不得不說明服務(wù)全面下降的原因。

多服務(wù)將代碼庫復(fù)雜度轉(zhuǎn)移到了平臺(tái)和基礎(chǔ)設(shè)施。 這可能很昂貴。
另外你不得不使用正確的工具和適當(dāng)?shù)娜肆Y源管理。

多數(shù)應(yīng)用有狀態(tài)曾， 像數(shù)據(jù)庫和任務(wù)隊(duì)列。 微服務(wù)站也需要記錄服務(wù)部署地點(diǎn)和實(shí)例數(shù)量。 當(dāng)一個(gè)實(shí)際服務(wù)實(shí)例啟動(dòng)，可合適的分配路由流量。 這通常稱為 [service discovery]().

由于我們處理容器，我們需要特別關(guān)注如何處理狀態(tài)容器，因?yàn)樗麄儾粦?yīng)下降。

隔離特定服務(wù)的狀態(tài)使得它分享和復(fù)制機(jī)器困難。你通常不得不處理
不同來源且頻繁調(diào)整的情況，這歸結(jié)為設(shè)計(jì)原因。

通常， 使用微服務(wù)架構(gòu)開發(fā)應(yīng)用， 你無法完整的測試所有服務(wù)知道你部署到一個(gè)預(yù)發(fā)或生產(chǎn)服務(wù)器。這獲得反饋的時(shí)間太長。 幸運(yùn)的是， Docker 能通過更容易的連接本地獨(dú)立小應(yīng)用服務(wù)來幫助加速這一個(gè)進(jìn)程。

日志，監(jiān)控， 和調(diào)試也更難了。