做積極的人，而不是積極廢人
本文來源：
https://www.cnblogs.com/jackyfei/p/10019621.html
希望給你3-5分鐘的碎片化學習，可能是坐地鐵、等公交，積少成多，水滴石穿，碼字辛苦，如果你吃了蛋覺得味道不錯，希望點個讚，謝謝關注。
如何學習
學習是一個人的核心競爭力，終生持續學習是別人離不開你的秘訣，如果能分享和教會別人，你的收穫可能是雙邊甚至更多。就技術領域的學習，我還是一個在海邊玩耍的小孩，時不時因為撿到一塊漂亮的石頭就開心不已。
學習金字塔
學習金字塔是個被熟知的好方法，如下圖所示。
該方法至少內置了兩層含義：1.學習是循序漸進的過程，不要希望走捷徑，刷聰明才智。2.學習是從理論到實踐再到理論的反覆疊代的過程，不要覺得一個閉環就能搞的定。如果人家恭維覺得你是某一方面的專家，你要有所保留，不要掉進讚美的坑裡。
學習好比小孩玩樂高遊戲，首先要明確要拼什麼，是航空母艦還是直升機，其次要儘可能的占有更多有價值的學習資源，也就是要有足夠的的積木，接下來就是看說明書，按步驟，分階段，按級別的動手過程。
所以回到我們的主題，我們要學習的是微服務這個總目標，接下來搜集儘可能多的有價值的資源，最後查一查我們的說明書或者叫地圖，了解學習圖譜和路徑了(百度腦圖)。下面接著要規劃的就是我的腦圖和學習要點，如果您有更好的方式，請多指教。
學習路徑
學習路徑屬於學習的細節部分，根據以上的路徑，我們需要整體了解微服務整片森林的構成，也是就後面要展示的思維導圖，隨後導圖的每個構件需要逐個拆分梳理，比如微服務包含的六大組建，最後我們開始行動，各個擊破。在分階段學習的過程中，我們至少要循序漸進，由簡入深，避免一開始拔高門檻，導致的心理受挫。最後一環，通過討論，分享進行知識的盤點和複習、固話。
提到學習方法，另外補充一個左耳朵耗子提出ARTS的學習小技巧，即每周至少做一個 leetcode 的算法題、閱讀並點評至少一篇英文技術文章、學習至少一個技術技巧、分享一篇有觀點和思考的技術文章。（也就是 Algorithm、Review、Tip、Share 簡稱 ARTS）需要堅持至少一年。我覺得這種方式也很不錯，不過那是學習的細節和學習毅力的問題了，但凡有這種好習慣的人，值得敬仰，我知道的有阮一峰前輩有這種持續的學習毅力。
學習什麼
微服務已經不是什麼新技術，只是聞道有先後，大廠和趨勢在前行，你不得不邁開腳步（可能你反對，但是趨勢擋不住），當微服務撲面而來的時候，你是否還在觀望或者猶豫，當你恍然大悟的時候，你是否又迷茫不知所措？是的，我們需要一份微服務的腦圖，也許這份圖譜不一定是標準答案，但是在你做參考和評估的時候，希望能對你有所幫助。如下圖所示：
由於內容較多，查看全貌請移步百度腦圖。
為了更好地理解微服務和設計微服務架構，列出幾個比較經典的設計圖輔助理解：
圖一
圖二：(胡忠想 微博技術專家)
六大組件
如腦圖所示，微服務總體的內容包含有六大組件：服務描述，註冊中心，服務架構，服務監控，服務跟蹤和服務治理。這六大組件互相依賴，相輔相成，縱深挖掘，又可以牽扯出DevOps和容器化技術等周邊信息，這些武器庫代表的是技術的未來，不管是你是在小企業還是大廠，還是大廠里的小部門，不知道你是否有這種體驗?
（微服務生態）
服務描述：
類似服務的說明文檔，簡單但不可或缺。比如，服務調用首先要解決的問題就是服務如何對外描述。比如，你對外提供了一個服務，那麼這個服務的服務名叫什麼？調用這個服務需要提供哪些信息？調用這個服務返回的結果是什麼格式的？該如何解析？這些就是服務描述要解決的問題。
註冊中心：
有了服務的接口描述，下一步要解決的問題就是服務的發布和訂閱，就是說你提供了一個服務(Provider)，如何讓外部(Consumer)想調用你的服務的人知道。這個時候就需要一個類似註冊中心(Registry)的角色，服務提供者將自己提供的服務以及地址登記到註冊中心，服務消費者則從註冊中心查詢所需要調用的服務的地址，然後發起請求。如下圖所示：
服務框架：
通過註冊中心，服務消費者就可以獲取到服務提供者的地址，有了地址後就可以發起調用。但在發起調用之前你還需要解決以下幾個問題。服務通信採用什麼協議？是RESTful API還是gRPC？數據傳輸採用什麼方式數據壓縮採用什麼格式？這些活通常集成到了我們的服務框架裡面，市面上有很多這樣的開源框架，相對都比較成熟，接下來考驗你的是快速上手的能力。
服務監控：
一旦服務消費者與服務提供者之間能夠正常發起服務調用，你就需要對調用情況進行監控，以了解服務是否正常。通常來講，服務監控主要包括三個流程，指標收集，數據處理，數據展示。監控是為了發現問題和異常，如果要進一步跟蹤和定位問題，則需要進一步了解服務追蹤。
服務追蹤：
除了需要對服務調用情況進行監控之外，你還需要記錄服務調用經過的每一層鏈路，以便進行問題追蹤和故障定位，最後達到接近問題的目的。服務監控和追蹤可以合併起來，但是要明確各自的職責是不一樣的。
服務治理：
服務監控能夠發現問題，服務追蹤能夠定位問題所在，而解決問題就得靠服務治理了。服務治理就是通過一系列的手段來保證在各種意外情況下，服務調用仍然能夠正常進行。就目前開源的服務框架，大部分都不包括服務治理的內容，所以有可能這塊是需要你和你的團隊進行定製化開發，就看你做到什麼程度了，就好比你有資料庫但是你沒有ER圖描述，並不影響你用微服務，當然如果有就是錦上添花的東西了。
以上六大組件可以粗暴的定義為微服務的二級目錄，他們共同組成了微服務架構，在生產環境下缺一不可。
相信通過以上的整理，你對微服務的學習方法和學習路徑已經有了一個大概的思路了，接下來就是邁開腳步，持續輸出的能力了，你準備好了嗎？
參考文獻：
- 微服務架構理解
- 微服務架構設計
- Martinfowler博客Microservices
- Microservice Architecture
- Wikipedia
END