Spring Cloud微服務：入門、實戰與進階
尹吉歡 著
第1章
Spring Cloud 與微服務概述
微服務架構是一種架構風格，而Spring Cloud 是實作微服務架構的一系列架構的有序集合。本章将帶你進入神秘的微服務世界，去探索微服務存在的價值及意義，并為閱讀後面的章節打下紮實的理論基礎。
本書涉及的源碼均可在
https://github.com/yinjihuan/spring-cloud中下載下傳。如果下載下傳失敗，也可以發郵件給筆者 [email protected]，或者關注微信公衆号 “猿天地”，直接與筆者交流。
1.1 傳統的單體應用
所謂單體應用程式，通俗來說就是把所有功能全部堆積在一起。這個應用大部分都是一個 WAR 包或者 JAR 包。以筆者自己搭建的技術網站“猿天地”為例，使用者、文章、源碼、課程都是在一個項目中的。随着業務的發展，功能的增加，多年以後這個單體項目将變得越來越臃腫。
這樣的單體應用在公司建立初期是一種比較好的方案，要快速增加新功能或部署釋出都比較簡單。不過，随着時間的推移，危機也會慢慢顯露出來。任何一個BUG都可能導緻整個應用癱瘓，正所謂牽一發而動全身。
1.1.1 改進單體應用的架構
架構總是通過演變而來的，既然傳統的單體應用架構不能滿足業務的發展，那麼架構的改變必然會提上日程。在系統不能支撐目前的使用者量後，我們将項目按照不同的業務來做拆分，分成多個子系統，系統之間通過 Webservice 或者 HTTP 接口來進行互動，這樣做的好處是系統不再那麼臃腫了。
随着使用者量越來越多，系統的壓力也随之增長。可能其中某一個子產品使用的頻率比較高，這個時候就需要對這個子產品進行擴充，其實就是多部署幾個節點。前面再加一個 Nginx 用于負載均衡，剛開始還沒什麼大問題，當子系統越來越多的時候，每個子系統前面都要加一層負載，對運維人員來說工作量就增加了，因為要維護的也增多了。
1.1.2 向微服務靠攏
前面講了這麼多，還是不能滿足網際網路公司快速發展的需求，比如高并發、高可用、高擴充。于是基于之前的架構又改進了一番，引入了阿裡巴巴開源的 Dubbo 架構，解決了服務之間的調用問題，服務調用方不再需要關注服務提供方的位址，隻要從注冊中心擷取服務提供方的位址即可。
目前國内很多公司的微服務架構都是基于 Dubbo 建構的，為什麼我們要轉向 Spring Cloud ？可以從下面幾個方面進行分析：
社群的支援：
- 首先 Spring Cloud 有強大的社群支援， 在 Java 生态圈必定離不開 Spring，且Spring Cloud 的更新頻率也越來越高。
- Dubbo 雖然出自阿裡巴巴，但是有很長一段時間沒維護了，原因是内部有另一個RPC 的架構 HSF，是以 Dubbo 被抛棄了，不過去年 Dubbo 又重回大衆視野，對使用開源架構的使用者來說，社群對架構的持續維護非常重要，是以筆者認為 Spring 家族的産品更适合中小型公司。
關注内容：
- Spring Cloud 關注的是整個服務架構會涉及的方方面面，在 Spring Cloud 中各種元件應有盡有，進而使其具有可快速內建、友善、成本低等優勢。
- Dubbo 關注的更細一些，隻針對服務治理，相當于 Spring Cloud 中的一個子集。能和 Dubbo 互相比較的應該是 gRPC，Thrift 之類的架構。
性能問題：
- 對于性能這塊，Dubbo 确實要比 Spring Cloud 好，原因大家也都清楚，Dubbo 基于 Netty 的 TCP 及二進制的資料傳輸，Spring Cloud 基于 HTTP，HTTP 每次都要建立連接配接，傳輸的也是文本内容，自然在性能上有些損耗。
- Spring Cloud 帶來的性能損耗對于大部分應用來說是可以接受的，而它具有的HTTP 風格的 API 互動，在不同的語言中是通用的，且對每個微服務的測試來說是非常友善的，也就是說 Spring Cloud 用小的性能損耗換來了更多好處。當當網在Dubbo 的基礎上加上 REST 的支援擴充出目前的 Dubbox 也是這個道理。
1.2 什麼是微服務
“微服務”一詞來源于Martin Fowler的《Microservices》一文。微服務是一種架構風格，即将單體應用劃分為小型的服務單元，微服務之間使用HTTP的API進行資源通路與操作。
在筆者看來，微服務架構的演變更像是一個公司的發展過程，從最開始的小公司，到後來的大集團。大集團可拆分出多個子公司，每個子公司的都有自己獨立的業務、員工，各自發展，互不影響，合起來則是威力無窮。
1.2.1 使用微服務架構的優勢和劣勢
臃腫的系統、重複的代碼、超長的啟動時間帶給開發人員的隻有無限的埋怨，絲毫沒有那種很舒服的、很流暢的寫代碼的感覺。他們把大部分時間都花在解決問題和項目啟動上面了。
1.優勢
使用微服務架構能夠為我們帶來如下好處：
- 服務的獨立部署：每個服務都是一個獨立的項目，可以獨立部署，不依賴于其他服務，耦合性低。
- 服務的快速啟動：拆分之後服務啟動的速度必然要比拆分之前快很多，因為依賴的庫少了，代碼量也少了。
- 更加适合靈活開發：靈活開發以使用者的需求進化為核心，采用疊代、循序漸進的方法進行。服務拆分可以快速釋出新版本，修改哪個服務隻需要釋出對應的服務即可， 不用整體重新釋出。
- 職責專一，由專門的團隊負責專門的服務：業務發展迅速時，研發人員也會越來越多，每個團隊可以負責對應的業務線，服務的拆分有利于團隊之間的分工。
- 服務可以動态按需擴容：當某個服務的通路量較大時，我們隻需要将這個服務擴容即可。
- 代碼的複用：每個服務都提供 REST API，所有的基礎服務都必須抽出來，很多的底層實作都可以以接口方式提供。
2.劣勢
微服務其實是一把雙刃劍，既然有利必然也會有弊。下面我們來談談微服務有哪些弊端，以及能采取什麼辦法避免。
- 分布式部署，調用的複雜性高：單體應用的時候，所有子產品之前的調用都是在本地進行的，在微服務中，每個子產品都是獨立部署的，通過 HTTP 來進行通信，這當中會産生很多問題，比如網絡問題、容錯問題、調用關系等。
- 獨立的資料庫，分布式事務的挑戰：每個微服務都有自己的資料庫，這就是所謂的去中心化的資料管理。這種模式的優點在于不同的服務，可以選擇适合自身業務的資料，比如訂單服務可以用MySQL、評論服務可以用Mongodb、商品搜尋服務可以用Elasticsearch。缺點就是事務的問題了，目前最理想的解決方案就是柔性事務中的最終一緻性，後面的章節會給大家做具體介紹。
- 測試的難度提升：服務和服務之間通過接口來互動，當接口有改變的時候，對所有的調用方都是有影響的，這時自動化測試就顯得非常重要了，如果要靠人工一個個接口去測試，那工作量就太大了。這裡要強調一點，就是API文檔的管理尤為重要。
- 運維難度的提升：在采用傳統的單體應用時，我們可能隻需要關注一個Tomcat的叢集、一個MySQL的叢集就可以了，但這在微服務架構下是行不通的。當業務增加時，服務也将越來越多，服務的部署、監控将變得非常複雜，這個時候對于運維的要求就高了。
1.2.2 重構前的準備工作
對于上不上微服務，關鍵在于公司的發展程度。系統是否真的到了必須做分解的地步？在上微服務之前一定要做好技術選型。用什麼架構來建構微服務？公司是否支援重構？這些問題都很重要，沒有公司的支援一切都是空談。你要告訴你的上級為什麼要重構，為什麼要上微服務，上了之後能解決哪些問題，比如能否提高系統穩定性、能否節約機器資源等。有了明确的目标及計劃，我相信這件事必成。
在重構之前，架構師一定要對公司所有的産品做一遍梳理，出一個重構方案，畫一個架構圖。還要對團隊成員進行一次教育訓練，講講重構的過程中會遇到哪些技術問題，可采用什麼方式解決，在這個過程中大家能學到什麼。我相信，對于有成長、有意義的事情，就算加班，大家也會開心的。這些你都不準備好，别人會覺得你沒事找事，天天讓他加班。
重構時最好采用循序漸進的模式，首先對一個産品進行重構規劃，抽出業務服務，再抽出這個産品所依賴的基礎服務，基礎服務是最為重要的。等一個産品穩定之後，再重構其他産品，把核心業務放到最後面。不要想着一步登天，重構就像堆積木，堆着堆着就高了，一周抽一個微服務，慢慢就都變成微服務了。
1.3 什麼是Spring Cloud
Spring Cloud 是一系列架構的有序集合。它利用 Spring Boot 的開發便利性，巧妙地簡化了分布式系統基礎設施的開發，如服務注冊、服務發現、配置中心、消息總線、負載均衡、斷路器、資料監控等，這些都可以用 Spring Boot 的開發風格做到一鍵啟動和部署。通俗地講，Spring Cloud 就是用于建構微服務開發和治理的架構集合（并不是具體的一個架構），主要貢獻來自 Netflix OSS。
1.3.1 Spring Cloud子產品介紹
Spring Cloud 子產品的相關介紹如下：
- Eureka：服務注冊中心，用于服務管理。
- Ribbon：基于用戶端的負載均衡元件。
- Hystrix：容錯架構，能夠防止服務的雪崩效應。
- Feign：Web 服務用戶端，能夠簡化 HTTP 接口的調用。
- Zuul：API 網關，提供路由轉發、請求過濾等功能。
- Config：分布式配置管理。
- Sleuth：服務跟蹤。
- Stream：建構消息驅動的微服務應用程式的架構。
- Bus：消息代理的叢集消息總線。
除了上述子產品，還有 Cli、Task……。本書隻介紹一些常用的子產品。
Spring Cloud 是一個非常好的架構集合，它包含的功能子產品非常多，這裡不可能一一講解到，凡是在本書中出現的子產品都是真實開發中用得到的。對于那些沒有在本書中進行講解的子產品，大家也可以自行學習，當然有任何問題也可以咨詢筆者。
1.3.2 Spring Cloud版本介紹
相信大家跟筆者一樣，在第一次通路 Spring Cloud 官網時一定會有一個疑惑那就是版本太多了，到底哪個是穩定版本？哪個才是自己需要的版本？接下來就給大家簡單介紹一下版本的問題。
通路官網
https://projects.spring.io/spring-cloud/#learn可以看到網頁右側的版本清單，如圖1-1 所示。
截至本書完稿時，最新的穩定版本是 Finchley SR2。為什麼其中還有 Dalston、Edgware等這些版本？而不是像别的項目那樣，版本号采用 1.1、1.2、1.3 這種的格式？因為 Spring Cloud 是一個擁有諸多子項目的大型綜合項目，可以說是對微服務架構解決方案的綜合套件元件，其中包含的各個子項目都獨立進行着内容的疊代與更新，各自維護着自己的釋出版本号。
至于怎麼選擇适合自己的版本，筆者認為，大家可以在接觸的時候直接選最新的穩定版本。新版本中的Bug肯定要少，并且更穩定。寫作本書的時候，官方釋出的Spring Cloud最新穩定版本是 Finchley SR2，是以本書的案例都是基于 Finchley SR2 進行講解的。不同的版本有不同的功能，對應的每個子子產品的版本也不一樣，那麼如何知道每個大版本下面具體的子子產品是什麼版本呢？答案就在官網的首頁上面，在頁面的最下方有一個表格（見表1-1），通過這個表格我們可以清楚地知道 Finchley SR2 對應的 Spring Boot 版本是 2.0.6.RELEASE，Spring-Cloud- Bus 是 2.0.0.RELEASE。
1.4 本章小結
Spring Cloud 的誕生對于微服務架構來說簡直是如魚得水，本章主要是對微服務及Spring Cloud 做了一些理論性的講解，同時介紹了我們為什麼要選擇 Spring Cloud、Spring Cloud 有哪些内容、使用 Spring Cloud 能夠為我們帶來什麼好處等。下一章我們将學習Spring Boot 架構的使用方法。