系統架構演變

隨著網際網路的發展，網站應用的規模不斷擴大。需求的激增，帶來的是技術上的壓力。系統架構也因此 也不斷的演進、升級、迭代。 從單一應用，到垂直拆分，到分散式服務，到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

概念

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

作用體現

• 實現RPC主要是做到兩點：
  • 實現遠端呼叫其他計算機的服務
  • 像呼叫本地服務一樣呼叫遠端服務

認識HTTP

概念

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

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 Cloud介紹

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，屬於依 賴的關係。

Spring Cloud主要框架

服務發現——Netflix Eureka

服務呼叫——Netflix Feign

熔斷器——Netflix Hystrix

服務閘道器——Netflix Zuul

分散式配置——Spring Cloud Config

訊息匯流排 —— Spring Cloud Bus

服務發現元件Eureka

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在這段時間內不會剔除任何服務例項，直到網路恢復正常。生產環境下這很有效，保證了大多數 服務依然可用，不過也有可能獲取到失敗的服務例項，因此服務呼叫者必須做好服 務的失敗容錯。