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