幾種常見的架構模式
本文已經收錄到Github倉庫，該倉庫包含計算機基礎、Java基礎、多執行緒、JVM、資料庫、Redis、Spring、Mybatis、SpringMVC、SpringBoot、分散式、微服務、設計模式、架構、校招社招分享等核心知識點，歡迎star~
如果存取不了Github，可以存取gitee地址。
分享一些工作中會用到的一些架構方面的設計模式。總體而言，共有八種，分別是：
- 單庫單應用模式：最簡單的，可能大家都見過
- 內容分發模式：目前用的比較多
- 查詢分離模式：對於大並行的查詢、業務
- 微服務模式：適用於複雜的業務模式的拆解
- 多級快取模式：可以把快取玩的很好
- 分庫分表模式：解決單機資料庫瓶頸
- 彈性伸縮模式：解決波峰波谷業務流量不均勻的方法之一
- 多機房模式：解決高可用、高效能的一種方法
三、單庫單應用模式
這是最簡單的一種設計模式，我們的大部分本科畢業設計、一些小的應用，基本上都是這種模式，這種模式的一般設計見下圖：
如上圖所示，這種模式一般只有一個資料庫，一個業務應用層，一個後臺管理系統，所有的業務都是用過業務層完成的，所有的資料也都是儲存在一個資料庫中的，好一點會有資料庫的同步。雖然簡單，但是也並不是一無是處。
- 優點：結構簡單、開發速度快、實現簡單，可用於產品的第一版等有原型驗證需求、使用者少的設計。
- 缺點：效能差、基本沒有高可用、擴充套件性差，不適用於大規模部署、應用等生產環境。
四、內容分發模式
基本上所有的大型的網站都有或多或少的採用這一種設計模式，常見的應用場景是使用CDN技術把網頁、圖片、CSS、JS等這些靜態資源分發到離使用者最近的伺服器。這種模式的一般設計見下圖：
如上圖所示，這種模式較單庫單應用模式多了一個CDN、一個雲端儲存OSS(七牛、又拍等雷同)。一個典型的應用流程(以使用者上傳、檢檢視片需求為例)如下：
- 上傳的時候，使用者選擇本地機器上的一個圖片進行上傳
- 程式會把這個圖片上傳到雲端儲存OSS上，並返回該圖片的一個URL
- 程式把這個URL字串儲存在業務資料庫中，上傳完成。
- 檢視的時候，程式從業務資料庫得到該圖片的URL
- 程式通過DNS查詢這個URL的圖片伺服器
- 智慧DNS會解析這個URL，得到與使用者最近的伺服器(或叢集)的地址A
- 然後把伺服器A上的圖片返回給程式
- 程式顯示該圖片，檢視完成。
由上可知，這個模式的關鍵是智慧DNS，它能夠解析出離使用者最近的伺服器。執行原理大致是：根據請求者的IP得到請求地點B，然後通過計算或者設定得到與B最近或通訊時間最短的伺服器C，然後把C的IP地址返回給請求者。這種模式的優缺點如下：
- 優點：資源下載快、無需過多的開發與設定，同時也減輕了後端伺服器對資源的儲存壓力，減少頻寬的使用。
- 缺點：目前來說OSS，CDN的價格還是稍微有些貴(雖然已經降價好幾次了)，只適用於中小規模的應用，另外由於網路傳輸的延遲、CDN的同步策略等，會有一些一致性、更新慢方面的問題。
五、查詢分離模式
這種模式主要解決單機資料庫壓力過大，從而導致業務緩慢甚至超時，查詢響應時間變長的問題，也包括需要大量資料庫伺服器計算資源的查詢請求。這個可以說是單庫單應用模式的升級版本，也是技術架構迭代演進過程中的必經之路。 這種模式的一般設計見下圖：
如上圖所示，這種模式較單庫單應用模式與內容分發模式多了幾個部分，一個是業務資料庫的主從分離，一個是引入了ES，為什麼要這樣？都解決了哪些痛點，下面具體結合業務需求場景進行敘述。
場景一：全文關鍵詞檢索
我想這個需求，絕大多數應用都會有，如果使用傳統的資料庫技術，大部分可能都會使用like這種SQL語句，高階一點可能是先分詞，然後通過分詞index相關的記錄。SQL語句的效能問題與全表掃描機制導致了非常嚴重的效能問題，現在基本上很少見到。 這裡的ES是ElasticSearch的縮寫，是一種查詢引擎，類似的還有Solr等，都差不多的技術，ES較Solr設定簡單、使用方便，所以這裡選用了它。另外，ES支援橫向擴充套件，理論上沒有效能的瓶頸。同時，還支援各種外掛、自定義分詞器等，可延伸性較強。在這裡，使用ES不僅可以替代資料庫完成全文檢索功能，還可以實現諸如分頁、排序、分組、分面等功能。具體的，請同學們自行學習之。那怎麼使用呢？一個一般的流程是這樣的：
- 伺服器端把一條業務資料落庫
- 伺服器端非同步把該條資料傳送到ES
- ES把該條記錄按照規則、設定放入自己的索引庫
- 使用者端查詢的時候，由伺服器端把這個請求傳送到ES，得到資料後，根據需求拼裝、組合資料，返回給使用者端
實際中怎麼用，還請同學們根據實際情況做組合、取捨。
場景二：大量的普通查詢
這個場景是指我們的業務中的大部分輔助性的查詢，如：取錢的時候先查詢一下餘額，根據使用者的ID查詢使用者的記錄，取得該使用者最新的一條取錢記錄等。我們肯定是要天天要用的，而且用的還非常多。同時呢，我們的寫入請求也是非常多的，導致大量的寫入、查詢操作壓向同一資料庫，然後，資料庫掛了，系統掛了，領導生氣了，被開除了，還不起房貸了，露宿街頭了，老婆跟別人跑了，......
不敢想，所以要求我們必須分散資料庫的壓力，一個業界較成熟的方案就是資料庫的讀寫分離，寫的時候入主庫，讀的時候讀從庫。這樣就把壓力分散到不同的資料庫了，如果一個讀庫效能不行，扛不住的話，可以一主多從，橫向擴充套件。可謂是一劑良藥啊！那怎麼使用呢？一個一般的流程是這樣的：
- 伺服器端把一條業務資料落庫
- 資料庫同步或非同步或半同步把該條資料複製到從庫
- 伺服器端讀資料的時候直接去從庫讀相應的資料
比較簡單吧，一些聰明的、愛思考的、上進的同學可能發現問題了，也包括上面介紹的場景一，就是延遲問題，如：資料還沒有到從庫，我就馬上讀，那麼是讀不到的，會發生問題的。 對於這個問題，各家公司解決的思路不一樣，方法不盡相同。一個普遍的解決方案是：讀不到就讀主庫，當然這麼說也是有前提條件的，但具體的方案這裡就不一一展開了，我可能會在接下來的分享中詳解各種方案。 另外，關於資料庫的複製模式，還請同學們自行學習，太多了，這裡說不清。該總結一下這種模式的優缺點的了，如下：
- 優點：減少資料庫的壓力，理論上提供無限高的讀效能，間接提高業務(寫)的效能，專用的查詢、索引、全文(分詞)解決方案。
- 缺點：資料延遲，資料一致性的保證。
六、微服務模式
上面的模式看似不錯，解決了效能問題，我可以不用露宿街頭了、老婆還是我的，哈哈。但是
軟體系統天生的複雜性決定了，除了效能，還有其他諸如高可用、健壯性等大量問題等待我們解決，再加上各個部門間的撕逼、扯皮，更讓我們碼農雪上加霜，所以
繼續吧......
微服務模式可以說是最近的熱點，花花綠綠、大大小小、國內國外的公司都在鼓吹，實踐這個模式，可是大部分都沒有弄清楚為什麼要這麼做，也並不知道這麼做有什麼好處、壞處，在這裡，我將以我自己的親身實踐說一下我對這個模式的看法，不喜勿噴！隨著業務與人員的增加，遇到了如下的問題：
- 單機資料庫寫請求量大量增加，導致資料庫壓力變大
- 資料庫一旦掛了，那麼整個業務都掛了
- 業務程式碼越來越多，都在一個GIT裡，越來越難以維護
- 程式碼腐化嚴重、臭味越來越濃
- 上線越來越頻繁，經常是一個小功能的修改，就要整個大專案要重新編譯
- 部門越來越多，該哪個部門改動大專案中的哪個東西，撕逼的厲害
- 其他一些外圍系統直接連線資料庫，導致一旦資料庫結構發生變化，所有的相關係統都要通知，甚至對修改不敏感的系統也要通知
- 每個應用伺服器需要開通所有的許可權、網路、FTP、各種各樣的，因為每個伺服器部署的應用都是一樣的
- 作為架構師，我已經失去了對這個系統的把控......
為了解決上述問題，我司使用了微服務模式，這種模式的一般設計見下圖：
如上圖所示，我把業務分塊，做了垂直切分，切成一個個獨立的系統，每個系統各自衍化，有自己的庫、快取、ES等輔助系統，系統之間的實時互動通過RPC，非同步互動通過MQ，通過這種組合，共同完成整個系統功能。 那麼，這麼做是否真的解決上述問題了呢？不玩虛的，一個個來說。對於問題一，由於拆分成了多個子系統，系統的壓力被分散了，而各個子系統都有自己的資料庫範例，所以資料庫的壓力變小。
對於問題二，一個子系統A的資料庫掛了，只是影響到系統A和使用系統A的那些功能，不會所有的功能不可用，從而解決一個資料庫掛了，導致所有功能不可用的問題。
問題三、四，也因為拆分得到了解決，各個子系統有自己獨立的GIT程式碼庫，不會相互影響。通用的模組可通過庫、服務、平臺的形式解決。
問題五，子系統A發生改變，需要上線，那麼我只需要編譯A，然後上線就可以了，不需要其他系統做同樣的事情。
問題六，順應了康威定律，我部門該幹什麼事、輸出什麼，也通過服務的形式暴露出來，我部只管把我部的職責、軟體功能做好就可以。
問題七，所有需要我部資料的需求，都通過介面的形式釋出出去，客戶通過介面獲取資料，從而遮蔽了底層資料庫結構，甚至資料來源，我部只需保證我部的介面契約沒有發生變化即可，新的需求增加新的介面，不會影響老的介面。
問題八，不同的子系統需要不同的許可權，這個問題也優雅的解決了。
問題九，暫時控制住了複雜性，我只需控制好大的方面，定義好系統邊界、介面、大的流程，然後再分而治之、逐個擊破、合縱連橫。
目前來說，所有問題得到解決！bingo! 但是，還有許多其他的副作用會隨之產生，如RPC、MQ的超高穩定性、超高效能，網路延遲，資料一致性等問題，這裡就不展開來講了，太多了，一本書都講不完。
另外，對於這個模式來說，最難把握的是度，切記不要切分過細，我見過一個功能一個子系統，上百個方法分成上百個子系統的，真的是太過度了。實踐中，一個較為可行的方法是：能不分就不分，除非有非常必要的理由！。
- 優點：相對高效能，可延伸性強，高可用，適合於中等以上規模公司架構。
- 缺點：複雜、度不好把握。指不僅需要一個能在高層把控大方向、大流程、總體技術的人，還需要能夠針對各個子系統有針對性的開發。把握不好度或者濫用的話，這個模式適得其反！
七、多級快取模式
這個模式可以說是應對超高查詢壓力的一種普遍採用的策略，基本的思想就是在所有鏈路的地方，能加快取就加快取，如下圖所示：
如上圖所示，一般在三個地方加入快取，一個是使用者端處，一個是API閘道器處，一個是具體的後端業務處，下面分別介紹。
使用者端處快取：這個地方加快取可以說是效果最好的---無延遲。因為不用經過長長的網路鏈條去後端業務處獲取資料，從而導致載入時間過長，客戶流失等損失。雖然有CDN的支援，但是從使用者端到CDN還是有網路延遲的，雖然不大。具體的技術依據不同的使用者端而定，對於WEB來講，有瀏覽器本地快取、Cookie、Storage、快取策略等技術；對於APP來講，有本地資料庫、本地檔案、本地記憶體、程序內快取支援。以上提到的各種技術有興趣的同學可以繼續展開來學習。如果使用者端快取沒有命中，那麼就會去後端業務拿資料，一般來講，都會有個API閘道器，在這裡加快取也是非常有必要的。
API閘道器處快取：這個地方加快取的好處是不用把請求傳送到後方，直接在這裡就處理了，然後返回給請求者。常見的技術，如http請求，API閘道器用的基本都是nginx，可以使用nginx本身的快取模組，也可以使用Lua+Redis技術客製化化。其他的也都大同小異。
後端業務處：這個我想就不用多說了，大家應該差不多都知道，什麼Redis,Memcache,Jvm內等等，不熬述了。
實踐中，要結合具體的實際情況，綜合利用各級快取技術，使得各種請求最大程度的在到達後端業務之前就被解決掉，從而減少後端服務壓力、減少佔用頻寬、增強使用者體驗。至於是否只有這三個地方加快取，我覺得要活學活用，心法比劍法重要！總結一下這個模式的優缺點：
- 優點：抗住大量讀請求，減少後端壓力。
- 缺點：資料一致性問題較突出，容易發生雪崩，即：如果使用者端快取失效、API閘道器快取失效，那麼所有的大量請求瞬間壓向後端業務系統，後果可想而知。
八、分庫分表模式
這種模式主要解決單表寫入、讀取、儲存壓力過大，從而導致業務緩慢甚至超時，交易失敗，容量不夠的問題。一般有水平切分和垂直切分兩種，這裡主要介紹水平切分。這個模式也是技術架構迭代演進過程中的必經之路。 這種模式的一般設計見下圖：
如上圖所示紅色部分，把一張表分到了幾個不同的庫中，從而分擔壓力。是不是很籠統？哈哈，那我們接下來就詳細的講解一下。首先澄清幾個概念，如下： 主機：硬體，指一臺物理機，或者虛擬機器器，有自己的CPU，記憶體，硬碟等。 範例：資料庫範例，如一個MySQL服務程序。一個主機可以有多個範例，不同的範例有不同的程序，監聽不同的埠。 庫：指表的集合，如學校庫，可能包含教師表、學生表、食堂表等等，這些表在一個庫中。一個範例中可以有多個庫。庫與庫之間用庫名來區分。 表：庫中的表，不必多說，不懂的就不用往下看了，不解釋。
那麼怎麼把單表分散呢？到底怎麼個分發呢？分發到哪裡呢？以下是幾個工作中的實踐，分享一下： 主機：這是最主要的也是最重要的點，本質上分庫分表是因為計算與儲存資源不夠導致的，而這種資源主要是由物理機，主機提供的，所以在這裡分是最基本的，畢竟沒有可用的計算資源，怎麼分效果都不是太好的。 範例：範例控制著連線數，同時受OS限制，CPU、記憶體、硬碟、網路IO也會受間接影響。會出現熱範例的現象，即：有些範例特別忙，有些範例非常的空閒。一個典型的現象是：由於單表反應慢，導致連線池被打滿，所有其他的業務都受影響了。這時候，把表分到不同的範例是有一些效果的。 庫：一般是由於單庫中最大單表數量的限制，才採取分庫。 表：單表壓力過大，索引量大，容量大，單表的鎖。據以上，把單表水平切分成不同的表。
大型應用中，都是一臺主機上只有一個範例，一個範例中只有一個庫，庫範例主機，所以才有了分庫分表這個簡稱。
既然知道了基本理論，那麼具體是怎麼做的呢？邏輯是怎麼跑的呢？接下來以一個例子來講解一下。 這個需求很簡單，使用者表(user)，單表資料量1億，查詢、插入、儲存都出現了問題，怎麼辦呢？
首先，分析問題，這個明顯是由於資料量太大了而導致的問題。 其次，設計方案，可以分為10個庫，這樣每個庫的資料量就降到了1KW，單表1KW資料量還是有些大，而且不利於以後量的增長，所以每個庫再分100個表，這個每個單表資料量就為10W了，對於查詢、索引更新、單表檔案大小、開啟速度，都有一些益處。接下來，給IT部門打電話，要10臺物理機，擴充套件資料庫...... 最後，邏輯實現，這裡應該是最有學問的地方。首先是寫入資料，需要知道寫到哪個分庫分表中，讀也是一樣的，所以，需要有個請求路由層，負責把請求分發、轉換到不同的庫表中，一般有路由規則的概念。
怎麼樣，簡單吧？哈哈，too 那義務。說說這個模式的問題，主要是帶來了事務上的問題，因為分庫分表，事務完成不了，而分散式事務又太笨重，所以這裡需要有一定的策略，保證在這種情況下事務能夠完成。採取的策略如：最終一致性、複製、特殊設計等。再有就是業務程式碼的改造，一些關聯查詢要改造，一些單表orderBy的問題需要特殊處理，也包括groupBy語句，如何解決這些副作用不是一句兩句能說清楚的，以後有時間，我單獨講講這些。
該總結一下這種模式的優缺點的了，如下：
- 優點：減少資料庫單表的壓力。
- 缺點：事務保證困難、業務邏輯需要做大量改造。
九、彈性伸縮模式
這種模式主要解決突發流量的到來，導致無法橫向擴充套件或者橫向擴充套件太慢，進而影響業務，全站崩潰的問題。這個模式是一種相對來說比較高階的技術，也是各個大公司目前都在研究、試用的技術。截至今日，有這種思想的架構師就已經是很不錯了，能夠拿到較高薪資，更別提那些已經實踐過的，甚至實現了底層系統的那些，所以，你懂得...... 這種模式的一般設計見下圖：
如上圖所示，多了一個彈性伸縮服務，用來動態的增加、減少範例。原理上非常簡單，但是這個模式到底解決什麼問題呢？先說說由來和意義。
每年的雙11、六一八或者一些大促到來之前，我們都會為大流量的到來做以下幾個方面的工作: 提前準備10倍甚至更多的機器，即使用不上也要放在那裡備著，以防萬一。這樣浪費了大量的資源。 每臺機器設定、偵錯、引流，以便讓所有的機器都可用。這樣浪費了大量的人力、物力，更容易出錯。 如果機器準備不充分，那麼還要加班加點的重複上面的工作。這樣做特別容易出錯，引來領導的不滿，沒時間回家陪老婆，然後你的老婆就......(自己想)
在雙十一之後，我們還要人工做縮容，非常的辛苦。一般一年中會有多次促銷，那麼我們就會一直這樣，實在是煩！
最嚴重的，突然間的大流量爆發，會讓我們觸不及防，半夜起來擴容是在正常不過的事情，為此，我們偷懶起來，要更多的機器備著，也就出現了大量的cpu利用率為1%的機器。
我相信，如果你是老闆一定很震驚吧！！！ 哈哈，那麼如何改變這種情況呢？請接著看
為此，首先把所有的計算資源整合成資源池的概念，然後通過一些策略、監控、服務，動態的從資源池中獲取資源，用完後在放回到池子中，供其他系統使用。 具體實現上比較成熟的兩種資源池方案是VM、docker，每個都有著自己強大的生態。監控的點有CPU、記憶體、硬碟、網路IO、服務質量等，根據這些，在配合一些預留、擴張、收縮策略，就可以簡單的實現自動伸縮。怎麼樣？是不是很神奇？深入的內容我們會在的碼農原創的公眾號文章中詳細介紹。
該總結一下這種模式的優缺點的了，如下：
- 優點：彈性、隨需計算，充分優化企業計算資源。
- 缺點：應用要從架構層做到可橫向擴充套件化改造、依賴的底層配套比較多，對技術水平、實力、應用規模要求較高。
十、多機房模式
這種模式主要解決不同地區高效能、高可用的問題。
隨著應用使用者不斷的增加，使用者群體分佈在全球各地，如果把伺服器部署在一個地方，一個機房，比如北京，那麼美國的使用者使用應用的時候就會特別慢，因為每一個請求都需要通過海底光纜走上個那麼一秒鐘(預估)左右，這樣對使用者體驗及其不好。怎麼辦？使用多機房部署。
這種模式的一般設計見下圖：
如上圖所示，一個典型的使用者請求流程如下：
使用者請求一個連結A 通過DNS智慧解析到離使用者最近的機房B 使用B機房服務連結A
是不是覺得很簡單，沒啥？其實這裡面的問題沒有表面這麼簡單，下面一一道來。 首先是資料同步問題，在中國產生的資料要同步到美國，美國的也一樣，資料同步就會涉及資料版本、一致性、更新丟棄、刪除等問題。 其次是一地多機房的請求路由問題，典型的是如上圖，中國的北京機房和杭州機房，如果北京機房掛了，那麼要能夠通過路由把所有發往北京機房的請求轉發到杭州機房。異地也存在這個問題。
所以，多機房模式，也就是異地多活並不是那麼的簡單，這裡只是起了個頭，具體的有哪些坑，會在另一篇文章中介紹。
該總結一下這種模式的優缺點的了，如下：
- 優點：高可用、高效能、異地多活。
- 缺點：資料同步、資料一致性、請求路由。
至此，整個關於八種架構設計模式及其優缺點概述就介紹完了，大約1W字左右。最後，我想說的是沒有銀彈、靈活運用，共勉！
最後給大家分享一個Github倉庫，上面有大彬整理的300多本經典的計算機書籍PDF，包括C語言、C++、Java、Python、前端、資料庫、作業系統、計算機網路、資料結構和演演算法、機器學習、程式設計人生等，可以star一下，下次找書直接在上面搜尋，倉庫持續更新中~
