springcloud

時間 2019-12-09

標籤 springcloud 简体版

原文原文鏈接

中文文檔：https://springcloud.cc/spring-cloud-dalston.html

訪問eureka不用加項目名： http://localhost:8761/

1. 與dubbo對比

2.服務架構

Eureka:服務註冊中心,完成服務註冊、發現、調用

訪問http s://start.spring.io 出現一直失敗時,可改爲http形式

Eureka Server：做爲註冊中心,提供給服務註冊，mvn clean package後可到對應eureka項目目錄下打成jar包,經過java -jar eureka.jar啓動做爲服務

Eureka Client:服務提供者和消費者

@EnableEurekaClient

Ribbon:完成負載均衡；RestTemplate、Feign、Zuul都使用到了Ribbon，@LoadBalanced

a.服務發現 b.服務選擇 c.服務監聽

ServerList獲取服務列表,再經過ServerListFilter過濾部分服務,最後經過IRule選擇一個實例做爲最終目標

Zuul:實現網關做用,反爬蟲等做用

Hystrix:實現服務熔斷、降級(資源緊張時,下調非必要服務)、限流

Hystrix Dashboard:服務流量管控臺

Config Server:管理配置

Sleuth：請求日誌、服務請求時長等

3.請求耗時比較

4.Eureka架構：

Application Service:向Eureka Server完成服務提供

Application Client:從Eureka Server調用服務

Eureka Server:服務註冊中心

分佈式系統中爲何須要服務發現？

微服務的特色：異構

1.不一樣語言

2.不一樣類型的數據庫

服務拆分理論：如何拆"數據"

1.每一個服務都有單獨的數據存儲

2.依據服務特色選擇不一樣的結構選擇的數據庫類型

3.難點在於邊界

5.springCloud常見異常： http://www.javashuo.com/article/p-glpdbksj-gx.html

服務註冊到eureka後,不重啓沒法清理服務列表？

兩個提供者，分別8100和8200

6.服務如何拆分：

起點：既有架構的形態

終點：好的架構不是設計出來的，而是進化(演化)而來的

適不適合微服務？

業務形態不適合的：

1.系統中包含不少強事務場景 2.業務想對穩定、迭代週期長 3.訪問壓力不大，可用性要求不高

康威定律:任何組織在設計一套系統(廣義概念上的系統)時，所交付的設計方案在結構上都與該組織的溝通結構保持一致。

微服務的特色：

1.一系列的微小的服務共同組成 2.單獨部署，跑在本身的進程裏 3.每一個服務爲獨立的業務開發 4.分佈式的管理

服務拆分的方法論：

如何拆分功能：

1.單一職責、鬆耦合、高內聚

2.關注點分離(職責(訂單)、通用性(消息)、粒度)

服務和數據的關係：

1.先考慮業務功能，再考慮數據

2.無狀態服務(有->無)

啓動client錯誤： https://blog.csdn.net/solocoder/article/details/82182533

啓動兩個client,須要配置不一樣的端口，不然都會去使用8080,後啓動的會報錯

server配置了server.port，client若是也要配置server.port，二者端口不能同樣。

7.服務間調用：

RestTemplate:

第一種：

第二種：

第三種：

Feign:注意pom依賴版本,僞RPC，聲明式加註解式RPC

當無參、@RequestParam、 @PathVariable可以使用GetMapping

服務調用方：

服務提供方：

應用間通訊：經過客戶端負載均衡器 Ribbon

1.ServerList->IRule->ServerListFilter

2.RestTemplate, Feign Zuul都用到了Ribbon(@LoadBalance)

8.配置中心：遠端git->config server->本地git

a.爲何要用配置中心：不方便維護，配置內容安全與權限，更新配置項目須要重啓

b.當作eureka客戶端，註冊到eureka，增長@EnableDiscoveryClient和@EnableConfigServer

c.git倉庫建立config.yml，啓動配置中心後瀏覽器訪問：http://localhost:8080/config -a.yml(-a的a可隨意,但必定要寫一個)

d.客戶端讀取配置中心數據：配置中心config.yml可做爲config-dev.yml的通用配置，否則每次都會被加載過來,但不能自動刷新

e.spring cloud bus能支持自動刷新，增長完spring-cloud-bus組件後，在rabbitmq上會相應多一個隊列

config項目上增長就能暴露 /bus-refresh；客戶端增長@RefreshScope

9.異步：客戶端請求不會阻塞進程，服務端的響應能夠是非即時的

常見形式：1.通知 2.請求/異步響應 3.消息(MQ)

MQ應用場景：1.異步處理：用戶註冊後發短信、加積分等 2.流量削峯：秒殺 3.日誌處理(最多見kafka) 4.應用解耦：訂單系統完成下單,發消息到商品服務扣庫存等

rabbitMq:需管控臺新建隊列myQueue，增長queuesToDeclare可自動建立隊列

10.maven依賴自動補全： File->setting->maven->repositories，選擇本地倉庫，點擊右上角更新，更新maven倉庫索引

springCloud對消息中間件進行封裝，代碼層面作到對中間件無感知，目前Binder支持rabbitmq(項目啓動時會管控臺會多一個myMessage隊列)和kafka；

發送方：

@RestController
public class MessageProductController {
    @Autowired
    private StreamClient  streamClient;
    @GetMapping("/sendMessage")
    public void process(){
        streamClient.output().send(MessageBuilder.withPayload("aa").build());
    }
}