Udemy 課程Microservices with Spring Cloud 25

簡介Microservice與其挑戰，及簡介Spring Cloud

目前沒有完全準確的Microservices的定義

只提供一些基本觀點來描述Microservices:

1. 透過REST來暴露的服務
2. 深思熟濾過的邊界，極小化且精挑細選的可部署單位
3. 可雲端化(Cloud Enabled)

以下為一組Microservice架構，有各自的邊界，但又互相影響

而以下為可雲端化的一組Microservice架構

右側藍色是對應的實例(如OCP節點(pod))

A1與A2為Microservice的實例，以此類推

可雲端化是指，我可以在容易地下架如上B4或B3

或是可以新增C2或新增C3實例，

而不會有太大問題，且不用牽設到太多的設定問題

建置Microservice的挑戰

1. BOUNDED CONTEXT

我們該如何定義各個微服務邊界

亦即MicroserverN可以做什麼?不可以做什麼?

定義微服務邊界將會是一個持續進化的過程

不用期望第一次就能定出完美的邊界

只能持續的加強相關邏輯知識(ex:domain knowledge)

2. CONFIGURATION MANAGEMENT

有上百個微服務，甚至對應一堆實例對應多個環境

比如說有10個微服務對應有5個不同環境，且有50個實例

光要維護就困難

3. DYNAMIC SCALE UP AND SCALE DOWN

每個微服務的loading依據實例的數量、時間點不同，都可能不同

依據不同需求流量，要求不同的實例(節點)數量

甚至可以確定多個實例的微服務的負載量真的有充分使用

4. VISIBILITY

比如前面一連串的一組微服務(如下圖)

其中有一個出bug，你怎麼確認?

所以需要要集中化的log機制

假設今天有上百個微服務，其中一個異常，怎麼確認?

尤其許多微服務又互相牽連的寫法架構下，確認將更加困難

甚至單一個微服務掛了?

5. PACK OF CARDS

微服務架構互相依賴

如上面五個微服務圖

微服務1呼叫微服務2，微服務2又呼叫微服務3...依此類推

當今天微服務5掛掉，等於五個全掛

這考驗微服務的容錯率

Spring Cloud

Spring Cloud不完全是指某個Project

而是多個Project在Spring Cloud的雨傘下

goolge spring cloud

上面括起來文字描述:

Spring Cloud為開發人員提供了快速構建分佈式系統中一些常見模式的工具

該網頁往下拉會見到:

一堆與spring cloud相關的不同project

其中重要的如Spring Cloud Netflix...等

基本可能架構如下

我們可能有多個微服務專案(如上圖有三個)

而且有一個專門提供相關環境設定的Server專案，專門管理環境設定

這樣也比較好管理環境相關設定

而針對單一個微服務來說，我們尚需偵測其實例負載量

所以需要有DYNAMIC SCALE UP AND SCALE DOWN機制

所以需要以下:

1. Naming Server(Eureka)
2. Ribbon(Client Side Load Balancing)
3. Fegin(Easier REST Clients)

Naming Server(Eureka)負責所有微服務的註冊

(待編輯54課)