六種常見系統架構 —— 進階篇
常見的幾種系統架構設計，接下來講後面三個：
1、單庫單應用架構：最簡單的，可能大家都見過
2、內容分發架構：目前用的比較多
3、讀寫分離架構：對於大併發的查詢、業務
4、微服務架構：適用於複雜的業務模式的拆解
5、多級緩存架構：可以把緩存玩的很好
6、分庫分表架構：解決單及數據庫瓶頸
四、微服務架構
上面的模式看似不錯，解決了性能問題，我可以不用魯肅街頭了、老婆還是我的，哈哈，但是軟件系統天生的複雜性決定了，出了性能，還有其他諸如高可用、健壯性等大量問題等待我們去解決，在加上各個部門的撕逼、扯皮，更讓我們碼農雪上加霜，所以，繼續吧……
微服務模式可以說是最近的熱點，花花綠綠、大大小小、國內國外的公司都在鼓吹，實踐這個模式，可是大部分都沒有弄清爲什麼要這麼做，也並不知道這麼做有什麼好處、壞處，在這裏，我將以我自己的親身實踐說一下我對這個模式的看法，不喜勿噴，隨着業務與人員的增加，遇到的問題如下：
1、單及數據庫寫請求量大量增加，導致數據庫壓力變大
2、數據庫一旦掛了，那麼整個業務都掛了
3、業務代碼越來越多，都在一個GIT裏，越來越難以維護
4、代碼腐化嚴重，臭味越來越濃
5、上線越來越頻繁，經常是一個小功能的修改，就要整個大項目重新編譯
6、部門越來越多，該哪個部門改動大項目中的哪個東西，撕逼的厲害
7、其他一些外圍系統直接連數據庫，導致一旦數據庫結構發生變化，所有的相關係統都要通知，甚至對修改不敏感的系統也要通知
8、每個應用服務器需要開通所有權限、網絡、FTP、各種各樣的，因爲每個服務器部署的應用都是一樣的。
9、作爲架構師，我已經屎去了對這個系統的把控……
爲了解決上述問題，我司使用了微服務模式，這種模式的一般設計如下圖：
如上圖所示，我把業務分塊，做了垂直切分，切成一個個獨立的系統，每個系統各子衍化，有自己的庫、緩存、ES等輔助系統，系統之間的實時交互通過RPC，異步交互通過MQ，通過這種組合，共同完成整個系統功能。
那麼，這麼做是否真的能解決上述問題了呢？不玩虛的，一個一個來說。
對於問題一，由於拆分成多個子系統，系統的壓力被分散了，而各個子系統都有自己的數據庫實例，所以數據庫的壓力變小。
對於問題二，一個子系統A的數據庫掛了，只是影響到系統A和使用系統A的那些功能，不會所有的功能不可用，從而解決一個數據庫掛了，導致所有的功能都不可用的情況。
對於問題三、四，也因爲拆分得到了解決，各個子系統都有自己獨立的GIT代碼庫，不會相互影響。通用的模塊可通過庫、服務、平臺的形式解決。
對於問題五，子系統A發生改變，需要上線，那麼我們只需要編譯A，然後上線就可以了，不需要其他系統做通向的事情。
對於問題六，順應了康威定律，我部門該幹什麼事，輸出什麼，也通過服務的形式暴露出來，我部門只管把我部的職責、軟件功能做好就可以。
對於問題七，所有需要我部數據的需求，都通過接口的形式發不出去，客戶通過接口獲取數據，從而屏蔽了底層數據庫結構，甚至數據來源，我部只需保證我部的接口契約沒有發生變化即可，新的需求增加新的接口，不會影響老的接口。
對於問題八，不同的子系統需要不同的權限，這個問題也優雅的解決了。
對於問題九，暫時控制住複雜性，我只需要控制好大方面，定義好系統邊界、接口、大的流程，然後再分而治之、逐個擊破、合縱連橫。
目前來說，所有問題得到解決！bingo！
但是，還有許多其他的副作用會隨之產生，如RPC、MQ的超高穩定性、超高性能，網絡延遲，數據一致性等問題，這個就不展開來講了，太多了，一本書都講不完。
另外，對於這個模式來說，最難把握的是度，切記不要切分過細，我見過一個功能一個子系統，上百個方法分成上百個子系統的，真的是太過度了。實踐中，一個比較可行的方法是：能不分就不分，除非有非常必要的理由！
優點：相對高性能，可擴展性強，高可用，適用於中等以上規模公司架構。
缺點：複雜、度不好把握。指不僅需要一個能再高層把控大方向、大流程、總體技術的人，還需要能夠針對各個子系統有針對性的開發。把握不好度或者濫用的話，這個模式適得其反！
五、多級緩存架構
這個模式可以說是應對超高查詢壓力的一種普遍採用的策略，基本的思想就是再所有鏈路的地方，能加緩存的就加緩存，如下圖所示：
如上圖所示，一般在三個地方加入緩存，一個是客戶端處，一個是API網關處，一個是具體的後端業務處，下面分別介紹：
客戶端處緩存：這個地方加緩存可以說是效果最好的一個——無延遲。因爲不用經過長長的網絡鏈條去後端業務處獲取數據，從而導致加載時間過長，客戶流失等損失，雖然有CDN的支持，但是從客戶端到CDN還是有網絡延遲的，雖然不大，具體的技術依據不同的客戶端而定，對於WEB來講，有瀏覽器本地緩存、Cookie、Storage、緩存策略等技術；對於APP來講，有本地數據庫，本地文件，本地內存，進程內緩存支持，以上提到的各種技術有興趣的同學可以繼續展開學習，如果客戶端緩存沒有命中，那麼會去後端業務拿數據，一般來講，就會有個API網關，在這裏加緩存也是非常重要的。
後端業務處理：這個我就不用多說了，大家應該差不多都知道，什麼Redis、Memcache、Jvm等等，不贅述了。
實踐中，要結合具體的實際情況，綜合利用各級緩存技術，使得各種請求最大程度的在到達後端業務之前就被解決掉，從而減少後端服務器壓力、減少佔用帶寬、增強用戶體驗。至於是否只有這三個地方加緩存，我覺得要活學活用，心法比劍法重要！總結一下這個模式的優缺點：
優點：抗住大量讀請求，減少後端壓力。
缺點：數據一致性問題較爲突出，容易發生雪崩，即：如果客戶端緩存失效、API網關緩存失效，那麼所有的大量請求瞬間壓向後端業務系統，後果可想而知。
六、分庫分表架構
這種模式主要解決單表寫入、讀取 、存儲壓力過大，從而導致業務緩慢甚至超時，交易失敗，容量不夠的問題。一般有水平切分和垂直切分兩種，這裏主要介紹水平切分。這個模式也是技術架構迭代演進的畢竟之路。
這種模式的一般設計見下圖：
如上圖所示紅色部分，把一張表分到了幾個不同的庫中，從而分擔壓力。是不是很籠統？哈哈，那我們接下來就詳細的講解一下，首先澄清幾個概念，如下：
主機：硬件，指一臺物理機，或虛擬機，有自己的CPU，內存，硬盤等。
實例：數據庫實例，如一個MySql服務進程，一個主機可以有多個實例，不同的實例有不同的進程，監聽不同的端口。
庫：指表的集合，如學校庫，可能包含教師表、學生表、食堂表等等，這些表在一個庫中。一個實例中可以有多個庫，庫與庫之間用庫名來區分。
表：庫中的表，不必多說，不懂的就不用往下看了，不解釋。
那麼怎麼把單表分散呢？到底怎麼個分發呢？分發到哪裏呢？以下是幾個工作中的實踐，分享一下：
主機：這是最主要的也是最重要的點，本質上分庫分表是因爲計算與存儲資源不夠導致的，而這種資源主要由物理機，主機提供的，畢竟沒有可用的計算資源，怎麼分效果都不是太好。
本文章源自公衆號:javabaiwen。