任何微服務的容量都是有限的, 但是理想情況下一般的微服務應該只局限于服務器的數(shù)量(計算能力), 存儲的容量和網(wǎng)絡的帶寬.

當用戶的請求和用量增加時, 只要財務預算上沒有問題, 理論上是可以接近無限地擴展的.

實際上, 這個假定往往并不成立, 更大的數(shù)據(jù)量, 更多的請求, 更高的并發(fā)量, 你的服務會撐不住.

你會想到加內(nèi)存, 加存儲, 加帶寬, 加服務器, 然而事情沒那么容易, 你的應用的服務能力必須能夠隨著資源的增加而線性增加

由于單機的內(nèi)存, CPU 及帶寬畢竟有限, 所以盡量把你的服務設計成由多個相對獨立的, 無狀態(tài)的自治節(jié)點組成, 這樣你可以輕松地增加節(jié)點來應對不斷增長的服務請求

術(shù)語

• Scale up: 向上擴展或垂直擴展
• Scale out: 向外擴展或水平擴展
• Failover: 快速切換從 primary 節(jié)點或分區(qū)切換到 slave 節(jié)點或分區(qū), 以減小對用戶的影響
• Stateless: 無狀態(tài)的, 服務器節(jié)點本身不存儲狀態(tài), 好處在于可以隨時增加和減少節(jié)點, 有利于水平擴展
• Stateful: 有狀態(tài)的, 狀態(tài)總是存在的, 就看你把它放在哪里, 服務器內(nèi)存, 數(shù)據(jù)庫, 或共享的緩存服務器
• Sharding: 根據(jù)數(shù)據(jù)的分布特點以及用途, 將數(shù)據(jù)集分布在多個數(shù)據(jù)庫上來存儲, 以避免單機處理能力及存儲限制

要點

服務分離 Separation of services

從自給自足的小農(nóng)社會到現(xiàn)代化的社會化大分工, 單個人掌握的技能變少了, 不同的人有不同的分工和專長, 社會的生產(chǎn)效率大幅度提高了

微服務就是要把服務做小,做精, 專注于一個相對獨立的領(lǐng)域, 以利于分散風險, 和重用組合, 也有利于服務的擴展, 哪塊是瓶頸, 就優(yōu)化和擴展哪一塊，而不是所有服務器都要一起升級.

例如我要做一個網(wǎng)絡會議服務器，需要支持文字聊天，音頻視頻對話，桌面共享，文件分享，遠程控制，會議錄制等等，既有控制信令的處理，又有媒體的傳輸，編碼解碼和混音處理，如果都放在一起，可想而知，系統(tǒng)的復雜性大大增加不說，調(diào)優(yōu)和擴展很難做，音視頻的編碼解碼是極其耗費CPU 資源，允許丟包，而控制及文字聊天則不同，必須保證消息可靠傳達，所以還是各自分開為不同的服務為好

無狀態(tài) Stateless

狀態(tài)總是存在的, 關(guān)鍵看你把它放在哪里, 內(nèi)存里, 文件里, 數(shù)據(jù)表里, 還是緩存里?
假如我們把狀態(tài)放在單個服務器的內(nèi)存或文件系統(tǒng)中, 擴展起來就會非常麻煩, 高可靠性也有問題.

狀態(tài)需要在不同的服務器之間同步, 才能做到避免單點失敗, 每個服務器保持一致顯然不可能應對海量請求和數(shù)據(jù).

• 單臺獨有狀態(tài)
• 多臺同步狀態(tài)
• 外置共享狀態(tài)

只有第三種，你的服務器才可以隨意增加，線性擴展

數(shù)據(jù)分片 Data sharding

根據(jù)地理位置, 用戶組織或數(shù)據(jù)中心及服務區(qū)集群都可以進行數(shù)據(jù)分片, 假設你有多個客戶, 這些客戶分布在不同的地域, 不同的客戶服務請求和數(shù)據(jù)大小也不同, 如何進行數(shù)據(jù)分片呢?

假設你提供的服務是在線教育平臺, 域名是天天向上 www.day-day-up.com, 客戶是各個大大小小的補習班，以及一些在線的教育機構(gòu)。

你可以根據(jù)為不同的客戶(租戶tenant )進行數(shù)據(jù)分片

• 東方補習學校 https://east-school.day-day-up.com, 這個學校比較大, 有兩個大校區(qū):
  • 大中華區(qū)
  • 東南亞區(qū)

• 西方補習學校 https://west-school.day-day-up.com, 這個學校比較小, 只有一個主校區(qū)

于是, 我們有如下配置數(shù)據(jù)表, 放在一個中央數(shù)據(jù)庫中, 并緩存在 Redis 中

• Tenant 表

tenant_idtenant_nameexpire_date

d423b7f7-aa2f-40ee-afe7-6b4e5a245ff3	東方補習學校	2018-12-31
c5ae1066-522b-4cf3-aba7-923f72f7f07d	西方補習學校	2018-12-31

• Org 表

org_idorg_nametenant_id

b30bae13-75ca-4b3c-8998-2d46ba6f74ff	大中華區(qū)	d423b7f7-aa2f-40ee-afe7-6b4e5a245ff3
c3cd2f82-dde6-481d-b441-d7e4e50e3eb6	東南亞區(qū)	d423b7f7-aa2f-40ee-afe7-6b4e5a245ff3
b18dde72-de20-4952-b33c-73da44ebe95a	主校區(qū)	c5ae1066-522b-4cf3-aba7-923f72f7f07d

• Sharding 表

tenant_idorg_iddatabase_pool_id

d423b7f7-aa2f-40ee-afe7-6b4e5a245ff3	b30bae13-75ca-4b3c-8998-2d46ba6f74ff	ajpc_a1
d423b7f7-aa2f-40ee-afe7-6b4e5a245ff3	c3cd2f82-dde6-481d-b441-d7e4e50e3eb6	us_a1
d423b7f7-aa2f-40ee-afe7-6b4e5a245ff3	b30bae13-75ca-4b3c-8998-2d46ba6f74ff	ajpc_b1

• DbPool 表

db_pool_idprimary_db_poolbackup_db_pool

ajpc_a1	mysql://username:password@hosta1/mysqldb_name	mysql://username:password@hosta2/mysqldb_name
ajpc_b1	mysql://username:password@hostb1/mysqldb_name	mysql://username:password@hostb2/mysqldb_name
us_a1	mysql://username:password@hosta1_us/mysqldb_name	mysql://username:password@hosta1_us/mysqldb_name

小貼士 -- 快速生成 UUID
python -c 'import uuid; print uuid.uuid4();'

如何自動擴展和收縮

基本要求:

• 高峰期增加服務器，快速提供服務
• 低谷期減少服務器，提高資源效率
• 而增減服務器由監(jiān)控和分析程序來觸發(fā)

下面這個傳統(tǒng)結(jié)構(gòu)顯然不夠

根據(jù)Monitor 和 Metrics 系統(tǒng)所得出的結(jié)果決定, 實時增加服務器, 注冊到類似 Consul 的服務發(fā)現(xiàn)系統(tǒng)中, 利用它的服務發(fā)現(xiàn)和健康檢查功能, 用 consul-template 來刷新更改 HAProxy, Nginx 這樣的軟件負載均衡系統(tǒng)的配置文件并重載 ( F5 , NetScalar 這樣的硬件負載同理), 減少服務器也是一樣的過程.

如圖所示

當然, 你的服務器最好是無狀態(tài)的, 否則就很麻煩, 增加服務器時可能要做狀態(tài)同步, 關(guān)閉服務器時要先將服務器設為 suspend 狀態(tài), 不再接受新的服務, 等到所有服務在這臺服務器已經(jīng)結(jié)束了, 才能關(guān)機

參考資料

• Cloud Architecture Patterns for Mere Mortals by Bill Wilder
• Web Scalability for startup engineers
• https://cloud.google.com/solutions/autoscaled-load-balancing-using-haproxy-and-consul-on-compute-engine

作者：瓦爾特有范
鏈接：https://www.jianshu.com/p/3a7d9d34126f
來源：簡書
簡書著作權(quán)歸作者所有，任何形式的轉(zhuǎn)載都請聯(lián)系作者獲得授權(quán)并注明出處。

總結(jié)

以上是生活随笔為你收集整理的微服务实战之扩展性的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。