摘要:一些官宣的特性,在公司內(nèi)是嚴(yán)格禁止的。一個(gè)超過個(gè)表的聯(lián)合查詢業(yè)務(wù),大概率是不合理的。微服務(wù)就是一個(gè)多模塊項(xiàng)目規(guī)范化的過程。服務(wù)治理微服務(wù)最重要的特色就是其治理功能。微服務(wù)引出的另外一個(gè)問題就是調(diào)用鏈,即某個(gè)請求的真實(shí)路徑。
大家都在學(xué)SpringCloud,貌似學(xué)會(huì)了SC就牛逼哄哄,感覺不得了的樣子。但微服務(wù),在整個(gè)企業(yè)級應(yīng)用中,只占了一小部分。微服務(wù)引入的問題比解決的問題還要多,你會(huì)遇到各種各樣的bottleneck。
微服務(wù)解決的是計(jì)算節(jié)點(diǎn)的問題,然而根源卻在存儲(chǔ)節(jié)點(diǎn)。當(dāng)業(yè)務(wù)規(guī)模變得越來越龐大,存儲(chǔ)、編碼、管理都會(huì)成為問題。
接下來我們談一些放之四海而皆準(zhǔn)的道理,不需要貼上"XX公司最佳實(shí)踐"之類的標(biāo)簽。
下面是一張因數(shù)據(jù)擴(kuò)張引出的微服務(wù)相關(guān)的圖,簡約但不簡單。中小型公司只要有這些元素,就能玩的很好;大點(diǎn)的公司,因?yàn)橐?guī)模太大,每個(gè)組件都會(huì)遇到瓶頸,所謂的專項(xiàng)的優(yōu)化并不能脫離它的本質(zhì)。
那我們開始。
注意,這張圖僅是主要數(shù)據(jù)路徑,一個(gè)子集,其他的包括CDN、通訊層等,不在此列。
這張圖并不包含某個(gè)特定領(lǐng)域的具體架構(gòu),屬于一個(gè)整體性的概括。我們從數(shù)據(jù)庫容量的瓶頸說起,看一下微服務(wù)在其中的比重。
數(shù)據(jù)庫用戶數(shù)據(jù)要存儲(chǔ),就存在數(shù)據(jù)庫。過去這么多年,NoSQL并不能消除開發(fā)人員的恐懼,所以,MySQL之類還是大多數(shù)公司的首選存儲(chǔ)。
假設(shè)你的業(yè)務(wù)增長的很好,這個(gè)就有意思多了。項(xiàng)目開始,你的sql玩的越6,那么給后人埋的坑,越多。因?yàn)閟ql的功能太豐富了,一不小心,就炫技了。你會(huì)發(fā)現(xiàn),林子越大,對sql的規(guī)范要求越高。一些官宣的特性,在公司內(nèi)是嚴(yán)格禁止的。
市場發(fā)展很好,終于來報(bào)應(yīng)了。以前的技巧變成了現(xiàn)在的累贅。慢查詢、全文掃描,招招斃命。想要加緩存,結(jié)果發(fā)現(xiàn)無從下手;想要分庫分表,結(jié)果發(fā)現(xiàn)表關(guān)系錯(cuò)綜復(fù)雜。
小表和寬表所以第一步,還是得去填坑。一個(gè)超過3個(gè)表的聯(lián)合查詢業(yè)務(wù),大概率是不合理的。在加緩存和分庫分表之前,還是得重新設(shè)計(jì)一下數(shù)據(jù)表。
忘掉什么數(shù)據(jù)庫范式,我們將存在兩類表:小表和寬表。
小表提供了最基本的數(shù)據(jù),可能一個(gè)簡單的KV就完成了。一些聯(lián)合查詢,是直接可以在程序里進(jìn)行循環(huán)拼接的。程序里循環(huán)1000次10毫秒的查詢,比單次查詢耗費(fèi)6秒要強(qiáng)的多。這就是分布式系統(tǒng)的特點(diǎn),小耗時(shí)的批量查詢,比hang在那里更加有生命力。
寬表通過冗余的方式,提供了某個(gè)重要功能常用的分析數(shù)據(jù)。這種表的字段一般都特別多,在寫入時(shí)通過拼接獲取冗余數(shù)據(jù),一般用在讀多寫少的場景。
完成了這一步,接下來的工作才能進(jìn)行。
在《“分庫分表" ?選型和流程要慎重,否則會(huì)失控》中,詳細(xì)的說明了分庫分表的選型,這里淺談一下過程。
分庫分表很可能會(huì)引入某一種中間件,因?yàn)閮H僅將數(shù)據(jù)庫分開還不行。HA,F(xiàn)ailOver等特性,是同時(shí)需要的。
分庫分為垂直分和水平分。垂直面向的是業(yè)務(wù)拆分,即將一部分表按照業(yè)務(wù)邏輯獨(dú)立到其他庫中;水平面向的是容量,即通過分庫分表的模式使數(shù)據(jù)有一個(gè)擴(kuò)張的途徑。
數(shù)據(jù)一定要有一個(gè)可以度量的切分維度,否則就過于分散,或者過于傾斜,影響后續(xù)的處理。
數(shù)據(jù)同步有分就有合,比如某些報(bào)表業(yè)務(wù)需要全量的數(shù)據(jù)。
不同業(yè)務(wù)通過共享數(shù)據(jù)庫來共享數(shù)據(jù)不得不說是個(gè)非常蠢的主意。這個(gè)時(shí)候就需要一些數(shù)據(jù)同步工具。
數(shù)據(jù)同步組件可以說是一個(gè)公司的必備組件。有基于最后更新時(shí)間的高延遲同步工具,也有基于binlog的低延遲同步工具。有的公司為了穩(wěn)定,還會(huì)有所謂的多機(jī)房同步。
數(shù)據(jù)同步最怕異常,因?yàn)榇蠖鄶?shù)同步都有順序性要求。一切運(yùn)行良好的時(shí)候,大家皆大歡喜;一旦出現(xiàn)異常,就需要其他手段來保證異常期間的數(shù)據(jù)同步和延遲。
這都是些臟活,自動(dòng)化有時(shí)候會(huì)適得其反,監(jiān)控是第一位的。
分層的數(shù)據(jù)存儲(chǔ)可以預(yù)見的是,即使你分庫分表了,還是能很快達(dá)到瓶頸。分庫分表后,你的一些統(tǒng)計(jì)功能可能還用不了了,在一些傳統(tǒng)的管理系統(tǒng)上,這是硬傷。
一個(gè)分層的數(shù)據(jù)存儲(chǔ)層是必要的。你的一些業(yè)務(wù),可能一個(gè)分支走的是MySQL,換了另外一個(gè)條件就成了ES。
不同的DB做不同的事情。RDBMS只做原是數(shù)據(jù)的存儲(chǔ)和查詢,是扁平快的數(shù)據(jù)通道;特定的單機(jī)高性能DB,做一些匯聚和科學(xué)計(jì)算;分布式的類RT的存儲(chǔ),用來存儲(chǔ)一些中等規(guī)模的數(shù)據(jù),并提供一些中延遲的搜索功能;海量的存儲(chǔ)系統(tǒng),存儲(chǔ)系統(tǒng)所有的歷史記錄,并提供離線分析功能。
不要想著某一類存儲(chǔ)解決所有的問題,那是騙人的。存儲(chǔ)部分的復(fù)雜性不是普通的微服務(wù)能夠相比的。
是誰保證了分層的數(shù)據(jù)存儲(chǔ)設(shè)計(jì)呢?除了一部分通過MQ分發(fā)數(shù)據(jù)的業(yè)務(wù),還是得靠我們的數(shù)據(jù)同步組件。
緩存但DB的壓力實(shí)在是太大了,我們不得不考慮緩存。緩存不能亂用,有兩個(gè)原則:一個(gè)是緩存不能侵入業(yè)務(wù),也就是不能帶有業(yè)務(wù)邏輯;一個(gè)是緩存的命中率要高,否則適得其反。緩存是對高并發(fā)、高速接口的補(bǔ)充,是系統(tǒng)穩(wěn)定性的必要不充分條件。
除了Redis等外置的緩存集群,jvm內(nèi)緩存也是一個(gè)比較重要的場所。緩存的存在是因?yàn)镮/O設(shè)備的緩慢,通常放在內(nèi)存中,斷電后即消失。
緩存涉及到源數(shù)據(jù)庫和緩存數(shù)據(jù)庫之間的數(shù)據(jù)同步。通常,更新源庫時(shí),會(huì)同時(shí)刪掉緩存中相關(guān)的就數(shù)據(jù),這樣在下次讀取的時(shí)候,能夠讀取到最新的數(shù)據(jù)。
緩存限制最大的就是其容量問題,而且都貴的很。假如業(yè)務(wù)模式固定,一些kv存儲(chǔ)使用LevelDB或者HBase等方案,會(huì)顯著節(jié)約成本。
是時(shí)候?qū)⒐こ棠K化了,畢竟上百個(gè)程序員共享一個(gè)代碼庫,風(fēng)險(xiǎn)已經(jīng)很大了。
模塊化通常會(huì)按照業(yè)務(wù)線進(jìn)行拆分。比如,支付模塊和報(bào)表模塊的拆分。
模塊拆分后,相似的模塊會(huì)共享數(shù)據(jù)庫。但更多的是通過冗余數(shù)據(jù)來解決,這樣能將業(yè)務(wù)解耦,一部分出現(xiàn)問題,另一部分能夠運(yùn)行良好。好比你隔壁出了殺人案你第二天還能正常去上班。
模塊之間要找到一種交互方式,比如使用HttpClient、OkHttp等。重要的是統(tǒng)一,統(tǒng)一了以后就有一個(gè)高大上的名字了:RPC。
一個(gè)小模塊很有可能會(huì)發(fā)展為一個(gè)大的業(yè)務(wù)線,也有可能無人問津。
模塊化之間另一種共享數(shù)據(jù)或者數(shù)據(jù)交互的方式就是MQ。除了有削峰等功效,MQ更多改變的是一種交互模式,一種對業(yè)務(wù)的解耦。
Kafka幾乎每個(gè)公司都在用,最高能有幾十萬的吞吐量。RabbitMQ、RocketMQ等,更多用在可靠性要求非常高的場景,但比較耗機(jī)器。
MQ資源一般都要求絕對的高可靠,作為基礎(chǔ)設(shè)施,一旦出問題,將帶來非常大的事故。設(shè)計(jì)的時(shí)候要考慮異常情況下的數(shù)據(jù)處理流向,以及MQ恢復(fù)后的補(bǔ)償策略。
MQ集群設(shè)計(jì)的比較小一些才合理,避免不同業(yè)務(wù),不同可靠性級別的消息互相影響。MQ在業(yè)務(wù)上和功能上要相互隔離,做到最小服務(wù)集合。
為了避免MQ當(dāng)機(jī)對正常業(yè)務(wù)產(chǎn)生影響,非重要鏈路上的MQ不能阻塞業(yè)務(wù)的正常進(jìn)行,這種消息通常通過異步線程發(fā)送。
微服務(wù)我們已經(jīng)使用消息和模塊化,將系統(tǒng)拆分成了多個(gè)工程。將這些工程使用統(tǒng)一的方式管理起來,統(tǒng)一其交互模式和在上面的治理,就是微服務(wù)的范疇。
微服務(wù)就是一個(gè)多模塊項(xiàng)目規(guī)范化的過程。非規(guī)范的服務(wù)與微服務(wù)體系,是要共存一段時(shí)間的,如何保證新舊服務(wù)的替換,是一個(gè)管理上的問題。
根據(jù)SpringCloud的描述,一個(gè)服務(wù)想要被發(fā)現(xiàn),需要將自己注冊到通用的注冊中心,其他服務(wù)可以從同一個(gè)地方,獲取它的實(shí)例,進(jìn)而調(diào)用。
而真正產(chǎn)生調(diào)用的功能,就是RPC的功能。RPC要考慮一系列比如超時(shí)、重拾、熔斷等功能。在某些訪問量非常大的節(jié)點(diǎn),可能還要考慮預(yù)熱。
RPC要能產(chǎn)生一些統(tǒng)計(jì)性數(shù)據(jù),比如TPS、QPS、TP值等,很顯然SpringCloud是缺乏的,我們要借助外部系統(tǒng)進(jìn)行分析。
在外部請求流轉(zhuǎn)到內(nèi)部之前,需要經(jīng)過一層網(wǎng)關(guān)的處理。像一些通用的操作,比如權(quán)限、限流、灰度等,就可以在網(wǎng)關(guān)層處理。
微服務(wù)最重要的特色就是其治理功能。服務(wù)治理的依據(jù)就是監(jiān)控信息。通過統(tǒng)計(jì)每次調(diào)用的大小、耗時(shí)、分布,能夠得出服務(wù)的大體拓?fù)洹?/p>
通常以下信息最有用:
1、QPS,時(shí)間序列的qps分布,最高區(qū)間qps
2、平均響應(yīng)時(shí)間,接口的平均響應(yīng)時(shí)間,最大耗時(shí)和最小耗時(shí)
3、TP值分布,90%,99%等請求是在x耗時(shí)內(nèi)完成
通過以上信息能夠?qū)Ψ?wù)進(jìn)行畫像。是擴(kuò)容、縮容、專項(xiàng)治理的數(shù)據(jù)依據(jù)。
微服務(wù)引出的另外一個(gè)問題就是調(diào)用鏈,即某個(gè)請求的真實(shí)路徑。分布式環(huán)境下的問題排查,會(huì)非常的困難,調(diào)用鏈能夠幫助研發(fā)快速定位問題,并幫助理解業(yè)務(wù)的數(shù)據(jù)流向。
服務(wù)治理的目的就是找到不合理的請求和分布,比如某個(gè)接口耗時(shí)太長;某個(gè)接口請求量大,需要加緩存;某個(gè)功能依賴鏈條過長,需要業(yè)務(wù)優(yōu)化等。
服務(wù)治理要借助大量的外部分析工具,更多通用的業(yè)務(wù)模型,需要大數(shù)據(jù)平臺(tái)的支持。
我們把監(jiān)控/報(bào)警也放在服務(wù)治理的部分,在《這么多監(jiān)控組件,總有一款適合你》中,我們詳細(xì)的討論了監(jiān)控部分的技術(shù)選擇方案。
日志
微服務(wù)產(chǎn)生的另外一個(gè)問題就是日志太過分散。一個(gè)核心的業(yè)務(wù)可能有上百個(gè)實(shí)例,你不可能打開100個(gè)終端去看日志。這就涉及到日志的收集。
日志歸集功能就是把分散的日志集合到一個(gè)地方,它的主要挑戰(zhàn)就是數(shù)據(jù)量。
通常日志分為兩部分,一部分是全量的,可以通過定時(shí)同步等方式,備份到日志堡壘機(jī)或者h(yuǎn)dfs中;一部分是過濾后的日志,比如一些異常信息,集中在某一個(gè)處理平臺(tái)中進(jìn)行報(bào)警。
很多研發(fā)喜歡將用戶行為數(shù)據(jù)輸出到日志文件中,這部分日志被收集后,會(huì)通過流計(jì)算或者離線計(jì)算,得到一些推薦和模型。日志信息進(jìn)入了大數(shù)據(jù)處理的范疇,我們不過多描述。
持續(xù)集成如果一個(gè)上點(diǎn)規(guī)模的公司,技術(shù)團(tuán)隊(duì)有什么值得一做的系統(tǒng),那么發(fā)布系統(tǒng)算一個(gè)。《發(fā)布系統(tǒng)有那么難么?》中,談了一種可能的模式。
發(fā)布系統(tǒng)就是給一堆腳本包了一張方便的皮。一些流程性工具、發(fā)布驗(yàn)證、CI/CD功能,很容易能夠添加到自己的發(fā)布系統(tǒng)中。
很多微服務(wù)推廣的文章中,談到虛擬化(Docker)等,其實(shí)不是必須的。虛擬化減少了服務(wù)編排的時(shí)間,能夠方便的進(jìn)行擴(kuò)容和縮容,但對監(jiān)控、日志收集、網(wǎng)絡(luò)拓?fù)涞龋蟊容^高。建議是整個(gè)體系中的最后一步而不是第一步。
你的系統(tǒng)是否靈活,還與公司的文化環(huán)境相關(guān)。如果上個(gè)線走審批流程就需要一兩周,那么做一個(gè)敏捷的持續(xù)集成系統(tǒng)就不是那么必要了。
基礎(chǔ)設(shè)施基礎(chǔ)設(shè)施更多指的是運(yùn)維體系,這是支撐整個(gè)系統(tǒng)健康發(fā)展的基石。我傾向于基礎(chǔ)運(yùn)維和基礎(chǔ)架構(gòu)不分家,因?yàn)樗鼈兊哪J胶臀幕且粋€(gè)公司研發(fā)環(huán)境的基石。
另外一些基礎(chǔ)組件,比如配置中心、調(diào)度中心、分布式鎖管理等,都對可靠性有較高的要求。
這套體系看著簡單,也有固定的解決方案。但問題就在于,許多公司從成立玩到倒閉,玩了那么多年,還是沒玩好。
真是可憐。
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://specialneedsforspecialkids.com/yun/11965.html
摘要:緩存攻擊是和個(gè)人電腦相關(guān)的一種邊信道攻擊,因?yàn)楦咚倬彌_區(qū)被不同的進(jìn)程和用戶使用而導(dǎo)致了信息的泄露。報(bào)告中的攻擊方式因此是高度可行的對于攻擊者的假設(shè)和限定是實(shí)際的運(yùn)行的時(shí)間是實(shí)際的給攻擊者帶來的好處也是實(shí)際的。 原文 The Spy in the Sandbox – Practical Cache Attacks in Javascript 相關(guān)論文可在 https://github.c...
摘要:私有是趨勢還是熱潮那么,為何這些科技巨頭會(huì)紛紛進(jìn)軍私有領(lǐng)域呢這只是一種風(fēng)尚潮流還是必然的趨勢在一些觀點(diǎn)看來,是趨勢性的可能性要更高一些。這么想來,公有云巨頭與傳統(tǒng)私有供應(yīng)商之間的合作便是有跡可循了。而另一方面,又是公有云領(lǐng)域中的絕對王者。如果單純以收入進(jìn)行衡量的話,公有云市場的巨頭們?yōu)閬嗰R遜(AWS)、微軟Azure、谷歌云、阿里云、騰訊云和百度云等。從2017年Q2到2018年Q2這一段時(shí)...
摘要:微服務(wù)能夠?yàn)閼?yīng)用程序設(shè)計(jì)提供一種更具針對性范圍性與模塊性的實(shí)現(xiàn)方案。安全微服務(wù)部署模式可謂多種多樣但其中使用最為廣泛的當(dāng)數(shù)每主機(jī)服務(wù)模式。在微服務(wù)環(huán)境下,安全性往往成為最大的挑戰(zhàn)。不同微服務(wù)之間可通過多種方式建立受信關(guān)系。 每個(gè)人都在討論微服務(wù),每個(gè)人也都希望能夠?qū)崿F(xiàn)微服務(wù)架構(gòu),而微服務(wù)安全也日漸成為大家關(guān)注的重要問題。今天小數(shù)與大家分享的文章,就從應(yīng)用層面深入探討了應(yīng)對微服務(wù)安全挑戰(zhàn)...
摘要:微服務(wù)已經(jīng)開始形成一套正式標(biāo)準(zhǔn),也帶來了一票提供相應(yīng)服務(wù)的供應(yīng)商。結(jié)論源于一組概念,它們與微服務(wù)架構(gòu)具有相同的核心概念。 服務(wù)導(dǎo)向架構(gòu)(簡稱SOA,service-oriented architecture)已經(jīng)死亡?你可能會(huì)這么想。 但其實(shí)不然。的確,隨著新技術(shù)的出現(xiàn),SOA本身的價(jià)值可能已經(jīng)大不如前,但是SOA的遺產(chǎn)仍在推動(dòng)微服務(wù)市場發(fā)展。 將SOA原則納入微服務(wù)的設(shè)計(jì)和構(gòu)建是確保...
閱讀 1371·2023-04-25 16:45
閱讀 1917·2021-11-17 09:33
閱讀 2306·2021-09-27 14:04
閱讀 914·2019-08-30 15:44
閱讀 2632·2019-08-30 14:24
閱讀 3411·2019-08-30 13:59
閱讀 1690·2019-08-29 17:00
閱讀 887·2019-08-29 15:33