Spring Cloud入門01

系統架構演變

随着網際網路的發展，網站應用的規模不斷擴大。需求的激增，帶來的是技術上的壓力。系統架構也是以 也不斷的演進、更新、疊代。 從單一應用，到垂直拆分，到分布式服務，到SOA，以及現在火熱的微服務架構。

當網站流量很小時，隻需一個應用，将所有功能都部署在一起，以減少部署節點和成本，此時，用于簡 化增删改查工作量的資料通路架構(ORM)是影響項目開發的關鍵。

存在問題：

代碼耦合，開發維護困難

無法針對不同子產品進行針對性優化

無法水準擴充

單點容錯率低，并發能力差

當通路量逐漸增大，單一應用無法滿足需求，此時為了應對更高的并發和業務需求，我們根據業務功能 對系統進行拆分

優點

系統拆分實作流量分流，解決了并發問題

可針對不同子產品進行優化

友善水準擴充，負載均衡，容錯率提高

缺點

系統間互相獨立，有很多重複工作，影響開發效率

當垂直應用越來越多，應用之間互動不可避免，将核心業務抽取出來，作為獨立的服務，逐漸形成穩定 的服務中心， 使前端應用能更快速的響應多變的市場需求。此時，用于提高業務複用及整合的分布式調用是關鍵。

分布式：将不同的業務子產品部署到不同伺服器上，每個子產品各種獨立，單獨部署（SOA架構）

将基礎服務進行抽取，系統間互相調用，提高了代碼複用和開發效率

系統間耦合變高，調用關系錯綜複雜，難以維護

當服務越來越多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增加一個排程中心基于通路 壓力實時管理叢集容量，提高叢集使用率。此時，用于提高機器使用率的資源排程和治理中心(SOA)是關鍵

以前出現了什麼問題？ ·

服務越來越多，需要管理每個服務的位址 ·

調用關系錯綜複雜，難以理清依賴關系 ·

服務過多，服務狀态難以管理，無法根據服務情況動态管理

服務治理要做什麼？

服務注冊中心，實作服務自動注冊和發現，無需人為記錄服務位址

服務自動訂閱，服務清單自動推送，服務調用透明化，無需關心依賴關系 ·

動态監控服務狀态監控報告，人為控制服務狀态

缺點：

服務間會有依賴關系，一旦某個環節出錯會影響較大

服務關系複雜，運維、測試部署困難，不符合DevOps（開發部署等一體化）思想

相對于分布式，粒度更細，完全都可以單獨部署，獨立運作。

微服務是一種架構模式或者一種架構風格，提倡将單一應用程式劃分成一組小的服務獨立部署，服務之 間互相配合、互相協調，每個服務運作于自己的程序中。 服務與服務間采用輕量級通訊，如HTTP的RESTful API等 避免統一的、集中式的服務管理機制

每個服務足夠内聚，足夠小，比較容易聚焦

開發簡單且效率高，一個服務隻做一件事情

開發團隊小，一般2-5人足以（當然按實際為準）

微服務是松耦合的，無論開發還是部署都可以獨立完成

微服務能用不同的語言開發

易于和第三方內建，微服務允許容易且靈活的自動內建部署（持續內建工具有 Jenkins,Hudson,bamboo等）

微服務易于被開發人員了解，修改和維護，這樣可以使小團隊更加關注自己的工作成果，而無需一 定要通過合作才能展現價值

微服務允許你融合最新的技術

微服務隻是業務邏輯的代碼，不會和HTML,CSS或其他界面元件融合。

每個微服務都可以有自己的存儲能力，資料庫可自有也可以統一，十分靈活。

開發人員要處理分布式系統的複雜性

多服務運維難度，随着服務的增加，運維的壓力也會增大

依賴系統部署

服務間通訊的成本

資料的一緻性

系統內建測試

性能監控的難度

遠端調用方式

無論是微服務還是SOA，都面臨着服務間的遠端調用。

常見遠端調用

RPC：Remote Produce Call遠端過程調用，類似的還有RMI(Remote Method Invocation，遠端 方法調用)。自定義資料格式，基于原生TCP通信，速度快，效率高。早期的webservice，現在熱門 的dubbo，都是RPC的典型

HTTP：：http其實是一種網絡傳輸協定，基于TCP，規定了資料傳輸的格式。現在用戶端浏覽器與服 務端通信基本都是采用Http協定。也可以用來進行遠端服務調用。缺點是消息封裝臃腫。現在熱門 的Rest風格，就可以通過http協定來實作。

RPC，即 Remote Procedure Call（遠端過程調用），是一個計算機通信協定。 該協定允許運作于一台 計算機的程式調用另一台計算機的子程式，而程式員無需額外地為這個互動作用程式設計。 說得通俗一點就是：A計算機提供一個服務，B計算機可以像調用本地服務那樣調用A計算機的服務。

實作RPC主要是做到兩點：

實作遠端調用其他計算機的服務

像調用本地服務一樣調用遠端服務

Http協定：超文本傳輸協定，是一種應用層協定。規定了網絡傳輸的請求格式、響應格式、資源定位和 操作的方式等。但是底層采用什麼網絡傳輸協定，并沒有規定，不過現在都是采用TCP協定作為底層傳 輸協定。說到這裡，大家可能覺得，Http與RPC的遠端調用非常像，都是按照某種規定好的資料格式進 行網絡通信，有請求，有響應。沒錯，在這點來看，兩者非常相似，但是還是有一些細微差别。

RPC并沒有規定資料傳輸格式，這個格式可以任意指定，不同的RPC協定，資料格式不一定相同。

Http中定義了資源定位的路徑，RPC中并不需要

RPC需要滿足像調用本地服務一樣調用遠端服務，也就是對調用過程在API層面進 行封裝。Http協定沒有這樣的要求，是以請求、響應等細節需要自己去實作。

優點：RPC方式更加透明，對使用者更友善。Http方式更靈活，沒有規定API和語言，跨語言、跨平台

缺點：RPC方式需要在API層面進行封裝，限制了開發的語言環境

速度來看，RPC要比http更快，雖然底層都是TCP，但是http協定的資訊往往比較臃腫，不過可以采用 gzip壓縮。

難度來看，RPC實作較為複雜，http相對比較簡單

· 靈活性來看，http更勝一籌，因為它不關心實作細節，跨平台、跨語言。

微服務，更加強調的是獨立、自治、靈活。而RPC方式的限制較多，是以微服務架構中，一般都會采用 基于Http的Rest風格服務。

RestFul風格：在相同的URI（http://xxx:xx）下采用不同的請求方式(GET、POST、PUT、DELETE)完成不同操作（查詢、插入、修改、删除），不同的表示方式稱為RestFul風格

Spring Cloud入門概述

Spring的三大子產品：SpringBoot（建構），Spring Cloud（協調），Spring Cloud Data Flow（連接配接）

Spring Boot 是 Spring 的一套快速配置腳手架，可以基于Spring Boot 快速開發單個微服務，Spring Cloud是一個基于Spring Boot實作的雲應用開發工具；

Spring Boot專注于快速友善開發單個微服務個體，Spring Cloud關注全局的服務治理架構，它将 SpringBoot開發的一個個微服務整合并管理起來，為各個服務之間提供 服務發現、負載均衡、斷路器、 路由、配置管理、微代理，消息總線、全局鎖、分布式會話等內建服務；

Spring Boot使用了預設大于配置的理念，很多內建方案已經幫你選擇好了，能不配置就不配置，Spring Cloud很大的一部分是基于Spring Boot來實作，可以不基于Spring Boot嗎？不可以。 Spring Boot可以離開Spring Cloud獨立使用開發項目，但是Spring Cloud離不開Spring Boot，屬于依 賴的關系。

服務發現——Netflix Eureka

服務調用——Netflix Feign

熔斷器——Netflix Hystrix

服務網關——Netflix Zuul

分布式配置——Spring Cloud Config

消息總線 —— Spring Cloud Bus

服務發現元件Eureka

Eureka 是Spring Cloud Netflix 微服務套件中的一部分， 它基于Netflix Eureka 做了二次封裝， 主要負 責完成微服務架構中的服務治理功能。我們隻需通過簡單引入依賴和注解配置就能讓Spring Boot 建構 的微服務應用輕松地與Eureka 服務治理體系進行整合。

Eureka包含兩個元件：Eureka Server和Eureka Client。

Eureka Server提供服務注冊服務。

Eureka Client是一個java用戶端，用來簡化與Eureka Server的互動、用戶端同時也就是一個内置的、使用輪詢(round-robin)負載算法的負載均衡器。

Eureka的服務剔除與保護機制

注冊到eureka的服務可能由于記憶體溢出或網絡故障等原因使得服務不能正常的工作，而服務注冊中心并 未收到“服務下線”的請求。服務注冊中心在啟動時會建立一個定時任務，預設每隔一段時間（預設為60 秒）将目前清單中逾時（預設為90秒）沒有續約的服務剔除，這個操作被稱為失效剔除。

關停一個服務，很可能會在Eureka面闆看到一條警告

這是觸發了Eureka的自我保護機制。當服務未按時進行心跳續約時，Eureka會統計服務執行個體最近15分鐘 心跳續約的比例是否低于了85%。

在生産環境下，因為網絡延遲等原因，心跳失敗執行個體的比例很有可能超标，但是此時就把服務剔除清單 并不妥當，因為服務可能沒有當機。

Eureka在這段時間内不會剔除任何服務執行個體，直到網絡恢複正常。生産環境下這很有效，保證了大多數 服務依然可用，不過也有可能擷取到失敗的服務執行個體，是以服務調用者必須做好服 務的失敗容錯。