中小型互聯網公司微服務實踐-經驗和教訓

上次寫了一篇文章叫Spring Cloud在國內中小型公司能用起來嗎?介紹了Spring Cloud是否能在中小公司使用起來，這篇文章是它的姊妹篇。其實咱們在這條路上已經走了一年多，從16年初到如今。在使用Spring Cloud以前咱們對微服務實踐是沒有太多的體會和經驗的。從最初的開源軟件雲收藏來熟悉Spring Boot，到項目中的慢慢使用，再到最後全面擁抱Spring Cloud。這篇文章就給你們介紹一下咱們使用Spring Boot/Cloud一年多的經驗。

在開始以前咱們先介紹一下幾個概念，什麼是微服務，它的特色是什麼?
Spring Boot/Cloud都作了那些事情？他們三者之間又有什麼聯繫？

技術背景

什麼是微服務

微服務的概念源於2014年3月Martin Fowler所寫的一篇文章「Microservices」。

微服務架構是一種架構模式，它提倡將單一應用程序劃分紅一組小的服務，服務之間互相協調、互相配合，爲用戶提供最終價值。每一個服務運行在其獨立的進程中，服務與服務間採用輕量級的通訊機制互相溝通（一般是基於HTTP的RESTful API）。每一個服務都圍繞着具體業務進行構建，而且可以被獨立地部署到生產環境、類生產環境等。另外，應儘可能避免統一的、集中式的服務管理機制，對具體的一個服務而言，應根據業務上下文，選擇合適的語言、工具對其進行構建。

微服務是一種架構風格，一個大型複雜軟件應用由一個或多個微服務組成。系統中的各個微服務可被獨立部署，各個微服務之間是鬆耦合的。每一個微服務僅關注於完成一件任務並很好地完成該任務。在全部狀況下，每一個任務表明着一個小的業務能力。

微服務架構優點

複雜度可控：在將應用分解的同時，規避了本來複雜度無止境的積累。每個微服務專一於單一功能，並經過定義良好的接口清晰表述服務邊界。因爲體積小、複雜度低，每一個微服務可由一個小規模開發團隊徹底掌控，易於保持高可維護性和開發效率。

獨立部署：因爲微服務具有獨立的運行進程，因此每一個微服務也能夠獨立部署。當某個微服務發生變動時無需編譯、部署整個應用。由微服務組成的應用至關於具有一系列可並行的發佈流程，使得發佈更加高效，同時下降對生產環境所形成的風險，最終縮短應用交付週期。

技術選型靈活：微服務架構下，技術選型是去中心化的。每一個團隊能夠根據自身服務的需求和行業發展的現狀，自由選擇最適合的技術棧。因爲每一個微服務相對簡單，故須要對技術棧進行升級時所面臨的風險就較低，甚至徹底重構一個微服務也是可行的。

容錯：當某一組建發生故障時，在單一進程的傳統架構下，故障頗有可能在進程內擴散，造成應用全局性的不可用。在微服務架構下，故障會被隔離在單個服務中。若設計良好，其餘服務可經過重試、平穩退化等機制實現應用層面的容錯。

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

什麼是Spring Boot

Spring Boot是由Pivotal團隊提供的全新框架，其設計目的是用來簡化新Spring應用的初始搭建以及開發過程。該框架使用了特定的方式來進行配置，從而使開發人員再也不須要定義樣板化的配置。用個人話來理解，就是Spring Boot其實不是什麼新的框架，它默認配置了不少框架的使用方式，就像maven整合了全部的jar包，Spring Boot整合了全部的框架（不知道這樣比喻是否合適）。

Spring Boot簡化了基於Spring的應用開發，經過少許的代碼就能建立一個獨立的、產品級別的Spring應用。 Spring Boot爲Spring平臺及第三方庫提供開箱即用的設置，這樣你就能夠有條不紊地開始。Spring Boot的核心思想就是約定大於配置，多數Spring Boot應用只須要不多的Spring配置。採用Spring Boot能夠大大的簡化你的開發模式，全部你想集成的經常使用框架，它都有對應的組件支持。

Spring Cloud都作了哪些事

Spring Cloud是一系列框架的有序集合。它利用Spring Boot的開發便利性巧妙地簡化了分佈式系統基礎設施的開發，如服務發現註冊、配置中心、消息總線、負載均衡、斷路器、數據監控等，均可以用Spring Boot的開發風格作到一鍵啓動和部署。Spring並無重複製造輪子，它只是將目前各家公司開發的比較成熟、經得起實際考驗的服務框架組合起來，經過Spring Boot風格進行再封裝屏蔽掉了複雜的配置和實現原理，最終給開發者留出了一套簡單易懂、易部署和易維護的分佈式系統開發工具包

如下爲Spring Cloud的核心功能：

• 分佈式/版本化配置
• 服務註冊和發現
• 路由
• 服務和服務之間的調用
• 負載均衡
• 斷路器
• 分佈式消息傳遞

咱們再來看一張圖：

經過這張圖，咱們來了解一下各組件配置使用運行流程：

• 一、請求統一經過API網關（Zuul）來訪問內部服務.
  
• 二、網關接收到請求後，從註冊中心（Eureka）獲取可用服務
  
• 三、由Ribbon進行均衡負載後，分發到後端具體實例
  
• 四、微服務之間經過Feign進行通訊處理業務
• 五、Hystrix負責處理服務超時熔斷
• 六、Turbine監控服務間的調用和熔斷相關指標

Spring Cloud體系介紹

上圖只是Spring Cloud體系的一部分，Spring Cloud共集成了19個子項目，裏面都包含一個或者多個第三方的組件或者框架！

Spring Cloud 工具框架

一、Spring Cloud Config 配置中心，利用git集中管理程序的配置。
二、Spring Cloud Netflix 集成衆多Netflix的開源軟件
三、Spring Cloud Bus 消息總線，利用分佈式消息將服務和服務實例鏈接在一塊兒，用於在一個集羣中傳播狀態的變化
四、Spring Cloud for Cloud Foundry 利用Pivotal Cloudfoundry集成你的應用程序
五、Spring Cloud Cloud Foundry Service Broker 爲創建管理雲託管服務的服務代理提供了一個起點。
六、Spring Cloud Cluster 基於Zookeeper, Redis, Hazelcast, Consul實現的領導選舉和平民狀態模式的抽象和實現。
七、Spring Cloud Consul 基於Hashicorp Consul實現的服務發現和配置管理。
八、Spring Cloud Security 在Zuul代理中爲OAuth2 rest客戶端和認證頭轉發提供負載均衡
九、Spring Cloud Sleuth SpringCloud應用的分佈式追蹤系統，和Zipkin，HTrace，ELK兼容。
十、Spring Cloud Data Flow 一個雲本地程序和操做模型，組成數據微服務在一個結構化的平臺上。
十一、Spring Cloud Stream 基於Redis,Rabbit,Kafka實現的消息微服務，簡單聲明模型用以在Spring Cloud應用中收發消息。
十二、Spring Cloud Stream App Starters 基於Spring Boot爲外部系統提供spring的集成
1三、Spring Cloud Task 短生命週期的微服務，爲SpringBooot應用簡單聲明添加功能和非功能特性。
1四、Spring Cloud Task App Starters
1五、Spring Cloud Zookeeper 服務發現和配置管理基於Apache Zookeeper。
1六、Spring Cloud for Amazon Web Services 快速和亞馬遜網絡服務集成。
1七、Spring Cloud Connectors 便於PaaS應用在各類平臺上鍊接到後端像數據庫和消息經紀服務。
1八、Spring Cloud Starters （項目已經終止而且在Angel.SR2後的版本和其餘項目合併）
1九、Spring Cloud CLI 插件用Groovy快速的建立Spring Cloud組件應用。

固然這個數量還在一直增長...

三者之間的關係

微服務是一種架構的理念，提出了微服務的設計原則，從理論爲具體的技術落地提供了指導思想。Spring Boot是一套快速配置腳手架，能夠基於Spring Boot快速開發單個微服務；Spring Cloud是一個基於Spring Boot實現的服務治理工具包；Spring Boot專一於快速、方便集成的單個微服務個體，Spring Cloud關注全局的服務治理框架。

Spring Boot/Cloud是微服務實踐的最佳落地方案。

實戰經歷

遇到問題，尋找方案

2015年初的時候，由於公司業務的大量發展，咱們開始對原有的業務進行拆分，新上的業務線也所有使用獨立的項目來開發，項目和項目之間經過http接口進行訪問。15年的業務發展很是迅速，項目數量也就相應急劇擴大，到了15底的時候項目達60多個，當項目數達到30幾個的時候，其實咱們就遇到了問題，常常某個項目由於擴展增長了新的IP地址，咱們就須要被動的更新好幾個相關的項目。服務愈來愈多，服務之間的調用關係也愈來愈複雜，有時候想畫一張圖來表示項目和項目之間的依賴關係，線條密密麻麻沒法看清。網上有一張圖能夠表達咱們的心情。

這個時候咱們就想找一種方案，能夠將咱們這麼多分佈式的服務給管理起來，到網上進行了技術調研。咱們發現有兩款開源軟件比較適合咱們，一個是Dubbo，一個是Spring Cloud。

其實剛開始咱們是走了一些彎路的。這兩款框架咱們當時都不熟悉，當時國內使用Spring Cloud進行開發的企業很是的少，我在網上也幾乎沒找到太多應用的案例。可是Dubbo當時在國內的使用仍是挺廣泛的，相關的資料各方面都比較完善。所以在公司擴展新業務線衆籌平臺的時候，技術選型就先定了Dubbo，由於也是全新的業務沒有什麼負擔，這個項目咱們大概開發了六個月投產，上線之初也遇到了一些問題，但最終還比較順利。

在新業務線選型使用Dubbo的同時，咱們也沒有徹底放棄Spring Cloud，咱們抽出了一兩名開發人員學習Spring Boot我也參與其中，爲了驗證Spring Boot是否能夠到達實戰的標準，咱們在業餘的時間使用Spring Boot開發了一款開源軟件雲收藏，通過這個項目的實戰驗證咱們對Spring Boot就有了信心。最重要的是你們體會到使用Spring Boot的各類便利以後，就不再想使用傳統的方式來進行開發了。

可是還有一個問題，在選擇了Spring Boot進行新業務開發的同時，並無解決咱們上面的那個問題，服務於服務直接調用仍然比較複雜和傳統，這時候咱們就開始研究Spring Cloud。由於你們在前期對Spring Boot有了足夠的瞭解，所以學習Sprig Cloud就顯得順風順水了。因此在使用Dubbo半年以後，咱們又全面開始擁抱Spring Cloud。

爲何選擇使用Spring Cloud而放棄了Dubbo

可能你們會問，爲何選擇了使用Dubbo以後，而又選擇全面使用Spring Cloud呢？其中有幾個緣由：

1）從兩個公司的背景來談：Dubbo，是阿里巴巴服務化治理的核心框架，並被普遍應用於中國各互聯網公司；Spring Cloud是大名鼎鼎的Spring家族的產品。阿里巴巴是一個商業公司，雖然也開源了不少的頂級的項目，但從總體戰略上來說，仍然是服務於自身的業務爲主。Spring專一於企業級開源框架的研發，不管是在中國仍是在世界上使用都很是普遍，開發出通用、開源、穩健的開源框架就是他們的主業。

2）從社區活躍度這個角度來對比，Dubbo雖然也是一個很是優秀的服務治理框架，而且在服務治理、灰度發佈、流量分發這方面作的比Spring Cloud還好，除過當當網在基礎上增長了rest支持外，已有兩年多的時間幾乎都沒有任何更新了。在使用過程當中出現問題，提交到github的Issue也少有回覆。

相反Spring Cloud自從發展到如今，仍然在不斷的高速發展，從github上提交代碼的頻度和發佈版本的時間間隔就能夠看出，如今Spring Cloud即將發佈2.0版本，到了後期會更加完善和穩定。

3) 從整個大的平臺架構來說，dubbo框架只是專一於服務之間的治理，若是咱們須要使用配置中心、分佈式跟蹤這些內容都須要本身去集成，這樣無形中使用dubbo的難度就會增長。Spring Cloud幾乎考慮了服務治理的方方面面，更有Spring Boot這個大將的支持，開發起來很是的便利和簡單。

4）從技術發展的角度來說，Dubbo剛出來的那會技術理念仍是很是先進，解決了各大互聯網公司服務治理的問題，中國的各中小公司也從中受益很多。通過了這麼多年的發展，互聯網行業也是涌現了更多先進的技術和理念，Dubbo一直停滯不前，天然有些掉隊，有時候我我的也會感到有點惋惜，若是Dubbo一直沿着當初的那個路線發展，而且延伸到周邊，今天可能又是另外一番景象了。

Spring 推出Spring Boot/Cloud也是由於自身的不少緣由。Spring最初推崇的輕量級框架，隨着不斷的發展也愈來愈龐大，隨着集成項目愈來愈多，配置文件也愈來愈混亂，慢慢的背離最初的理念。隨着這麼多年的發展，微服務、分佈式鏈路跟蹤等更多新的技術理念的出現，Spring急需一款框架來改善之前的開發模式，所以纔會出現Spring Boot/Cloud項目，咱們如今訪問Spring官網，會發現Spring Boot和Spring Cloud已經放到首頁最重點突出的三個項目中的前兩個，可見Spring對這兩個框架的重視程度。

總結一下，dubbo曾經確實很牛逼，可是Spring Cloud是站在近些年技術發展之上進行開發，所以更具技術表明性。

如何進行微服務架構演進

當咱們將全部的新業務都使用Spring Cloud這套架構以後，就會出現這樣一個現象，公司的系統被分紅了兩部分，一部分是傳統架構的項目，一部分是微服務架構的項目，如何讓這兩套配合起來使用就成爲了關鍵，這時候Spring Cloud裏面的一個關鍵組件解決了咱們的問題，就是Zuul。在Spring Cloud架構體系內的全部微服務都經過Zuul來對外提供統一的訪問入口，全部須要和微服務架構內部服務進行通信的請求都走統一網關。以下圖：

從上圖能夠看出咱們對服務進行了分類，有四種：基礎服務、業務服務、組合服務、前置服務。不一樣服務遷移的優先級不一樣

• 基礎服務，是一些基礎組件，與具體的業務無關。好比：短信服務、郵件服務。這裏的服務最容易摘出來作微服務，也是咱們第一優先級分離出來的服務。
• 業務服務，是一些垂直的業務系統，只處理單一的業務類型，好比：風控系統、積分系統、合同系統。這類服務職責比較單一，根據業務狀況來選擇是否遷移，好比：若是忽然有需求對積分系統進行大優化，咱們就趁機將積分系統進行改造，是咱們的第二優先級分離出來的服務。
• 前置服務，前置服務通常爲服務的接入或者輸出服務，好比網站的前端服務、app的服務接口這類，這是咱們第三優先級分離出來的服務。
• 組合服務，組合服務就是涉及到了具體的業務，好比買標過程，須要調用不少垂直的業務服務，這類的服務咱們通常放到最後再進行微服務化架構來改造，由於這類服務最爲複雜，除非涉及到大的業務邏輯變動，咱們是不會輕易進行遷移。

在這四類服務以外，新上線的業務所有使用Sprng Boot/Cloud這套技術棧。就這樣，咱們從開源項目雲收藏開始，上線幾個Spring Boot項目，到如今公司絕大部分的項目都是在Spring Cloud這個架構體系中。

經驗和教訓

架構演化的步驟

• 在肯定使用Spring Boot/Cloud這套技術棧進行微服務改造以前，先梳理平臺的服務，對不一樣的服務進行分類，以確認演化的節奏。
• 先讓團隊熟悉Spring Boot技術，而且優先在基礎服務上進行技術改造，推進改動後的項目投產上線
• 當團隊熟悉Spring Boot以後，再推動使用Spring Cloud對原有的項目進行改造。
• 在進行微服務改造過程當中，優先應用於新業務系統，前期能夠只是少許的項目進行了微服務化改造，隨着你們對技術的熟悉度增長，能夠加快加大微服務改造的範圍
• 傳統項目和微服務項目共存是一個很常見的狀況，除非公司業務有大的變化，不建議直接遷移核心項目。

服務拆分原則

服務拆分有如下幾個原則和你們分享

橫向拆分。按照不一樣的業務域進行拆分，例如訂單、營銷、風控、積分資源等。造成獨立的業務領域微服務集羣。

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

要作好微服務的分層：梳理和抽取核心應用、公共應用，做爲獨立的服務下沉到核心和公共能力層，逐漸造成穩定的服務中心，使前端應用能更快速的響應多變的市場需求

服務拆分是越小越好嗎？微服務的大與小是相對的。好比在初期，咱們把交易拆分爲一個微服務，可是隨着業務量的增大，可能一個交易系統已經慢慢變得很大，而且併發流量也不小，爲了支撐更多的交易量，我會把交易系統，拆分爲訂單服務、投標服務、轉讓服務等。所以微服務的拆分力度需與具體業務相結合，總的原則是服務內部高內聚，服務之間低耦合。

微服務vs傳統開發

使用微服務有一段時間了，這種開發模式和傳統的開發模式對比，有很大的不一樣。

• 分工不一樣，之前咱們多是一個一個模塊，如今多是一人一個系統。
• 架構不一樣，服務的拆分是一個技術含量很高的問題，拆分是否合理對之後發展影響巨大。
  
• 部署方式不一樣，若是還像之前同樣部署估計累死了，自動化運維不可不上。
  
• 容災不一樣，好的微服務能夠隔離故障避免服務總體down掉，壞的微服務設計仍然能夠由於一個子服務出現問題致使連鎖反應。

給數據庫帶來的挑戰

每一個微服務都有本身獨立的數據庫，那麼後臺管理的聯合查詢怎麼處理？這應該是你們會廣泛遇到的一個問題，有三種處理方案。

1）嚴格按照微服務的劃分來作，微服務相互獨立，各微服務數據庫也獨立，後臺須要展現數據時，調用各微服務的接口來獲取對應的數據，再進行數據處理後展現出來，這是標準的用法，也是最麻煩的用法。

2) 將業務高度相關的表放到一個庫中，將業務關係不是很緊密的表嚴格按照微服務模式來拆分，這樣既可使用微服務，也避免了數據庫分散致使後臺系通通計功能難以實現，是一個折中的方案。

3）數據庫嚴格按照微服務的要求來切分，以知足業務高併發，實時或者準實時將各微服務數據庫數據同步到NoSQL數據庫中，在同步的過程當中進行數據清洗，用來知足後臺業務系統的使用，推薦使用MongoDB、HBase等。

三種方案在不一樣的公司我都使用過，第一種方案適合業務較爲簡單的小公司；第二種方案，適合在原有系統之上，慢慢演化爲微服務架構的公司；第三種適合大型高併發的互聯網公司。

微服務的經驗和建議

一、建議儘可能不要使用Jsp，頁面開發推薦使用Thymeleaf。Web項目建議獨立部署Tomcat，不要使用內嵌的Tomcat，內嵌Tomcat部署Jsp項目會偶現龜速訪問的狀況。

二、服務編排是個好東西，主要的做用是減小項目中的相互依賴。好比如今有項目a調用項目b，項目b調用項目c...一直到h，是一個調用鏈，那麼項目上線的時候須要先更新最底層的h再更新g...更新c更新b最後是更新項目a。這只是這一個調用鏈，在複雜的業務中有很是多的調用，若是要記住每個調用鏈對開發運維人員來講就是災難。

有這樣一個好辦法能夠儘可能的減小項目的相互依賴，就是服務編排，一個核心的業務處理項目，負責和各個微服務打交道。好比以前是a調用b，b掉用c，c調用d，如今統一在一個核心項目W中來處理，W服務使用a的時候去調用b，使用b的時候W去調用c，舉個例子：在第三方支付業務中，有一個核心支付項目是服務編排，負責處理支付的業務邏輯，W項目使用商戶信息的時候就去調用「商戶系統」，須要校驗設備的時候就去調用「終端系統」，須要風控的時候就調用「風控系統」，各個項目須要的依賴參數都由W來作主控。之後項目部署的時候，只須要最後啓動服務編排項目便可。

三、不要爲了追求技術而追求技術，肯定進行微服務架構改造以前，須要考慮如下幾方面的因素：
1）團隊的技術人員是否已經具有相關技術基礎。
2）公司業務是否適合進行微服務化改造，並非全部的平臺都適合進行微服務化改造，好比：傳統行業有不少複雜垂直的業務系統。
3）Spring Cloud生態的技術有不少，並非每一種技術方案都須要用上，適合本身的纔是最好的。

總結

Spring Cloud對於中小型互聯網公司來講是一種福音，由於這類公司每每沒有實力或者沒有足夠的資金投入去開發本身的分佈式系統基礎設施，使用Spring Cloud一站式解決方案能在從容應對業務發展的同時大大減小開發成本。同時，隨着近幾年微服務架構和Docker容器概念的火爆，也會讓Spring Cloud在將來愈來愈「雲」化的軟件開發風格中立有一席之地，尤爲是在目前五花八門的分佈式解決方案中提供了標準化的、全站式的技術方案，意義可能會堪比當前Servlet規範的誕生，有效推動服務端軟件系統技術水平的進步。

近期我會在GitChat分享從架構演進的角度聊聊 Spring Cloud 都作了些什麼？，若是你感興趣也能夠來聽聽。