摘要：清晰的分離意味著錯誤可最大限度的定位到開發(fā)者所工作的服務?？瑟毩⒉渴鹨馕吨俚鸟詈鲜沟靡?guī)?；菀住２坏貌徽f明服務全面下降的原因。這通常稱為由于我們處理容器，我們需要特別關注如何處理狀態(tài)容器，因為他們不應下降。

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

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

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

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

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

也就是說， 這是一個好注意來創(chuàng)建一些組織標準來確保每個團隊可以一起發(fā)揮作用。例如代碼質量，風格檢查，代碼檢查， API 設計。

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

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

不需要理解整個系統(tǒng)，小代碼庫更容易理解。只要有固定的必要 API 設計， 微服務棧的應用可以更快部署，更容易測試， 重構， 和規(guī)?；７毡３忠恢碌拈_發(fā)標準很重要，開發(fā)可以更容易從一個服務到另外一個。

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

決定拆分應用為微服務并不是個輕松的任務。 通常在整個大項目更容易重構成獨立模塊。

一旦拆分一個服務就無法回頭。

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

這可能導致問題，特別是多個應用需要和另外一個通信， 導致乒乓效應。 不得不說明服務全面下降的原因。

多服務將代碼庫復雜度轉移到了平臺和基礎設施。 這可能很昂貴。
另外你不得不使用正確的工具和適當?shù)娜肆Y源管理。

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

由于我們處理容器，我們需要特別關注如何處理狀態(tài)容器，因為他們不應下降。

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

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

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