簡介
最近都在弄微服務的東西，現在來記錄下收穫。我從一知半解到現在能從0搭建使用最大的感觸有兩點
1.微服務各大元件的版本很多，網上很多部落格內容不一定適合你的版本，很多時候苦苦琢磨都是無用功
2.網上部落格參差不齊，有些甚至錯誤的。更離譜的是，好的文章閱讀量除非高出天際，不然就都很低，比那些複製貼上，隨便應付的都低（這個搜尋推薦演算法不知道基於什麼的）
通過這段時間學習，我覺得最重要是從好的部落格入手，先不要著急怎麼元件怎麼使用，而是先了解元件的作用，大概的原理，然後才是使用，這樣搭建和嘗試的過程中才能更好的定位問題，最後再次回到原理和一些實際問題的處理（不知道實際問題怎樣的，直接搜那個元件的面試題往往效果最好）
接下來的內容，都以導航的形式展現給大家（畢竟優秀的輪子很多，直接看大佬寫的不香嘛），再順帶提些自己的理解
傳送門
更多微服務的介紹可點選下方連結
微服務介紹、Nginx導航、Nacos導航、Gateway導航、Ribbon導航、Feign導航、Sentinel導航
博主微服務git練手專案：https://github.com/NiceJason/SpringCloudDemo
微服務介紹
這篇博文主要介紹微服務的基本概念，讓大家明白什麼是微服務
在實際工作中會越來越覺得，用各種技術打造高效能，高併發，高可靠的系統無非就圍繞兩個字：省錢，為公司省錢，為自己省錢
這是很現實的事情，假如一個單機系統做的很差，伺服器2核8G的不行就升級為4核，8核的16G，32G，64G的，效能不行，硬體來湊總能滿足
別說幾十萬上百萬的高併發，有多少公司能達到十幾萬，幾萬的。很多時候只要注意併發問題業務其實就能正常流轉，效能意思下就夠了，如果業務量升級就靠硬體去湊，因為硬體只要不是高標準還真的不是很貴（隨著時代發展，硬體有著質的提升），就像考試30,40分努努力到60分一樣，伺服器從很低端的配置升級到低端配置也就小錢（比每個月多出幾千上萬招高階程式划算多了），而大部分公司業務量其實已經滿足了（能掙到錢養活整個公司了）。
但還是要弄，因為隨著業務量提升，需求擴充套件變更，如果程式碼不設計好，最終苦逼的還是程式設計師自己，重構是不可能重構的，所以只能在危樓上繼續加蓋。這期間時間的開銷很大，收穫的經驗低價值。按照國內普遍35歲就程式設計師危機的行情來看，你還有多少時間去浪費，時間就是金錢啊。而高標準要求自己寫程式碼的同時，也確實降低了線上出錯的風險和最大效率發揮有限的資源（就是公司省錢了），因此自己努力就能達到雙贏的局面
而微服務能有效解決應用高效能，高併發，高可靠3大問題，詳情看連結內容，本文只是總結和提下經驗
優秀原文連結：https://www.zhihu.com/question/65502802（作者老劉那一個回答）
文章從單體應用開始，一步步因為需求的增加而逐步向微服務邁進（並不是微服務流行就用微服務），這篇文章引領我走入微服務的世界，讓學習的方向更加明確
文中主要提到微服務的好處：
1.讓每個服務功能邊界清晰，理清依賴關係，從而減少冗餘程式碼，方便擴充套件
2.讓瓶頸的地方（如資料庫）得到更好的解決（其實就是可擴充套件），其實如果不是程式設計的十分離譜，對於記憶體一般都是夠用的，瓶頸幾乎都圍繞資料庫展開，從而需要快取（讀多寫少），需要MQ佇列（非同步執行，減少高峰期資料庫壓力）
3.增加系統穩定性，防止單點崩盤，同時減少測試和部署的複雜度（很關鍵的一點，經常會被忽略）
4.微服務會引來穩定性的問題（與3其實不衝突，只是不同角度看穩定性），可以從減少錯誤（事前監控、事後分析），降低影響（熔斷、限流）兩個方面入手
5.這裡提一下服務降級。例如A服務訪問B服務，B服務掛了，如果僅僅熔斷，那麼請求還是源源不斷的進入到A服務中，只不過A服務快速返回失敗（這和@FeignClient配置降級方法是一樣的），服務降級另一方面則從請求的源頭（如介面點選按鈕沒了，推薦介面沒了）切斷，這就需要前後端對一些功能有個開關，開關斷了則前端停止請求。
6.最重要的還是結合實際專案，單機系統並非一無是處，服務劃分才是關鍵點，合適自己的業務需求才是最重要的
至於微服務相關的CAP原則，Base理論，大家百度下就好，實際中還是要多接觸微服務和分散式的系統才能有更深的體會，每項技術都有優缺點，只有最適合業務的，沒有絕對的
小結
本篇部落格最主要是想讓大家瞭解微服務的優缺點，很多時候學著學著就會忘記初心，不知道為什麼要用這個技術（本人就經常犯迷糊哈哈哈），從而多個知識點串不起來就經常忘（好氣啊，當時琢磨了這麼久）。所以接下來的部落格都以原理為主，具體使用其實還是比較次要的（很容易搜尋出來），技術之間原理多多少少有互通點，也能讓平日開發借鑑（咳咳，其實就是記不住這麼多知識，只能挑重點了解，舉一反三），希望能幫到大家啦~