首先微服務並沒有一個官方的定義，想要直接描述微服務比較困難，我們可以通過對比傳統WEB應用，來理解什麼是微服務。

傳統的WEB應用核心分為業務邏輯、介面卡以及API或通過UI訪問的WEB介面。業務邏輯定義業務流程、業務規則以及領域實體。介面卡包括資料庫訪問元件、訊息元件以及訪問介面等。一個打車軟體的架構圖如下：

儘管也是遵循模組化開發，但最終它們會打包並部署為單體式應用。例如Java應用程式會被打包成WAR，部署在Tomcat或者Jetty上。

這種單體應用比較適合於小專案，優點是：

• 開發簡單直接，集中式管理
• 基本不會重複開發
• 功能都在本地，沒有分散式的管理開銷和呼叫開銷

當然它的缺點也十分明顯，特別對於網際網路公司來說：

• 開發效率低：所有的開發在一個專案改程式碼，遞交程式碼相互等待，程式碼衝突不斷
• 程式碼維護難：程式碼功能耦合在一起，新人不知道何從下手
• 部署不靈活：構建時間長，任何小修改必須重新構建整個專案，這個過程往往很長
• 穩定性不高：一個微不足道的小問題，可以導致整個應用掛掉
• 擴充套件性不夠：無法滿足高併發情況下的業務需求

所以，現在主流的設計一般會採用微服務架構。其思路不是開發一個巨大的單體式應用，而是將應用分解為小的、互相連線的微服務。一個微服務完成某個特定功能，比如乘客管理和下單管理等。每個微服務都有自己的業務邏輯和介面卡。一些微服務還會提供API介面給其他微服務和應用客戶端使用。

比如，前面描述的系統可被分解為：

每個業務邏輯都被分解為一個微服務，微服務之間通過REST API通訊。一些微服務也會向終端使用者或客戶端開發API介面。但通常情況下，這些客戶端並不能直接訪問後臺微服務，而是通過API Gateway來傳遞請求。API Gateway一般負責服務路由、負載均衡、快取、訪問控制和鑑權等任務。

微服務架構的優點

微服務架構有很多重要的優點。首先，它解決了複雜性問題。它將單體應用分解為一組服務。雖然功能總量不變，但應用程式已被分解為可管理的模組或服務。這些服務定義了明確的RPC或訊息驅動的API邊界。微服務架構強化了應用模組化的水平，而這通過單體程式碼庫很難實現。因此，微服務開發的速度要快很多，更容易理解和維護。

其次，這種體系結構使得每個服務都可以由專注於此服務的團隊獨立開發。只要符合服務API契約，開發人員可以自由選擇開發技術。這就意味著開發人員可以採用新技術編寫或重構服務，由於服務相對較小，所以這並不會對整體應用造成太大影響。

第三，微服務架構可以使每個微服務獨立部署。開發人員無需協調對服務升級或更改的部署。這些更改可以在測試通過後立即部署。所以微服務架構也使得CI／CD成為可能。

最後，微服務架構使得每個服務都可獨立擴充套件。我們只需定義滿足服務部署要求的配置、容量、例項數量等約束條件即可。比如我們可以在EC2計算優化例項上部署CPU密集型服務，在EC2記憶體優化例項上部署記憶體資料庫服務。

微服務架構的缺點和挑戰

實際上並不存在silver bullets，微服務架構也會給我們帶來新的問題和挑戰。其中一個就和它的名字類似，微服務強調了服務大小，但實際上這並沒有一個統一的標準。業務邏輯應該按照什麼規則劃分為微服務，這本身就是一個經驗工程。有些開發者主張10-100行程式碼就應該建立一個微服務。雖然建立小型服務是微服務架構崇尚的，但要記住，微服務是達到目的的手段，而不是目標。微服務的目標是充分分解應用程式，以促進敏捷開發和持續整合部署。

微服務的另一個主要缺點是微服務的分散式特點帶來的複雜性。開發人員需要基於RPC或者訊息實現微服務之間的呼叫和通訊，而這就使得服務之間的發現、服務呼叫鏈的跟蹤和質量問題變得的相當棘手。

微服務的另一個挑戰是分割槽的資料庫體系和分散式事務。更新多個業務實體的業務交易相當普遍。這些型別的事務在單體應用中實現非常簡單，因為單體應用往往只存在一個數據庫。但在微服務架構下，不同服務可能擁有不同的資料庫。CAP原理的約束，使得我們不得不放棄傳統的強一致性，而轉而追求最終一致性，這個對開發人員來說是一個挑戰。

微服務架構對測試也帶來了很大的挑戰。傳統的單體WEB應用只需測試單一的REST API即可，而對微服務進行測試，需要啟動它依賴的所有其他服務。這種複雜性不可低估。

微服務的另一大挑戰是跨多個服務的更改。比如在傳統單體應用中，若有A、B、C三個服務需要更改，A依賴B，B依賴C。我們只需更改相應的模組，然後一次性部署即可。但是在微服務架構中，我們需要仔細規劃和協調每個服務的變更部署。我們需要先更新C，然後更新B，最後更新A。

部署基於微服務的應用也要複雜得多。單體應用可以簡單的部署在一組相同的伺服器上，然後前端使用負載均衡即可。每個應用都有相同的基礎服務地址，例如資料庫和訊息佇列。而微服務由不同的大量服務構成。每種服務可能擁有自己的配置、應用例項數量以及基礎服務地址。這裡就需要不同的配置、部署、擴充套件和監控元件。此外，我們還需要服務發現機制，以便服務可以發現與其通訊的其他服務的地址。因此，成功部署微服務應用需要開發人員有更好地部署策略和高度自動化的水平。

以上問題和挑戰可大體概括為：

• API Gateway
• 服務間呼叫
• 服務發現
• 服務容錯
• 服務部署
• 資料呼叫

幸運的是，出現了很多微服務框架，可以解決以上問題。

第一代微服務框架

Spring Cloud

Spring Cloud為開發者提供了快速構建分散式系統的通用模型的工具（包括配置管理、服務發現、熔斷器、智慧路由、微代理、控制匯流排、一次性令牌、全域性鎖、領導選舉、分散式會話、叢集狀態等）。 主要專案包括：

• Spring Cloud Config：由Git儲存庫支援的集中式外部配置管理。配置資源直接對映到Spring Environment，但是如果需要可以被非Spring應用程式使用。
• Spring Cloud Netflix：與各種Netflix OSS元件（Eureka，Hystrix，Zuul，Archaius等）整合。
• Spring Cloud Bus：用於將服務和服務例項與分散式訊息傳遞聯絡起來的事件匯流排。用於在叢集中傳播狀態更改（例如配置更改事件）。
• Spring Cloud for Cloudfoundry：將您的應用程式與Pivotal Cloudfoundry整合。提供服務發現實現，還可以輕鬆實現通過SSO和OAuth 2保護資源，還可以建立Cloudfoundry服務代理。
• Spring Cloud - Cloud Foundry Service Broker：提供構建管理一個Cloud Foundry中服務的服務代理的起點。
• Spring Cloud Cluster：領導選舉和通用狀態模型（基於ZooKeeper，Redis，Hazelcast，Consul的抽象和實現）。
• Spring Cloud Consul：結合Hashicorp Consul的服務發現和配置管理
• Spring Cloud Security：在Zuul代理中為負載平衡的OAuth 2休眠客戶端和認證頭中繼提供支援。
• Spring Cloud Sleuth：適用於Spring Cloud應用程式的分散式跟蹤，與Zipkin，HTrace和基於日誌（例如ELK）跟蹤相容。
• Spring Cloud Data Flow：針對現代執行時的可組合微服務應用程式的雲本地編排服務。易於使用的DSL，拖放式GUI和REST-API一起簡化了基於微服務的資料管道的整體編排。
• Spring Cloud Stream：輕量級事件驅動的微服務框架，可快速構建可連線到外部系統的應用程式。使用Apache Kafka或RabbitMQ在Spring Boot應用程式之間傳送和接收訊息的簡單宣告式模型。
• Spring Cloud Stream Application Starters：Spring Cloud任務應用程式啟動器是Spring Boot應用程式，可能是任何程序，包括不會永遠執行的Spring Batch作業，並且它們在有限時間的資料處理之後結束/停止。
• Spring Cloud ZooKeeper：ZooKeeper的服務發現和配置管理。
• Spring Cloud for Amazon Web Services：輕鬆整合託管的Amazon的Web Services服務。它通過使用Spring的idioms和APIs便捷整合AWS服務，例如快取或訊息API。開發人員可以圍繞託管服務，不必關心基礎架構來構建應用。
• Spring Cloud Connectors：使PaaS應用程式在各種平臺上輕鬆連線到後端服務，如資料庫和訊息代理（以前稱為“Spring Cloud”的專案）。
• Spring Cloud Starters：作為基於Spring Boot的啟動專案，降低依賴管理（在Angel.SR2後，不在作為獨立專案）。
• Spring Cloud CLI：外掛支援基於Groovy預言快速建立Spring Cloud的元件應用。

Dubbo

Dubbo是一個阿里巴巴開源出來的一個分散式服務框架，致力於提供高效能和透明化的RPC遠端服務呼叫方案，以及SOA服務治理方案。其核心部分包含：

• 遠端通訊： 提供對多種基於長連線的NIO框架抽象封裝，包括多種執行緒模型，序列化，以及“請求-響應”模式的資訊交換方式。
• 叢集容錯：提供基於介面方法的透明遠端過程呼叫，包括多協議支援，以及軟負載均衡，失敗容錯，地址路由，動態配置等叢集支援。
• 自動發現：基於註冊中心目錄服務，使服務消費方能動態的查詢服務提供方，使地址透明，使服務提供方可以平滑增加或減少機器。

但是顯而易見，無論是Dubbo還是Spring Cloud都只適用於特定的應用場景和開發環境，它們的設計目的並不是為了支援通用性和多語言性。並且它們只是Dev層的框架，缺少DevOps的整體解決方案（這正是微服務架構需要關注的）。而隨之而來的便是Service Mesh的興起。