微服務架構可謂是當前軟件開發領域的技術熱點，它在各類博客、知識媒體和業界知名會議演講上的出鏡率很是之高，不管是作基礎架構仍是作業務系統的工程師，對微服務都至關關注，而這個現象與熱度已經持續了近5年之久，經久不衰。數據庫
然而，隨着雲原生技術的推廣，以及大量的微服務落地，反微服務的聲音愈加響亮。尤爲是在今年3月初，服務網格的著名開源項目 Istio 發佈了 1.5 版本，其控制面由原先的多個微服務組件，合併成了一個單體應用，大大簡化了其架構與部署運維的複雜性，贏得了滿堂喝彩。社區關於微服務模式質疑的聲音此起彼伏，也有文章大聲呼喊：「醒醒，你不是真的須要微服務！」編程
那麼，在雲原生時代，是否須要微服務？何時應該採用微服務？微服務究竟能給業務帶來哪些好處？如何在不一樣環境下正確合理地落地微服務？但願讀完本文後，每位讀者都能在心中有個答案。後端
微服務是什麼
2014年，Martin Fowler 與 James Lewis 共同提出微服務的概念，定義了微服務架構是以一組小型服務的方式來開發一個獨立的應用系統，每一個服務都以一個獨立進程的方式運行，每一個服務與其餘服務使用輕量級（一般是 HTTP ）通訊機制。這些服務是圍繞業務功能構建的，能夠經過全自動部署機制獨立部署，同時服務會使用最小規模的集中管理能力，也能夠採用不一樣的編程語言和數據庫，實現去中心化的服務管理。服務器
而早在 2005年，Peter Rodgers 博士在雲端運算博覽會上就提出了微 Web 服務，將程序設計成細粒度的服務（Granular Service），以做爲 Microsoft 下一階段的軟件架構。網絡
由此能夠看出，微服務並非一個新的概念，在很早以前就有了充足的理論基礎。大系統終究會拆解成小系統，「合久必分，分而治之」；傳統行業的系統架構大多都是龐大的單體架構，微服務是架構發展的一個很是天然的演變狀態。架構
遺憾的是，微服務模式並不是「銀彈」，微服務也有其弊端和痛點。Martin Fowler 也在他的博客中寫道：「除非你的系統太複雜，做爲單體應用會很難管理，不然不要考慮微服務。絕大多數軟件系統都應該構建爲單體應用。要注重在單體應用中實現良好的模塊化，但不要試圖將其拆分紅單獨的服務。」併發
微服務架構的優勢
一般來講，架構沒有好壞優劣之分，只有適合與不適合。可是當把微服務架構與單體架構進行比較，會發現微服務有以下一些優勢：負載均衡
| 因素 | 單體架構 | 微服務架構 | 說明 |
|---|---|---|---|
| 故障隔離 | 線程級 | 進程級 | 微服務獨立運行，經過進程的方式隔離，使故障範圍獲得有效控制、架構變得更可靠。 |
| 總體可用性 | 較低 | 較高 | 微服務架構因爲故障獲得有效隔離，總體可用性更高，有效下降了單點故障對總體的影響。 |
| 架構持續演進 | 困難 | 容易 | 微服務的粒度更小，架構演進的影響面相應也更小，架構演進不須要大規模重構，只需調整個別微服務便可。 |
| 可重用性 | 低 | 高 | 微服務架構能夠實現以服務爲粒度，經過接口共享重用。 |
| 可擴展性 | 笨重 | 靈活 | 微服務架構能夠根據服務對資源的要求以服務爲粒度進行擴展，而單體應用只能總體進行擴展。 |
| 交付速度 | 較慢 | 較快 | 服務拆分後，各個服務能夠獨立並行開發、測試、部署，交付效率大大提高，產品更新換代速度更快，用戶體驗更好。 |
微服務還有許多優勢，如「反脆弱性（anti-fragility）」、架構抽象、技術隔離等。但並非說採用了微服務就天然地具有了這些特性。框架
微服務的先決條件
準確地來說，要想享受微服務的福利，須要具有一些先決條件。
1、團隊調整
須要從新組建團隊，以服務爲核心，按照業務領域劃分全功能團隊，改變原有的研發流程、決策機制。例如，倡導敏捷文化、快速迭代，作更多的自動化測試，增強 Code Review 等。運維
在新的團隊組織裏面，一切以人爲本，須要創建開放自由的環境。領導對下級高度信任，加強其自我驅動，充分發揮每個人的力量，而不是讓工程師成爲「螺絲釘」。
微服務框架能夠封裝、抽象分佈式場景下的一些經常使用能力，例如負載均衡、服務註冊發現、容錯、遠程通訊等能力，可讓開發人員快速地開發出高質量的服務。所以，在採用微服務架構以前，應該先進行微服務架構的選型、學習和試用。整個團隊要對微服務的基本概念、微服務框架的實現原理，微服務治理與監控等知識須要有必定的儲備。
2、基礎設施建設
基礎設施即代碼，能夠經過編程的方式管理虛機或容器，免去了手動配置、更新各個硬件的環節，這就使得基礎設施極具彈性，可以快速、高效、準確地進行重複性操做。開發人員使用同一套代碼或配置，就能夠部署並管理成千上萬臺物理機。
當服務數量增多、交付頻繁的時候，故障次數可能會大幅度上升，咱們須要經過全面地監控發現故障，及時處理併發出警報。當生產環境出現問題的時候，須要將故障進行分級，評估影響面，並分配給相應的負責人。
微服務架構的一個大優點就是快速交付，快速交付不止體如今服務的粒度更小，能夠獨立交付，還體如今整個流程更快速。微服務架構基於自動化的工具鏈，以流水線交付的方式串聯整個 DevOps 流程。小團隊能夠基於服務獨立開發、測試、部署、運維。
以上這兩點不是採用微服務模式的充分必要條件，但當團隊知足了上述兩個條件後，微服務化的過程將事半功倍，後續維護和迭代也會順風順水，而不是叫苦不迭。
微服務是逐步拆分出來的
其次，微服務是應該隨着業務的演進逐步拆分出來的。
避免在設計系統的時候直接劃分微服務。幾乎全部成功的微服務架構都是從一個巨大的單體架構拆分出來的；幾乎全部在一開始就構建微服務架構的案例，後續都遇到了巨大的困難。
面對一個新的業務和領域，很難在開始階段就對業務梳理得很清晰，每每是通過一段時間踩過一些坑，通過模塊調整後，業務內部架構才能逐漸清晰起來。而且從一個已有的模塊清晰的單體架構逐步劃分服務，要比一開始就構建微服務簡單的多。若是一開始就劃分了微服務，其一，初版交付的時間會延後許多，由於有許多公共服務須要去構建起來；其二，服務很容易拆分得不合理，大大影響整個調用流程的性能，甚至可能須要花費很大的精力去處理分佈式事務，最後不得再也不將多個微服務整合成一個單體。
只有當業務複雜度達到必定的程度後，微服務架構消耗的成本纔會體現其優點，這個時候就能夠開始設計微服務架構、進行微服務劃分了。微服務設計應該優先尊崇垂直劃分優先原則，垂直劃分服務可讓團隊自上而下地關注業務實現，端到端負責，避免跨服務屢次調用引發的性能與溝通成本。
微服務須要監控與治理
拆分以前，整個系統擁有的服務數通常只有個位數；拆分以後，服務可能變成了數十上百個，實例數可能會達到成千上萬個。這麼多服務與實例，須要構建一套監控系統，可以監控全部服務平常運行狀態，而且須要在服務出錯的時候給對應負責人發出報警信息；在出現故障時，可以經過調用鏈查詢以及服務拓撲圖等功能進行分析查看，也能夠進一步查看到全息日誌等具體信息。
除了監控，服務治理也相當重要。能夠經過 SDK/Sidecar 手段提供服務高可用的治理策略，這些策略每每對業務是非侵入或者弱侵入的，可以讓絕大多數服務輕鬆實現服務高可用。
微服務之間一旦創建起路由，就意味着會有數據在服務之間流通。因爲不一樣服務能夠提供的資源和對數據流量的承載能力不盡相同，爲了防止單個 Consumer 佔用 Provider 過多的資源，或者突發的大流量衝擊致使 Provider 故障，須要服務限流來保證服務的高可用。
在服務治理中，雖然咱們能夠經過限流規則儘可能避免服務承受太高的流量，可是在實際生產中服務故障依然難以徹底避免。當整個系統中某些服務產生故障時，若是不及時採起措施，這種故障就有可能由於服務之間的互相訪問而被傳播開來，最終致使故障規模的擴大，甚至致使整個系統奔潰，這種現象咱們稱之爲「雪崩」。熔斷降級其實不僅是服務治理中，在金融行業也有很普遍的應用。好比當股指的波動幅度超過規定的熔斷點時，交易所爲了控制風險採起的暫停交易措施。
負載均衡是高可用架構的一個關鍵組件，主要用來提升性能和可用性，經過負載均衡將流量分發到多個服務器，同時多服務器可以消除這部分的單點故障。
如何在雲原生時代落地微服務
1、選擇合適的時機
就像前面提到的，組織架構與團隊文化要適應雲原生的節奏，須要足夠敏捷、足夠自主，構建全功能團隊，產品、UI、先後端研發、測試等角色要齊全；須要提早作好自動化的流水線，能夠一鍵構建、發佈、部署，能夠快速擴縮容等；服務提早作好容器化部署改造，服務容器化更適合在雲原生場景下集成其餘功能與組建。等上述一切都 ready 了以後，而且業務也逐步發展到了必定規模急需拆分了，這個時候就應該果斷進行微服務拆分和架構設計了。
2、選擇合適的微服務框架
如今主流的微服務框架主要分爲兩類：侵入式與非侵入式。主流的開源侵入式框架包括 Spring Cloud、Dubbo、brpc 等，其功能特點各有千秋，在不一樣的場景均有應用，大部分架構師對其均有比較多的瞭解，社區和文檔的成熟度都比較高。雖然 Spring Cloud 這樣的傳統侵入式微服務框架大多具備版本碎片化嚴重、升級成本高等問題，但總的來講，已經能夠知足絕大部分服務治理的需求，而且藉此快速推動微服務化改造。
如今大部分人更關心的是非侵入式框架的選型，即近幾年火起來的服務網格技術。2017年，隨着 Linkerd 的傳入，Service Mesh 翻譯成服務網格，並開始進入國內社區的視野，部分大公司也同步自研了適配公司內部應用場景和依賴的服務網格框架，用以助力內部服務快速迭代與發展。
而 Istio 做爲一個開源的 Service Mesh 開源框架，一經推出就備受矚目，成爲了各大廠商和開發者爭相追捧的對象。不少人相信，Istio 會成爲繼 Kubernetes 以後又一個明星級產品。有了 Istio，你幾乎能夠再也不須要其餘的微服務框架，也不須要本身去實現服務治理等功能。只要把網絡層委託給 Istio，它就能幫你完成這一系列的功能。簡單來講，Istio 就是一個提供了服務治理能力的服務網格。此外，Istio 還提供完善的可觀察性方面的能力，包括對全部網格控制下的流量進行自動化度量、日誌記錄和追蹤。換句話說，選擇了 Istio，單體應用無需作任何改造便可輕鬆接入微服務，享受雲原生各項福利。
3、藉助雲廠商產品快速進行雲原生與微服務落地
之因此提到雲廠商，是由於大部分中小型公司或者傳統行業都面臨着單體應用和傳統微服務框架的各類弊端和詬病，急需進行雲原生與微服務改造，可是缺少足夠的人力與技術，去維護一套功能齊全的雲原生底座與基礎架構服務。例如 Istio 框架，其版本迭代頻繁，控制面與數據面在提供了強大的功能的同時，代碼實現至關複雜，在遇到了異常的時候，不少工程師每每很難定位問題。
而云廠商則提供了一整套雲原生應用編排與微服務管理解決方案，全部技術都獲得產品化，方便使用與查看效果，而且避免或者快速解決運行期間可能遇到的各類問題。在必定程度上，這不只提升的服務的效率，也大大下降了各類成本，能夠快速充分地享受雲原生福利，助力內部業務穩定對外服務，快速擴張。
總結
最後，咱們再回到開篇的疑問，咱們是否還須要微服務？
這個問題沒有惟一與正確的答案，每一個人所處的場景不一樣，正如一千我的心中有一千個哈姆雷特。任何軟件或者架構都有其利弊，沒有十全十美的東西。你們須要思考和衡量的是，當前的軟件與系統是否知足了微服務化改造的前提，微服務化改造後其帶來的收益是否大於損失、利是否大於弊，團隊各個方面是否作好了準備，若是尚未，那麼請你再等等，單體架構也挺好！
做者簡介：羅廣明，現就任於百度基礎架構部雲原生團隊，雲原生技術專家，雲原生社區聯合創始人，ServiceMesher 社區管委會成員，多年來一直從事微服務技術與產品的研發工做，對 Spring Cloud、Istio 以及微服務中間件有深刻研究和實戰經驗。
參考文獻
-
《持續演進的 Cloud Native 》 王啓軍/著
-
《Istio Handbook——Istio 服務網格進階實戰》ServiceMesher社區聯合編著：https://www.servicemesher.com/istio-handbook/
-
《混合微服務高可用在企業級生產中的實踐》 羅廣明：https://cloudnative.to/blog/microservices-ha-practice/