什麼是微服務架構,該從哪些方面深入了解?到底能解決哪些問題呢？

微服務架構概述

微服務在設計之初就是緻力于解決單體式架構的問題而出發的，是以它幾乎可以解決單體式架構面臨的所有問題。雖然微服務本身也有一些缺陷，但絲毫不影響它替代單體式架構成為主流架構的步伐。那麼，微服務架構到底能解決哪些問題呢？

微服務能解決的問題

下面從之前總結的單體式架構的缺點來分析。首先，微服務解決了難以維護的問題。微服務本身微小的設計，導緻一個服務的職責不會過大，進而輕松地解決了難以維護的問題，單對一個服務來講，它的代碼量不會特别多，量少的東西不一定簡單，但一定是好管理的，而且後續介紹的有關微服務更科學的程式設計方法，也會大大增加代碼的可維護性。

其次，過載的IDE和過載的Web容器，似乎也随着服務的微小化而輕松解決了，微服務架構中的每個服務都是獨立部署的，擁有自己獨立的程序，無論是IDE還是Web容器，都可以輕松地承載，而且應用程式的啟動和調試效率也要高得多。

然後，對于部署，微服務架構中，服務都是自動部署的（具體的方式後續章節會有介紹），而且每個服務負責的職責都很小，隻會部署有變化的服務，是以單體式架構中需要部署全部功能的風險也就沒有了。

這樣的方式，在應用需要做水準擴充的時候，隻需增加需要的服務節點即可，再根據具體增加節點的特性，如存儲、CPU、記憶體等增加具體的符合需求的資源，也就不會出現資源的浪費了。

最後，關于技術創新，微服務本身是獨立的，而且每個微服務之間的通信是輕量級的，這就導緻微服務之前幾乎是沒有技術依賴和限制的，服務既可以有自己獨立的存儲方式，也可以有不同的語言，服務所采用的技術棧也可以是完全不一樣的。是以，你幾乎可以使用任何你認為合适的技術，當然，做技術選型往往可能需要考慮更多的問題，但至少在項目的服務架構層面，微服務并不會對一個項目的技術選擇造成什麼困擾。

看上去微服務似乎真的解決了單體式架構的所有問題，那除了能解決這些問題，微服務本身又有哪些新的特點呢？

微服務架構的特點

微服務定義大緻反映出微服務架構的一些特點：微服務是小的服務；微服務是獨立運作的；微服務的互動是輕量級的，是可以跨語言的；服務的設計是圍繞業務的；微服務是可以自動部署的，有集中式的服務管理等。

但随着微服務的發展，它的定義是多變的，每個人在使用微服務架構時的做法都不完全一樣，其中有很多很好的實踐，有複雜的，也有簡單的，似乎很難去界定誰對誰錯，畢竟由于軟體項目的獨特性，每種實踐都是在特定的需求和場景下産生的，是以不妨把目光放在它們的共同點上。此前有過無數人的大膽嘗試和實踐，我們可以通過分析來看看大多數人都在怎樣做着微服務。

ThoughtWorks的Martin Fowler是業界的權威專家，他認為雖然很難給微服務的架構一個正确的定義，但可以嘗試描述我們認為有合适标簽的架構的共同特征。并非所有的微服務架構都具有所有的特征，但是Martin Fowler希望大多數微服務能具有大部分特征。最後，他總結了微服務的九大特征，成為當下這個松散的社群關于微服務的一個寬松的标準。

下面就來看看微服務的九大特征，如圖1.8所示。

1. 服務元件化

元件簡單來說就是一個可以獨立更換和更新的軟體單元，就像計算機的記憶體、顯示卡、硬碟一樣，是可插拔的，而且更換和設計不會影響其他單元。在微服務架構設計中，我們将應用拆分為一個個獨立的服務，這些服務像元件一樣可以獨立更換和更新。每個服務擁有獨立的程序，可以獨立開發和部署；每個服務可以擁有獨立的存儲，服務之間通過HTTP等輕量級的通信協定進行互動，而不是傳統的嵌入式的方式。

2. 圍繞業務組織團隊

通常，傳統的公司可能會按照技術去組建團隊，如測試團隊、前端開發團隊、後端開發團隊、資料庫團隊、運維團隊等，但微服務本身的設計是圍繞業務展開的，各個服務按照業務價值來劃分邊界，這樣就導緻了微服務的團隊組織結構上是必須跨技術能力的，一個團隊中可能需要包括各種能力的人，如前業務分析師、測試工程師、前端開發工程師、後端開發工程師、資料庫工程師、UI設計師、運維工程師等。

當然，由于微服務小的設計理念，團隊的規模不會很大，如亞馬遜的“Two Pizza Team”原則，一個團隊吃一餐飯隻需兩個披薩就夠了。這樣一個團隊，工作中的内耗是很低的，因為團隊的職責邊界更加清晰，團隊間溝通不暢或者推卸責任等現象将會得到改善。

3. 做産品而非項目

微服務架構中流行着一句話：“You build，you run it！”意思是你建構的應用，那麼由你來負責運作它。

人們在傳統的軟體項目中，往往以一個做傳遞的方式來做項目，而不會考慮整個産品的運作方式或生命周期。例如，産品将需求傳遞給開發，開發将應用傳遞給測試，測試将建構好的版本傳遞給運維，運維負責将應用運作起來。

微服務架構的團隊組織可以說是麻雀雖小五髒俱全，一個團隊往往需要負責項目的全部階段的工作，微服務團隊更像是在做産品而非項目，大家需要關注整個産品的生命周期，負責各個階段的各種工作，并且持續關注服務的運作情況，進而不斷分析，來幫助客戶提升業務價值，倡導開發運維一體化，現在很流行的DevOps等角色，也是在微服務流行趨勢下所産生的。

4. 智能端點和啞管道

由于微服務本身分離的特點，它并不能像單體式架構那樣通過本地的函數調用即可進行服務間的互動，那麼選擇一個好的遠端調用的通信方式是關鍵。

在SOA中，有一些較好的實踐，如在之前提到的ESB就強調需要将調用邏輯放入溝通機制本身，各個端點遵循統一的标準，由企業服務總線來完成消息路由、編排和轉換等功能。這會導緻服務間的通信更加繁瑣，笨重的調用方式在服務更新或更換時顯得尤為吃力。是以，我們需要更加粗粒度、更加輕量的通信機制。微服務社群更傾向于采用另一種方法：智能端點和啞管道。微服務在設計上不隻是在意分離，還強調内聚，每個服務擁有自己的領域邏輯，就像是UNIX的管道設計一樣。目前最常用的有兩種協定：一種是帶有資源API的HTTP請求，即人們常說的RESTful API請求；另一種是通過輕量級的消息總線，如使用RabbitMQ或ZeroMQ等來進行消息傳遞。

5. 去中心化治理

無論是單體式架構，還是SOA，似乎都需要定義一個統一的技術平台标準，但經驗表明，這種做法并不好，不是每個問題都是釘子，不是每個解決方案都是錘子，每種技術平台都會有它的短闆，一旦規定了統一的技術平台标準，在遇到它的短闆時，開發者将感到十分痛苦。

微服務團隊更提倡采用不同的方法或标準，使用正确的工具和技術來完成工作。通過輕量級的、粗粒度的通信機制，不同的服務不再需要中心化的技術平台标準，服務可以是不同語言、不同架構的，可以根據不同的業務場景需要來選擇合适的技術。

6. 分散的資料管理

分散的資料管理十分符合微服務最初的定義，服務間是獨立運作的，每個服務都可以擁有自己獨立的存儲。當然，關于去中心化資料管理，業界也有很多解決方案，如模型概念上的不同，可以抽象出不同的視圖，可以使用領域驅動設計的方式（後面章節會介紹）将複雜的領域劃分成不同的限界上下文，這有助于澄清業務邊界，強化資料模型上的分離。

微服務除在概念模型上的分散政策之外，還分散了資料的存儲決策，讓每個服務管理自己的資料庫，可以是相同的資料庫技術的不同實作，也可以是完全不同的資料庫系統。人們把這種方式稱為“Polyglot Persistence”（多語言持久化）。

當然，這種做法也會帶來一些弊端，如分布式事務等問題，往往需要通過額外的工作來保證事務的最終一緻性，但是這絲毫不會阻礙其在微服務架構中的應用，微服務團隊往往把這個問題的解決寄希望于服務拆分的合理性上。

7. 基礎設施自動化

微服務由于小和分離的特點，往往一個大型複雜的項目運作需要部署很多服務，如果都是人工手動來完成這項工作，那麼無疑将會耗費巨大的成本，而且人工容易出錯，一旦出錯，排查會十分費力，好在基礎設施自動化技術在過去幾年中發生了巨大的變化，特别是雲技術、Docker和K8s等技術的發展，大大降低了建構、部署和運作軟體的成本。各種持續內建和持久傳遞的工具層出不窮，而微服務架構中就需要這樣的服務或技術工具來保證服務的建構、部署和測試等工作可以做到自動化。

8. 容錯設計

使用服務作為元件的結果就是需要設計的應用程式能夠容忍服務的失敗。由于服務提供者不可用，任務服務消費者調用此服務時都可能失敗，是以服務消費者必須盡可能優雅地對此做出響應。

單體式架構在這方面似乎有一定的優勢，由于都是本地函數調用，它無須引入額外的複雜代碼就可達到優雅響應的目的，但任何事情都有其多面性，單體式架構的優點是系統複雜度降低了，但缺點也是毋庸置疑的。也就是說，如果服務不可用，可能會影響整個應用，緻使其他無關的功能都不可用。

是以，微服務架構中一般最基本的做法是針對每個服務都進行彈性的監控和日志記錄，這樣能夠保證在服務出現故障時快速地監控并加以恢複。有關斷路器、目前吞吐量和延遲的資訊監控等其他方式，在後續的章節中詳細介紹。

9. 演進式設計

現在已經知道了很多微服設計的關鍵因素，不難看出，要設計一個完美的微服務架構，尤其是對于沒有足夠經驗的團隊來說，無疑是很難的。但從軟體設計的思路來看，沒有設計從一開始就是完美的。

是以，很多情況下，微服務從業者都會以演進的方式進行系統的設計，筆者在工作中也常被項目的業務分析師問道：為什麼我看你們總在重構，就不能一開始寫代碼時把結構設計好嗎？這時，筆者反而覺得這是軟體設計好的表現，然後很耐心地和他解釋軟體設計的思路就是這樣的。人們稱其為演進式設計。

當然，重構也是需要條件的，開發人員應該能夠控制應用程式的更改，而且不會降低變更速度。變更控制并不一定意味着改變，但可以通過正确的态度和工具，如單元測試、契約測試等，對軟體進行頻繁、快速和良好控制的更改。

微服務架構的優勢

綜上所述，微服務不是SOA，它能直擊單體式架構的痛點，在比較其他架構之後，了解到了微服務的九大特性，那麼，在實際應用過程中，微服務到底能帶給人們哪些便利呢？與其他架構比較，它的優勢究竟是什麼呢？

當然，一個流程的架構模式必然是有很多優勢的，要列舉全部的微服務架構的優勢不太現實，在這裡列舉微服架構的幾個強大優勢，強大到各大公司，如亞馬遜、Netflix、eBay，包括國内的某些大公司都開始轉型。

（1）微服務架構的一個重要優勢在于可以做到故障隔離，應用程式可以不受單個子產品故障的影響，這是軟體工程尤為重要的一點，微服務是松散耦合的，各個部署單元都是獨立的，加上服務監控及熔斷的機制，可以輕松地保證一個系統的健壯性。無論是運作還是部署，各個服務都可以做到完全獨立。

（2）微服務架構消除了項目需要長期保持單個技術棧的狀況，微服務的分散式設計本身就鼓勵開發者在不同的場景和需求下使用最合适的技術，而且服務本身運作的獨立性和通信的輕便性也保證了開發者在做技術選型時不會受到太多的限制。

（3）微服務架構使新開發人員更容易上手，微服務架的複雜性是本地化的，服務前較低的依賴可以讓開發人員不用過多地關注服務之外的邏輯，而隻關注本地服務的業務，再加上服務本身小巧的特性，單個微服務的業務不會特别複雜，新開發人員很容易就能上手，對項目整體而言，也可以通過對各個服務的熟悉，來逐漸了解整個系統的全貌。

（4）微服務架構除了在技術上能帶來諸多好處，在企業的組織結構上也能起到優化作用。微服務架構通常是圍繞着業務進行設計的，那麼它的團隊也常常圍繞業務的價值和優先級進行配置，進而使團隊組建者能夠完全專注于所配置設定服務的特定擴充和可用性要求。是以，團隊往往是全能的、高效的，同時也是跨職能的。這樣的團隊也帶來了外包的靈活性，雖然許多企業主希望能夠将工作轉交給第三方合作夥伴，但他們常常擔心自己的知識産權，微服務架構則可以滿足企業在不披露其核心服務的情況下，将其與非核心業務功能外包的工作分割開來。

這些令人印象深刻的優勢使微服務看起來非常誘人，那麼微服務架構就是我們要找的完美架構了？當然不是，與前文所說一樣，并不是每個問題都是釘子，不是每個解決方案都是錘子，微服務架構自然也有其缺點，而微服務架構的優勢也并不是每個項目都能發揮出來的，可能還取決于具體項目技術群組織等各種内在和外在的因素。

微服務的挑戰

僅僅是因為某些事情在整個行業風靡一時，并不意味着它沒有任何缺點。相反，站在風口浪尖，微服務所面臨的挑戰也不會小。微服務就是為了應付那些大而複雜的項目而誕生的，是以往往面對的問題都不會太簡單，而且似乎很多團隊在做微服務轉型時都遇到了不少困難，其中不乏一些很有經驗、很成熟的團隊。

那麼，使用微服務究竟有哪些難點呢？微服務本身又有哪些缺點呢？

使用微服務的難點

要評價一個軟體架構或技術架構的缺點，筆者認為最直接的就是看這個架構或技術是否好用，使用過程中的難點就代表着這個架構或技術架構的缺點。微服務也應該如此，微服務在使用過程中的難點如圖1.9所示。

1. 分布式系統可能很複雜

微服務的架構設計導緻了它一定是分布式的，是以分布式系統的難點，幾乎微服務全都有。由于一切都是元件化的，而且各個服務都是獨立的，是以必須仔細處理子產品之間的請求，為了保證系統的健壯性，需要專門額外的代碼去監控服務的健康狀态，記錄和收集各種日志，否則當遠端呼叫中斷或延遲時，事情會變得更加複雜。

2. 事務管理可能很痛苦

微服務具有分散的資料管理特性，服務不僅可以擁有獨立的資料存儲，而且可以使用不同的技術實作。這就導緻了如果需要做到事務的一緻性将變得非常困難，當然困難還是有辦法解決的，如現在比較流行的分布式事務最終一緻性的解決方案等，也有不少的開源架構來做這件事。但是這無疑給系統實作增加了相當的複雜度，而且針對這些複雜度而産生的工作可能對使用者來講，并沒有直接的業務價值。

3. 微服務的測試可能很麻煩

與單體式架構比較，微服務的測試可能很複雜，單體式架構往往是一些外部元件依賴，如資料庫，而一個微服務架構的系統，往往一個完成的業務功能測試需要依賴多個服務組合共同完成，而且服務之前可能會存在調用順序的依賴，在某一個時間點上，同一個微服務可能具有多個版本，這無疑又增加了測試和調試的成本。

4. 運維部署要求較高

由于系統被拆分為多個服務，部署時需要了解服務整體的關聯關系，工程師除需要使用和搭建自動化技術來進行服務部署之外，還需要對整個系統進行有效的監控。是以，DevOps的角色是必需的，而很多企業或項目，一個全職的DevOps無疑是奢侈的。

5. 通信成本較高

微服務都采用遠端的方式進行調研，通常會采用輕量級的HTTP協定或消息機制進行通信，是以可能在規模不大時與本地函數調用的差別不會很大，但随着項目時間的推移，系統規模的擴大，服務間的調用越來越頻繁，獲得單個業務結果的調用鍊越來越長，這時通信成本的消耗将是可怕的。

微服務不是銀彈

綜上所述，微服務并不是萬能的，它會有各式各樣的問題，隻不過目前我們尚能接受，或者說它帶給我們的好處遠大于這些缺點。而且，這些問題并不是沒有解決方案，畢竟有些問題可能在其他架構中仍然存在。

例如，部署難度大，我們可以使用一些易用的平台或工具，來幫助快速地搭建自動部署的流水線，如Jenkins、PaaS平台等技術；又如，難以測試多版本的問題，可以通過WireMock等技術消除依賴，把測試做到盡可能的單元，然後建立良好的契約測試規範，保證不同版本的相容測試；再如，分布式事務，如二段送出、補償事務、最終一緻性等方案也都比較成熟；此外，還有服務監控和容錯及日志記錄等，Spring Cloud提供了相應全面的架構來實作這些功能，這些方案和技術都會在後續章節中介紹。

當然，即使解決了這些問題，微服務仍然不能作為一個銀彈，畢竟軟體工程本就沒有銀彈，甚至有人認為微服務并不能代表軟體架構在未來的發展方向。我們也無法評估現在的微服務架構是否成熟，但這絲毫不會阻止勇敢的程式員探索和追求真理的步伐。

我們希望微服務變得越來越成熟，就如同希望自己的系統元件化做得越來越好一樣，至少目前看來，微服務是一條值得走的路，雖然我們無法确定這條路最終會走到哪裡，但是對事物本質和真理的探索及追求技術卓越的腳步永遠不會停下。

覺得文章不錯的朋友可以轉發此文關注小編，有需要的可以掃下方二維碼擷取資料~

感謝大家的支援！