天天看點

微服務應用技術總結

為什麼要用微服務?

随着業務擴充、人員增長,單體式應用有以下問題:

  1. 團隊協作效率低下
  2. 部署釋出慢
  3. 業務之間耦合度高,可用性差

微服務的好處

  1. 獨立部署
  2. 獨立維護
  3. 業務低耦合

單體應用拆分方式

1、縱向拆分是從業務次元進行拆分。标準是按照業務的關聯程度來決定,關聯比較密切的業務适合拆分為一個微服務,而功能相對比較獨立的業務适合單獨拆分為一個微服務。

2、橫向拆分是從公共且獨立功能次元拆分。标準是按照是否有公共的被多個其他服務調用,且依賴的資源獨立不與其他業務耦合。

拆分前需要思考的

1、用什麼協定通訊

2、如何釋出訂閱

3、如何監控

4、服務如何治理

5、故障如何定位

一次正常的服務調用

微服務應用技術總結

1、【服務注冊】首先服務提供者向注冊中心注冊服務,聲明自己能夠提供哪些服務以及服務的位址是什麼,完成服務釋出。

2、【可用服務查詢】接下來服務消費者,從注冊中心查詢所需要調用服務的位址,

3、【調用,序列化和反序列化】調用方以約定的通信協定向服務提供者發起請求,得到請求結果後再按照約定的協定解析結果。

依賴的基礎元件:

  1. 服務描述:常用的服務描述方式包括 RESTful API、XML 配置以及 IDL 檔案三種。
  2. 注冊中心:解決服務的釋出和訂閱,工作流程如下:
    • 服務提供者在啟動時,根據服務釋出檔案中配置的釋出資訊向注冊中心注冊自己的服務。
    • 服務消費者在啟動時,根據消費者配置檔案中配置的服務資訊向注冊中心訂閱自己所需要的服務。
    • 注冊中心傳回服務提供者位址清單給服務消費者。
    • 當服務提供者發生變化,注冊中心将變更通知給服務消費者。
      微服務應用技術總結
  3. 服務架構
  4. 服務監控
    • 名額收集
    • 資料處理
    • 資料展示
  5. 服務追蹤
    • 首次調用生成requestId
    • 每次調用繼續傳輸requestId
  6. 服務治理
    • 單點故障
    • 單idc故障
    • 依賴服務不可用

資料序列化和反序列化

  1. 常用的序列化方式分為兩類:文本類如 XML/JSON 等,二進制類如 PB/Thrift 等
  2. 選型:
    • 資料結構豐富度
    • 跨語言特性
    • 性能:主要看兩點,一個是序列化後的壓縮比,一個是序列化的速度。以常用的 PB 序列化和 JSON 序列化協定為例來對比分析,PB 序列化的壓縮比和速度都要比 JSON 序列化高很多,是以對性能和存儲空間要求比較高的系統選用 PB 序列化更合适;而 JSON 序列化雖然性能要差一些,但可讀性更好,更适合對外部提供服務。

      Proto Buf https://www.ibm.com/developerworks/cn/linux/l-cn-gpb/index.html

資料監控:

  • 監控對象:
    • 用戶端監控
    • 接口監控
    • 資源監控
    • 基礎監控
  • 監控名額:
    • 請求量(QPS)
    • 響應時間 TP90 TP99 TP 999
    • 錯誤率
  • 監控緯度
    • 全局緯度
    • 分機房緯度
    • 單機緯度
    • 時間緯度
    • 核心緯度

服務治理有哪些手段:

  • 節點管理:
    • 注冊中心主動摘除
    • 服務消費者摘除機制
  • 負載均衡
    • 随機算法
    • 輪訓算法
    • 最少活躍調用算法
    • 一緻性hash算法
  • 路由規則:
    • 灰階釋出
    • 多IDC通路問題
    • 配置方案:
  • 服務容錯的幾個手段:
    • FailOver
    • FailBack
    • FailCache
    • FailFast

注冊中心選型:

選型基本要求:

  1. 高可用
    • 多IDC部署
    • 叢集部署

2.資料一緻性:多資料中心資料保持一緻

CAP 理論:即同時滿足一緻性、可用性、分區容錯性這三者是不可能的,其中 C(Consistency)代表一緻性,A(Availability)代表可用性,P(Partition Tolerance)代表分區容錯性。

CP 型注冊中心,犧牲可用性來保證資料強一緻性,最典型的例子就是 ZooKeeper,etcd,Consul 了。ZooKeeper 叢集内隻有一個 Leader,而且在 Leader 無法使用的時候通過 Paxos 算法選舉出一個新的 Leader。這個 Leader 的目的就是保證寫資訊的時候隻向這個 Leader 寫入,Leader 會同步資訊到 Followers,這個過程就可以保證資料的強一緻性。但如果多個 ZooKeeper 之間網絡出現問題,造成出現多個 Leader,發生腦裂的話,注冊中心就不可用了。而 etcd 和 Consul 叢集内都是通過 raft 協定來保證強一緻性,如果出現腦裂的話, 注冊中心也不可用。

AP 型注冊中心,犧牲一緻性來保證可用性,最典型的例子就是 Eureka 了。對比下 Zookeeper,Eureka 不用選舉一個 Leader,每個 Eureka 伺服器單獨儲存服務注冊位址,是以有可能出現資料資訊不一緻的情況。但是當網絡出現問題的時候,每台伺服器都可以完成獨立的服務。

繼續閱讀