摘要：一些官宣的特性，在公司內(nèi)是嚴(yán)格禁止的。一個(gè)超過(guò)個(gè)表的聯(lián)合查詢(xún)業(yè)務(wù)，大概率是不合理的。微服務(wù)就是一個(gè)多模塊項(xiàng)目規(guī)范化的過(guò)程。服務(wù)治理微服務(wù)最重要的特色就是其治理功能。微服務(wù)引出的另外一個(gè)問(wèn)題就是調(diào)用鏈，即某個(gè)請(qǐng)求的真實(shí)路徑。

大家都在學(xué)SpringCloud，貌似學(xué)會(huì)了SC就牛逼哄哄，感覺(jué)不得了的樣子。但微服務(wù)，在整個(gè)企業(yè)級(jí)應(yīng)用中，只占了一小部分。微服務(wù)引入的問(wèn)題比解決的問(wèn)題還要多，你會(huì)遇到各種各樣的bottleneck。

微服務(wù)解決的是計(jì)算節(jié)點(diǎn)的問(wèn)題，然而根源卻在存儲(chǔ)節(jié)點(diǎn)。當(dāng)業(yè)務(wù)規(guī)模變得越來(lái)越龐大，存儲(chǔ)、編碼、管理都會(huì)成為問(wèn)題。

接下來(lái)我們談一些放之四海而皆準(zhǔn)的道理，不需要貼上"XX公司最佳實(shí)踐"之類(lèi)的標(biāo)簽。

下面是一張因數(shù)據(jù)擴(kuò)張引出的微服務(wù)相關(guān)的圖，簡(jiǎn)約但不簡(jiǎn)單。中小型公司只要有這些元素，就能玩的很好；大點(diǎn)的公司，因?yàn)橐?guī)模太大，每個(gè)組件都會(huì)遇到瓶頸，所謂的專(zhuān)項(xiàng)的優(yōu)化并不能脫離它的本質(zhì)。

那我們開(kāi)始。

注意，這張圖僅是主要數(shù)據(jù)路徑，一個(gè)子集，其他的包括CDN、通訊層等，不在此列。

這張圖并不包含某個(gè)特定領(lǐng)域的具體架構(gòu)，屬于一個(gè)整體性的概括。我們從數(shù)據(jù)庫(kù)容量的瓶頸說(shuō)起，看一下微服務(wù)在其中的比重。

用戶(hù)數(shù)據(jù)要存儲(chǔ)，就存在數(shù)據(jù)庫(kù)。過(guò)去這么多年，NoSQL并不能消除開(kāi)發(fā)人員的恐懼，所以，MySQL之類(lèi)還是大多數(shù)公司的首選存儲(chǔ)。

假設(shè)你的業(yè)務(wù)增長(zhǎng)的很好，這個(gè)就有意思多了。項(xiàng)目開(kāi)始，你的sql玩的越6，那么給后人埋的坑，越多。因?yàn)閟ql的功能太豐富了，一不小心，就炫技了。你會(huì)發(fā)現(xiàn)，林子越大，對(duì)sql的規(guī)范要求越高。一些官宣的特性，在公司內(nèi)是嚴(yán)格禁止的。

市場(chǎng)發(fā)展很好，終于來(lái)報(bào)應(yīng)了。以前的技巧變成了現(xiàn)在的累贅。慢查詢(xún)、全文掃描，招招斃命。想要加緩存，結(jié)果發(fā)現(xiàn)無(wú)從下手；想要分庫(kù)分表，結(jié)果發(fā)現(xiàn)表關(guān)系錯(cuò)綜復(fù)雜。

所以第一步，還是得去填坑。一個(gè)超過(guò)3個(gè)表的聯(lián)合查詢(xún)業(yè)務(wù)，大概率是不合理的。在加緩存和分庫(kù)分表之前，還是得重新設(shè)計(jì)一下數(shù)據(jù)表。

忘掉什么數(shù)據(jù)庫(kù)范式，我們將存在兩類(lèi)表：小表和寬表。

小表提供了最基本的數(shù)據(jù)，可能一個(gè)簡(jiǎn)單的KV就完成了。一些聯(lián)合查詢(xún)，是直接可以在程序里進(jìn)行循環(huán)拼接的。程序里循環(huán)1000次10毫秒的查詢(xún)，比單次查詢(xún)耗費(fèi)6秒要強(qiáng)的多。這就是分布式系統(tǒng)的特點(diǎn)，小耗時(shí)的批量查詢(xún)，比hang在那里更加有生命力。

寬表通過(guò)冗余的方式，提供了某個(gè)重要功能常用的分析數(shù)據(jù)。這種表的字段一般都特別多，在寫(xiě)入時(shí)通過(guò)拼接獲取冗余數(shù)據(jù)，一般用在讀多寫(xiě)少的場(chǎng)景。

完成了這一步，接下來(lái)的工作才能進(jìn)行。

在《“分庫(kù)分表" ？選型和流程要慎重，否則會(huì)失控》中，詳細(xì)的說(shuō)明了分庫(kù)分表的選型，這里淺談一下過(guò)程。

分庫(kù)分表很可能會(huì)引入某一種中間件，因?yàn)閮H僅將數(shù)據(jù)庫(kù)分開(kāi)還不行。HA，F(xiàn)ailOver等特性，是同時(shí)需要的。

分庫(kù)分為垂直分和水平分。垂直面向的是業(yè)務(wù)拆分，即將一部分表按照業(yè)務(wù)邏輯獨(dú)立到其他庫(kù)中；水平面向的是容量，即通過(guò)分庫(kù)分表的模式使數(shù)據(jù)有一個(gè)擴(kuò)張的途徑。

數(shù)據(jù)一定要有一個(gè)可以度量的切分維度，否則就過(guò)于分散，或者過(guò)于傾斜，影響后續(xù)的處理。

有分就有合，比如某些報(bào)表業(yè)務(wù)需要全量的數(shù)據(jù)。

不同業(yè)務(wù)通過(guò)共享數(shù)據(jù)庫(kù)來(lái)共享數(shù)據(jù)不得不說(shuō)是個(gè)非常蠢的主意。這個(gè)時(shí)候就需要一些數(shù)據(jù)同步工具。

數(shù)據(jù)同步組件可以說(shuō)是一個(gè)公司的必備組件。有基于最后更新時(shí)間的高延遲同步工具，也有基于binlog的低延遲同步工具。有的公司為了穩(wěn)定，還會(huì)有所謂的多機(jī)房同步。

數(shù)據(jù)同步最怕異常，因?yàn)榇蠖鄶?shù)同步都有順序性要求。一切運(yùn)行良好的時(shí)候，大家皆大歡喜；一旦出現(xiàn)異常，就需要其他手段來(lái)保證異常期間的數(shù)據(jù)同步和延遲。

這都是些臟活，自動(dòng)化有時(shí)候會(huì)適得其反，監(jiān)控是第一位的。

可以預(yù)見(jiàn)的是，即使你分庫(kù)分表了，還是能很快達(dá)到瓶頸。分庫(kù)分表后，你的一些統(tǒng)計(jì)功能可能還用不了了，在一些傳統(tǒng)的管理系統(tǒng)上，這是硬傷。

一個(gè)分層的數(shù)據(jù)存儲(chǔ)層是必要的。你的一些業(yè)務(wù)，可能一個(gè)分支走的是MySQL，換了另外一個(gè)條件就成了ES。

不同的DB做不同的事情。RDBMS只做原是數(shù)據(jù)的存儲(chǔ)和查詢(xún)，是扁平快的數(shù)據(jù)通道；特定的單機(jī)高性能DB，做一些匯聚和科學(xué)計(jì)算；分布式的類(lèi)RT的存儲(chǔ)，用來(lái)存儲(chǔ)一些中等規(guī)模的數(shù)據(jù)，并提供一些中延遲的搜索功能；海量的存儲(chǔ)系統(tǒng)，存儲(chǔ)系統(tǒng)所有的歷史記錄，并提供離線分析功能。

不要想著某一類(lèi)存儲(chǔ)解決所有的問(wèn)題，那是騙人的。存儲(chǔ)部分的復(fù)雜性不是普通的微服務(wù)能夠相比的。

是誰(shuí)保證了分層的數(shù)據(jù)存儲(chǔ)設(shè)計(jì)呢？除了一部分通過(guò)MQ分發(fā)數(shù)據(jù)的業(yè)務(wù)，還是得靠我們的數(shù)據(jù)同步組件。

但DB的壓力實(shí)在是太大了，我們不得不考慮緩存。緩存不能亂用，有兩個(gè)原則：一個(gè)是緩存不能侵入業(yè)務(wù)，也就是不能帶有業(yè)務(wù)邏輯；一個(gè)是緩存的命中率要高，否則適得其反。緩存是對(duì)高并發(fā)、高速接口的補(bǔ)充，是系統(tǒng)穩(wěn)定性的必要不充分條件。

除了Redis等外置的緩存集群，jvm內(nèi)緩存也是一個(gè)比較重要的場(chǎng)所。緩存的存在是因?yàn)镮/O設(shè)備的緩慢，通常放在內(nèi)存中，斷電后即消失。

緩存涉及到源數(shù)據(jù)庫(kù)和緩存數(shù)據(jù)庫(kù)之間的數(shù)據(jù)同步。通常，更新源庫(kù)時(shí)，會(huì)同時(shí)刪掉緩存中相關(guān)的就數(shù)據(jù)，這樣在下次讀取的時(shí)候，能夠讀取到最新的數(shù)據(jù)。

緩存限制最大的就是其容量問(wèn)題，而且都貴的很。假如業(yè)務(wù)模式固定，一些kv存儲(chǔ)使用LevelDB或者HBase等方案，會(huì)顯著節(jié)約成本。

是時(shí)候?qū)⒐こ棠K化了，畢竟上百個(gè)程序員共享一個(gè)代碼庫(kù)，風(fēng)險(xiǎn)已經(jīng)很大了。

模塊化通常會(huì)按照業(yè)務(wù)線進(jìn)行拆分。比如，支付模塊和報(bào)表模塊的拆分。

模塊拆分后，相似的模塊會(huì)共享數(shù)據(jù)庫(kù)。但更多的是通過(guò)冗余數(shù)據(jù)來(lái)解決，這樣能將業(yè)務(wù)解耦，一部分出現(xiàn)問(wèn)題，另一部分能夠運(yùn)行良好。好比你隔壁出了殺人案你第二天還能正常去上班。

模塊之間要找到一種交互方式，比如使用HttpClient、OkHttp等。重要的是統(tǒng)一，統(tǒng)一了以后就有一個(gè)高大上的名字了：RPC。

一個(gè)小模塊很有可能會(huì)發(fā)展為一個(gè)大的業(yè)務(wù)線，也有可能無(wú)人問(wèn)津。

模塊化之間另一種共享數(shù)據(jù)或者數(shù)據(jù)交互的方式就是MQ。除了有削峰等功效，MQ更多改變的是一種交互模式，一種對(duì)業(yè)務(wù)的解耦。

Kafka幾乎每個(gè)公司都在用，最高能有幾十萬(wàn)的吞吐量。RabbitMQ、RocketMQ等，更多用在可靠性要求非常高的場(chǎng)景，但比較耗機(jī)器。

MQ資源一般都要求絕對(duì)的高可靠，作為基礎(chǔ)設(shè)施，一旦出問(wèn)題，將帶來(lái)非常大的事故。設(shè)計(jì)的時(shí)候要考慮異常情況下的數(shù)據(jù)處理流向，以及MQ恢復(fù)后的補(bǔ)償策略。

MQ集群設(shè)計(jì)的比較小一些才合理，避免不同業(yè)務(wù)，不同可靠性級(jí)別的消息互相影響。MQ在業(yè)務(wù)上和功能上要相互隔離，做到最小服務(wù)集合。

為了避免MQ當(dāng)機(jī)對(duì)正常業(yè)務(wù)產(chǎn)生影響，非重要鏈路上的MQ不能阻塞業(yè)務(wù)的正常進(jìn)行，這種消息通常通過(guò)異步線程發(fā)送。

我們已經(jīng)使用消息和模塊化，將系統(tǒng)拆分成了多個(gè)工程。將這些工程使用統(tǒng)一的方式管理起來(lái)，統(tǒng)一其交互模式和在上面的治理，就是微服務(wù)的范疇。

微服務(wù)就是一個(gè)多模塊項(xiàng)目規(guī)范化的過(guò)程。非規(guī)范的服務(wù)與微服務(wù)體系，是要共存一段時(shí)間的，如何保證新舊服務(wù)的替換，是一個(gè)管理上的問(wèn)題。

根據(jù)SpringCloud的描述，一個(gè)服務(wù)想要被發(fā)現(xiàn)，需要將自己注冊(cè)到通用的注冊(cè)中心，其他服務(wù)可以從同一個(gè)地方，獲取它的實(shí)例，進(jìn)而調(diào)用。

而真正產(chǎn)生調(diào)用的功能，就是RPC的功能。RPC要考慮一系列比如超時(shí)、重拾、熔斷等功能。在某些訪問(wèn)量非常大的節(jié)點(diǎn)，可能還要考慮預(yù)熱。

RPC要能產(chǎn)生一些統(tǒng)計(jì)性數(shù)據(jù)，比如TPS、QPS、TP值等，很顯然SpringCloud是缺乏的，我們要借助外部系統(tǒng)進(jìn)行分析。

在外部請(qǐng)求流轉(zhuǎn)到內(nèi)部之前，需要經(jīng)過(guò)一層網(wǎng)關(guān)的處理。像一些通用的操作，比如權(quán)限、限流、灰度等，就可以在網(wǎng)關(guān)層處理。

微服務(wù)最重要的特色就是其治理功能。服務(wù)治理的依據(jù)就是監(jiān)控信息。通過(guò)統(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%等請(qǐng)求是在x耗時(shí)內(nèi)完成

通過(guò)以上信息能夠?qū)Ψ?wù)進(jìn)行畫(huà)像。是擴(kuò)容、縮容、專(zhuān)項(xiàng)治理的數(shù)據(jù)依據(jù)。

微服務(wù)引出的另外一個(gè)問(wèn)題就是調(diào)用鏈，即某個(gè)請(qǐng)求的真實(shí)路徑。分布式環(huán)境下的問(wèn)題排查，會(huì)非常的困難，調(diào)用鏈能夠幫助研發(fā)快速定位問(wèn)題，并幫助理解業(yè)務(wù)的數(shù)據(jù)流向。

服務(wù)治理的目的就是找到不合理的請(qǐng)求和分布，比如某個(gè)接口耗時(shí)太長(zhǎng)；某個(gè)接口請(qǐng)求量大，需要加緩存；某個(gè)功能依賴(lài)鏈條過(guò)長(zhǎng)，需要業(yè)務(wù)優(yōu)化等。

服務(wù)治理要借助大量的外部分析工具，更多通用的業(yè)務(wù)模型，需要大數(shù)據(jù)平臺(tái)的支持。

我們把監(jiān)控/報(bào)警也放在服務(wù)治理的部分，在《這么多監(jiān)控組件，總有一款適合你》中，我們?cè)敿?xì)的討論了監(jiān)控部分的技術(shù)選擇方案。

微服務(wù)產(chǎn)生的另外一個(gè)問(wèn)題就是日志太過(guò)分散。一個(gè)核心的業(yè)務(wù)可能有上百個(gè)實(shí)例，你不可能打開(kāi)100個(gè)終端去看日志。這就涉及到日志的收集。

日志歸集功能就是把分散的日志集合到一個(gè)地方，它的主要挑戰(zhàn)就是數(shù)據(jù)量。

通常日志分為兩部分，一部分是全量的，可以通過(guò)定時(shí)同步等方式，備份到日志堡壘機(jī)或者h(yuǎn)dfs中；一部分是過(guò)濾后的日志，比如一些異常信息，集中在某一個(gè)處理平臺(tái)中進(jìn)行報(bào)警。

很多研發(fā)喜歡將用戶(hù)行為數(shù)據(jù)輸出到日志文件中，這部分日志被收集后，會(huì)通過(guò)流計(jì)算或者離線計(jì)算，得到一些推薦和模型。日志信息進(jìn)入了大數(shù)據(jù)處理的范疇，我們不過(guò)多描述。

如果一個(gè)上點(diǎn)規(guī)模的公司，技術(shù)團(tuán)隊(duì)有什么值得一做的系統(tǒng)，那么發(fā)布系統(tǒng)算一個(gè)?！栋l(fā)布系統(tǒng)有那么難么?》中，談了一種可能的模式。

發(fā)布系統(tǒng)就是給一堆腳本包了一張方便的皮。一些流程性工具、發(fā)布驗(yàn)證、CI/CD功能，很容易能夠添加到自己的發(fā)布系統(tǒng)中。

很多微服務(wù)推廣的文章中，談到虛擬化（Docker）等，其實(shí)不是必須的。虛擬化減少了服務(wù)編排的時(shí)間，能夠方便的進(jìn)行擴(kuò)容和縮容，但對(duì)監(jiān)控、日志收集、網(wǎng)絡(luò)拓?fù)涞?，要求比較高。建議是整個(gè)體系中的最后一步而不是第一步。

你的系統(tǒng)是否靈活，還與公司的文化環(huán)境相關(guān)。如果上個(gè)線走審批流程就需要一兩周，那么做一個(gè)敏捷的持續(xù)集成系統(tǒng)就不是那么必要了。

基礎(chǔ)設(shè)施更多指的是運(yùn)維體系，這是支撐整個(gè)系統(tǒng)健康發(fā)展的基石。我傾向于基礎(chǔ)運(yùn)維和基礎(chǔ)架構(gòu)不分家，因?yàn)樗鼈兊哪Ｊ胶臀幕?，是一個(gè)公司研發(fā)環(huán)境的基石。

另外一些基礎(chǔ)組件，比如配置中心、調(diào)度中心、分布式鎖管理等，都對(duì)可靠性有較高的要求。

這套體系看著簡(jiǎn)單，也有固定的解決方案。但問(wèn)題就在于，許多公司從成立玩到倒閉，玩了那么多年，還是沒(méi)玩好。

真是可憐。