第一章 基礎知識
什麼是微服務架構
“微服務”一詞源於Martin Flower的名爲Microservices的博文，可以在他的官方博客上找到：http://martinfowler.com/articles/microservices.html
簡單地說，微服務是系統架構上的一種設計風格，它的主旨是將一個原本獨立的系統拆分成多個小型服務，這些小型服務都在各自獨立的進程中運行，服務之間通過基於HTTP的RESTful API進行通信協作。被拆分成的每一額小型服務都圍繞着系統中的某一項或一些耦合度較高的業務功能進行構建，並且每個服務都維護着自身的數據存儲、業務開發、自動化測試案例以及獨立部署機制。由於有了輕量級的通信協作基礎，所以這些微服務可以使用不同的語言來編寫。
與單體系統的區別
傳統的企業系統架構
- 複雜的業務需求通常使用對象或業務類型來構建一個單體項目；
- 需求分爲三個主要部分：數據庫、服務端處理、前端展現；
- 業務邏輯在一個應用中；
- 需求的擴大使得單體應用變臃腫；
- 部署在一個進程內，一處修改，會影響其他功能的運行；
- 系統容量難以準確評估
微服務架構
- 不同功能模塊拆分成多個不同的服務，這些服務都能獨立部署和擴展；
- 每個服務都運行在自己的進程內，每個服務的更新不會影響其他服務的運行；
- 獨立部署，可以準確地評估每個服務的性能容量。
如何實施微服務
在實施微服務之前，我們必須要知道，微服務雖然有非常多吸引人的優點，但是也因爲服務的拆分引發了諸多原本在單體應用中沒有的問題。
運維的新挑戰
在微服務架構中，運維人員需要維護的進程數量會大大增加。有條不紊地將這些進程編排和組織起來不是一件容易的事，傳統的運維人員往往很難適應這樣的改變。
接口的一致性
雖然我們拆分了服務，但是業務邏輯上的依賴並不會消除，只是從單體應用中的代碼依賴變爲了服務間的通信依賴。而當我們對原有接口進行了一些修改，那麼交互方也需要協調這樣的改變來進行發佈，以保證接口的正確調用。我們需要更完善的接口和版本管理，或是嚴格地遵循開閉原則。
分佈式的複雜性
由於拆分後的各個微服務都是獨立部署並運行在各自的進程內，它們只能通過通信進行協作，所以分佈式環境的問題都將是微服務架構系統設計時需要考慮的重要因素，比如網絡延遲、分佈式事務、異步消息等。
微服務架構的九大特性
服務組件化
組件，是一個可以獨立更換和升級的單元。就像PC中的CPU、內存、顯卡、硬盤一樣，獨立且可以更換升級而不影響其他單元。
按服務組織團隊
在實施微服務架構時，需要採用不同的團隊分割方法。由於每一個微服務都是針對特定業務的寬棧或是全棧實現，既要負責數據的持久化存儲，又要負責用戶的接口定義等各種跨專業領域的職能。因此，面對大型項目的時候，對於微服務團隊的拆分更加建議按業務線的方式進行拆分，一方面可以有效減少服務內部修改所產生的內耗；另一方面，團隊邊界可以變得更爲清晰。
做“產品”的態度
在實施微服務架構的團隊中，每個小團隊都應該以做產品的方式，對其產品的整個生命週期負責。而不是以項目的模式，以完成開發與交付並將成果交接給維護者爲最終目標。
智能端點與啞管道
在單體應用中，組件間直接通過函數調用的方式進行交互協作。而在微服務架構中，由於服務不在一個進程中，組件間的通信模式發生了改變，若僅僅將原本在進程內的方法調用改成RPC方式的調用，會導致微服務之間產生繁瑣的通信，使得系統表現更爲糟糕，所以我們需要更粗粒度的通信協議。
在微服務架構中，通常會使用以下兩種服務調用方式：
- 第一種：使用HTTP的RESTful API 或輕量級的消息發送協議，實現信息傳遞與服務調用的觸發；
- 第二種：通過在輕量級消息總線上傳遞消息，類似RabbitMQ等一些提供可靠異步交換的中間件。
在極度強調性能的情況下，可能會使用二進制的消息發送協議，例如protobuf。即使這樣，這些系統仍然會呈現出“智能端點和啞管道”的特點，這是爲了在易讀性與高效性之間取得平衡。當然大多數Web應用或企業系統並不需要在這兩者間做出選擇，能夠獲得易讀性已經是一個極大的勝利了。
去中心化治理
在實施微服務架構時，通過採用輕量級的契約定義接口，使得我們對於服務本身的具體技術平臺不再那麼敏感，這樣整個微服務架構系統中的各個組件就能針對其不同的業務特點選擇不同的技術平臺，終於不會出現殺雞用牛刀或是傻妞用指甲剪的尷尬處境了。
“不是每一個問題都是釘子，不是每一個解決方案都是錘子。”
去中心化管理數據
-
數據管理的去中心化：每一個微服務管理自有的數據庫。
- 將原數據庫中的存儲內容拆分到新的同平臺的其他數據庫實例中，如把原本存儲在MySQL中的表拆分後，存儲到多個不同的MySQL實例中。
- 將具有特殊結構或業務特性的數據存儲到其他技術的數據庫實例中，如吧日誌信息存儲到MongoDB中或把用戶登錄信息存儲到Redis中。
-
缺點：
- 數據一致性問題；
- 分佈式事務實現難度大；
-
解決方法：
- 要求數據最後的處理狀態一致即可；
- 各服務之間進行“無事務”的調用；
- 過程中發現錯，通過補償機制進行處理，使得錯誤數據達到最終的一致性。
基礎設施自動化
微服務架構中，務必一開始就構建“持續交付”平臺來支撐整個實施過程，因此需要下面兩大內容：
- 自動化測試：每次部署前的強心劑，儘可能地獲得對正在運行的軟件的信心。
- 自動化部署：解放繁瑣枯燥的重複操作以及對多環境的配置管理。
容錯設計
- 單體應用：一掛全掛；
- 微服務架構：部分故障，其他正常運行；
在微服務架構中，會出現故障的蔓延，因此快速檢測出故障源並儘可能地自動恢復服務是必須設計和考慮的。通常，我們都希望在每個服務中實現監控和日誌記錄的組件，比如服務狀態、斷路器、吞吐量、網絡延遲等關鍵數據的儀表盤等。
演進式設計
在很多情況下，架構師都會以演進的方式進行系統的構建。在初期，以單體系統的方式來設計和實施，一方面系統體量初期並不會很大，構建和維護成本都不高。另一方面，初期的核心業務在後期通常也不會發生巨大的改變。隨着系統的發展或者業務的需要，架構師會將一些經常變動或是有一定時間效應的內容進行微服務處理，並逐漸將原來在單體系統中多變的模塊逐步拆分出來，而穩定不太變化的模塊就形成一個核心微服務存在於整個架構中。
爲什麼選擇Spring Cloud
Spring Cloud的出現，可以說是對微服務架構的巨大支持和強有力的技術後盾。它是一個解決微服務架構是的綜合性解決框架，它整合了諸多被廣泛實踐和證明過的框架作爲實施的基礎部件，又在該體系基礎上創建了一些非常優秀的邊緣組件。
Spring Cloud簡介
Spring Cloud 是一個基於Spring Boot 實現的微服務架構開發工具。它爲微服務架構中涉及的配置管理、服務治理、斷路器、智能路由、微代理、控制總線、全局鎖、決策競選、分佈式會話和集羣狀態管理等操作提供了一種簡單的開發方式。
Spring Cloud 包含了多個子項目（針對分佈式系統中涉及的多個不同開源產品，還可能會新增），如下所述：
- Spring Cloud Config:配置管理工具，支持使用Git存儲配置內容，可以使用它實現應用配置的外部化存儲，並支持客戶端配置信息刷新、加密/解密配置內容等。
- Spring Cloud Netflix：核心組件，對多個Netflix OSS 開源套件進行整合。
- Eureka：服務治理組件，包含註冊中心、服務註冊與發現機制的實現。
- Hystrix：容錯管理組件，實現斷路器模式，幫助服務依賴中出現的延遲和爲故障提供強大的容錯能力。
- Ribbon：客戶端負載均衡的服務調用組件。
- Feign：基於Ribbon和Hystrix的聲明式服務調用組件。
- Zuul：網關組件，提供智能路由、訪問過濾等功能。
- Archaius：外部化配置組件。
- Spring Cloud Bus：事件、消息總線，用於傳播集羣中的狀態變化或事件，以觸發後續的處理，比如用來動態刷新配置等。
- Spring Cloud Cluster：針對ZooKeeper、Redis、Hazelcast、Consul的選舉算法和通用狀態模式的實現。
- Spring Cloud Cloudfoundry：與Pivotal Cloudfoundry的整合支持。
- Spring Cloud Consul：服務發現與配置管理工具。
- Spring Cloud Stream：通過Redis、Rabbit或者Kafka實現的消費微服務，可以通過簡單的聲明式模型來發送和接收消息。
- Spring Cloud AWS：用於簡化整合Amazon Web Service的組件。
- Spring Cloud Security：安全工具包，提供在Zuul代理中對OAuth2客戶端請求的中繼器。
- Spring Cloud Sleuth：Spring Cloud英勇的分佈式跟蹤實現，可以完美整合Zipkin。
- Spring Cloud ZooKeeper：基於ZooKeeper的服務發現與配置管理組件。
- Spring Cloud Starters：Spring Cloud的基礎組件，它是基於Spring Boot風格項目的基礎依賴模塊。
- Spring Cloud CLI：用於在Groovy中快速創建Spring Cloud應用的Spring Boot CLI插件。
- …
版本說明
由於Spring Cloud 不像Spring社區其他一些項目那樣相對獨立，它是一個擁有諸多子項目的大型綜合項目，可以說是對微服務架構解決方案的綜合套件組合，其包含的各個子項目也都獨立進行着內容更新與迭代，各自都維護者自己的發佈版本號。因此每一個Spring Cloud的版本都會包含多個不同的版本的子項目，爲了管理每個版本的子項目清單，避免Spring Cloud的版本號與其子項目的版本號相混淆，沒有采用版本號的方式，而是通過命名的方式。這些版本的名字採用了倫敦地鐵站的名字，根據字母表的順序來對應版本時間順序。