前言
微服務在程式設計圈火的是不行不行的啦，可能還有很多小夥伴還沒有進行微服務實操，但這個詞，要說沒聽過、沒看過，那小夥伴一定是假Programmer。
雖然微服務很火，但不能盲目使用；先不說涉及技術和工具有多少，首先應該針對業務需求和開發團隊有一個規劃，評估業務需求的複雜度和開發團隊人數及技術能力。對於微服務本身，業務的劃分、開發的技能、部署的方案、維護的成本每一項都不能缺，否則很大一種可能就是以失敗告終。
來，小夥伴們一起聊聊，我先來說說我的理解，小夥伴可以評論，私聊都行.....
正文
微服務的出現，並不是為了替代原先單體架構，而是為了解決單體架構出現的相關問題；也不是為了取代面向SOA服務化的設計，其實應用場景很關鍵，通常SOA面向服務化的方式，是企業資訊化整合的常用的手段；對於SOA，雖然也是面向介面通訊，但我的理解其實是將更多的單體程式整合，業務細分沒有微服務那麼精細。所以微服務並不是為了取代某一種程式架構，而是它更適合於某種業務場景或更好地解決某種問題。
單體到微服務的演變
對於單體架構而言，本身就是一種高生產力的架構，程式設計師上來就幹，幹完就上線。儘管隨著業務複雜和訪問量的增多，也可以通過分散式+叢集的方式實現應用程式在高併發下的高可用；但是在Code過程中，當每新出一種方案解決遺留問題時，隨之而來也有新問題的誕生，只是利益大於危害罷了。接下來，看看單體是如何演變到微服的，下圖只是針對軟體架構進行演變描述，圖片為自頂向下邏輯查閱。
從上圖看到，從最初的一臺伺服器，隨著業務需求複雜及併發資料的增大，演變到三臺伺服器，應用程式、快取、資料庫各自有專門的伺服器的處理；通過快取中介軟體緩解資料庫壓力，從而可以接受更多的請求，但是單臺應用伺服器的記憶體、CPU處理能力、檔案IO、網路IO都有瓶頸，當業務需求增加、併發量增大時，就要考慮叢集啦。我們們接著聊↓↓↓
上圖為了應對高併發實現高可用，剛開始採取了叢集部署的方式，將請求合理分配到各個叢集伺服器中，提升處理能力。這樣一來，隨著長時間資料的積累，特別針對資料比較多的系統，就會導致單庫或單表的資料量比較大，最終影響系統效能；這裡一般的解決方案會採用分庫分表的形式解決，資料量特別大的，可以集合大資料平臺進行資料儲存和分析，這裡就不在單獨作圖表示啦；
當一個系統到了叢集部署這一步，這個專案也不算小啦；通常業務需求會陸陸續續而來，最終會導致單體程式碼量增大，維護和新增功能不容易，而最好的辦法是將比較單獨的業務獨立成一個專案，通過分散式的方式實現新增需求的擴充套件，專案之間通常使用API、RPC或訊息佇列的方式進行通訊；分散式+叢集其實已經足夠能應付專案的開發啦，究竟存在哪些問題促使微服務的到來呢？
單體架構面臨的問題：
-
部署成本高：只要稍微改一處程式碼，就可能導致整體替換部署；一些專案，時間就是金錢，不能接受；
-
迭代速度慢：專案整體龐大，稍一改動，就得需要花費大量的時間整體測試驗證；
-
不易於擴充套件：當擴充套件需求時，只能持續往專案中增加程式碼，最後導致開發難度係數增大，風險高；部署擴充套件也有風險；
-
大量程式碼重用：雖然已經分散式，但獨立出來的專案還是單體，存在大量程式碼重用，比如許可權和一些公共功能模組等；
-
新人上手成本高：需要整體瞭解專案邏輯，花費更多的時間，否則容易出錯，風險高；
單體架構的問題作為導火索，再加上當今業務需求的複雜化及迭代速度要求高，最終就促進了微服務的落地，為什麼是落地呢？其實微服務概念在2014年一位馬丁.福勒的工程師就提出啦。
微服務這張圖去掉閘道器和服務治理是不是和分散式有異曲同工之處，其實微服務就是分散式，不過其劃分的更加精細，當然對於監控和追蹤那些沒在圖中體現，那微服務能解決什麼問題呢？
微服務解決哪些問題(最接近開發的點)
-
部署成本低：針對具體的服務模組進行部署即可，不影響整體系統其它服務模組執行；
-
迭代速度快：單獨模組服務易於開發和維護，負責人員能快速進行開發、驗證；
-
伸縮性好：開發可以根據業務進行服務劃分，快速開發，不影響其他服務；部署易於擴充套件；
-
程式碼重用好：對於公共服務模組進行獨立共用，比如使用者認證，許可權管理等相關公用模組； 電商裡面的支付、物流等；
-
新人上手成本低：針對進入專案的新人，可以先從單個服務開始進行開發，更容易上手，風險低；
是不是把單體對應的問題都解決了，最起碼好處很明顯；當然還有其他優點，比如開發不限於語言，可以多語言進行開發等；
對於每一種方案，解決問題的同時，肯定也有新問題的產生；絕對完美對於程式設計而言，好像這樣的方案還沒有，但相對完美還是得追求的，微服務究竟帶來哪些問題呢？
微服務帶來的問題(最接近開發的點)
-
分散式問題更加複雜化：因為本來分散式問題就存在，比如分散式鎖，分散式事務，資料一致性等問題，隨著服務的細化，自然就讓分散式問題更加複雜化；
-
問題排查增加難度：微服務很多時，如果出現問題，需要明確的定位，比起單體定位問題更加難啦，但可以藉助追蹤工具和日誌分析工具進行輔助；
-
整體專案質量管控更難：從效能方面，多服務互動需消耗網路IO；單個服務掛了，如果處理不好可能導致系統雪崩；一般需要做熔斷、隔離、限流等相關防護；
-
對應開發人員技術要求高：不僅是業務開發，對業務劃分、服務之間通訊、服務部署、服務監控、虛擬化等都得有所熟悉，所以從技術開發到運維監控都得有對應的技術棧知識的支撐；
-
部署難度增加：當服務很多時，靠人為進行操作已經不現實；
所以，微服務並不是完美，只是在解決問題上帶來的好處相對比帶來問題更有價值；
既然最終都要演變到微服務，直接用是不是最好？
一般情況，各路大神都不建議直接使用微服務架構，而是根據業務驅動架構的演進，通常在使用微服務時，需要考慮以下情況：
-
專案生產力要求，其實就是商務，如果公司允許有足夠的時間進行開發，可以繼續考慮；否則單體架構前期的生產力更容易體現；
-
業務複雜度要求，如果業務需求本身不復雜，後續新增可能性不大，沒必要為了流行使用微服務；
-
開發團隊要求，微服務初期是需要花費大量的人力的，後期運維也是重要活，如果團隊人不多、技術不熟，得綜合考慮，否則會累死；
說這麼多，不是說使用微服務不好，而是過早的使用，反而會一團糟；還是那句話，一個專案在開發過程中過早的過度優化，肯定等於玩火自焚：專案週期可能不能如期完成；當前的優化可能並不是適合後面的開發，可能還會重工等。
在刷部落格的時候，看到一個詞：單體微服務，當然這不是官方的詞，是博友自己的理解，就是用微服務的思想設計單體程式，這樣後續過渡到微服務的時候就相對平滑；
有沒有小夥伴關注到圖片上針對每一次演變都標有段位，從倔強青銅到至尊星耀，那為什麼沒有最強王者？或者說微服務為什麼不是最強王者呢？ 軟體架構隨著業務驅動會不斷髮展，總有一些新思路會出現，如今現在有些大廠在搞的Service Mesh(服務網格)可能就是下一個微服務演變的架構，所以給最強王者留了個問號。
總結
微服務對於複雜業務的確很香，但同時也帶來了相關問題，同時要求的技術棧比較豐富，所以說它是麻辣味的，並不是一開始就能將其一下消化，需要慢慢實踐。好啦，微服務我理解的差不多是這樣，小夥伴歡迎指點及分享自己的想法，互相學習；
接下來會針對微服務的落地持續學習和分享相關文章，具體計劃在下一篇再好好說說。
一個被程式搞醜的帥小夥，關注"Code綜藝圈"，跟我一起學~
