簡介
微服務興起已經多年了，這幾年已到大發展階段。公司内部做了很多和微服務相關的事情，自己也看了一些微服務相關的内容。現在再來認識”微服務“三個字，終于有點懂了的感覺。
學習期間看過的内容有
- 微服務設計
- 雲原生分布式存儲基石：etcd深入解析
- Docker技術入門與實戰
- 每天5分鐘玩轉Kubernetes
- 左耳聽風
- 從0開始學微服務
出現原因
微服務為什麼會出現？我覺得這是網際網路發展的必然結果。
如同以前沒有IOS七層模型的時候，當時的程式員做程式設計，他們需要自己做七層模型做的事情，這個事情每一個程式員都需要做，造成了大量的資源浪費，而且每個人做出的效果也很難說完美。然後IOS七層模型出現了，統一的規範幫程式員完成重複性工作，大大提升了開發效率。
這麼看來的話，微服務做的是相同的事情。
網際網路曆經幾十年的發展，頭部公司規模巨大，碰到大量問題，而這些問題每一個企業都可能遇到。在很多事情上大家都在重複造輪子，而且很多時候做的也未必很好。高人們在吸收優秀實踐的基礎上，結合自己廣博的學識，推動了微服務的發展。
目前看微服務形成統一标準還比較困難，一是從整個發展階段來看，現在還是處于初期，相關的微服務人才并沒有大量出現，二是各個公司自身業務情況不一樣，很難完全統一。但是，微服務其實已經成燎原之勢，在不久的将來，可能開一家網際網路公司會變得更加簡單，微服務會像TCP/IP一樣，對開發人員來說是完全透明的，開發人員隻需要關注開發業務邏輯即可，當然，前提是發展到這個階段，還需要程式員的話。
開發這種通用性的微服務平台，倒也是很不錯的一個創業方向。
是以作為當代程式員，學習微服務還是必須的，這是必然的趨勢，也能增加自己的競争力。假如真有一天，微服務和TCP/IP一樣透明了，懂微服務核心原理的人仍然更有價值，畢竟到時候隻有這些人才能解決某些神奇的問題。
體系
微服務的水挺深的，準确的說，不僅深還特别廣。微服務涉及的内容特别多，而且每一塊都可以深入研究，成為這方面的專家。
在《微服務設計》這本書裡，給微服務下的定義為：微服務就是一些協同工作的小而自治的服務。
這個定義不是特别好，總感覺是把微服務的範圍縮小了。
另外閱曆不同對這句話的了解上差距還是蠻大的。記得以前我有一個評論系統，評論服務、評論背景、DB、緩存等都是獨立部署的，我當時覺得這個評論系統就是微服務。這麼說不能算百分之百的錯，但肯定也不是正确的。
因為微服務闡述的是一整套體系，單單一個獨立的服務，隻占微服務很小的一部分。
微服務主要由6部分構成
-
服務描述
類似服務的說明文檔，簡單但不可或缺。比如，服務調用首先要解決的問題就是服務如何對外描述。比如，你對外提供了一個服務，那麼這個服務的服務名叫什麼？調用這個服務需要提供哪些資訊？調用這個服務傳回的結果是什麼格式的？該如何解析？這些就是服務描述要解決的問題。
-
注冊中心
有了服務的接口描述，下一步要解決的問題就是服務的釋出和訂閱，就是說你提供了一個服務(Provider)，如何讓外部(Consumer)想調用你的服務的人知道。這個時候就需要一個類似注冊中心(Registry)的角色，服務提供者将自己提供的服務以及位址登記到注冊中心，服務消費者則從注冊中心查詢所需要調用的服務的位址，然後發起請求。
-
服務架構
通過注冊中心，服務消費者就可以擷取到服務提供者的位址，有了位址後就可以發起調用。但在發起調用之前你還需要解決以下幾個問題。服務通信采用什麼協定？是RESTful API還是gRPC？資料傳輸采用什麼方式資料壓縮采用什麼格式？這些活通常內建到了我們的服務架構裡面，市面上有很多這樣的開源架構，相對都比較成熟，接下來考驗你的是快速上手的能力。
-
服務監控
一旦服務消費者與服務提供者之間能夠正常發起服務調用，你就需要對調用情況進行監控，以了解服務是否正常。通常來講，服務監控主要包括三個流程，名額收集，資料處理，資料展示。監控是為了發現問題和異常，如果要進一步跟蹤和定位問題，則需要進一步了解服務追蹤。
-
服務追蹤
除了需要對服務調用情況進行監控之外，你還需要記錄服務調用經過的每一層鍊路，以便進行問題追蹤和故障定位，最後達到接近問題的目的。服務監控和追蹤可以合并起來，但是要明确各自的職責是不一樣的。
-
服務治理
服務監控能夠發現問題，服務追蹤能夠定位問題所在，而解決問題就得靠服務治理了。服務治理就是通過一系列的手段來保證在各種意外情況下，服務調用仍然能夠正常進行。就目前開源的服務架構，大部分都不包括服務治理的内容，是以有可能這塊是需要你和你的團隊進行定制化開發，就看你做到什麼程度了，就好比你有資料庫但是你沒有ER圖描述，并不影響你用微服務，當然如果有就是錦上添花的東西了。
這6部分組合起來才稱之為微服務。下面的連結是我做的一個思維導圖，導圖裡面的有些内容我還沒有完全學會，後期會做進一步的整理，如果大家喜歡的話，可以先記一下這個連結。
https://www.processon.com/view/link/5f3952a17d9c0806d41a90a9
學習路線
微服務算是集現代網際網路技術大成者。我是初學者，需要給自己建立一條學習路線，這樣能夠幫助自己更好的掌握内容。
對于學習路線，我認為有幾個原則：
- 找出必學内容并做筆記
- 以前看過很多文章或者書籍，但是沒有把内容寫下來，總覺得學得比較淺，将内容消化後寫出來，能夠加深印象
- 必學的内容應該是核心内容，像k8s、docker、分布式等是百分之百需要學習的
- 不必學
- 同一個方案有多個技術選型，隻學一個就行。如服務編排隻要看k8s，因為這個已經算是行業标準。服務追蹤可以從zipkin和skywalking中選擇一個
- 有些内容特别偏向于運維層面，可以了解淺一點或者完全不去了解
- 不斷更新和豐富腦圖
- 學習過程中，需要進行實踐，最終搭建出基礎款微服務。
目前計劃學習以及重新學習的内容有
- k8s
- docker
- Etcd
- GRPC
- Netty
- Dubbo
- ELK
- Grafana
- Kafka
- Skywalking
- Apollo
- Istio
其實除了這些，微服務還有很多其他的内容需要學習，這些内容可以在今後慢慢補齊。
資料
- 微服務學習架構路線圖(初稿)
- 微服務學習導航
- 【幹貨分享】可能是東半球最全的.NET Core跨平台微服務學習資源
最後
大家如果喜歡我的文章，可以關注我的公衆号（程式員麻辣燙）
往期文章回顧：
技術
- 淺談微服務
- TCP性能優化
- 限流實作1
- Redis實作分布式鎖
- Golang源碼BUG追查
- 事務原子性、一緻性、持久性的實作原理
- CDN請求過程詳解
- 記部落格服務被壓垮的曆程
- 常用緩存技巧
- 如何高效對接第三方支付
- Gin架構簡潔版
- InnoDB鎖與事務簡析
讀書筆記
- 如何鍛煉自己的記憶力
- 簡單的邏輯學-讀後感
- 熱風-讀後感
- 論語-讀後感
思考
- 對項目管理的一些看法
- 對産品經理的一些思考
- 關于程式員職業發展的思考
- 關于代碼review的思考
- Markdown編輯器推薦-typora