如何理解微服務(wù)架構(gòu)下的高可用和高性能設(shè)計(jì)

這篇文章主要講解了“如何理解微服務(wù)架構(gòu)下的高可用和高性能設(shè)計(jì)”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請(qǐng)大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“如何理解微服務(wù)架構(gòu)下的高可用和高性能設(shè)計(jì)”吧！

高可用性三個(gè)維度和相互關(guān)系

對(duì)于業(yè)務(wù)系統(tǒng)的高可用性，實(shí)際上包括了高可靠，高性能和高擴(kuò)展三個(gè)方面的內(nèi)容。而且三方面相互之間還存在相互的依賴和影響關(guān)系。

對(duì)于三者的關(guān)系，我們可以用下圖進(jìn)行描述。

上圖可以看到高可靠，高性能和高擴(kuò)展性三者之間的關(guān)系。

對(duì)于高可靠性來來說，傳統(tǒng)的HA架構(gòu)，冗余設(shè)計(jì)都可以滿足高可靠性要求，但是并不代表系統(tǒng)具備了高性能和可擴(kuò)展性能力。反過來說，當(dāng)系統(tǒng)具備了高擴(kuò)展性的時(shí)候，一般我們?cè)谠O(shè)計(jì)擴(kuò)展性的時(shí)候都會(huì)考慮到同時(shí)兼顧冗余和高可靠，比如我們常說的集群技術(shù)。

對(duì)于高性能和高擴(kuò)展性兩點(diǎn)來說，高擴(kuò)展性是高性能的必要條件，但是并不是充分條件。一個(gè)業(yè)務(wù)系統(tǒng)的高性能不是簡單的具備擴(kuò)展能力就可以，而是需要業(yè)務(wù)系統(tǒng)本身軟件架構(gòu)設(shè)計(jì)，代碼編寫各方面都滿足高性能設(shè)計(jì)要求。

對(duì)于高可靠和高性能，兩者反而表現(xiàn)出來一種相互制約的關(guān)系，即在高性能支撐的狀態(tài)下，往往是對(duì)系統(tǒng)的高可靠性形成嚴(yán)峻挑戰(zhàn)，也正是這個(gè)原因我們會(huì)看到類似限流熔斷，SLA服務(wù)降級(jí)等各種措施來控制異常狀態(tài)下的大并發(fā)訪問和調(diào)用。

數(shù)據(jù)庫的高可用性

在我前面談微服務(wù)架構(gòu)的時(shí)候就談到，在微服務(wù)架構(gòu)下傳統(tǒng)的單體應(yīng)用要進(jìn)行拆分，這個(gè)拆分不僅僅是應(yīng)用層組件的拆分，還包括了數(shù)據(jù)庫本身的拆分。

如果一個(gè)傳統(tǒng)的單體應(yīng)用規(guī)劃為10個(gè)微服務(wù)，則可能會(huì)垂直拆分為10個(gè)獨(dú)立的數(shù)據(jù)庫。這實(shí)際上減小了每一個(gè)數(shù)據(jù)庫本身面對(duì)的性能負(fù)荷，同時(shí)提升了數(shù)據(jù)庫整體的處理能力。

同時(shí)在拆分后雖然引入了各種跨庫查詢，分布式事務(wù)等問題，但是實(shí)際很多跨庫操作，復(fù)制的數(shù)據(jù)處理計(jì)算都不在數(shù)據(jù)庫里面完成，數(shù)據(jù)庫更多的是提供單純的CRUD類操作接口，這本身也是提升數(shù)據(jù)庫性能的一個(gè)關(guān)鍵。

如果采用Mysql數(shù)據(jù)庫。

要滿足高可靠性，你可以采用Dual-Master雙主架構(gòu)，即兩個(gè)主節(jié)點(diǎn)雙活，但是僅一個(gè)節(jié)點(diǎn)提供數(shù)據(jù)庫接口能力，另外一個(gè)節(jié)點(diǎn)實(shí)時(shí)同步數(shù)據(jù)庫日志，作為備節(jié)點(diǎn)。當(dāng)主節(jié)點(diǎn)出現(xiàn)故障的時(shí)候，備節(jié)點(diǎn)自動(dòng)轉(zhuǎn)變?yōu)橹鞴?jié)點(diǎn)服務(wù)。

簡單的雙主架構(gòu)兩節(jié)點(diǎn)間安裝代理，通過Binlog日志復(fù)制，上層通過類似Haproxy+Keepalive實(shí)現(xiàn)通過的VIP浮動(dòng)IP提供和心跳監(jiān)測(cè)。

可以看到雙主架構(gòu)更多的是為高可靠服務(wù)。

如果要滿足高性能，常采用的是讀寫分離集群。即1個(gè)主節(jié)點(diǎn)承擔(dān)讀寫操作，多個(gè)從節(jié)點(diǎn)承擔(dān)讀操作。從節(jié)點(diǎn)仍然是通過Binlog日志進(jìn)行主節(jié)點(diǎn)信息同步。當(dāng)有數(shù)據(jù)訪問請(qǐng)求進(jìn)入的時(shí)候，前端Proxy可以自動(dòng)分析是CUD類請(qǐng)求，還是R讀請(qǐng)求，以進(jìn)行請(qǐng)求的路由轉(zhuǎn)發(fā)。

當(dāng)我們進(jìn)行訂單新增操作的時(shí)候，當(dāng)新增成功的時(shí)候需要快速的刷新當(dāng)前訂單列表界面，第二次的刷新本身是讀操作，但是和前面的寫綁定很緊，實(shí)際上不太適合從Slave節(jié)點(diǎn)讀取數(shù)據(jù)的。這個(gè)時(shí)候可以在進(jìn)行Sql調(diào)用的時(shí)候明確指定是否仍然從主節(jié)點(diǎn)獲取數(shù)據(jù)。

當(dāng)然，大部分時(shí)候可能需要兩者結(jié)合，既提供足夠的高可靠性，又提供足夠的高性能。因此Mysql集群在搭建的時(shí)候既需要進(jìn)行雙主設(shè)置，又需要進(jìn)行多個(gè)從節(jié)點(diǎn)設(shè)置。

在上圖這種邏輯部署架構(gòu)下，基本就可以同時(shí)滿足高可靠和高性能兩個(gè)方面的需求。但是從上面架構(gòu)部署可以看到，備節(jié)點(diǎn)的主和從都處于一種熱備無法實(shí)際提供能力狀態(tài)。

是否可以將所有Slave掛到一個(gè)Master上?

如果這樣設(shè)計(jì)，那么當(dāng)主Master出現(xiàn)故障的時(shí)候，就需要對(duì)多個(gè)Slave節(jié)點(diǎn)進(jìn)行自動(dòng)化漂移。這一方面是整體實(shí)現(xiàn)比較復(fù)雜，另外就是可靠性也不如上面這種架構(gòu)。

對(duì)數(shù)據(jù)庫性能擴(kuò)展的思考

首先來看前面架構(gòu)本身的一些潛在問題點(diǎn)：

第一就是CUD操作仍然是單節(jié)點(diǎn)提供能力。對(duì)于讀操作占大部分場(chǎng)景的，基本可以通過雙主+讀寫分離集群實(shí)現(xiàn)很好的性能擴(kuò)展。但是如果CUD操作頻繁仍然可能出現(xiàn)性能問題。

其次，數(shù)據(jù)庫性能問題一般分為兩個(gè)層面，其一就是大并發(fā)請(qǐng)求下的性能，這個(gè)可以通過集群負(fù)載均衡去解決，其二是單個(gè)請(qǐng)求訪問大數(shù)據(jù)庫表模糊查詢性能，這個(gè)是服務(wù)通過負(fù)載去解決的。

也就是說上面的設(shè)計(jì)，在大并發(fā)的CUD操作，對(duì)大數(shù)據(jù)表的關(guān)聯(lián)查詢或模糊查詢操作仍然可能出現(xiàn)明顯的性能問題。

如何來解決這個(gè)問題?

簡單來說就是寫入通過消息中間件來將同步轉(zhuǎn)異步，進(jìn)行前端削峰。而對(duì)于查詢則進(jìn)行內(nèi)容緩存或創(chuàng)建二級(jí)索引，提升查詢效率。

對(duì)于查詢本身又包括了偏結(jié)構(gòu)化數(shù)據(jù)查詢和處理，類似采用Redis庫或Memcached進(jìn)行緩存;而對(duì)于非結(jié)構(gòu)化數(shù)據(jù)，類似消息報(bào)文，日志等采用Solr或ElasticSearch構(gòu)建二級(jí)索引并實(shí)現(xiàn)全文檢索能力。

當(dāng)面臨大量的數(shù)據(jù)寫入操作類操作的時(shí)候，單個(gè)Master節(jié)點(diǎn)往往性能很難支撐住，這個(gè)時(shí)候采用類似RabbitMQ，RocketMQ，Kafka等消息中間件來進(jìn)行異步銷峰處理就是必要的。這個(gè)異步實(shí)際上涉及到兩個(gè)層面的異步。

其一是對(duì)于發(fā)短信，記錄日志，啟流程等接口服務(wù)異步。其二是對(duì)長耗時(shí)寫入操作異步，先反饋用戶請(qǐng)求收到，處理完再通知用戶拿結(jié)果。

而對(duì)于查詢操作，前面談到的并發(fā)查詢可以進(jìn)行集群負(fù)載。

但是對(duì)于大數(shù)據(jù)量表，比如上億記錄的大表模糊查詢，這塊就必須進(jìn)行二級(jí)索引。對(duì)這種大的數(shù)據(jù)表的查詢即使沒有并發(fā)查詢，如果不進(jìn)行二級(jí)索引，查詢效率和響應(yīng)速度仍然很慢。

對(duì)半結(jié)構(gòu)化信息啟用分布式存儲(chǔ)

對(duì)于類似日志，接口服務(wù)調(diào)用日志等半結(jié)構(gòu)化信息，本身數(shù)據(jù)量很大，如果全部存儲(chǔ)在結(jié)構(gòu)化數(shù)據(jù)庫中，那么對(duì)存儲(chǔ)空間需求很大，而且很難擴(kuò)展。特別是前面的Mysql集群方案本身還是采用本地磁盤進(jìn)行存儲(chǔ)的情況下。

因此需要對(duì)歷史日志進(jìn)行清除，同時(shí)將歷史日志遷移到分布式存儲(chǔ)庫，比如Hdfs或Hbase庫，然后基于分布式存儲(chǔ)再構(gòu)建二級(jí)緩存能力。

構(gòu)建DaaS數(shù)據(jù)層進(jìn)行水平擴(kuò)展

前面談到在拆分了微服務(wù)后已經(jīng)進(jìn)行了垂直擴(kuò)展，比如一個(gè)資產(chǎn)管理系統(tǒng)可以拆分為資產(chǎn)新增，資產(chǎn)調(diào)撥，資產(chǎn)折舊，資產(chǎn)盤點(diǎn)等10個(gè)微服務(wù)模塊。

但是在拆分后仍然發(fā)現(xiàn)資產(chǎn)數(shù)據(jù)量極大，比如在集團(tuán)集中化這種大型項(xiàng)目可以看到，一個(gè)省的資產(chǎn)數(shù)據(jù)表就接近上億條記錄。這種時(shí)候?qū)⑺惺?shù)據(jù)全部集中化在一個(gè)數(shù)據(jù)庫管理不現(xiàn)實(shí)。因此需要進(jìn)一步按省份或組織域進(jìn)行水平拆分。

在水平拆分后，在上層構(gòu)建DaaS層提供統(tǒng)一對(duì)外訪問能力。

應(yīng)用集群擴(kuò)展

對(duì)于應(yīng)用集群擴(kuò)展實(shí)際比數(shù)據(jù)庫層要簡單，應(yīng)用中間件層可以很方便的結(jié)合集群管理節(jié)點(diǎn)或者獨(dú)立的負(fù)載均衡硬件或軟件進(jìn)行集群能力擴(kuò)展。對(duì)于應(yīng)用集群擴(kuò)展，本身就是提升整個(gè)性能的關(guān)鍵方式。在集群的擴(kuò)展過程中還是有些問題需要進(jìn)一步討論。

集群做到完全的無狀態(tài)化

如果集群做到完全的無狀態(tài)化，那么集群就可以做到和負(fù)載均衡設(shè)備或軟件結(jié)合來實(shí)現(xiàn)負(fù)載均衡擴(kuò)展能力。比如硬件常用的F5或radware等，軟件如HAProxy，Nginx等。

Session會(huì)話信息如何處理?對(duì)于Session本身是有狀態(tài)的，因此對(duì)于Session信息可以考慮存儲(chǔ)到數(shù)據(jù)庫或Redis緩存庫中。

集群節(jié)點(diǎn)在啟動(dòng)的時(shí)候往往需要讀取一些全局變量或配置文件信息，這些信息如果簡單的存在在本地磁盤往往難以集中化管理。因此當(dāng)前主流思路是啟用全局的配置中心來統(tǒng)一管理配置。

如果應(yīng)用功能實(shí)現(xiàn)中存在文件的上傳和存儲(chǔ)，那么這些文件存儲(chǔ)在磁盤本地本身也是有狀態(tài)的，因此對(duì)于這些文件本身也需要通過文件服務(wù)能力或分布式對(duì)象存儲(chǔ)服務(wù)能力來實(shí)現(xiàn)。

微服務(wù)架構(gòu)下各個(gè)微服務(wù)間本身存在接口交互和協(xié)同，對(duì)于接口調(diào)用的具體地址信息也需要通過服務(wù)注冊(cè)中心獲取，獲取后可以緩存在本地，但是必須有變更后實(shí)時(shí)更新機(jī)制。

四層負(fù)載和七層負(fù)載

首先看下最簡單的四層負(fù)載和七層負(fù)載的一個(gè)說明:

• 四層負(fù)載：即在OSI第4層工作，就是TCP層，可以根據(jù)IP+端口進(jìn)行負(fù)載均衡。此種Load  Balance不理解應(yīng)用協(xié)議(如HTTP/FTP/MySQL等等)。

• 七層負(fù)載：工作在OSI的最高層，應(yīng)用層，可以基于Http協(xié)議和URL內(nèi)容進(jìn)行負(fù)載均衡。此時(shí)負(fù)載均衡能理解應(yīng)用協(xié)議。

當(dāng)前可以看到對(duì)于F5,Array等硬件負(fù)載均衡設(shè)備本身也是支持7層負(fù)載均衡的，同時(shí)在四層負(fù)載均衡的時(shí)候我們還可以設(shè)置是否進(jìn)行會(huì)話保持等高級(jí)特性。要明白四層負(fù)載均衡本質(zhì)是轉(zhuǎn)發(fā)，而七層負(fù)載本質(zhì)是內(nèi)容交換和代理。

也就是說在不需要進(jìn)行狀態(tài)保留和基于內(nèi)容的路由的時(shí)候，我們完全可以啟用四層負(fù)載均衡來獲取更好的性能。

在微服務(wù)架構(gòu)前后端分離開發(fā)后。

后端微服務(wù)組件可以完全提供Rest  API接口服務(wù)能力，那么本身就無狀態(tài)。而對(duì)于前端微服務(wù)組件直接面對(duì)最終用戶訪問，需要保持Session狀態(tài)。在這種情況下就可以進(jìn)行兩層負(fù)載均衡設(shè)計(jì)，即前端采用七層負(fù)載，而后端采用四層負(fù)載均衡。

前端緩存

前端緩存主要是分為HTTP緩存和瀏覽器緩存。其中HTTP緩存是在HTTP請(qǐng)求傳輸時(shí)用到的緩存，主要在服務(wù)器代碼上設(shè)置;而瀏覽器緩存則主要由前端開發(fā)在前端js上進(jìn)行設(shè)置。緩存可以說是性能優(yōu)化中簡單高效的一種優(yōu)化方式了。一個(gè)優(yōu)秀的緩存策略可以縮短網(wǎng)頁請(qǐng)求資源的距離，減少延遲，并且由于緩存文件可以重復(fù)利用，還可以減少帶寬，降低網(wǎng)絡(luò)負(fù)荷。

具體可以參考：

https://www.jianshu.com/p/256d0873c398

軟件性能問題分析和診斷

對(duì)于業(yè)務(wù)系統(tǒng)性能診斷，如果從靜態(tài)角度我們可以考慮從以下三個(gè)方面進(jìn)行分類

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2. 操作系統(tǒng)和存儲(chǔ)層面

3. 中間件層面(包括了數(shù)據(jù)庫，應(yīng)用服務(wù)器中間件)

4. 軟件層面(包括了數(shù)據(jù)庫SQL和存儲(chǔ)過程，邏輯層，前端展現(xiàn)層等)

那么一個(gè)業(yè)務(wù)系統(tǒng)應(yīng)用功能出現(xiàn)問題了，我們當(dāng)然也可以從動(dòng)態(tài)層面來看實(shí)際一個(gè)應(yīng)用請(qǐng)求從調(diào)用開始究竟經(jīng)過了哪些代碼和硬件基礎(chǔ)設(shè)施，通過分段方法來定位和查詢問題。

比如我們常見的就是一個(gè)查詢功能如果出現(xiàn)問題了，首先就是找到這個(gè)查詢功能對(duì)應(yīng)的SQL語句在后臺(tái)查詢是否很慢，如果這個(gè)SQL本身就慢，那么就要優(yōu)化優(yōu)化SQL語句。如果SQL本身快但是查詢慢，那就要看下是否是前端性能問題或者集群問題等。

軟件代碼的問題往往是最不能忽視的一個(gè)性能問題點(diǎn)

對(duì)于業(yè)務(wù)系統(tǒng)性能問題，我們經(jīng)常想到的就是要擴(kuò)展數(shù)據(jù)庫的硬件性能，比如擴(kuò)展CPU和內(nèi)存，擴(kuò)展集群，但是實(shí)際上可以看到很多應(yīng)用的性能問題并不是硬件性能導(dǎo)致的，而是由于軟件代碼性能引起的。對(duì)于軟件代碼常見的性能問題我在以往的博客文章里面也談過到，比較典型的包括了。

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2. 循環(huán)中初始化大的結(jié)構(gòu)對(duì)象，數(shù)據(jù)庫連接等

3. 資源不釋放導(dǎo)致的內(nèi)存泄露等

4. 沒有基于場(chǎng)景需求來適度通過緩存等方式提升性能

5. 長周期事務(wù)處理耗費(fèi)資源

6. 處理某一個(gè)業(yè)務(wù)場(chǎng)景或問題的時(shí)候，沒有選擇最優(yōu)的數(shù)據(jù)結(jié)構(gòu)或算法

以上都是常見的一些軟件代碼性能問題點(diǎn)，而這些往往需要通過我們進(jìn)行Code  Review或代碼評(píng)審的方式才能夠發(fā)現(xiàn)出來。因此如果要做全面的性能優(yōu)化，對(duì)于軟件代碼的性能問題排查是必須的。

其次就是可以通過APM性能監(jiān)控工具來發(fā)現(xiàn)性能問題。

傳統(tǒng)模式下，當(dāng)出現(xiàn)CPU或內(nèi)存滿負(fù)荷的時(shí)候，如果要查找到具體是哪個(gè)應(yīng)用，哪個(gè)進(jìn)程或者具體哪個(gè)業(yè)務(wù)功能，哪個(gè)sql語句導(dǎo)致的往往并不是容易的事情。在實(shí)際的性能問題優(yōu)化中往往也需要做大量的日志分析和問題定位，最終才可能找到問題點(diǎn)。

而通過APM可以很好的解決這個(gè)問題。

比如在我們最近的項(xiàng)目實(shí)施中，結(jié)合APM和服務(wù)鏈監(jiān)控，我們可以快速的發(fā)現(xiàn)究竟是哪個(gè)服務(wù)調(diào)用出現(xiàn)了性能問題，或者快速的定位出哪個(gè)SQL語句有驗(yàn)證的性能問題。這個(gè)都可以幫助我們快速的進(jìn)行性能問題分析和診斷。

資源上承載的是應(yīng)用，應(yīng)用本身又包括了數(shù)據(jù)庫和應(yīng)用中間件容器，同時(shí)也包括了前端;在應(yīng)用之上則是對(duì)應(yīng)到具體的業(yè)務(wù)功能。因此APM一個(gè)核心就是要將資源-》應(yīng)用-》功能之間進(jìn)行整合分析和銜接。通過APM來發(fā)現(xiàn)應(yīng)用運(yùn)行中的性能問題并解決。

感謝各位的閱讀，以上就是“如何理解微服務(wù)架構(gòu)下的高可用和高性能設(shè)計(jì)”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對(duì)如何理解微服務(wù)架構(gòu)下的高可用和高性能設(shè)計(jì)這一問題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是億速云，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！