微服務學習導航

原文: 微服務學習導航

但願給你3-5分鐘的碎片化學習，多是坐地鐵、等公交，聚沙成塔，水滴石穿，碼字辛苦，若是你吃了蛋以爲味道不錯，但願點個贊，謝謝關注。

如何學習

　　學習是一我的的核心競爭力，終生持續學習是別人離不開你的祕訣，若是能分享和教會別人，你的收穫多是雙邊甚至更多。就技術領域的學習，我仍是一個在海邊玩耍的小孩，時不時由於撿到一塊漂亮的石頭就開心不已。

學習金字塔

　　學習金字塔是個被熟知的好方法，以下圖所示。

　　該方法至少內置了兩層含義：1.學習是按部就班的過程，不要但願走捷徑，刷聰明才智。2.學習是從理論到實踐再到理論的反覆迭代的過程，不要以爲一個閉環就能搞的定。若是人家恭維以爲你是某一方面的專家，你要有所保留，不要掉進讚美的坑裏。

　　

　　學習比如小孩玩樂高遊戲，首先要明確要拼什麼，是航空母艦仍是直升機，其次要儘量的佔有更多有價值的學習資源，也就是要有足夠的的積木，接下來就是看說明書，按步驟，分階段，按級別的動手過程。

　　因此回到咱們的主題，咱們要學習的是微服務這個總目標，接下來蒐集儘量多的有價值的資源，最後查一查咱們的說明書或者叫地圖，瞭解學習圖譜和路徑了(百度腦圖)。下面接着要規劃的就是個人腦圖和學習要點，若是您有更好的方式，請多指教。

學習路徑

　　

　　學習路徑屬於學習的細節部分，根據以上的路徑，咱們須要總體瞭解微服務整片森林的構成，也是就後面要展現的思惟導圖，隨後導圖的每一個構件須要逐個拆分梳理，好比微服務包含的六大組建，最後咱們開始行動，各個擊破。在分階段學習的過程當中，咱們至少要按部就班，由簡入深，避免一開始拔高門檻，致使的心理受挫。最後一環，經過討論，分享進行知識的盤點和複習、固話。

　　提到學習方法，另外補充一個左耳朵耗子提出ARTS的學習小技巧，即每週至少作一個 leetcode 的算法題、閱讀並點評至少一篇英文技術文章、學習至少一個技術技巧、分享一篇有觀點和思考的技術文章。（也就是 Algorithm、Review、Tip、Share 簡稱 ARTS）須要堅持至少一年。我以爲這種方式也很不錯，不過那是學習的細節和學習毅力的問題了，但凡是有這種好習慣的人，值得敬仰，我知道的有阮一峯前輩有這種持續的學習毅力。

學習什麼

　　微服務已經不是什麼新技術，只是聞道有前後，大廠和趨勢在前行，你不得不邁開腳步（可能你反對，可是趨勢擋不住），當微服務撲面而來的時候，你是否還在觀望或者猶豫，當你恍然大悟的時候，你是否又迷茫不知所措？是的，咱們須要一份微服務的腦圖，也許這份圖譜不必定是標準答案，可是在你作參考和評估的時候，但願能對你有所幫助。以下圖所示：

　　

　　因爲內容較多，查看全貌請移步百度腦圖。

　　爲了更好地理解微服務和設計微服務架構，列出幾個比較經典的設計圖輔助理解：

　　圖一

　　

　　　圖二：(胡忠想 微博技術專家)

　　

　　不知道你對以上的圖有何感想，歡迎加入咱們的QQ羣進行深刻討論：105365283

六大組件

　　如腦圖所示，微服務整體的內容包含有六大組件：服務描述，註冊中心，服務架構，服務監控，服務跟蹤和服務治理。這六大組件互相依賴，相輔相成，縱深挖掘，又能夠牽扯出DevOps和容器化技術等周邊信息，這些武器庫表明的是技術的將來，不論是你是在小企業仍是大廠，仍是大廠裏的小部門，不知道你是否有這種體驗?

　　

　　　　　（微服務生態）

服務描述：

　　相似服務的說明文檔，簡單但不可或缺。好比，服務調用首先要解決的問題就是服務如何對外描述。好比，你對外提供了一個服務，那麼這個服務的服務名叫什麼？調用這個服務須要提供哪些信息？調用這個服務返回的結果是什麼格式的？該如何解析？這些就是服務描述要解決的問題。

註冊中心：

　　有了服務的接口描述，下一步要解決的問題就是服務的發佈和訂閱，就是說你提供了一個服務(Provider)，如何讓外部(Consumer)想調用你的服務的人知道。這個時候就須要一個相似註冊中心(Registry)的角色，服務提供者將本身提供的服務以及地址登記到註冊中心，服務消費者則從註冊中心查詢所須要調用的服務的地址，而後發起請求。以下圖所示：

　　

服務框架：

　　經過註冊中心，服務消費者就能夠獲取到服務提供者的地址，有了地址後就能夠發起調用。但在發起調用以前你還須要解決如下幾個問題。服務通訊採用什麼協議？是RESTful API仍是gRPC？數據傳輸採用什麼方式數據壓縮採用什麼格式？這些活一般集成到了咱們的服務框架裏面，市面上有不少這樣的開源框架，相對都比較成熟，接下來考驗你的是快速上手的能力。

服務監控：

　　一旦服務消費者與服務提供者之間可以正常發起服務調用，你就須要對調用狀況進行監控，以瞭解服務是否正常。一般來說，服務監控主要包括三個流程，指標收集，數據處理，數據展現。監控是爲了發現問題和異常，若是要進一步跟蹤和定位問題，則須要進一步瞭解服務追蹤。

服務追蹤：

　　除了須要對服務調用狀況進行監控以外，你還須要記錄服務調用通過的每一層鏈路，以便進行問題追蹤和故障定位，最後達到接近問題的目的。服務監控和追蹤能夠合併起來，可是要明確各自的職責是不同的。

服務治理：

　　服務監控可以發現問題，服務追蹤可以定位問題所在，而解決問題就得靠服務治理了。服務治理就是經過一系列的手段來保證在各類意外狀況下，服務調用仍然可以正常進行。就目前開源的服務框架，大部分都不包括服務治理的內容，因此有可能這塊是須要你和你的團隊進行定製化開發，就看你作到什麼程度了，就比如你有數據庫可是你沒有ER圖描述，並不影響你用微服務，固然若是有就是錦上添花的東西了。

　　以上六大組件能夠粗暴的定義爲微服務的二級目錄，他們共同組成了微服務架構，在生產環境下缺一不可。

　　相信經過以上的整理，你對微服務的學習方法和學習路徑已經有了一個大概的思路了，接下來就是邁開腳步，持續輸出的能力了，你準備好了嗎？

參考文獻：

• 微服務架構理解
• 微服務架構設計
• Martinfowler博客Microservices 
• Microservice Architecture 
• Wikipedia

但願以上分享對你有幫助，我是IT人張飛洪，入行10年有餘，人不堪其憂，吾不改其樂，謝謝您關注。