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

[[321931]]

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

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

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

那我們開始。

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

 

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

數據庫

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

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

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

小表和寬表

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

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

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

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

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

 

分庫分表

分庫分表很可能會引入某一種中間件，因為僅僅將數據庫分開還不行。HA，FailOver等特性，是同時需要的。

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

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

數據同步

有分就有合，比如某些報表業務需要全量的數據。

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

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

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

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

分層的數據存儲

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

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

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

 

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

是誰保證了分層的數據存儲設計呢?除了一部分通過MQ分發數據的業務，還是得靠我們的數據同步組件。

緩存

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

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

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

 

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

模塊化

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

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

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

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

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

 

MQ

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

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

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

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

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

微服務

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

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

 

功能組件

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

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

RPC要能產生一些統計性數據，比如TPS、QPS、TP值等，很顯然SpringCloud是缺乏的，我們要借助外部系統進行分析。

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

 

服務治理

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

通常以下信息最有用：

1、QPS，時間序列的qps分布，最高區間qps

2、平均響應時間，接口的平均響應時間，最大耗時和最小耗時

3、TP值分布，90%，99%等請求是在x耗時內完成

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

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

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

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

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

日志

 

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

日志歸集功能就是把分散的日志集合到一個地方，它的主要挑戰就是數據量。

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

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

持續集成

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

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

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

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

基礎設施

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

 

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

END

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

真是可憐。