SpringCloud入門篇筆記

Spring Cloud

Spring Cloud 自 2016 年 1 月發佈第一個 Angel.SR5 版本，到目前 2020 年 3 月發佈 Hoxton.SR3 版本，已經歷經了 4 年時間。這 4 年時間裏，Spring Cloud 一共發佈了 46 個版本，支持的組件數從 5 個增加到 21 個。Spring Cloud 在 2019 年 12 月對外宣佈後續 RoadMap：

• 下一個版本 Ilford 版本是一個大版本。這個版本基於 Spring Framework 5.3 & Spring Boot 2.4，會在 2020 Q4 左右發佈；
• Ilford 版本會刪除處於維護模式的項目。目前處於維護模式的 Netflix 大部分項目都會被刪除（spring-cloud-netflix Github 項目已經刪除了這些維護模式的項目）；
• 簡化 Spring Cloud 發佈列車。後續 IaasS 廠商對應的 Spring Cloud 項目會移出 Spring Cloud 組織，各自單獨維護（spring-cloud-azure 一直都是單獨維護，spring-cloud-alibaba 孵化在 Spring Cloud 組織，畢業後單獨維護）；
• API 重構，會帶來重大的改變（Spring Cloud Hoxton 版本新增了 Spring Cloud Circuit Breaker 用於統一熔斷操作的編程模型和 Spring Cloud LoadBalanacer 用於處理客戶端負載均衡並代替 Netflix Ribbon）。

這個 RoadMap 可以說是對 Spring Cloud 有着非常大的變化。

SpringCloud替代實現

SpringCloud Alibaba

組件

Sentinel：把流量作爲切入點，從流量控制、熔斷降級、系統負載保護等多個維度保護服務的穩定性。

Nacos：一個更易於構建雲原生應用的動態服務發現、配置管理和服務管理平臺。

RocketMQ：一款開源的分佈式消息系統，基於高可用分佈式集羣技術，提供低延時的、高可靠的消息發佈與訂閱服務。

Dubbo：Apache Dubbo™ 是一款高性能 Java RPC 框架。

Seata：阿里巴巴開源產品，一個易於使用的高性能微服務分佈式事務解決方案。

Alibaba Cloud ACM：一款在分佈式架構環境中對應用配置進行集中管理和推送的應用配置中心產品。

Alibaba Cloud OSS: 阿里雲對象存儲服務（Object Storage Service，簡稱 OSS），是阿里雲提供的海量、安全、低成本、高可靠的雲存儲服務。您可以在任何應用、任何時間、任何地點存儲和訪問任意類型的數據。

Alibaba Cloud SchedulerX: 阿里中間件團隊開發的一款分佈式任務調度產品，提供秒級、精準、高可靠、高可用的定時（基於 Cron 表達式）任務調度服務。

Alibaba Cloud SMS: 覆蓋全球的短信服務，友好、高效、智能的互聯化通訊能力，幫助企業迅速搭建客戶觸達通道。

Spring Cloud技術點

Eureka：服務註冊與發現，用於服務管理。

Feign： web調用客戶端，能夠簡化HTTP接口的調用。

Ribbon：基於客戶端的負載均衡。

Hystrix：熔斷降級，防止服務雪崩。

Zuul：網關路由，提供路由轉發、請求過濾、限流降級等功能。

Config：配置中心，分佈式配置管理。

Sleuth：服務鏈路追蹤

Admin：健康管理

服務進化概述

1. 傳統服務到微服務進化。

2. 單體應用-> SOA ->微服務（下面講）

課外擴展：
持續集成，持續部署，持續交付。
集成:是指軟件個人研發的部分向軟件整體部分集成，以便儘早發現個人開發部分的問題；
部署: 是代碼儘快向可運行的開發/測試節交付，以便儘早測試；
交付: 是指研發儘快向客戶交付，以便儘早發現生產環境中存在的問題。
   如果說等到所有東西都完成了才向下個環節交付，導致所有的問題只能在最後才爆發出來，解決成本巨大甚至無法解決。而所謂的持續，就是說每完成一個完整的部分，就向下個環節交付，發現問題可以馬上調整。使問題不會放大到其他部分和後面的環節。
   這種做法的核心思想在於：既然事實上難以做到事先完全瞭解完整的、正確的需求，那麼就乾脆一小塊一小塊的做，並且加快交付的速度和頻率，使得交付物儘早在下個環節得到驗證。早發現問題早返工。

上面的3個持續，也都隨着微服務的發展而發展，當架構師的同學，可以參考這種方式。

持續集成的工具，向大家推薦：https://jenkins.io/doc/book/pipeline/

單體應用

1. 概念：所有功能全部打包在一起。應用大部分是一個war包或jar包。我參與網約車最開始架構是：一個乘客項目中有 用戶、訂單、消息、地圖等功能。隨着業務發展，功能增多，這個項目會越來越臃腫。

2. 好處：容易開發、測試、部署，適合項目初期試錯。

3. 壞處：

   ​ 隨着項目越來越複雜，團隊不斷擴大。壞處就顯現出來了。

   • 複雜性高：代碼多，十萬行，百萬行級別。加一個小功能，會帶來其他功能的隱患，因爲它們在一起。
   • 技術債務：人員流動，不壞不修，因爲不敢修。
   • 持續部署困難：由於是全量應用，改一個小功能，全部部署，會導致無關的功能暫停使用。編譯部署上線耗時長，不敢隨便部署，導致部署頻率低，進而又導致兩次部署之間 功能修改多，越不敢部署，惡性循環。
   • 可靠性差：某個小問題，比如小功能出現OOM，會導致整個應用崩潰。
   • 擴展受限：只能整體擴展，無法按照需要進行擴展， 不能根據計算密集型（派單系統）和IO密集型（文件服務） 進行合適的區分。
   • 阻礙創新：單體應用是以一種技術解決所有問題，不容易引入新技術。但在高速的互聯網發展過程中，適應的潮流是：用合適的語言做合適的事情。比如在單體應用中，一個項目用spring MVC，想換成spring boot，切換成本很高，因爲有可能10萬，百萬行代碼都要改，而微服務可以輕鬆切換，因爲每個服務，功能簡單，代碼少。

SOA

對單體應用的改進：引入SOA（Service-Oriented Architecture）面向服務架構，拆分系統，用服務的流程化來實現業務的靈活性。服務間需要某些方法進行連接，面向接口等，它是一種設計方法，其中包含多個服務， 服務之間通過相互依賴最終提供一系列的功能。一個服務 通常以獨立的形式存在於操作系統進程中。各個服務之間 通過網絡調用。但是還是需要用些方法來進行服務組合，有可能還是個單體應用。

所以要引入微服務，是SOA思想的一種具體實踐。

微服務架構 = 80%的SOA服務架構思想 + 100%的組件化架構思想

微服務

微服務概況

• 無嚴格定義。
• 微服務是一種架構風格，將單體應用劃分爲小型的服務單元。
• 微服務架構是一種使用一系列粒度較小的服務來開發單個應用的方式；每個服務運行在自己的進程中；服務間採用輕量級的方式進行通信(通常是HTTP API)；這些服務是基於業務邏輯和範圍，通過自動化部署的機制來獨立部署的，並且服務的集中管理應該是最低限度的，即每個服務可以採用不同的編程語言編寫，使用不同的數據存儲技術。
• 英文定義：

看這篇文章：
http://www.martinfowler.com/articles/microservices.html

• 小類比

  合久必分。分開後通信，獨立部署，獨立存儲。

分封制：
服從天子命令：服從服務管理。
有爲天子鎮守疆土的義務：各自完成各自的一塊業務。
隨從作戰：服務調用。
交納貢獻：分擔流量壓力。

• 段子（中臺戰略）

Q：大師大師，服務拆多了怎麼辦？
A：那就再合起來。
Q：那太沒面子了。
A：那就說跨過了微服務初級階段，在做中臺（自助建站系統）。

微服務特性

獨立運行在自己進程中。

一系列獨立服務共同構建起整個系統。

一個服務只關注自己的獨立業務。

輕量的通信機制RESTful API

使用不同語言開發

全自動部署機制

微服務組件介紹

不侷限與具體的微服務實現技術。

• 服務註冊與發現：服務提供方將己方調用地址註冊到服務註冊中心，讓服務調用方能夠方便地找到自己；服務調用方從服務註冊中心找到自己需要調用的服務的地址。

• 負載均衡：服務提供方一般以多實例的形式提供服務，負載均衡功能能夠讓服務調用方連接到合適的服務節點。並且，服務節點選擇的過程對服務調用方來說是透明的。

• 服務網關：服務網關是服務調用的唯一入口，可以在這個組件中實現用戶鑑權、動態路由、灰度發佈、A/B測試、負載限流等功能。

  灰度發佈（又名金絲雀發佈）是指在黑與白之間，能夠平滑過渡的一種發佈方式。在其上可以進行A/B testing，即讓一部分用戶繼續用產品特性A，一部分用戶開始用產品特性B，如果用戶對B沒有什麼反對意見，那麼逐步擴大範圍，把所有用戶都遷移到B上面來。灰度發佈可以保證整體系統的穩定，在初始灰度的時候就可以發現、調整問題，以保證其影響度。
  

• 配置中心：將本地化的配置信息(Properties、XML、YAML等形式)註冊到配置中心，實現程序包在開發、測試、生產環境中的無差別性，方便程序包的遷移，也是無狀態特性。

• 集成框架：微服務組件都以職責單一的程序包對外提供服務，集成框架以配置的形式將所有微服務組件(特別是管理端組件)集成到統一的界面框架下，讓用戶能夠在統一的界面中使用系統。Spring Cloud就是一個集成框架。

• 調用鏈監控：記錄完成一次請求的先後銜接和調用關係，並將這種串行或並行的調用關係展示出來。在系統出錯時，可以方便地找到出錯點。

• 支撐平臺：系統微服務化後，各個業務模塊經過拆分變得更加細化，系統的部署、運維、監控等都比單體應用架構更加複雜，這就需要將大部分的工作自動化。現在，Docker等工具可以給微服務架構的部署帶來較多的便利，例如持續集成、藍綠髮布、健康檢查、性能監控等等。如果沒有合適的支撐平臺或工具，微服務架構就無法發揮它最大的功效。

  1. 藍綠部署是不停老版本，部署新版本然後進行測試，確認OK，將流量切到新版本，然後老版本同時也升級到新版本。
  2. 灰度是選擇部分部署新版本，將部分流量引入到新版本，新老版本同時提供服務。等待灰度的版本OK，可全量覆蓋老版本。
  
  灰度是不同版本共存，藍綠是新舊版本切換，2種模式的出發點不一樣。
  

微服務優點

1. 獨立部署。不依賴其他服務，耦合性低，不用管其他服務的部署對自己的影響。
2. 易於開發和維護：關注特定業務，所以業務清晰，代碼量少，模塊變的易開發、易理解、易維護。
3. 啓動塊：功能少，代碼少，所以啓動快，有需要停機維護的服務，不會長時間暫停服務。
4. 局部修改容易：只需要部署 相應的服務即可，適合敏捷開發。
5. 技術棧不受限：java，node.js等
6. 按需伸縮：某個服務受限，可以按需增加內存，cpu等。
7. 職責專一。專門團隊負責專門業務，有利於團隊分工。
8. 代碼複用。不需要重複寫。底層實現通過接口方式提供。
9. 便於團隊協作：每個團隊只需要提供API就行，定義好API後，可以並行開發。

微服務缺點

1. 分佈式固有的複雜性：容錯（某個服務宕機），網絡延時，調用關係、分佈式事務等，都會帶來複雜。

2. 分佈式事務的挑戰：每個服務有自己的數據庫，有點在於不同服務可以選擇適合自身業務的數據庫。訂單用MySQL，評論用Mongodb等。目前最理想解決方案是：柔性事務的最終一致性。

   剛性事務：遵循ACID原則，強一致性。
   柔性事務：遵循BASE理論，最終一致性；與剛性事務不同，柔性事務允許一定時間內，不同節點的數據不一致，但要求最終一致。
   
   BASE 是 Basically Available(基本可用)、Soft state(軟狀態)和 Eventually consistent (最終一致性)三個短語的縮寫。BASE理論是對CAP中AP的一個擴展，通過犧牲強一致性來獲得可用性，當出現故障允許部分不可用但要保證核心功能可用，允許數據在一段時間內是不一致的，但最終達到一致狀態。滿足BASE理論的事務，我們稱之爲“柔性事務”。
   

3. 接口調整成本高：改一個接口，調用方都要改。

4. 測試難度提升：一個接口改變，所有調用方都得測。自動化測試就變的重要了。API文檔的管理也尤爲重要。推薦：yapi。

5. 運維要求高：需要維護 幾十 上百個服務。監控變的複雜。並且還要關注多個集羣，不像原來單體，一個應用正常運行即可。

6. 重複工作：比如java的工具類可以在共享common.jar中，但在多語言下行不通，C++無法直接用java的jar包。

設計原則

單一職責原則：關注整個系統功能中單獨，有界限的一部分。

服務自治原則：可以獨立開發，測試，構建，部署，運行，與其他服務解耦。

輕量級通信原則：輕，跨平臺，跨語言。REST,AMQP 等。

粒度把控：與自己實際相結合。 不要追求完美，隨業務進化而調整。《淘寶技術這10年》。

技術選型

1. Spring Cloud和dubbo組件比較

   dubbo：zookeeper+dubbo+springmvc/springboot
   通信方式：rpc
   註冊中心：zookeeper，nacos
   配置中心：diamond（淘寶開發）
   
   spring cloud：spring+Netflix
   通信方式：http restful
   註冊中心：eureka，consul，nacos				
   配置中心：config
   斷路器：hystrix
   網關：zuul，gateway
   分佈式追蹤系統：sleuth+zipkin
   
   

2. 差別

   	dubbo	spring cloud
   背景	國內影響大	國外影響大	平手
   社區活躍度	低(現在又好了)	高	cloud勝出
   架構完整度	不完善（dubbo有些不提供，需要用第三方，它只關注服務治理）	比較完善，微服務組件應有盡有。	cloud勝出
   學習成本	dubbo需要配套學習	無縫spring	cloud勝出
   性能	高。（基於Netty）	低。（基於http，每次都要創建）。 此性能的損耗對大部分應用是可以接受的。而HTTP風格的API,是很方便的。用小的性能損耗換來了方便。	dubbo勝出

Spring Cloud

概念

Spring Cloud是實現微服務架構的一系列框架的有機集合。

是在Spring Boot基礎上構建的，用於簡化分佈式系統構建的工具集。是擁有衆多子項目的項目集合。利用Spring Boot的開發便利性，巧妙地簡化了分佈式系統基礎設施（服務註冊與發現、熔斷機制、網關路由、配置中心、消息總線、負載均衡、鏈路追蹤等）的開發。

版本演進

1. 版本過程：版本名.版本號。

2. 版本名：倫敦地鐵字母順序。

3. 版本號：M（milestone）：里程碑，

   ​ SR（Service Releases）：穩定版，

   ​ RC(Release Candidate)：穩定版的候選版，也就是穩定版的最後一個版本。

看官網：查詢每個cloud版本下面的子模塊的版本。
https://spring.io/projects/spring-cloud
此網頁的最下面，目前最新的SpringCloud最新版本是：Greenwich.SR2

版本記錄
https://github.com/spring-cloud/spring-cloud-release/releases

整體架構

組成：

1. 服務註冊與發現組件：Eureka，Zookeeper，Consul,Nacos等。Eureka基於REST風格的。

2. 服務調用組件：Hystrix(熔斷降級，在出現依賴服務失效的情況下，通過隔離 系統依賴服務 的方式，防止服務級聯失敗，同時提供失敗回滾機制，使系統能夠更快地從異常中恢復)，Ribbon（客戶端負載均衡，用於提供客戶端的軟件負載均衡算法，提供了一系列完善的配置項：連接超時、重試等），OpenFeign（優雅的封裝Ribbon，是一個聲明式RESTful網絡請求客戶端，它使編寫Web服務客戶端變得更加方便和快捷）。

3. 網關：路由和過濾。Zuul，Gateway。

4. 配置中心：提供了配置集中管理，動態刷新配置的功能；配置通過Git或者其他方式來存儲。

5. 消息組件：Spring Cloud Stream（對分佈式消息進行抽象，包括髮布訂閱、分組消費等功能，實現了微服務之間的異步通信）和Spring Cloud Bus（主要提供服務間的事件通信，如刷新配置）

6. 安全控制組件：Spring Cloud Security 基於OAuth2.0開放網絡的安全標準，提供了單點登錄、資源授權和令牌管理等功能。

7. 鏈路追蹤組件：Spring Cloud Sleuth（收集調用鏈路上的數據），Zipkin（對Sleuth收集的信息，進行存儲，統計，展示）。

   每個點中的內容，後面都會講到。

獨立微服務編寫

開發工具

STS / IDEA

https://spring.io/tools

目的

通過這個服務來看eureka註冊中心的效果。

複習Spring Boot。

減少了大量配置。快速開發。

用Starter集成一個新框架。比如redis，web等。添加依賴，加配置文件。

嵌入式服務器，令開發和部署變的方便。

Spring Boot介紹：
https://docs.spring.io/spring-boot/docs/2.1.7.RELEASE/