使用微服務架構方案能解決企業面臨的很多挑戰，而且目前微服務架構的框架都比較成熟，例如Spring cloud或者dubbo在各大互聯網平臺都有成功案例，但看似簡單的框架在實際開發過程中會面臨很多問題。本文整理了企業從單體架構向微服務架構轉型的中的設計難點問題。

[[327745]]

整理者：潘志偉，某金融企業，擁有十多年從業經驗，精通微服務架構，精通大數據，擁有億級用戶平臺架構經驗，萬級并發的API網關經驗。還有以下專家分享：顧黃亮 蘇寧消費金融有限公司 技術總監、zhuqibs Mcd 軟件開發工程師 等

問題一：企業從單體架構往微服務架構轉型怎么啟動?

這是大家比較關注的問題，企業打算轉型微服務，但是真正的實施后發現又很難。其實微服務架構轉型不僅僅是一門技術活，更主要的的是組織結構和技術轉型的結合，其中組織機構轉型是起步的首要條件，包括統一思路和充分培訓。

(1) 思想統一

當準備要實施微服務的時候首要條件就是獲得高層的認可，因為涉及到組織結構的調整以及后續人力資源的增補，比如在單體應用中其組織機構包括開發部、測試部、運維部、DBA部，每個部門各司其職由高層統一指揮，看似很非常合理的組織結構，但是在項目或者迭代實際過程中會花費大量的時間去跨部門溝通，形成了孤島式功能團隊。

但是在實施微服務的時候，希望能協同配合快速交付，如果還是需要多次跨部門協調處理問題的話，那么“微”很難實現“微”的好處，微服務的團隊應該是如下所示，所以如果沒有高層參與那么組織架構就不會調整。

(2) 充分培訓

微服務開發關注點：微服務架構的開發人員具備“精”、“氣”、“神”的特質，否則在后續發展階段一定會出現各種難題。“精”是指熟悉業務，熟悉選型的開發框架，“氣”是指大家的思想認知一致，能夠在一個頻道上對話，“神”是指需要了解其理論知識，明白為什么需要這樣而不是那樣。微服務在開發設計過程中需要關注以下點：

一份基準代碼多份部署(deploy)：程序部署需要做到和環境無關，不需要改動任何一行代碼，如圖2-3

顯式聲明依賴關系:通過依賴清單 ，確切地聲明所有依賴項(例如MAVEN 依賴)，新進開發者簡化了環境配置流程“做產品”而不是“做項目”

在環境中存儲配置:所要求的代碼和配置嚴格分離，配置可以完全不一樣，但是代碼必須是一樣的，配置和代碼無關“去中心化”地治理技術

把后端服務當作資源:后端服務是指程序運行所需要的通過網絡調用的各種服務如數據庫，MQ，緩存等。例如在不進行任何代碼改動的情況下，將MySQL 數據庫換成第三方服務

嚴格分離構建和運行：構建階段是指將代碼倉庫轉化為可執行包的過程，發布階段會將構建的結果和當前部署所需配置相結合，并能夠立刻在運行環境中投入使用，如回滾，運行階段是指針對選定的發布版本，在執行環境中啟動一系列應用程序進程

無狀態進程運行應用：運行環境中，應用程序通常是以一個和多個 進程 運行的，任何需要持久化的數據都要存儲在 后端服務內，比如數據庫

問題二：微服務中所謂的服務到底如何拆分，服務拆分到什么粒度算好的服務?

在談服務拆分之前首先給服務做個定義：服務是分布式架構下的基礎單元，包含了一組特定的功能。微服務拆分的方式沒有明確標準，可謂說是千人千面，每個人對于服務拆分理解程度和拆分尺度都不一樣，有的團隊按每個接口一個服務。一般來說我們在拆分的時候會結合理論知識和拆分原則來綜合考慮：

1) 微服務拆分的理論指導

- 團隊規模大小

一般來說5-7個人一個小組比較合適，因為溝通效率和團隊可擴展性都能得到保障。如果一個團隊人數過少的話，本來應該是多人開發的服務最后由1-2人來開發，會導致本來設計好的服務拆分邏輯最后卻都合并在一個工程上做開發了，失去了微服務的意義。

- 項目交付周期

盡可能縮短項目交付周期短，把頻繁需求變更的功能盡量獨立成單獨的服務，保證快速的迭代，還能滿足快速上線的需求，縮短了項目交付周期，同時還能做到隨時回滾，風險變小，從而提高系統穩定性。

- 變更影響范圍

一個業務迭代功能點，盡量不要分布到多個微服務中，盡量將關聯的實體對象存于一個微服務，避免分布式事務，比如把20%經常變動的部分進行抽離，80%不經常變動的單獨部署和管理。

- 吞吐量大小

頻繁訪問，吞吐量大的服務，盡量獨立微服務，方便擴容, 能夠有效地提高資源利用率。

2) 服務拆分原則

- 高內聚低耦合

高內聚低耦合是軟件工程中的概念，在軟件設計中通常用耦合度和內聚度作為衡量模塊獨立程度的標準。但是在微服務拆分中同樣適用，服務拆分的一個準則是高內聚低耦合。從功能粒度來看，高內聚即每個服務盡可能只完成一件事(最大限度的聚合);低耦合即減少外部服務依賴，盡量避免服務再調用服務。從數據庫角度來看每個服務單獨使用獨立的數據庫，外部如果需要使用數據必須通過接口調用。

- 以業務模型切入

有了高內聚低耦合的前提，那么可以通過業務線來做拆分，比如用戶、商品、訂單、評論都拆分為獨立的服務。把相關的業務都聚合在同一個服務中，這樣也避免了跨庫所帶來數據一致性的問題。有可能以業務模型切入的方式初期階段會比較粗，但是可以通過后續的迭代頻率和吞吐量大小的指標再來衡量是否需要繼續拆分。

問題三：分布式事務怎么解決?

一旦完成服務拆分，就會涉及到分布式事務，在談數據一致性要求的時候有2個非常重要的理論即CAP定理和Base理論：

CAP定理：C表示一致性，也就是所有用戶看到的數據是一樣的，A表示可用性，是指總能找到一個可用的數據副本，P表示分區容錯性，能夠容忍網絡中斷等故障。

BASE理論：BA指的是基本業務可用性，支持分區失敗，當分布式系統出現故障的時候，允許損失一部分可用性，例如在電商大促的時候，對一些非核心鏈路的功能進行降級處理來提高系統的可用性，S表示柔性狀態，允許系統存在中間狀態，這個中間狀態不會影響系統整體可用性。比如，數據庫讀寫分離，寫庫同步到讀庫(主庫同步到從庫)會有一個延時，E表示最終一致性，數據最終是一致的，例如主從同步雖然有短暫的數據不一致情況，但是最終數據還是一致的。

在實際中可以通過本地事務和發送MQ消息這種柔性事務方式來解決分布式事物所面臨的問題，既能保障服務的穩定性又能保障調用效率的高效性，針對MQ可以使用Apache的RocketMQ所提供的事物消息和本地事物表結合。

問題四：微服務框架選型?

在選擇微服務架構框架的時候，都在討論目前主流的微服務框架Dubbo以及Spring Cloud。Dubbo出生于阿里系，是阿里巴巴服務化治理的核心框架，并被廣泛應用于中國各互聯網公司，只需要通過spring配置的方式即可完成服務化，對于應用無入侵。設計的目的還是服務于自身的業務為主。Spring Cloud 是大名鼎鼎的 Spring 家族的產品， 專注于企業級開源框架的研發。Spring Cloud 自從發展到現在，仍然在不斷的高速發展，幾乎考慮了服務治理的方方面面，開發起來非常的便利和簡單。

這2種開發框架各巨頭互聯網公司都有深度使用，所以選擇任何一套框架都不會成為技術的瓶頸，關鍵還是看團隊熟悉哪種框架，選擇最擅長的，而不是去跟風。

問題五：微服務架構下網關的必要性以及在網關下做限流、熔斷、降級等操作

在談到網關的時候，首先需要確認下目前微服務的業務線有幾條，如果只有單一的業務線，那么有沒有網關意義不大。其實網關可以理解為一個反向路由，它屏蔽內部細節，為調用者提供統一入口，接收所有調用者請求，通過路由機制轉發到服務實例，同時網關也是“過濾器”集合，可以實現一系列與業務無關的橫切面功能，如安全認證、限流熔斷、日志監控。

- 網關工作原理

協議轉換 ：將不同的協議轉換成“通用協議”，然后再將通用協議轉化成本地系統能夠識別的協議 ，例如把 http 協議統一轉換為 dubbo 協議。

鏈式處理：消息從第一個插件流入，從最后一個插件流出，每個步驟的插件對經過的消息進行處理，整個過程形成了一個鏈條。優勢在于它將處理請求和處理步驟分開，每個處理的插件，只關心這個插件上需要做的處理操作，處理步驟和邏輯順序由“鏈”來完成。

異步請求：所有的請求都會通過 API 網關訪問應用服務，無論業務量如何變化，網關的吞吐量要保持穩定狀態。假如把網關的請求看成一次 IO 操作的話，處理請求的線程，從接受請求開始直到服務端返回響應，都是阻塞狀態。操作系統所能承載的線程數是有限的，如果多個線程都處在這種狀態，會導致系統緩慢。異步請求是指每個請求訪問網關的時候，會被包裝成一個事件， CPU 內核會維持一個監聽器，不斷輪詢請求事件，請求的線程不用一直等待數據的返回。它在請求完畢以后，就直接返回了。

- 網關限流、降級

網關的熔斷、降級是針對接口而言，可以選擇hystrix或者sentinel來做服務包括，一般來說需要具備以下設置：

設置錯誤率：可以設置每個服務錯誤率到達制定范圍后開始熔斷或降級;

具備人工干預：可以人工手動干預，主動觸發降級服務;

設置時間窗口：可配置化來設置熔斷或者降級觸發的統計時間窗口;

具備主動告警：當接口熔斷之后，需要主動觸發短信告知當前熔斷的接口信息;

問題六：超時時間如何設置?

微服務中存在一次接口調用涉及到多個依賴服務，每個依賴服務的耗時又不一樣，所以設置怎么樣的超時時間非常有講究，首先必須要有一刀切的態度，即每個接口的響應時間不能超過閥值(比如1秒或者2秒)，一方面提升用戶體驗，另外一方面也是增加系統的穩定性。如果調用鏈路比較深的，則需要把非必要鏈路通過發送MQ消息的方式解耦，其次通過并行調用的方式來降低系統的響應時間。總的來說超時時間一般不會超過1秒，如何優化到一秒，需要從系統的全局考慮，而不是只關注某一個點。

問題七：熔斷設計需要考慮哪些點?

在進行服務化拆分之后，系統中原有的本地調用就會變成遠程調用，這樣就引入了更多的復雜性。比如說服務A依賴于服務B，這個過程中可能會出現網絡抖動、網絡異常，服務B變得不可用或者響應慢時，也會影響到A的服務性能，甚至可能會使得服務A占滿整個線程池，導致這個應用上其它的服務也受影響，從而引發更嚴重的雪崩效應。需要針對如下幾項做了個性化配置：

Ø 錯誤率：可以設置每個服務錯誤率到達制定范圍后開始熔斷或降級;

Ø 人工干預：可以人工手動干預，主動觸發降級服務;

Ø 時間窗口：可配置化來設置熔斷或者降級觸發的統計時間窗口;

主動告警：當接口熔斷之后，需要主動觸發短信告知當前熔斷的接口信息;

目前市場上可選擇的產品例如：Hystrix或者Sentinel做服務熔斷和降級，這里推薦下 Sentinel ，不管是Dubbo還是SpringCloud 只要使用官方給定的依賴即可快速接入。

問題八：微服務架構的業務系統眾多，那么數據的一致性怎么保障，數據的隔離機制如何實現等等?

當前微服務架構的業務系統越來越多，無論是做緩存場景，還是內存數據庫場景，redis的使用非常普遍，但是每套業務系統都部署一套redis集群，相當浪費資源，而且，考慮到同城和異地的信息系統建設，費用也相當之高，是否有機制可以類似中臺一樣，建立一個統一的redis平臺，提供各種場景的服務?那么數據的一致性怎么保障，數據的隔離機制如何實現，性能如何評估等等?

答1：

(1)首先統一的redis中心是很“技術”， 因為你要一個強大的技術人員或團隊;

(2)為了保證一致性，redis cluster讀取數據是從master上讀取數據的，這樣可以保證數據的一致性，當然，性能也就差了;redis 主從模式，寫master節點，異步同步slave節點，讀從slave上讀取數據，讀性能提高了，但一致性難以保證。這也就是門德爾不可能三角中的CAP原則中，保證P的同時，CA不可能同時滿足。

(3)當然，也不是沒有解決方案，但redis作為一個緩存數據庫，并沒有做的這么復雜。現代分布式數據庫中，使用multi raft架構，最大限度的解決了這個問題----master是變化的，根據應用的不同不斷的變化，同時讀永遠從變化的master上寫入和讀取。

(4)redis也是有事物的，但只保證了一致性和隔離性，沒有原子性，一致性上面說過了。因為redis本質上是單線程的，一個一個的去執行命令。這種順序執行，隔離性是有保證的。

答2：

首選糾正下你對微服務架構的理解，在微服務架構下，要求每個原子服務的數據庫、緩存都是相互獨立的，原因是當服務所依賴的數據庫或者緩存有問題只影響它本身的服務，不影響其他服務，避免級聯問題。

其次關于你所擔心的資源浪費問題，可以考慮每個服務的調用量來設置不同的服務資源配置，目前不管是虛擬化使用docker還是云平臺所提供的redis服務，都可以做到非常低的費用。

所以，想微服務穩定，按標準的模式來，每種資源做隔離，而不是聚集在一起。

答3：

這個架構有問題，統一的redis平臺或者是集群提供服務，因此這個集群肯定是橫向擴容的，只能是cluster集群架構，所以從一致性、數據隔離、性能評估三個方面來分析：

1、一致性可以做到，cluster的特性可以保證數據一致性

2、數據隔離做不到， 單機支持多個數據庫，并且每個數據庫的數據是隔離的不能共享。cluster就沒有數據庫的概念，不支持多數據庫。

3、性能評估取決于承載業務的訪問量。

問題九：接口拆分多個微服務后帶來的接口響應慢，怎么辦?

答1：

理論上不會有慢的現象，可從以下方面查 ：

(1)使用skywalking或其他APM監控軟件，定位問題，哪種服務慢;

(2)查看慢的服務所屬容器的cpu和內存配置，以及在運行時的cpu和內存負載;

(3)如果cpu和內存占用很大，需要進一步拆分應用;

(4)檢查是否有串行的微服務，此類微服務不適合拆分 。

答2：

這個問題應該是拆分之前沒有做好規劃

1、拆分以后鏈路會變長，服務之間的通信、交互、處理會耗時間，這是正常的現象，但不至于造成性能陡降 ;

2、拆分原則有幾個，輕重、快慢、讀寫、多少 ;

3、如果慢，通過鏈路監控看慢在哪里，然后進行擴容、包括微服務組件擴容，優化 。

答3：

一個應用功能被拆分成多個服務之后，原本調用一個接口就能完成的功能如今變成需要調用多個服務，如果按順序逐個調用的話，使用微服務改造后的接口會比原始接口響應時間更長，因此要把原本串行調用的服務修改為并行調用。例如接口 A ，需要調用 S1 (耗時 200 毫秒)， S2 (耗時 180 毫秒)， S3 (耗時 320 毫秒)這 3 個接口，使用串行調用方式，那么接口 A 累計耗時 =SUM(S1+S2+S3)=700 毫秒。為了讓響應時間更短，就需要把這些串行調用的方式更改為并行調用的方式，并行調用方式調用接口 A 累計耗時為 MAX(S1 ， S2 ， S3)=320 毫秒。可以使用 jdk8 提供的 CompletableFuture 方法來并行執行。