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

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

微服務解決的是計算節(jié)點的問題，然而根源卻在存儲節(jié)點。當業(yè)務規(guī)模變得越來越龐大，存儲、編碼、管理都會成為問題。

接下來我們談一些放之四海而皆準的道理，不需要貼上"XX公司最佳實踐"之類的標簽。

下面是一張因數(shù)據(jù)擴張引出的微服務相關的圖，簡約但不簡單。中小型公司只要有這些元素，就能玩的很好；大點的公司，因為規(guī)模太大，每個組件都會遇到瓶頸，所謂的專項的優(yōu)化并不能脫離它的本質。

那我們開始。

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

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

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

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

市場發(fā)展很好，終于來報應了。以前的技巧變成了現(xiàn)在的累贅。慢查詢、全文掃描，招招斃命。想要加緩存，結果發(fā)現(xiàn)無從下手；想要分庫分表，結果發(fā)現(xiàn)表關系錯綜復雜。

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

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

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

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

完成了這一步，接下來的工作才能進行。

在《“分庫分表" ？選型和流程要慎重，否則會失控》中，詳細的說明了分庫分表的選型，這里淺談一下過程。

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

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

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

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

不同業(yè)務通過共享數(shù)據(jù)庫來共享數(shù)據(jù)不得不說是個非常蠢的主意。這個時候就需要一些數(shù)據(jù)同步工具。

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

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

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

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

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

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

不要想著某一類存儲解決所有的問題，那是騙人的。存儲部分的復雜性不是普通的微服務能夠相比的。

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

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

除了Redis等外置的緩存集群，jvm內緩存也是一個比較重要的場所。緩存的存在是因為I/O設備的緩慢，通常放在內存中，斷電后即消失。

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

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

是時候將工程模塊化了，畢竟上百個程序員共享一個代碼庫，風險已經(jīng)很大了。

模塊化通常會按照業(yè)務線進行拆分。比如，支付模塊和報表模塊的拆分。

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

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

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

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

Kafka幾乎每個公司都在用，最高能有幾十萬的吞吐量。RabbitMQ、RocketMQ等，更多用在可靠性要求非常高的場景，但比較耗機器。

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

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

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

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

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

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

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

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

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

微服務最重要的特色就是其治理功能。服務治理的依據(jù)就是監(jiān)控信息。通過統(tǒng)計每次調用的大小、耗時、分布，能夠得出服務的大體拓撲。

通常以下信息最有用：
1、QPS，時間序列的qps分布，最高區(qū)間qps
2、平均響應時間，接口的平均響應時間，最大耗時和最小耗時
3、TP值分布，90%，99%等請求是在x耗時內完成

通過以上信息能夠對服務進行畫像。是擴容、縮容、專項治理的數(shù)據(jù)依據(jù)。

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

服務治理的目的就是找到不合理的請求和分布，比如某個接口耗時太長；某個接口請求量大，需要加緩存；某個功能依賴鏈條過長，需要業(yè)務優(yōu)化等。

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

我們把監(jiān)控/報警也放在服務治理的部分，在《這么多監(jiān)控組件，總有一款適合你》中，我們詳細的討論了監(jiān)控部分的技術選擇方案。

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

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

通常日志分為兩部分，一部分是全量的，可以通過定時同步等方式，備份到日志堡壘機或者hdfs中；一部分是過濾后的日志，比如一些異常信息，集中在某一個處理平臺中進行報警。

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

如果一個上點規(guī)模的公司，技術團隊有什么值得一做的系統(tǒng)，那么發(fā)布系統(tǒng)算一個。《發(fā)布系統(tǒng)有那么難么?》中，談了一種可能的模式。

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

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

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

基礎設施更多指的是運維體系，這是支撐整個系統(tǒng)健康發(fā)展的基石。我傾向于基礎運維和基礎架構不分家，因為它們的模式和文化，是一個公司研發(fā)環(huán)境的基石。

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

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

真是可憐。