|
1. 查詢分離模式 這種模式主要解決單機數(shù)據(jù)庫壓力過大，從而導致業(yè)務緩慢甚至超時，查詢響應時間變長的問題，也包括需要大量數(shù)據(jù)庫服務器計算資源的查詢請求。這個可以說是單庫單應用模式的升級版本，也是技術架構(gòu)迭代演進過程中的必經(jīng)之路。 這種模式的一般設計見下圖：
如上圖所示，這種模式較單庫單應用模式與內(nèi)容分發(fā)模式多了幾個部分，一個是業(yè)務數(shù)據(jù)庫的主從分離，一個是引入了ES，為什么要這樣？都解決了哪些痛點，下面具體結(jié)合業(yè)務需求場景進行敘述。
場景一：全文關鍵詞檢索
我想這個需求，絕大多數(shù)應用都會有，如果使用傳統(tǒng)的數(shù)據(jù)庫技術，大部分可能都會使用like這種SQL語句，高級一點可能是先分詞，然后通過分詞index相關的記錄。SQL語句的性能問題與全表掃描機制導致了非常嚴重的性能問題，現(xiàn)在基本上很少見到。 這里的ES是ElasticSearch的縮寫，是一種查詢引擎，類似的還有Solr等，都差不多的技術，ES較Solr配置簡單、使用方便，所以這里選用了它。另外，ES支持橫向擴展，理論上沒有性能的瓶頸。同時，還支持各種插件、自定義分詞器等，可擴展性較強。在這里，使用ES不僅可以替代數(shù)據(jù)庫完成全文檢索功能，還可以實現(xiàn)諸如分頁、排序、分組、分面等功能。具體的，請同學們自行學習之。那怎么使用呢？一個一般的流程是這樣的：
實際中怎么用，還請同學們根據(jù)實際情況做組合、取舍。
場景二：大量的普通查詢
這個場景是指我們的業(yè)務中的大部分輔助性的查詢，如：取錢的時候先查詢一下余額，根據(jù)用戶的ID查詢用戶的記錄，取得該用戶最新的一條取錢記錄等。我們肯定是要天天要用的，而且用的還非常多。同時呢，我們的寫入請求也是非常多的，導致大量的寫入、查詢操作壓向同一數(shù)據(jù)庫，然后，數(shù)據(jù)庫掛了，系統(tǒng)掛了，領導生氣了，被開除了，還不起房貸了，露宿街頭了，老婆跟別人跑了，......
不敢想，所以要求我們必須分散數(shù)據(jù)庫的壓力，一個業(yè)界較成熟的方案就是數(shù)據(jù)庫的讀寫分離，寫的時候入主庫，讀的時候讀從庫。這樣就把壓力分散到不同的數(shù)據(jù)庫了，如果一個讀庫性能不行，扛不住的話，可以一主多從，橫向擴展。可謂是一劑良藥??！那怎么使用呢？一個一般的流程是這樣的：
比較簡單吧，一些聰明的、愛思考的、上進的同學可能發(fā)現(xiàn)問題了，也包括上面介紹的場景一，就是延遲問題，如：數(shù)據(jù)還沒有到從庫，我就馬上讀，那么是讀不到的，會發(fā)生問題的。 對于這個問題，各家公司解決的思路不一樣，方法不盡相同。一個普遍的解決方案是：讀不到就讀主庫，當然這么說也是有前提條件的，但具體的方案這里就不一一展開了，我可能會在接下來的分享中詳解各種方案。 另外，關于數(shù)據(jù)庫的復制模式，還請同學們自行學習，太多了，這里說不清。該總結(jié)一下這種模式的優(yōu)缺點的了，如下：
優(yōu)點：減少數(shù)據(jù)庫的壓力，理論上提供無限高的讀性能，間接提高業(yè)務(寫)的性能，專用的查詢、索引、全文(分詞)解決方案。 缺點：數(shù)據(jù)延遲，數(shù)據(jù)一致性的保證。
2. 微服務模式 上面的模式看似不錯，解決了性能問題，我可以不用露宿街頭了、老婆還是我的，哈哈。但是 軟件系統(tǒng)天生的復雜性決定了，除了性能，還有其他諸如高可用、健壯性等大量問題等待我們解決，再加上各個部門間的撕逼、扯皮，更讓我們碼農(nóng)雪上加霜，所以 繼續(xù)吧......
微服務模式可以說是最近的熱點，花花綠綠、大大小小、國內(nèi)國外的公司都在鼓吹，實踐這個模式，可是大部分都沒有弄清楚為什么要這么做，也并不知道這么做有什么好處、壞處，在這里，我將以我自己的親身實踐說一下我對這個模式的看法，不喜勿噴！隨著業(yè)務與人員的增加，遇到了如下的問題：
為了解決上述問題，我司使用了微服務模式，這種模式的一般設計見下圖：
如上圖所示，我把業(yè)務分塊，做了垂直切分，切成一個個獨立的系統(tǒng)，每個系統(tǒng)各自衍化，有自己的庫、緩存、ES等輔助系統(tǒng)，系統(tǒng)之間的實時交互通過RPC，異步交互通過MQ，通過這種組合，共同完成整個系統(tǒng)功能。 那么，這么做是否真的解決上述問題了呢？不玩虛的，一個個來說。對于問題一，由于拆分成了多個子系統(tǒng)，系統(tǒng)的壓力被分散了，而各個子系統(tǒng)都有自己的數(shù)據(jù)庫實例，所以數(shù)據(jù)庫的壓力變小。 對于問題二，一個子系統(tǒng)A的數(shù)據(jù)庫掛了，只是影響到系統(tǒng)A和使用系統(tǒng)A的那些功能，不會所有的功能不可用，從而解決一個數(shù)據(jù)庫掛了，導致所有功能不可用的問題。 問題三、四，也因為拆分得到了解決，各個子系統(tǒng)有自己獨立的GIT代碼庫，不會相互影響。通用的模塊可通過庫、服務、平臺的形式解決。 問題五，子系統(tǒng)A發(fā)生改變，需要上線，那么我只需要編譯A，然后上線就可以了，不需要其他系統(tǒng)做同樣的事情。 問題六，順應了康威定律，我部門該干什么事、輸出什么，也通過服務的形式暴露出來，我部只管把我部的職責、軟件功能做好就可以。 問題七，所有需要我部數(shù)據(jù)的需求，都通過接口的形式發(fā)布出去，客戶通過接口獲取數(shù)據(jù)，從而屏蔽了底層數(shù)據(jù)庫結(jié)構(gòu)，甚至數(shù)據(jù)來源，我部只需保證我部的接口契約沒有發(fā)生變化即可，新的需求增加新的接口，不會影響老的接口。 問題八，不同的子系統(tǒng)需要不同的權(quán)限，這個問題也優(yōu)雅的解決了。 問題九，暫時控制住了復雜性，我只需控制好大的方面，定義好系統(tǒng)邊界、接口、大的流程，然后再分而治之、逐個擊破、合縱連橫。
目前來說，所有問題得到解決！bingo! 但是，還有許多其他的副作用會隨之產(chǎn)生，如RPC、MQ的超高穩(wěn)定性、超高性能，網(wǎng)絡延遲，數(shù)據(jù)一致性等問題，這里就不展開來講了，太多了，一本書都講不完。
另外，對于這個模式來說，最難把握的是度，切記不要切分過細，我見過一個功能一個子系統(tǒng)，上百個方法分成上百個子系統(tǒng)的，真的是太過度了。實踐中，一個較為可行的方法是：能不分就不分，除非有非常必要的理由！。
優(yōu)點：相對高性能，可擴展性強，高可用，適合于中等以上規(guī)模公司架構(gòu)。 缺點：復雜、度不好把握。指不僅需要一個能在高層把控大方向、大流程、總體技術的人，還需要能夠針對各個子系統(tǒng)有針對性的開發(fā)。把握不好度或者濫用的話，這個模式適得其反！
3.多級緩存模式 這個模式可以說是應對超高查詢壓力的一種普遍采用的策略，基本的思想就是在所有鏈路的地方，能加緩存就加緩存，如下圖所示：
如上圖所示，一般在三個地方加入緩存，一個是客戶端處，一個是API網(wǎng)關處，一個是具體的后端業(yè)務處，下面分別介紹。
客戶端處緩存：這個地方加緩存可以說是效果最好的---無延遲。因為不用經(jīng)過長長的網(wǎng)絡鏈條去后端業(yè)務處獲取數(shù)據(jù)，從而導致加載時間過長，客戶流失等損失。雖然有CDN的支持，但是從客戶端到CDN還是有網(wǎng)絡延遲的，雖然不大。具體的技術依據(jù)不同的客戶端而定，對于WEB來講，有瀏覽器本地緩存、Cookie、Storage、緩存策略等技術；對于APP來講，有本地數(shù)據(jù)庫、本地文件、本地內(nèi)存、進程內(nèi)緩存支持。以上提到的各種技術有興趣的同學可以繼續(xù)展開來學習。如果客戶端緩存沒有命中，那么就會去后端業(yè)務拿數(shù)據(jù)，一般來講，都會有個API網(wǎng)關，在這里加緩存也是非常有必要的。 API網(wǎng)關處緩存：這個地方加緩存的好處是不用把請求發(fā)送到后方，直接在這里就處理了，然后返回給請求者。常見的技術，如http請求，API網(wǎng)關用的基本都是nginx，可以使用nginx本身的緩存模塊，也可以使用Lua+Redis技術定制化。其他的也都大同小異。 后端業(yè)務處：這個我想就不用多說了，大家應該差不多都知道，什么Redis,Memcache,Jvm內(nèi)等等，不熬述了。
實踐中，要結(jié)合具體的實際情況，綜合利用各級緩存技術，使得各種請求最大程度的在到達后端業(yè)務之前就被解決掉，從而減少后端服務壓力、減少占用帶寬、增強用戶體驗。至于是否只有這三個地方加緩存，我覺得要活學活用，心法比劍法重要！總結(jié)一下這個模式的優(yōu)缺點：
優(yōu)點：抗住大量讀請求，減少后端壓力。 缺點：數(shù)據(jù)一致性問題較突出，容易發(fā)生雪崩，即：如果客戶端緩存失效、API網(wǎng)關緩存失效，那么所有的大量請求瞬間壓向后端業(yè)務系統(tǒng)，后果可想而知。
本次分享的中篇到此結(jié)束，接下來的下篇將介紹最后三種模式：分庫分表模式、彈性伸縮模式、多機房模式，相對來講技術含量更高，敬請期待！ |
|
|
來自： CoCO-Ebook > 《待分類》
