微服務不是所有，只是特定領域的子集

更多精彩文章。

《微服務不是所有，只是特定領域的子集》

《「分庫分表" ？選型和流程要慎重，不然會失控》

這麼多監控組件，總有一款適合你

《使用Netty，咱們到底在開發些什麼？》

《這多是最中肯的Redis規範了》

《程序員畫像，十年沉浮》

最有用系列：

《Linux生產環境上，最經常使用的一套「vim「技巧》

《Linux生產環境上，最經常使用的一套「Sed「技巧》

《Linux生產環境上，最經常使用的一套「AWK「技巧》

---

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

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

接下來咱們談一些放之四海而皆準的道理，不須要貼上"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是缺少的，咱們要藉助外部系統進行分析。

在外部請求流轉到內部以前，須要通過一層網關的處理。像一些通用的操做，好比權限、限流、灰度等，就能夠在網關層處理。

服務治理

微服務最重要的特點就是其治理功能。服務治理的依據就是監控信息。經過統計每次調用的大小、耗時、分佈，可以得出服務的大致拓撲。

一般如下信息最有用： 一、QPS，時間序列的qps分佈，最高區間qps 二、平均響應時間，接口的平均響應時間，最大耗時和最小耗時 三、TP值分佈，90%，99%等請求是在x耗時內完成

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

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

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

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

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

日誌

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

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

一般日誌分爲兩部分，一部分是全量的，能夠經過定時同步等方式，備份到日誌堡壘機或者hdfs中；一部分是過濾後的日誌，好比一些異常信息，集中在某一個處理平臺中進行報警。

不少研發喜歡將用戶行爲數據輸出到日誌文件中，這部分日誌被收集後，會經過流計算或者離線計算，獲得一些推薦和模型。日誌信息進入了大數據處理的範疇，咱們不過多描述。

持續集成

若是一個上點規模的公司，技術團隊有什麼值得一作的系統，那麼發佈系統算一個。《發佈系統有那麼難麼?》中，談了一種可能的模式。

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

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

你的系統是否靈活，還與公司的文化環境相關。若是上個線走審批流程就須要一兩週，那麼作一個敏捷的持續集成系統就不是那麼必要了。

基礎設施

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

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

END

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

真是可憐。