14、服務(wù)化：微服務(wù)架構(gòu)，究竟解決什么問題？

• no14：在服務(wù)化前后的互聯(lián)網(wǎng)的常見架構(gòu)示意圖
  • 服務(wù)化前
  • 服務(wù)化后
• no14：沒有服務(wù)化前的痛點(diǎn)
  • 1.代碼到處拷貝
  • 2.底層復(fù)雜性擴(kuò)散
  • 3.公共庫(kù)耦合
  • 4.SQL 質(zhì)量無(wú)法保障
  • 5.不易擴(kuò)展，數(shù)據(jù)庫(kù)耦合
• no14：服務(wù)化的好處
  • 1.復(fù)用性，消除代碼拷貝
  • 2.專注性，防止復(fù)雜性擴(kuò)散
  • 3.解耦合，消除公共庫(kù)耦合
  • 4.高質(zhì)量，SQL 穩(wěn)定性有保障
  • 5.易擴(kuò)展，消除數(shù)據(jù)庫(kù)解耦合
  • 6.(最重要)高效，對(duì)業(yè)務(wù)調(diào)用方的研發(fā)效率提升了
• no14：服務(wù)化后的潛在問題有哪些？
  • 1.系統(tǒng)復(fù)雜性上升
  • 2.層次間依賴關(guān)系變得復(fù)雜
  • 3.運(yùn)維，部署更麻煩
  • 4.監(jiān)控變得更復(fù)雜
  • 5.定位問題更麻煩

15、服務(wù)化：微服務(wù)架構(gòu)，粒度多少合適？

• no15：微服務(wù)化架構(gòu)粒度拆分實(shí)踐一：統(tǒng)一服務(wù)層
  • 業(yè)務(wù)不是特別復(fù)雜的時(shí)候，統(tǒng)一整個(gè)服務(wù)層，所有數(shù)據(jù)都通過一個(gè)統(tǒng)一的服務(wù)層來(lái)進(jìn)行訪問
  • 缺點(diǎn)：一旦代碼出故障，就將影響整個(gè)服務(wù)
• no15：微服務(wù)化架構(gòu)粒度拆分實(shí)踐二：一個(gè)子業(yè)務(wù)一個(gè)服務(wù)(最佳實(shí)踐)
  • 在服務(wù)層進(jìn)行垂直拆分，一個(gè)子業(yè)務(wù)抽象出一個(gè)服務(wù)，數(shù)據(jù)層也按照子業(yè)務(wù)垂直拆分
  • 當(dāng)業(yè)務(wù)連接關(guān)系變得復(fù)雜時(shí)，加入網(wǎng)關(guān)分發(fā)層來(lái)消除這個(gè)網(wǎng)狀關(guān)系，并在協(xié)議設(shè)計(jì)的時(shí)候加入一個(gè)協(xié)議號(hào)服務(wù)號(hào)，分發(fā)層通過協(xié)議號(hào)服務(wù)號(hào)將請(qǐng)求路由到相關(guān)的子業(yè)務(wù)服務(wù)
• no15：微服務(wù)化架構(gòu)粒度拆分實(shí)踐三：一個(gè)數(shù)據(jù)庫(kù)一個(gè)服務(wù)
• no15：微服務(wù)化架構(gòu)粒度拆分實(shí)踐四：一個(gè)接口一個(gè)服務(wù)
  • 需要語(yǔ)言特性的支持，如 go 可以這么使用
• no15：微服務(wù)化架構(gòu)拆成細(xì)粒度優(yōu)缺點(diǎn)
  • 優(yōu)點(diǎn)
    • 服務(wù)能夠獨(dú)立部署，擴(kuò)容縮容相對(duì)方便
    • 能更有效地提高資源利用率
    • 耦合度相對(duì)減小
    • 容錯(cuò)性相對(duì)更好
    • 擴(kuò)展性也會(huì)更好
  • 缺點(diǎn)
    • 服務(wù)數(shù)量變多
    • 系統(tǒng)復(fù)雜性增加
    • 依賴關(guān)系復(fù)雜性增加
    • 運(yùn)維復(fù)雜性增加
    • 監(jiān)控更復(fù)雜
    • 定位問題更復(fù)雜

16、服務(wù)化：微服務(wù)架構(gòu)，必須搞定高可用！

• no16：高可用是什么？
  • 減少系統(tǒng)不能提供服務(wù)的時(shí)間
• no16：如何判斷是否高可用？
  • 隨機(jī)關(guān)停一臺(tái)線上服務(wù)器，如果對(duì)用戶的服務(wù)不受影響，那么系統(tǒng)就是高可用的
• no16：如何保障系統(tǒng)的高可用
  • 1.集群化(冗余)
  • 2.故障自動(dòng)轉(zhuǎn)移
• no16：常見微服務(wù)分層架構(gòu)？
• no16：微服務(wù)分層架構(gòu)如何保證「端」到「反向代理」的高可用
  • 通過 keepalived + 虛 IP 來(lái)實(shí)現(xiàn)
• no16：微服務(wù)分層架構(gòu)如何保證「反向代理」到「站點(diǎn)應(yīng)用」的高可用
  • 通過站點(diǎn)層的冗余來(lái)實(shí)現(xiàn)
• no16：微服務(wù)分層架構(gòu)如何保證「站點(diǎn)應(yīng)用」到「微服務(wù)」的高可用
  • 通過服務(wù)層的冗余來(lái)實(shí)現(xiàn)，上游有服務(wù)連接池
• no16：微服務(wù)分層架構(gòu)如何保證「微服務(wù)」到「緩存」的高可用(memcache)
• no16：微服務(wù)分層架構(gòu)如何保證「微服務(wù)」到「緩存」的高可用(redis)
  • 但很多時(shí)候緩存不需要保證高可用，只要不「雪崩」壓垮數(shù)據(jù)庫(kù)就行
    • 將緩存進(jìn)行水平切分，這也是個(gè)集群，但只是用來(lái)做分片，并不做數(shù)據(jù)冗余，在上游設(shè)置代理，即進(jìn)行完水平切分的入口
• no16：微服務(wù)分層架構(gòu)如何保證「微服務(wù)」到「數(shù)據(jù)庫(kù)」的高可用
  • 如果做了讀寫分離，必須保證
  • 「微服務(wù)」到「讀庫(kù)」的高可用
    • 通過讀庫(kù)的冗余化集群實(shí)現(xiàn)的
  • 「微服務(wù)」到「寫庫(kù)」的高可用
    • 通過寫庫(kù)的冗余化集群實(shí)現(xiàn)的，如 MySQL 可通過設(shè)置雙主相互同步

17、服務(wù)化：微服務(wù)架構(gòu)，必須搞定高并發(fā)！

• no17：什么是高并發(fā)？
  • 通過設(shè)計(jì)方案，保證系統(tǒng)能夠同時(shí)并行的處理很多用戶的很多請(qǐng)求
• no17：高并發(fā)相關(guān)的常見指標(biāo)有哪些？
  • 1.響應(yīng)時(shí)間(Response Time)
  • 2.吞吐量(Throughput)
  • 3.每秒查詢率 QPS(Query Per Second)
  • 4.并發(fā)用戶數(shù)
• no17：提升系統(tǒng)并發(fā)處理能力的方法論？
  • 1.垂直擴(kuò)展(Scale Up)
    • 1.提升單機(jī)硬件性能
    • 2.提升單機(jī)架構(gòu)性能
    • 業(yè)務(wù)早期建議使用，因?yàn)樗俣茸羁?/li>
  • 2.水平擴(kuò)展(Scale Out)
• no17：常見微服務(wù)分層架構(gòu)
  • 要想做到整體的性能無(wú)限，就必須做到每一層都能夠?qū)崿F(xiàn)水平擴(kuò)展性能無(wú)限
• no17：常見微服務(wù)分層架構(gòu)的反向代理層的水平擴(kuò)展
  • 之前都是通過 lvs 和 f5 的垂直擴(kuò)展的方式，這都是有性能上限的，反向代理的水平擴(kuò)展是通過 DNS 輪詢實(shí)現(xiàn)的，DNS server 對(duì)于同一個(gè)域名配置不同的 nginx 外網(wǎng) IP
• no17：常見微服務(wù)分層架構(gòu)的站點(diǎn)應(yīng)用層的水平擴(kuò)展
  • 通過反向代理層實(shí)現(xiàn)
• no17：常見微服務(wù)分層架構(gòu)的微服務(wù)的水平擴(kuò)展
  • 通過服務(wù)連接池去實(shí)現(xiàn)的，站點(diǎn)層通過 rpc client 調(diào)用下層的服務(wù)層 rpc server，rpc client 會(huì)建立多個(gè)服務(wù)連接，當(dāng)服務(wù)稱為瓶頸的時(shí)候，只要增加服務(wù)節(jié)點(diǎn)的數(shù)量，rpc client 會(huì)建立新的連接
• no17：常見微服務(wù)分層架構(gòu)的數(shù)據(jù)層(緩存，數(shù)據(jù)庫(kù))的水平擴(kuò)展
  • 需求
    • 1.存儲(chǔ)容量的擴(kuò)展，無(wú)限容量
    • 2.處理能力的擴(kuò)展，無(wú)限讀性能，無(wú)限寫性能
  • 根據(jù)數(shù)據(jù)的范圍水平切分
    • 優(yōu)點(diǎn)
      • 規(guī)則簡(jiǎn)單
      • 數(shù)據(jù)的均衡性比較好
      • 容易擴(kuò)展
    • 缺點(diǎn)
      • 雖然保證數(shù)據(jù)層是均衡的，但讀寫請(qǐng)求不一定是均衡的
  • 按照哈希水平切分
    • 優(yōu)點(diǎn)
      • 規(guī)則簡(jiǎn)單
      • 數(shù)據(jù)均衡性非常好
      • 請(qǐng)求均衡性非常好
    • 缺點(diǎn)
      • 不容易擴(kuò)展，擴(kuò)展可能需要進(jìn)行數(shù)據(jù)遷移

18、服務(wù)化：微服務(wù)架構(gòu)，必須搞定負(fù)載均衡！

• no18：什么是負(fù)載均衡
  • 將請(qǐng)求或者數(shù)據(jù)均勻地分?jǐn)偟蕉鄠€(gè)操作單元上執(zhí)行
    • 1.同構(gòu)，重點(diǎn)在于「均勻」
    • 2.異構(gòu)，重點(diǎn)在于「負(fù)載與能力匹配」
• no18：常見微服務(wù)分層架構(gòu)，保證負(fù)載均衡的思路
  • 實(shí)現(xiàn)每個(gè)上游都實(shí)現(xiàn)對(duì)下游的均勻訪問，即可實(shí)現(xiàn)系統(tǒng)整體的均勻分?jǐn)?/li>
• no18：常見微服務(wù)分層架構(gòu)，反向代理層的負(fù)載均衡
  • DNS 服務(wù)器使用 DNS 輪詢的方式，即可實(shí)現(xiàn) Nginx 的負(fù)載均衡
• no18：常見微服務(wù)分層架構(gòu)，站點(diǎn)應(yīng)用層的負(fù)載均衡
  • nginx 使用輪詢的方式，將請(qǐng)求路由到多個(gè)站點(diǎn)應(yīng)用的后端
• no18：常見微服務(wù)分層架構(gòu)，微服務(wù)的負(fù)載均衡
  • 通過連接池實(shí)現(xiàn)的，可使用隨機(jī)或輪詢等方式保證多個(gè)微服務(wù)的下游的請(qǐng)求是均勻的
• no18：常見微服務(wù)分層架構(gòu)，數(shù)據(jù)層(緩存，數(shù)據(jù)庫(kù))的負(fù)載均衡
  • 1.數(shù)據(jù)，均衡
  • 2.請(qǐng)求，均衡
  • 按照數(shù)據(jù)范圍水平切分
    • 數(shù)據(jù)負(fù)載是均衡的，水平負(fù)載未必均衡，如新用戶可能更活躍
  • 哈希水平切分
    • 數(shù)據(jù)、請(qǐng)求的負(fù)載都比較均衡，同構(gòu)節(jié)點(diǎn)的服務(wù)器的均衡比較容易
• no18：常見微服務(wù)分層架構(gòu)，異構(gòu)服務(wù)器負(fù)載均衡，方案一：靜態(tài)權(quán)重
  • 為下游每個(gè)微服務(wù)節(jié)點(diǎn)設(shè)置一個(gè)靜態(tài)權(quán)重，表示微服務(wù)的處理能力，來(lái)調(diào)配連接池
  • 優(yōu)點(diǎn)
    • 簡(jiǎn)單粗暴
  • 缺點(diǎn)
    • 無(wú)法自適應(yīng)地去調(diào)節(jié)
• no18：常見微服務(wù)分層架構(gòu)，異構(gòu)服務(wù)器負(fù)載均衡，方案二：動(dòng)態(tài)權(quán)重
  • 1.如何標(biāo)識(shí)服務(wù)的處理能力？(下游的處理能力是由調(diào)用方?jīng)Q定的)
  • 2.如何設(shè)計(jì)動(dòng)態(tài)權(quán)重？
  • 對(duì)每一個(gè)微服務(wù)的連接使用一個(gè)權(quán)重來(lái)標(biāo)識(shí)，這個(gè)權(quán)重決定分配給每個(gè)微服務(wù)請(qǐng)求的概率，獲得相應(yīng)連接的概率，當(dāng)下游每成功處理一個(gè)請(qǐng)求的時(shí)候，就認(rèn)為下游的微服務(wù)的處理能力足夠，增加權(quán)重(緩慢)，當(dāng)微服務(wù)超時(shí)處理一個(gè)請(qǐng)求的時(shí)候，就認(rèn)為下游的處理能力，可能要跟不上了，權(quán)重就減少(快速)
  • 可把權(quán)重的范圍設(shè)置為[0，100]之間，初始值設(shè)置為 60，
• no18：什么是過載保護(hù)？
  • 如果不對(duì)微服務(wù)實(shí)施過載保護(hù)，隨著上游的負(fù)載越來(lái)越高，在微服務(wù)的處理能力范圍內(nèi)，每秒處理的請(qǐng)求是越來(lái)越高的
  • 但是達(dá)到一個(gè)負(fù)載的極限時(shí)，外部負(fù)載持續(xù)的增加，它的處理能力會(huì)掉底，瞬間降為 0，即「雪崩」
  • 如果實(shí)施了過載保護(hù)，那么隨著外部負(fù)載的增加，處理能力到達(dá)一個(gè) max 值后，會(huì)保持相對(duì)穩(wěn)定的一個(gè)值，系統(tǒng)不會(huì)被完全壓垮
• no18：如何實(shí)施過載保護(hù)？
  • 1.靜態(tài)權(quán)重(粗暴，不優(yōu)雅)
    • 給微服務(wù)的處理能力設(shè)置一個(gè)閾值，如果負(fù)載超過這個(gè)閾值，就將后續(xù)的請(qǐng)求全部拋棄
  • 2.動(dòng)態(tài)權(quán)重
    • 1.連接表示服務(wù)，分值代表服務(wù)(連接)
    • 2.處理成功加小分，處理失敗扣大分
    • 3.到達(dá)臨界編譯時(shí)，如有請(qǐng)求超時(shí)的時(shí)候，可判斷快要處理不過來(lái)了，讓它有請(qǐng)求處理失敗的時(shí)候休息一會(huì)，再接下來(lái) 10 秒內(nèi)不再給這個(gè)超時(shí)的服務(wù)器進(jìn)行負(fù)載分配
    • 4.如果仍然連續(xù)地超時(shí)，可能判定這個(gè)服務(wù)器完全處理不過來(lái)了，如 fullGC，根據(jù)經(jīng)驗(yàn)，fullGC 差不多一分鐘之后能回過神，則一分鐘后給它分配請(qǐng)求
    • 但如果整體負(fù)載超過了微服務(wù)集群的整體負(fù)載，最終還是要拋棄部分請(qǐng)求

20、服務(wù)化：連接池，高可用可擴(kuò)展負(fù)載均衡都離不開他

• no20：微服務(wù)分層架構(gòu)中，連接池的位置
• no20：高可用，故障轉(zhuǎn)移，在連接池中是如何實(shí)現(xiàn)的？
  • 當(dāng)有節(jié)點(diǎn)失效時(shí)，連接池重試也連接不上，則連接池會(huì)把失敗的連接剔除出去
• no20：擴(kuò)展性，服務(wù)發(fā)現(xiàn)，在連接池的實(shí)現(xiàn)
  • 1.自動(dòng)載入新服務(wù)節(jié)點(diǎn)的配置
    • 方案一：監(jiān)控配置文件，并重新載入
      • 具體實(shí)現(xiàn)可以是啟動(dòng)一個(gè)進(jìn)程，監(jiān)控文件變化，循環(huán)檢測(cè)文件 md5是否變化，如果變化則讀取新服務(wù)節(jié)點(diǎn)的配置
    • 方案二：配置中心回調(diào)，并重新載入
      • 每當(dāng)調(diào)用方站點(diǎn)集群向配置中心注冊(cè)了下游所依賴的微服務(wù)集群的配置，如果微服務(wù)集群的節(jié)點(diǎn)發(fā)生了變化配置中心會(huì)給調(diào)用方的站點(diǎn)集群進(jìn)行回調(diào)，會(huì)將變化后的節(jié)點(diǎn)通知站點(diǎn)集群，再實(shí)施連接池自動(dòng)增刪節(jié)點(diǎn)
  • 2.動(dòng)態(tài)連接池
• no20：負(fù)載均衡，連接池的實(shí)現(xiàn)的三個(gè)方案
  • 方案一：隨機(jī)/輪詢(同構(gòu)服務(wù)器)
  • 方案二：靜態(tài)權(quán)重法(異構(gòu)服務(wù)器)
  • 方案二：動(dòng)態(tài)權(quán)重法(異構(gòu)服務(wù)器)

總結(jié)

以上是生活随笔為你收集整理的《沈剑架构师训练营》第4章 - 微服务架构的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

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