基于Spring Cloud微服務架構的應用

文/李娜

早期的系統開發，都采用了單體應用模式，比如淘寶、京東、豆瓣網等，這種模式是比較適合公司創業初期的，因為比較簡單，一個工程，一個數據庫，最后整體打包發布就上線了。但隨著業務的發展，特別是系統的訪問量、數據量的急劇增加，單體應用已經無法滿足業務需求，因此將龐大的單體應用按照某種維度進行拆分，進行分布式部署，為了讓這種分布式系統更加的規范、更容易管理，便形成了各種服務化的方式和工具，從基于ESB 的SOA（面向服務）的基礎架構到當前流行的微服務架構模式，都是在不斷適應越來越復雜的應用系統。

1 微服務簡介

1.1 什么是微服務

微服務是一種新興的軟件架構模式，它把一個大型的單體應用或服務拆分為多個支持微服務。一個微服務的策略可以讓工作變得更為簡便，它可擴展單個組件而不是整個應用程序堆棧，從而滿足服務等級協議。微服務最重要的就是這個“微”字，怎樣才能成為“微服務”呢，其實沒有標準，這要根據系統的實際功能需求而定，并不是拆分得越細越好，應該在業務層面上去劃分，能夠滿足各方面的需求。

1.2 微服務的特點

1.2.1 微服務的優勢

1.2.1.1 單個服務容易開發和維護

相比傳統的單體應用，單個微服務的功能更加單一，只關注特定的功能實現，因此，在開發和維護上不需要多方的協調以及冗長的業務流程。

1.2.1.2 服務可以獨立部署和擴展

微服務的開發、部署和維護都是相對獨立的，互不干擾，服務之間通過標準的接口進行交互，可以很方便的對服務進行擴容。

1.2.1.3 可以由不同的團隊來開發

在微服務的整體架構上，通常都是按照業務進行服務劃分，可以由不同的團隊進行開發，服務間通過接口進行交互。

1.2.1.4 服務開發技術的選項更加靈活

每個服務的技術選型都可以由相應的團隊決定，可以嘗試各種最新技術，更加的靈活。

1.2.2 微服務的不足

1.2.2.1 管理微服務是一件麻煩的事情

單個服務的開發和維護相對來說是很容易的，但從整個系統上看，這是一件很麻煩的事情，因為系統從單體變成了分布式，多個服務分布在不同的服務器中，需要完善的服務監控和管理的能力。

1.2.2.2 來自分區數據庫帶來的實現問題

每一個服務都有自己的數據庫，這樣才能達到真正系統微服務化的目的。由此會帶來一個最為突出的問題就是分布式事務，實現上可以選擇按照ACID 的強一致性或者基于BASE理論的最終一致性。

1.2.2.3 服務間調用的成本更高

由于服務都是分布式部署，服務之間的調用相比傳統的本地方法調用，需要更大的成本，調用過程中還會遇到安全、網絡抖動等外在的問題。

2 微服務的實現方式

微服務并不是一種技術或者框架，而是一種設計理念或者架構模式，它基于模塊化、組件化等架構思想。微服務的實現方式，目前主要有兩種，一種是基于RPC 的方式，另一種是基于HTTP 的Restful 方式，這兩種實現方式各有利弊，可以選擇其中的一種，也可以將兩種結合起來使用。在實際應用中，系統內部服務之間的調用通過RPC 方式，可以滿足對性能方面的需求；面向客戶端以及對外的服務輸出采用Restful 方式，一是調用簡單，二是更加標準，降低調用成本。

3 Spring-Cloud的技術架構

Spring Cloud 是一種基于Spring Boot 的微服務框架，它實現了微服務架構中常用的組件，目前比較常用的組件是基于Netflix 對多個開源組件的封裝，為微服務架構開發涉及的配置管理、服務治理、熔斷機制、智能路由、微代理、控制總線、一次性token、全局一致性鎖、leader 選舉、分布式session、集群狀態管理等操作提供了一種簡單的開發方式，spring-cloud的基礎架構如圖1所示。

3.1 網關

接受外部對服務接口的訪問，屏蔽底層服務的具體實現，提供權限、認證、安全、監控、限流等基礎服務，常見的有Zuul、springcloud-gateway。

3.2 Ribbon

Spring-Cloud-Ribbon 是基于HTTP 和TCP 的客戶端負載均衡工具，它基于Netflix Ribbon 實現，可以輕松地將面向服務的REST模版請求自動轉換成客戶端負載均衡的服務調用。

3.3 Eureka

Spring-Cloud-Eureka 是 對Netflix Eureka的封裝以實現服務發現功能，它包含了Server端和Client 端。Eureka Server 提供服務注冊功能，各個節點啟動后，會在Eureka Server 中進行注冊；Eureka Client 用于簡化與Eureka Server 的交互，可以方便地訪問注冊中心的服務。

圖1：Spring-cloud 基礎架構圖

3.4 Hystrix

Hystrix 是一種熔斷器，實現服務的限流、熔斷、降級等功能，可以很好的保證服務在高并發情況下的穩定性。

4 微服務應用場景

任何的架構模式都需要根據實際的業務場景而定，不能盲目的追求最新的技術，最適合的就是最好的。對于微服務而言，以下的場景或者條件是比較適合的。

系統業務量越來越大，核心業務和非核心業務變得涇渭分明，這個時候將你的業務系統拆分為細顆粒的服務進行管理，通過斷路由、降級、限流等服務管理措施保證系統高可用。

開發團隊具有足夠的實力，包括系統架構、開發、運維等方面，可以解決微服務帶來的各種問題，充分利用好微服務帶來的好處。

5 結論

綜上所述，相對于傳統的單體應用，微服務帶來了系統整體架構上的轉變，也給系統的設計和開發帶來了很多好處，但也不可避免的存在一些問題，這需要根據系統自身業務場景來選擇適合自己的架構模式。