微服務(wù)生態(tài)
微服務(wù)有哪些要點(diǎn)呢?先看下圖是 SpringCloud 的整個(gè)生態(tài)。
設(shè)計(jì)要點(diǎn)一:API 網(wǎng)關(guān)。
在實(shí)施微服務(wù)的過程中,不免要面臨服務(wù)的聚合與拆分,當(dāng)后端服務(wù)的拆分相對比較頻繁的時(shí)候,作為手機(jī) App 來講,往往需要一個(gè)統(tǒng)一的入口,將不同的請求路由到不同的服務(wù),無論后面如何拆分與聚合,對于手機(jī)端來講都是透明的。
有了 API 網(wǎng)關(guān)以后,簡單的數(shù)據(jù)聚合可以在網(wǎng)關(guān)層完成,這樣就不用在手機(jī) App 端完成,從而手機(jī) App 耗電量較小,用戶體驗(yàn)較好。
有了統(tǒng)一的 API 網(wǎng)關(guān),還可以進(jìn)行統(tǒng)一的認(rèn)證和鑒權(quán),盡管服務(wù)之間的相互調(diào)用比較復(fù)雜,接口也會(huì)比較多,API 網(wǎng)關(guān)往往只暴露必須的對外接口,并且對接口進(jìn)行統(tǒng)一的認(rèn)證和鑒權(quán),使得內(nèi)部的服務(wù)相互訪問的時(shí)候,不用再進(jìn)行認(rèn)證和鑒權(quán),效率會(huì)比較高。
有了統(tǒng)一的 API 網(wǎng)關(guān),可以在這一層設(shè)定一定的策略,進(jìn)行 A/B 測試,藍(lán)綠發(fā)布,預(yù)發(fā)環(huán)境導(dǎo)流等等。API 網(wǎng)關(guān)往往是無狀態(tài)的,可以橫向擴(kuò)展,從而不會(huì)成為性能瓶頸。
設(shè)計(jì)要點(diǎn)二:無狀態(tài)化,區(qū)分有狀態(tài)的和無狀態(tài)的應(yīng)用。
影響應(yīng)用遷移和橫向擴(kuò)展的重要因素就是應(yīng)用的狀態(tài),無狀態(tài)服務(wù),是要把這個(gè)狀態(tài)往外移,將 Session 數(shù)據(jù),文件數(shù)據(jù),結(jié)構(gòu)化數(shù)據(jù)保存在后端統(tǒng)一的存儲(chǔ)中,從而應(yīng)用僅僅包含商務(wù)邏輯。
狀態(tài)是不可避免的,例如 ZooKeeper, DB,Cache 等,把這些所有有狀態(tài)的東西收斂在一個(gè)非常集中的集群里面。
整個(gè)業(yè)務(wù)就分兩部分,一個(gè)是無狀態(tài)的部分,一個(gè)是有狀態(tài)的部分。
無狀態(tài)的部分能實(shí)現(xiàn)兩點(diǎn),一是跨機(jī)房隨意地部署,也即遷移性,一是彈性伸縮,很容易地進(jìn)行擴(kuò)容。
有狀態(tài)的部分,如 DB,Cache,ZooKeeper 有自己的高可用機(jī)制,要利用到他們自己高可用的機(jī)制來實(shí)現(xiàn)這個(gè)狀態(tài)的集群。
雖說無狀態(tài)化,但是當(dāng)前處理的數(shù)據(jù),還是會(huì)在內(nèi)存里面的,當(dāng)前的進(jìn)程掛掉數(shù)據(jù),肯定也是有一部分丟失的,為了實(shí)現(xiàn)這一點(diǎn),服務(wù)要有重試的機(jī)制,接口要有冪等的機(jī)制,通過服務(wù)發(fā)現(xiàn)機(jī)制,重新調(diào)用一次后端服務(wù)的另一個(gè)實(shí)例就可以了。
設(shè)計(jì)要點(diǎn)三:數(shù)據(jù)庫的橫向擴(kuò)展。
數(shù)據(jù)庫是保存狀態(tài),是最重要的也是最容易出現(xiàn)瓶頸的。有了分布式數(shù)據(jù)庫可以使數(shù)據(jù)庫的性能可以隨著節(jié)點(diǎn)增加線性地增加。
分布式數(shù)據(jù)庫最最下面是 RDS,是主備的,通過 MySql 的內(nèi)核開發(fā)能力,我們能夠?qū)崿F(xiàn)主備切換數(shù)據(jù)零丟失,所以數(shù)據(jù)落在這個(gè) RDS 里面,是非常放心的,哪怕是掛了一個(gè)節(jié)點(diǎn),切換完了以后,你的數(shù)據(jù)也是不會(huì)丟的。
再往上就是橫向怎么承載大的吞吐量的問題,上面有一個(gè)負(fù)載均衡 NLB,用 LVS,HAProxy, Keepalived,下面接了一層 Query Server。Query Server 是可以根據(jù)監(jiān)控?cái)?shù)據(jù)進(jìn)行橫向擴(kuò)展的,如果出現(xiàn)了故障,可以隨時(shí)進(jìn)行替換的修復(fù),對于業(yè)務(wù)層是沒有任何感知的。
另外一個(gè)就是雙機(jī)房的部署,DDB 開發(fā)了一個(gè)數(shù)據(jù)運(yùn)河 NDC 的組件,可以使得不同的 DDB 之間在不同的機(jī)房里面進(jìn)行同步,這時(shí)候不但在一個(gè)數(shù)據(jù)中心里面是分布式的,在多個(gè)數(shù)據(jù)中心里面也會(huì)有一個(gè)類似雙活的一個(gè)備份,高可用性有非常好的保證。
設(shè)計(jì)要點(diǎn)四:緩存
在高并發(fā)場景下緩存是非常重要的。要有層次的緩存,使得數(shù)據(jù)盡量靠近用戶。數(shù)據(jù)越靠近用戶能承載的并發(fā)量也越大,響應(yīng)時(shí)間越短。
在手機(jī)客戶端 App 上就應(yīng)該有一層緩存,不是所有的數(shù)據(jù)都每時(shí)每刻從后端拿,而是只拿重要的,關(guān)鍵的,時(shí)常變化的數(shù)據(jù)。
尤其對于靜態(tài)數(shù)據(jù),可以過一段時(shí)間去取一次,而且也沒必要到數(shù)據(jù)中心去取,可以通過 CDN,將數(shù)據(jù)緩存在距離客戶端最近的節(jié)點(diǎn)上,進(jìn)行就近下載。
有時(shí)候 CDN 里面沒有,還是要回到數(shù)據(jù)中心去下載,稱為回源,在數(shù)據(jù)中心的最外層,我們稱為接入層,可以設(shè)置一層緩存,將大部分的請求攔截,從而不會(huì)對后臺(tái)的數(shù)據(jù)庫造成壓力。
如果是動(dòng)態(tài)數(shù)據(jù),還是需要訪問應(yīng)用,通過應(yīng)用中的商務(wù)邏輯生成,或者去數(shù)據(jù)庫讀取,為了減輕數(shù)據(jù)庫的壓力,應(yīng)用可以使用本地的緩存,也可以使用分布式緩存,如 Memcached 或者 Redis,使得大部分請求讀取緩存即可,不必訪問數(shù)據(jù)庫。
當(dāng)然動(dòng)態(tài)數(shù)據(jù)還可以做一定的靜態(tài)化,也即降級(jí)成靜態(tài)數(shù)據(jù),從而減少后端的壓力。
設(shè)計(jì)要點(diǎn)五:服務(wù)拆分和服務(wù)發(fā)現(xiàn)
當(dāng)系統(tǒng)扛不住,應(yīng)用變化快的時(shí)候,往往要考慮將比較大的服務(wù)拆分為一系列小的服務(wù)。
這樣第一個(gè)好處就是開發(fā)比較獨(dú)立,當(dāng)非常多的人在維護(hù)同一個(gè)代碼倉庫的時(shí)候,往往對代碼的修改就會(huì)相互影響,常常會(huì)出現(xiàn)我沒改什么測試就不通過了,而且代碼提交的時(shí)候,經(jīng)常會(huì)出現(xiàn)沖突,需要進(jìn)行代碼合并,大大降低了開發(fā)的效率。
另一個(gè)好處就是上線獨(dú)立,物流模塊對接了一家新的快遞公司,需要連同下單一起上線,這是非常不合理的行為,我沒改還要我重啟,我沒改還讓我發(fā)布,我沒改還要我開會(huì),都是應(yīng)該拆分的時(shí)機(jī)。
另外再就是高并發(fā)時(shí)段的擴(kuò)容,往往只有最關(guān)鍵的下單和支付流程是核心,只要將關(guān)鍵的交易鏈路進(jìn)行擴(kuò)容即可,如果這時(shí)候附帶很多其他的服務(wù),擴(kuò)容即是不經(jīng)濟(jì)的,也是很有風(fēng)險(xiǎn)的。
再就是容災(zāi)和降級(jí),在大促的時(shí)候,可能需要犧牲一部分的邊角功能,但是如果所有的代碼耦合在一起,很難將邊角的部分功能進(jìn)行降級(jí)。
當(dāng)然拆分完畢以后,應(yīng)用之間的關(guān)系就更加復(fù)雜了,因而需要服務(wù)發(fā)現(xiàn)的機(jī)制,來管理應(yīng)用相互的關(guān)系,實(shí)現(xiàn)自動(dòng)的修復(fù),自動(dòng)的關(guān)聯(lián),自動(dòng)的負(fù)載均衡,自動(dòng)的容錯(cuò)切換。
設(shè)計(jì)要點(diǎn)六:服務(wù)編排與彈性伸縮
當(dāng)服務(wù)拆分了,進(jìn)程就會(huì)非常的多,因而需要服務(wù)編排來管理服務(wù)之間的依賴關(guān)系,以及將服務(wù)的部署代碼化,也就是我們常說的基礎(chǔ)設(shè)施即代碼。這樣對于服務(wù)的發(fā)布,更新,回滾,擴(kuò)容,縮容,都可以通過修改編排文件來實(shí)現(xiàn),從而增加了可追溯性,易管理性,和自動(dòng)化的能力。
既然編排文件也可以用代碼倉庫進(jìn)行管理,就可以實(shí)現(xiàn)一百個(gè)服務(wù)中,更新其中五個(gè)服務(wù),只要修改編排文件中的五個(gè)服務(wù)的配置就可以,當(dāng)編排文件提交的時(shí)候,代碼倉庫自動(dòng)觸發(fā)自動(dòng)部署升級(jí)腳本,從而更新線上的環(huán)境,當(dāng)發(fā)現(xiàn)新的環(huán)境有問題時(shí),當(dāng)然希望將這五個(gè)服務(wù)原子性地回滾,如果沒有編排文件,需要人工記錄這次升級(jí)了哪五個(gè)服務(wù)。有了編排文件,只要在代碼倉庫里面 revert,就回滾到上一個(gè)版本了。所有的操作在代碼倉庫里都是可以看到的。
設(shè)計(jì)要點(diǎn)七:統(tǒng)一配置中心
服務(wù)拆分以后,服務(wù)的數(shù)量非常多,如果所有的配置都以配置文件的方式放在應(yīng)用本地的話,非常難以管理,可以想象當(dāng)有幾百上千個(gè)進(jìn)程中有一個(gè)配置出現(xiàn)了問題,是很難將它找出來的,因而需要有統(tǒng)一的配置中心,來管理所有的配置,進(jìn)行統(tǒng)一的配置下發(fā)。
在微服務(wù)中,配置往往分為幾類,一類是幾乎不變的配置,這種配置可以直接打在容器鏡像里面,第二類是啟動(dòng)時(shí)就會(huì)確定的配置,這種配置往往通過環(huán)境變量,在容器啟動(dòng)的時(shí)候傳進(jìn)去,第三類就是統(tǒng)一的配置,需要通過配置中心進(jìn)行下發(fā),例如在大促的情況下,有些功能需要降級(jí),哪些功能可以降級(jí),哪些功能不能降級(jí),都可以在配置文件中統(tǒng)一配置。
設(shè)計(jì)要點(diǎn)八:統(tǒng)一的日志中心
同樣是進(jìn)程數(shù)目非常多的時(shí)候,很難對成千上百個(gè)容器,一個(gè)一個(gè)登錄進(jìn)去查看日志,所以需要統(tǒng)一的日志中心來收集日志,為了使收集到的日志容易分析,對于日志的規(guī)范,需要有一定的要求,當(dāng)所有的服務(wù)都遵守統(tǒng)一的日志規(guī)范的時(shí)候,在日志中心就可以對一個(gè)交易流程進(jìn)行統(tǒng)一的追溯。例如在最后的日志搜索引擎中,搜索交易號(hào),就能夠看到在哪個(gè)過程出現(xiàn)了錯(cuò)誤或者異常。
設(shè)計(jì)要點(diǎn)九:熔斷,限流,降級(jí)
服務(wù)要有熔斷,限流,降級(jí)的能力,當(dāng)一個(gè)服務(wù)調(diào)用另一個(gè)服務(wù),出現(xiàn)超時(shí)的時(shí)候,應(yīng)及時(shí)返回,而非阻塞在那個(gè)地方,從而影響其他用戶的交易,可以返回默認(rèn)的托底數(shù)據(jù)。
當(dāng)一個(gè)服務(wù)發(fā)現(xiàn)被調(diào)用的服務(wù),因?yàn)檫^于繁忙,線程池滿,連接池滿,或者總是出錯(cuò),則應(yīng)該及時(shí)熔斷,防止因?yàn)橄乱粋€(gè)服務(wù)的錯(cuò)誤或繁忙,導(dǎo)致本服務(wù)的不正常,從而逐漸往前傳導(dǎo),導(dǎo)致整個(gè)應(yīng)用的雪崩。
當(dāng)發(fā)現(xiàn)整個(gè)系統(tǒng)的確負(fù)載過高的時(shí)候,可以選擇降級(jí)某些功能或某些調(diào)用,保證最重要的交易流程的通過,以及最重要的資源全部用于保證最核心的流程。
還有一種手段就是限流,當(dāng)既設(shè)置了熔斷策略,又設(shè)置了降級(jí)策略,通過全鏈路的壓力測試,應(yīng)該能夠知道整個(gè)系統(tǒng)的支撐能力,因而就需要制定限流策略,保證系統(tǒng)在測試過的支撐能力范圍內(nèi)進(jìn)行服務(wù),超出支撐能力范圍的,可拒絕服務(wù)。當(dāng)你下單的時(shí)候,系統(tǒng)彈出對話框說 “系統(tǒng)忙,請重試”,并不代表系統(tǒng)掛了,而是說明系統(tǒng)是正常工作的,只不過限流策略起到了作用。
設(shè)計(jì)要點(diǎn)十:全方位的監(jiān)控
當(dāng)系統(tǒng)非常復(fù)雜的時(shí)候,要有統(tǒng)一的監(jiān)控,主要有兩個(gè)方面,一個(gè)是是否健康,一個(gè)是性能瓶頸在哪里。當(dāng)系統(tǒng)出現(xiàn)異常的時(shí)候,監(jiān)控系統(tǒng)可以配合告警系統(tǒng),及時(shí)地發(fā)現(xiàn),通知,干預(yù),從而保障系統(tǒng)的順利運(yùn)行。
當(dāng)壓力測試的時(shí)候,往往會(huì)遭遇瓶頸,也需要有全方位的監(jiān)控來找出瓶頸點(diǎn),同時(shí)能夠保留現(xiàn)場,從而可以追溯和分析,進(jìn)行全方位的優(yōu)化。
-
網(wǎng)關(guān)
+關(guān)注
關(guān)注
9文章
4095瀏覽量
50565 -
數(shù)據(jù)庫
+關(guān)注
關(guān)注
7文章
3712瀏覽量
64028 -
微服務(wù)
+關(guān)注
關(guān)注
0文章
126瀏覽量
7303
原文標(biāo)題:微服務(wù)化的十個(gè)設(shè)計(jì)要點(diǎn)
文章出處:【微信號(hào):magedu-Linux,微信公眾號(hào):馬哥Linux運(yùn)維】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。
發(fā)布評(píng)論請先 登錄
相關(guān)推薦
評(píng)論