微服務之SpringCloud基礎

SpringCloud微服務基礎

微服務架構--SpringCloud
網站架構模式
單點應用/分散式系統面向於服務架構(SOA) /微服務架構
web項目
三層架構
1.控制層
2.業務邏輯層
3.數據訪問層
傳統項目：代碼全部在一個項目中，使用包名來區分
com.controller--控制
com.service--業務邏輯層
com.dao--數據訪問層

面向服務架構 公司
（如果互聯網公司，如果使用傳統架構技術開發代碼衝突，拆分項目）
1.分散式開發：將一個大的公司，拆分成n個子項目。
會員系統/支付系統/消息系統/微信系統
2.集群：將一個項目，相同功能部署在多台不同伺服器。
作用：解決高併發。

分散式架構就是將一個項目拆分成n多個子項目，每個子項目使用rpc遠程調用技術。
你用過哪些rpc遠程調用框架
SpringCloud/HttpClient/hessioan/dubbo
面向於微服務架構(SOA),通信協議SOAP SOAP http協議+xml序列號與反序列化
銀行使用webservice

反向代理伺服器
nginx
a.tomcate01
b.tomcate02

c.客戶端

SOA服務項目，提供外部訪問介面
提供外部訪問介面
(業務邏輯層和數據訪問層)

web工程-->rpc遠程調用
(控制層)

面向於服務架構優點：代碼服務/解耦，適合於大公司人多。
缺點：網路延遲，維護複雜，不好整合，編寫複雜
小公司 傳統項目
--------------------------------------------------------------------------------

微服務架構（分散式架構）
是在傳統soa架構領域升級
微--細分，輕量級，通訊協議http協議+rest風格+json
每個服務都是獨立運行

來源
1.移動端(安卓/ios端) pc端 h5端（手機瀏覽器）

2.H5工程 PC工程 混合工程 （RPC遠程調用 http協議+json格式+rest互聯網公司 httpclient）
使用比較簡單通信 使用httpclient[ 介面只允許在內網進行訪問，和外網介面進行對接https]
微服務架構與面向於服務架構區別：
面向於服務架構（SOA）主要針對於在銀行xml格式 企業級 ESP服務
微服務系統，會更加細分，Http+json+rest進行 輕量級 獨立運行 解耦

介面項目
3.會員服務 訂單服務 支付服務
（每個服務--對應一個資料庫）
主流：rpc解決框架dubbo/springcloud

--------------------------------------------------------------------------------

介面地址怎麼管理？http://member.itmayiedu.com/api/user
容錯機制/負載均衡/網關/路由策略/高併發情況下，怎麼介面限流/斷路
微服務解決框架--SpringCloud

SpringCloud解決什麼樣的問題？
配置管理（註冊中心eureka/zk）/服務發現/服務註冊/斷路器/路由策略/負載均衡/全局鎖（比如：redis）/分散式會話/客戶端調用/介面網關（ZUUL）/服務管理系統
----學習SpringCloud

rpc遠程調用
SpringBoot與SpringCloud
SpringBoot簡化xml配置，快捷整合框架
SpringCloud 是一套微服務解決方案--RPC遠程調用
關係SpringCloud依賴介面(SpringMVC)依賴與SpringBoot SpringMVC --介面

--------------------------------------------------------------------------------

SpringCloud技術流
1.SpringCloud註冊中心環境搭建euraka
2.服務註冊與發現
3.SpringCloud客戶端調用
rest/feign 客戶端調用工具
ribbon 負載均衡
zuul介面網關
eureka服務註冊

案例：會員服務提供用戶信息/訂單服務 查詢訂單
訂單服務需要查詢用戶，訂單服務調用會員服務介面

註冊中心（euraka）

會員服務（提供介面，服務提供者）-->註冊服務-->註冊中心（euraka）
訂單服務（調用介面，服務消費者）-->調用註冊中心(euraka)-->消費-->會員服務

編寫會員服務

編寫訂單服務

SpringCloud調用服務原理

負載均衡

怎麼實現負載均衡 nginx/lvs/HAproxy/F5
SpringCloud中負載均衡

什麼事介面網關？？
介面網關作用攔截請求 類似ngix（配置一些攔截策略）

qianduan.itmayiedu.com
來源渠道（H5端調用）
ajax1 member.itmayiedu.com
ajax2 order.itmayiedu.com
跨域問題

使用項目名稱區分介面網關轉發到實際地址
www.itmayiedu.com/member
www.itmayiedu.com/order
SpringCloud里的zuul介面網關
介面網關作用：攔截所有請求，任何請求先交給介面網關，然後再用網管進行轉發nginx 反向代理

member.itmayiedu.com
會員服務

order.itmayiedu.com
訂單服務

使用Zuul搭建服務介面網關

介面網關：解決跨域問題

分散式配置文件中心概述
開發中，怎麼區分環境？ dev測試環境/pre 預發佈/prd正式生產環境
調用第三方介面，alibaba.alibaba/api使用httpclient進行調用。配置信息，存放在配置文件中。
配置信息，存在配置中。需要重新發佈版本。
java代碼讀取配置，存放在永久區，static 修飾。缺點

1.將值存在緩存中，資料庫中備份。
2.後臺搭建一套可視化管理配置文件項目。
3.讀取流程先從緩存中讀取，緩存沒有在讀取資料庫。
4.緩存與資料庫值不同步怎麼解決，清理緩存。
將配置文件信息，存放在版本控制(git/svn)springcloud就是使用這種機制。

遠程地址

分散式配置文件中心（git）
dev文件--userName=itmayiedu
pre文件--userName=itmayiedu
prd文件--userName=itmayiedu

server-config
配置服務項目

會員服務工程

會員工程-->配置服務項目-->分散式配置文件中心

訂單服務工程

訂單工程-->配置服務項目-->分散式配置文件中心

1.遠程地址git主要存放配置文件信息
2.server-config主要緩存配置文件信息，可以被其他調用

搭建分散式配置中心

1.SpringCloud微服務解決框架RPC遠程調用
2.eureka註冊中心 ridbbon負載均衡客戶端 zuul網關 分散式配置中心
3.客戶端調用工具rest feign
feigin客戶端調用,SpringCloud斷路器Hystrix
服務降級/熔斷機制/限流

服務雪崩效應產生原因
SpringCloud Hystrix斷路器

SpringCloud hystrix 熔斷機制/服務降級/服務限流/解決服務雪崩效應

什麼是服務雪崩效應？

客戶端(同一時刻有51個請求)

tomcat伺服器

會員工程

user/login
user/get

（訂單功能需要訂單會員工程查詢）

訂單工程

order/getOrder【tomcate最大線程數50個】 依賴服務 user/get[每次需要3秒進行響應]
order/addOrder 請求等待（轉圈）/

雪崩效應：所有請求在處理一個服務，不能訪問其他服務介面。
1.使用超時機制，服務降級（）
服務降級：服務調用介面的時候，如果發生錯誤或者超時，不讓調用介面，調用本fallback。
服務一旦發生錯誤/超時的時候，返回請求過時或者錯誤。

jmeter做壓力測試的一個工具

雪崩效應解決辦法

1.服務雪崩，產生服務堆積等待，導致其他服務介面無法訪問。
2.如何解決服務雪崩效應
a.超時機制--服務降級處理
服務降級：服務介面發生錯誤，不去調用介面，調用本地方法 SrpingBoot的fallback
b.熔斷機制 類似於保險絲
熔斷機制 就是為瞭解決服務高併發，一旦達到規定請求，的時候，熔斷，報錯。--服務降級
c.隔離機制：每個服務介面隔離開
c1介面

線程池

c2介面

線程池

d.限流機制：nginx 使用網關

使用hystrix實現服務降級

SpringCloud hystix短容器 ：當我們使用RPC遠程調用的時候，超時，解決服務雪崩效應，
專門解決服務與服務之間報錯信息。

hystix斷路器 裡面包含服務降級，熔斷機制，隔離資源。

使用hystix解決服務雪崩原因