part-one-microservices

microservices

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

每一個獨立服務專一於一個單一任務， 一般按業務單元分離， 由 RESTful 協議管理。

課程目標是詳細介紹微服務的方式開發應用。 少談爲何， 專一怎麼作。 微服務很難。 它有大量的挑戰和問題很難解決。 開始拆分大型應用前記住這一點。

利

關注隔離

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

例如， 一個前端 JavaScript 工程師可開發面向客戶的視圖，不須要理解後端 API 的代碼實現。 可自由選擇語言和框架，只須要經過 AJAX 請求來消費 RESTful API來與後端通訊。換句話說， 由於經過 APIs 通訊開發者能夠將一個服務看做一個黑箱。實際的實現和複雜被隱藏。

也就是說， 這是一個好注意來建立一些組織標準來確保每一個團隊能夠一塊兒發揮做用。例如代碼質量，風格檢查，代碼檢查， API 設計。

清晰的分離意味着錯誤可最大限度的定位到開發者所工做的服務。使你能夠安排初級開發到較不嚴格的服務即便他掛掉了對應服務， 剩餘總體應用不受影響。

可獨立部署意味着更少的耦合使得規模化更容易。 也有助於消除一個團隊堆另外一個團隊依賴完成的等待。

更小的代碼庫

不須要理解整個系統，小代碼庫更容易理解。只要有固定的必要 API 設計， 微服務棧的應用能夠更快部署，更容易測試， 重構， 和規模化。服務保持一致的開發標準很重要，開發能夠更容易從一個服務到另一個。

加速反饋迴路

在微服務中，開發一般掌握應用從立項到交付的整個生命週期。使團隊不須要綁定特定的技術棧--像客戶端UI,服務端等--團隊能夠更聚焦產品。本身爲交付應用到用戶負責。 所以， 應用如何在真實環境運行更清晰可見。這加速反饋循環，更容易修復 bug 和迭代。

弊端

設計複雜

決定拆分應用爲微服務並非個輕鬆的任務。 一般在整個大項目更容易重構成獨立模塊。

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

網絡複雜

一般一個大型應用全部事情發生於同一線程。 不須要每次調用其它服務。只要你把應用拆分紅微服務， 你會發現你將不得不進行網絡調用， 以前你只須要調用某一函數。

這可能致使問題，特別是多個應用須要和另一個通訊， 致使乒乓效應。 不得不說明服務全面降低的緣由。

基礎設施

多服務將代碼庫複雜度轉移到了平臺和基礎設施。 這可能很昂貴。
另外你不得不使用正確的工具和適當的人力資源管理。

數據持久化

多數應用有狀態曾， 像數據庫和任務隊列。 微服務站也須要記錄服務部署地點和實例數量。 當一個實際服務實例啓動，可合適的分配路由流量。 這一般稱爲 [service discovery]().

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

隔離特定服務的狀態使得它分享和複製機器困難。你一般不得不處理
不一樣來源且頻繁調整的狀況，這歸結爲設計緣由。

集成測試

一般， 使用微服務架構開發應用， 你沒法完整的測試全部服務知道你部署到一個預發或生產服務器。這得到反饋的時間太長。 幸運的是， Docker 能經過更容易的鏈接本地獨立小應用服務來幫助加速這一個進程。

日誌，監控， 和調試也更難了。