微服務之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解決服務雪崩緣由