微服務

微服務架構提供了將大型應用拆分爲多個可相互做用的更小服務的一種手段.
每一個服務獨立交付,所以每一個服務能夠脫離主體,獨立部署升級拓展替換.
服務間通訊一般依賴HTTP調用網絡鏈接.
Web sockets,
message queues
pub/sub
RPC
也能夠用於鏈接獨立組件.

每一個獨立服務專一單一任務,一般按內務單元區分,受 RESTful 規範制約.

課程目標是詳述在微服務潮流下開發一款應用. 這裏側重怎麼作而較少討論爲何這麼作. 微服務很難. 他們有不少挑戰和問題難以解決. 開始拆分你的大塊應用前牢記這一點.

利

Separation of concerns 關注分離

服務間清晰的分離, 開發能夠更容易專一他們的專長領域,好比 語言,框架, 依賴, 工具, 還有 構建管道.
例如, 一個 前端 JavaScript 工程師能夠開發面向客戶的視圖,不須要理解後端 API 之下的代碼.他能夠自由選擇語言框架, 只須要和後端交流經過異步請求消費 RESTful API.
換句話說, 鑑於服務憑藉 APIs 通信開發能夠將服務看作一個黑盒, 將實現和複雜隱藏.
也就是說, 這是一個很好的理念來建立全機構的標準來確保每一團隊能夠一塊兒工做運行--好比代碼質檢和風格檢查, 代碼檢查, API 設計.

清晰的分離意味着錯誤最大限度的鎖定在開發工做的服務內. 所以,你能夠分配給初級程序員非關鍵服務,即便服務掛掉,整個應用也不受影響.

由於每一個服務獨立部署,更少的耦合也是的擴展更容易. 對消除團隊等待另外一個所依賴的團隊完成工做現象有必定幫助.

更小的代碼庫

更少代碼庫對更容易理解有益,由於不須要掌握整個系統. 只須要 固化 API 設計, 這意味着微服務棧中一般能夠更快開發更容易測試重構和拓展. 記住, 在全部服務站維護一致的代碼標準很重要,所以對於開發中從一個服務轉到另外一個服務很容易.

加速反饋閉環

微服務中,開發掌握應用的整個生命週期,從立項到交付.替換團隊調整使用特定的技術集--好比客戶端UI, 服務端, 等等. 由於這樣他們能夠更清晰的看到應用在真是環境中如何使用. 這加速了反饋閉環, 更容易修復 bugs 和迭代.

弊

設計複雜

決定分離你應用的一塊到微服務不是一個容易的任務. 一般重構爲一個獨立的模塊在所有大塊中更容易, 而不是分出去.
一旦你分出去沒有回頭路.

網絡複雜

在一個大塊應用,一般全部事在一個單獨的線程,因此不須要不少次調用其它服務. 因爲你拆分你的應用爲微服務, 你會發現你如今不得不將函數調用改成網絡調用.
這會致使不少問題特別是若是多個應用須要和其餘服務通訊, 結果在網絡請求方面產生乒乓效應. 你也不得不考慮服務的總體降低.

基礎設施 infrastructure

多服務下,複雜轉化從數據庫到平臺和基礎設施. 消耗很大. 並且,不得不使用正確的工具和適當的人力資源來管理.

數據持久化

多數應用有相似狀態層,像數據庫任務隊列. 微服務棧也須要跟蹤服務在哪裏銷燬和所有被摧毀的實例,這樣，當一個特定服務的新實例啓動時, 通訊量能夠適當的調整. 這一般稱爲服務發現.

因爲咱們將處理容器, 咱們須要特別關注如何處理狀態容器由於他們不該降低.

隔離一個特定服務的狀態使得他不被分享或複製是一個難以描述的困難. 你不得不常常處理各類不一樣來源的事實,不得不頻繁的調解. 再說一次, 歸結爲設計.

集成測試

一般, 開發微服務架構, 你不能完整測試全部服務直到你部署到預發或生產服務器. 獲取反饋的時間花費太長. 幸運的是, docker 經過更容易的鏈接小的獨立的本地服務有助於加速這一過程.

日誌, 監聽, 和調試一樣困難.

跟多微服務測試, 參考 Testing Strategies in a Microservice Architecture