微服務

微服務架構風格，就像是一把一個單獨的應用程式開發為一套小服務，每個小服務執行在自己的程序中，並使用輕量級機制通訊，通常是 HTTP API。這些服務圍繞業務能力來構建，並通過完全自動化部署機制來獨立部署。這些服務使用不同的程式語言書寫，以及不同資料儲存技術，並保持最低限度的集中式管理。
簡而言之：拒絕大型單體應用，基於業務邊界進行服務微化拆解，各個服務獨立部署執行

叢集&分散式&節點

• 叢集是個物理形態，分散式是個工作方式
• 只要是一堆機器，就可以叫叢集，他們是不是一起協作著幹活，這個誰也不知道
• 《分散式系統原理與範圍》定義：“分散式系統是若干獨立計算機的集合，這些計算機對於使用者來說就像單個相關係統”，分散式系統是建立在網路之上的軟體系統
• 分散式是指將不同的業務分佈在不同的地方
• 叢集指的是將幾臺伺服器集中在一起，實現同一業務

例如：京東是一個分散式系統，眾多業務執行在不同的機器，所有業務構成一個大型的業務叢集。每一個小的業務，比如使用者系統，訪問壓力大的時候一臺伺服器是不夠的。我們就應該將使用者系統部署到多個伺服器，也就是每一個業務系統也可以做叢集化

分散式中的每一個節點，都可以做叢集，而叢集並不一定就是分散式的

節點：叢集中的一個伺服器

遠端呼叫

在分散式系統中，各個服務可能處於不同主機，但是服務之間不可避免的需要互相呼叫，我們稱之為遠端呼叫

SpringCloud 中使用 HTTP + JSON 的方式完成呼叫

負載均衡

分散式系統中，A 服務需要呼叫 B 服務，B 服務在多臺機器中都不存在，A 呼叫任意一個伺服器均可以完成功能
為了使每一個伺服器都不要太忙或者太閒，我們可以負載均衡的呼叫每一個伺服器，提升網站的健壯性

常見的負載均衡演算法:

• 輪詢：為第一個請求選擇健康池中的第一個後端伺服器，然後按順序往後依次選擇，直到最後一個，然後迴圈
• 最小連線：優先選擇連線數最少，也就是壓力最小的後端伺服器，在會話較長的情況下 可以考慮採取這種方式
• 雜湊：根據請求源的 IP 的雜湊（hash）來選擇要轉發的伺服器。這種方式可以一定程 度上保證特定使用者能連線到相同的伺服器。如果你的應用需要處理狀態而要求使用者能連線到和之前相同的伺服器，可以考慮採取這種方式。

服務註冊/發現&註冊中心

A 服務呼叫 B 服務，A 服務並不知道 B 服務當前在哪幾臺伺服器有，哪些正常的，哪些服務已經下線。解決這個問題可以引入註冊中心

如果某些服務下線，我們其他人可以實時的感知到其他服務的狀態，從而避免呼叫的不可用的服務

配置中心

每一個服務最終都有大量的配置，並且每個服務都可能部署在多臺機器上。我們經常需要變更配置，我們可以讓每個服務在配置中心獲取自己的配置

配置中心用來集中管理微服務的配置資訊

服務熔斷&服務降級

在微服務架構中，微服務之間通過網路進行通訊，存在相互依賴，當其中一個服務不可用時，有可能會造成雪崩效應。要防止這樣的情況，必須要有容錯機制來保護服務。

• 服務熔斷
  設定服務的超時，當被呼叫的服務經常失敗到達某個閾值，我們可以開啟斷路保護機制，後來的請求不再去呼叫這個服務。本地直接返回預設的資料
• 服務降級
  在運維期間，當系統處於高峰期，系統資源緊張，我們可以讓非核心業務降級執行。降級：某些服務不處理，或者簡單處理【拋異常、返回 NULL、 呼叫 Mock 資料、呼叫 Fallback 處理邏輯】

API 閘道器

在微服務架構中，API Gateway 作為整體架構的重要元件，它抽象了微服務中都需要的公共功能，同時提供了客戶端負載均衡，服務自動熔斷，灰度釋出，統一認證，限流流控，日誌統計等豐富的功能，幫助我們解決很多 API 管理難題

參考文件

尚矽谷穀粒商城