歷時一年，我把系統升級成Spring Cloud的微服務架構

1.前言

現在研發的項目啟動今已近一年之久，期間從項目屬性、人員規模、系統定位等方面都發生了很大的變化，而且是越變越好。不過也因為此，項目最初的架構設計已經不能滿足現在的需求，並隨著時間的推移，詬病越來越多、越來越嚴重。

為了解決這一問題，開發人員也在努力的嘗試各種辦法，但總的來說之前的方式更多是在打補丁，暫時或看上去是解決問題了，實質上並沒有從本質的變化。基於這一情況，這一次我們下定決心，用一定的人力、物力去重新定義系統的架構——基於Spring Cloud實現微服務的架構。

本文簡要介紹微服務及微服務架構的概念，並描述了Spring Cloud的功能，然後基於Spring Cloud的各個組件搭建微服務的整體架構，並對升級後的系統架構進行了設計、約定和說明。

特別說明：鑑於現在的開發模式採用的是前後端分離的模式，系統問題在後端也較為嚴重，Spring Cloud也只一個後端治理的框架，所以本文主要講述的是後端微服務的架構設計，前端的架構調整等Spring Cloud雛形完成後進行組合設計。

2. 微服務簡述

2.1. 什麼是微服務

微服務（MicroService）沒有一個官方的標準定義，ThoughtWorks的首席科學家馬丁·福勒這樣說：「微服務架構是一種架構模式，它提倡將單一應用程式劃分成一組小的服務，服務之間互相協調、互相配合，為用戶提供最終價值。每個服務運行在其獨立的進程中，服務與服務間採用輕量級的通信機制互相溝通（通常是基於HTTP協議的RESTful API）。每個服務都圍繞著具體業務進行構建，並且能夠被獨立的部署到生產環境、類生產環境等。另外，應當儘量避免統一的、集中式的服務管理機制，對具體的一個服務而言，應根據業務上下文，選擇合適的語言、工具對其進行構建。」

1.2. 微服務架構優勢

1 複雜度可控

在將應用分解的同時，規避了原本複雜度無止境的積累。每一個微服務專注於單一功能，並通過定義良好的接口清晰表述服務邊界。

由於體積小、複雜度低，每個微服務可由一個小規模開發團隊完全掌控，易於保持高可維護性和開發效率。

2 獨立部署

由於微服務具備獨立的運行進程，所以每個微服務也可以獨立部署。當某個微服務發生變更時無需編譯、部署整個應用。

由微服務組成的應用相當於具備一系列可並行的發布流程，使得發布更加高效，同時降低對生產環境所造成的風險，最終縮短應用交付周期。

3 技術選型靈活

微服務架構下，技術選型是去中心化的。每個團隊可以根據自身服務的需求和行業發展的現狀，自由選擇最適合的技術棧。

由於每個微服務相對簡單，所以需要對技術棧進行升級時所面臨的風險就較低，甚至完全重構一個微服務也是可行的。

4 容錯

當某一組件發生故障時，在單一進程的傳統架構下，故障很有可能在進程內擴散，形成應用全局性的不可用。

在微服務架構下，故障會被隔離在單個服務中。若設計良好，其他服務可通過重試、平穩退化等機制實現應用層面的容錯。

5 擴展

單塊架構應用也可以實現橫向擴展，就是將整個應用完整的複製到不同的節點。當應用的不同組件在擴展需求上存在差異時，微服務架構便體現出其靈活性，因為每個服務可以根據實際需求獨立進行擴展。

簡單來說，微服務是基於單體應用的新型架構模式，可以基於微服務更好的進行自動化測試、運維、監控，從而滿足持續交付，最終實現高質量的用戶價值。

1.3. 微服務 VS 當前開發

微服務的開發模式和傳統開發模式有著很大的不同，大致有以下幾點：

• 分工不同 ：現在一個組負責一個系統，一個人負責系統的一部分；微服務後可能是一人負責一個或多個系統。
• 架構不同：現在更多的從模塊上拆分、前後端上拆分開發；微服務後將同時從橫向縱向上拆分。
• 部署方式不同：現在是手工和半自動發布；微服務後得自動化運維。
• 容災不同：現在的系統是一個整體，並且是單點運行；微服務後可以多點負載，還可以隔離故障避免系統整體宕機。
• 團隊結構不同 2 pizza（6~10人）的小團隊

分權機制 聯邦分權制 -- 對結果負責 職能分權制 -- 對行為負責

2. 技術選型

2.1. Dubbo

Dubbo是Alibaba開源的分布式服務框架，它最大的特點是按照分層的方式來架構，使用這種方式可以使各個層之間解耦合（或者最大限度地鬆耦合）。從服務模型的角度來看，Dubbo採用的是一種非常簡單的模型，要麼是提供方提供服務，要麼是消費方消費服務，所以基於這一點可以抽象出服務提供方（Provider）和服務消費方（Consumer）兩個角色。

Dubbo服務的官方更新非常不確定，2014年10月30日停止更新後，最近幾個月低調開始維護，發布了5個優化版本。

2.2. 為什麼選擇Spring Cloud

Spring Cloud是一系列框架的有序集合。它利用Spring Boot的開發便利性巧妙地簡化了分布式系統基礎設施的開發，如服務發現註冊、配置中心、消息總線、負載均衡、斷路器、數據監控等，都可以用Spring Boot的開發風格做到一鍵啟動和部署。

Spring Cloud的開發團隊專注於企業級開源框架的研發，不論是在中國還是在世界上使用都非常廣泛，開發出通用、開源、穩健的開源框架是他們的主業。

Spring Cloud是微服務架構的生態環境，考慮到了微服務的各個方面，不像阿里的Dubbo 框架只是專注於服務之間的治理。

Spring Cloud的社區熱度非常好，問題修復也非常及時，未來會更加完善和穩定。

Spring Cloud也可以較好的兼容python、php等其他語言開發的微服務。因為採用RESTful。

Spring Cloud與Docker可以完美組合使用。

Spring Cloud 英文官網：http://projects.spring.io/spring-cloud/Spring Cloud 中文文檔：https://springcloud.cc/

2.3. Spring Boot的特性

Spring Boot是一個簡化Spring使用的框架，可以使用少量的配置快速創建一個基於Spring的項目。Spring Boot主要有如下核心功能：

• 獨立運行的Spring項目：Spring Boot可以以jar包的形式來運行，運行一個Spring Boot項目我們只需要通過java -jar xx.jar類運行。
• 內嵌Servlet容器：Spring Boot可以內嵌Tomcat，這樣我們無需以war包的形式部署項目。
• 提供starter簡化Maven配置：使用Spring或者SpringMVC我們需要添加大量的依賴，而這些依賴很多都是固定的，這裡Spring Boot 通過starter能夠幫助我們簡化Maven配置。
• 自動配置Spring
• 提供生產就緒型功能，如指標，健康檢查和外部配置
• 無代碼生成和xml配置

3. 我們微服務架構約定

3.1. 技術棧

程式語言：Kotlin、JAVA、Python、PHP、SQL 構建工具：Gradle、Maven 資料庫：MySQL、MongoDB、SQL Server 緩存：Redis 消息隊列：RabbitMQ IDE：IntelliJ IDEA、Eclipse 服務部署：Linux、Docker、Jenkins、Ansible 微服務框架：Spring Cloud 後端開發框架：Spring Boot 前端開發框架：VUE

3.2. Spring Cloud基礎服務選型

• 配置：Spring Cloud Config，統一配置管理
• 總線：Spring Cloud Bus，可與Spring Cloud Config聯合實現熱部署
• 發現：Eureka，微服務的註冊與發現
• 容錯：Hystrix，斷路器
• 網關：Zuul，提供動態路由,監控,彈性,安全等邊緣服務的框架
• 負載：Ribbon，有多種負載均衡策略可供選擇
• 調用：Feign，一種聲明式、模板化的HTTP客戶端
• 跟蹤：Spring Cloud Sleuth， 日誌收集工具包
• 會話：Spring-Session

3.3. 工具版本約定

名稱版本備註Spring Boot2.0.0.M6-Spirng CloudFinchley.M4-Kotlin1.2需保持最新JAVA1.8.0_151—Gradle4.4.1保持更新Maven3.5.2-MySQL5.7.17-MongoDB3.6-PHP7.2.0—Python3.6.4—Redis4.0.1-Docker17.09-Jenkins2.89.2-CentOS7.4-SQL Server2008歷史系統Ansible2.3.3.0-1-Tomcat8.5.24-

3.4 微服務設計原則

• 單一職責：每個服務都很小，且專注於做一件事情，並且把它做好。至於要多小，有人喜歡100行以內，有人贊成1000行以內，數字並不是最重要的，只要團隊覺得合適就好。
• 輕量通訊服務和服務之間通過輕量級的機制實現彼此間的通信。所謂輕量級通信機制，通常指基於語言無關、平臺無關的這類協議，例如XML、JSON，而不是傳統我們熟知的Java RMI或者.Net Remoting等。
• 獨立部署每個服務都運行在一個獨立的作業系統進程中，這意味著不同的服務能被部署到不同的主機上。
• 康威定律請讀：https://yq.aliyun.com/articles/8611將1968年由梅爾.康威提出:產品反映了製造該產品的組織結構。

第一定律：Communication dictates design. 組織溝通方式會通過系統設計表達出來。

第二定律：There is never enough time to do something right, but there is always enough time to do it over. 時間再多一件事情也不可能做的完美，但總有時間做完一件事情。

第三定律：There is a homomorphism from the linear graph of a system to the linear graph of its design organization. 線型系統和線型組織架構間有潛在的異質同態特性。

第四定律：The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems. 大的系統組織總是比小系統更傾向於分解。

3.5 微服務拆分

微服務的拆分是個複雜問題，簡單來說需要從橫向和縱向多刀去拆。

3.5.1 橫向拆分

按照不同的業務域進行拆分，例如訂單、營銷、風控、積分資源等，形成獨立的業務領域微服務集群。

• 用戶：
• 訂單：
• 評論：
• 組織：
• 商品：
• 交易：
• 搜索：
• 營銷：
• 消費者信息：
• 消費者分布：
• 消費者畫像：
• 積分：
• 訂貨：
• 帳戶：

3.5.2 縱向拆分

把一個業務功能裡的不同模塊或者組件進行拆分。例如把公共組件拆分成獨立的原子服務，下沉到底層，形成相對獨立的原子服務層。這樣一縱一橫，就可以實現業務的服務化拆分。

• 簡訊：簡訊發送、記錄、均衡、防漏、模板配置
• 文件：文件上傳、縮略、下載、打包、資料庫記錄
• 微信：
• 日誌：
• 支付：
• 快遞：快遞查詢、狀態訂閱
• 地圖：地址經緯度互轉、距離計算、線路推薦
• 計劃任務：統一的計劃任務配置及調度
• 微信公眾號配置：
• 微信自動回覆：

3.6 架構升級步驟

1. 獨立構建微服務框架，將現有系統的核心功能分離出來做成基礎微服務。如簡訊模板消息發送、微信模板消息發送、文件上傳下載等；
2. 利用這些基礎微服務，解耦現有系統，修改其調用關係和依賴方式；
3. 通過不斷的微服務化，逐漸將現有系統分解成多個獨立的微服務；
4. 廢棄現有的系統，使用全新構建的微服務來替代。

3.7. 微服務總體架構圖

構建一套完整的微服務架構需要考慮許多問題，包括API Gateway、服務間調用、服務發現、服務容錯、服務部署、數據調用等。基於SpringCloud構建微服務架構可以通過自動配置和綁定Spring環境和其他Spring編程模型來實現微服務。採用Spring Boot應用程式提供的集成功能，通過幾個簡單的注釋，開發人員可以快速配置和啟用應用程式中的常見功能模塊，並使用久經考驗的Netflix組件構建大型分布式系統。提供的微服務功能模塊包括服務發現（Eureka），斷路器（Hystrix），智能路由（Zuul）和客戶端負載均衡（Ribbon）等。圖2顯示了採用Spring Cloud系列平臺構建的微服務整體架構。

基於Spring Cloud系統的微服務架構平臺

服務發現是microservice基礎架構的關鍵原則之一。服務註冊中心採用Spring CloudNetflix的項目可以自動註冊服務，也可以通過HTTP接口手動註冊。默認情況下，Eureka使用客戶端心跳來確定一個客戶端是否活著。也可以另指定DiscoveryClient來傳播當前SpringBoot Actuator的應用性能的健康檢查狀態。

統一的接入服務接口採用Spring Cloud的Zuul組件，實現內外有別的微服務調用。該組件也實現了服務路由功能。採用Spring Cloud Netflix來實現服務的限流和降級。

為實現服務的高可用，保證服務的容錯和負載均衡，本平臺可採用客戶端負載均衡（Ribbon）來實現。

Spring Cloud Netflix的Hystrix熔斷器組件，具有容錯管理工具，旨在通過熔斷機制控制服務和第三方庫的節點，從而對延遲和故障提供更強大的容錯能力。為保證核心服務的穩定性，可採用Spring Cloud Netflix的Hystrix組件來實現服務的服務的容錯、限流和降級等功能。

微服務的安全控制和權限驗證可採用Spring CloudSecurity來實現。對於RESTful，可採用Spring Cloud的Feign 組件，這是一個聲明Web服務客戶端。這使得編寫web服務客戶端更容易，使用Feign 創建一個接口並對它進行註解，它具有可插拔的註解支持包括Feign註解與JAX-RS註解，Feign還支持可插拔的編碼器與解碼器

4. 微服務帶來的新問題

• 一個服務拆成多大才合適？
• 多個微服務能否共享資料庫？每個微服務都有自己獨立的資料庫，那麼後臺管理的聯合查詢怎麼處理？這是大家普遍遇到的一個問題。有如下三種處理方案：

嚴格按照微服務的劃分來做，微服務相互獨立，各微服務資料庫也獨立，後臺需要展示數據時，調用各微服務的接口來獲取對應的數據，再進行數據處理後展示出來，這是標準的用法，也是最麻煩的用法。將業務相關的表放到一個庫中，將業務無關的表嚴格按照微服務模式來拆分，這樣既可以使用微服務，也避免了資料庫各種切換導致後臺統計難以實現，是一個折中的方案。資料庫嚴格按照微服務的要求來切分，以滿足業務高並發，實時或者準實時將各微服務資料庫數據同步到 NoSQL 資料庫中，在同步的過程中進行數據清洗，用來滿足後臺業務系統的使用，推薦使用 Mongodb、Hbase 等。三種方案在不同的公司我都使用過，第一種方案適合業務較為簡單的小公司；第二種方案，適合想在原有系統之上，慢慢演化為微服務架構的公司；第三種適合大型高並發的網際網路公司。

• 如何與現有系統結合使用、並行開發、最終替代？
• 如何避免開發人員瞎子摸象、管中窺豹？
• 服務調用流，服務編排如何使用？
• 自動化運維的新挑戰？

5. 結束語

微服務架構不是絕對的好，它有一定的使用場景，也有一定的落地難度。結合我們目前的情景和未來的發展來說，微服務架構是適合我們的，並且能夠解決很多現有系統的詬病，但是落地的難度也是比較大的，特別是要結合已有的各個系統進行使用。Spring Cloud作為穩定的微服務的一站式解決方案，能快速高效地搭建微服務架構，並且能夠結合多語言開發，這個正是我們所需要的。從今天開始，微服務的架構升級正式開始，一部分人直接開始參與，一部分人員間接來參與，但最終我們所有人都會在一個統一的架構上進行持續交付，從而更大的實現用戶價值