企業低成本萬能架構

企業軟體應用架構層出不窮（這裡的應用架構是指偏後端服務的軟體架構）每個企業由各自業務形態，技術棧，技術路線，技術實力不同，各自架構方案，技術選型各有各的不同，千姿百態，正所謂：「百花齊放，盡吐芬芳」。

沒有最好架構，只有當前最適合的架構方案，也沒有完美架構，只有持續迭代演進的架構。

有沒有一種萬能通用應用服務軟體架構呢？今天我們來聊聊我眼中的「萬能」架構。

所謂萬能，也不是真正的萬能！

我這裡提兩個指標：

1、適用於大多數企業的大多數業務場景（70%以上）；

2、在滿足業務條件下企業投入成本要求最小化，包括：（軟硬體成本+人員學習成本+實施成本+運維成本）。

 

1、極簡之萬能架構

應用服務+MySQL+Redis+ES

這是極簡的架構搭配基本上可以滿足70~80%的企業應用業務場景，應用服務開發語言不限，企業根據自己團隊善長技術方向就行，例如：PHP，C#，JAVA，go，python，ruby等。

MYSQL開源免費、穩定、可靠、安裝簡單，只要搞過web開發的人都熟悉，接入成本極低、運維成本較低（相比其他關係型資料庫）；

Redis開源免費、高效能、穩定、可靠，基本搞過軟體開發的人都會，接入成本、運維成本極低；

ElasticSearch開源免費、高效能、穩定、可靠，大多數開發人員都會使用，接入成本低，運維成本有那麼點高。

MYSQL+Redis+ElasticSearch這三者組合，可以滿足大多數業務應用場景，一般企業都可以考慮這種架構方式，簡單高效。真的沒有必要追求複雜的架構。

分散式鎖，及查詢少量穩定的資料，比如資料字典，redis基本上可以滿足而且性極高，高並行也不怕；

ES安裝稍微複雜一點，但也沒有多複雜，機器效能要求高一些，要求稍微高配一點的機器，記憶體大和高速SSD硬碟。它在查詢分頁資料列表，查詢億級資料量毫秒級（當然是要求正確建立分片和有效索引前提下）。

如下圖所示：

以上架構可以號稱最簡單的萬能架構，一般在萬級以內QPS可以頂得住的，而絕大多數企業應用實際上也沒有那麼大的並行量級；

但萬一有些特殊的業務場景並行遠不止是萬級的，特別面向網際網路消費者使用者量級就要高得多了，如：10萬級、百萬級、千萬級怎麼辦？

存在一些問題：

（1）應用怎麼實現水平擴充套件？

（2）三大件單點風險比較高，怎麼做高可用？

架構需要進一步擴充套件

2、極簡萬能架構之二

MYSQL+Redis+ES+Nginx (四個元件設定群集版)

這個架構增加了Nginx代理，從而可以實現應用服務水平擴充套件的能力，而nginx本身是開源免費，高效能、穩定，安裝設定簡單特點，非常適合在高並場景中做反向代理應用。

而Nginx本身也可設定多節點，通過虛擬IP即VIP實現高可用。

同時ES和Redis都可以設定部署多個節點，從而實現叢集版本，這兩個元件本身單機效能非常強悍。加上叢集設定，幾乎可以高枕無憂一段時間了。

另外MYSQL可以設定叢集版本，1主多從，為什麼要用1主呢？因為單一主節點簡單：程式實現簡單、寫入簡單、設定部署也簡單、運維也簡單。高並行場景一般都是查多寫少。

所以這種也能滿足絕大多數企業應用的高並行場景。所以讀多的情況下10萬級以下QPS可以頂住的。達到10萬級QPS，存取量算已經非常大的了，能達到這個量級，企業收入強大了，也不怕投入了。

 

但是凡事有萬一，萬一真的是寫多了怎麼辦，主庫一個節點根本扛不住怎麼辦？

存在問題：

（1）一個主庫寫入是不夠的？在高並行寫入的時候肯定扛不住。

 

3、多讀多寫方案一

Mysql部署多主多從

讀多上面分析過，問題不大，寫多呢？方案很多，可以使用mysql多主架構部署，但是運維和部署複雜度也會提高很多。應用程式不用太多改動，相當於主庫多一層代理，對上層呼叫透明。

多主記憶體在的問題：

1、主與主雙向同步複製問題；

2、主從複製同步問題

 

這裡需要展開描述一下主主雙向同步的問題。加個flag晚上有空再補充一下，現在有點忙。

 

4、多讀多寫方案二

Mysql分庫分表

Mysql分庫分表也是相當成熟的方案，可以用一些開源的中介軟體如：MyCat，ShardingJdbc等進行代理。查詢和寫入都實現分庫分表，寫入和查詢效能能夠實現較大的提升。

因為資料都雜湊到各個分片，資料規模打散。利用MyCat和ShardingJdbc元件作代理。

 

相應帶的問題是：

1、應用程式處理邏輯會變得比較複雜；

2、資料打散之時，資料運營和運維會帶來很多的不方面（例如：發現資料有一些問題，想上去查詢分析一下資料，這就比較麻煩了，得從程式邏輯解析打散的演演算法，然後聚合起來再去查詢）。

 

5、多讀多寫方案三

增加其他中介軟體緩衝

在寫入多的情況，如果不想拆分資料庫，可以增加一些中間來做緩解。

可以增加MQ元件，錯峰填谷，非同步排隊慢慢處理，同時也需要增加熔斷限制的元件，比如Sentinel元件，免費開源、設定使用簡單、學習成本低。

Sentinel以流量為切入點，從流量控制、流量路由、熔斷降級、系統自適應過載保護、熱點流量防護等多個維度保護服務的穩定性。當然上面其他方案也增加此元件，根據業務場景需要選擇是否使用，並不會衝突。

增加MQ元件（可以選擇RabbitMQ或RocketMQ都是免費開源的），一方面可以解耦服務間的依賴，另一方面起到限流緩衝作用，讓寫入排隊慢慢寫入，不至於衝跨資料庫。

 

增加Sentinel起到限流熔斷降級作用，高並行條件下不至於服務被衝跨，但本性上只是保持服務高可用，並沒有整個體上提高系統的並行量、吞吐量。

如果在百萬級別以上並行量下，雖然系統可以實現高可用，但是大部分使用者限流了阻擋在外面，使用者體驗並不友好！

 

6、多讀多寫方案四

使用NOSQL資料庫替換

NOSQL資料庫也有很多可選方案，這裡推薦使用TIDB，不是廣告！我們在生產實際業務使用驗證過，按官方最低設定（一個叢集最小要求7臺高配伺服器）；TIDB高效能查詢自然不用說本來就高效能（比Mysql高效得多了），我們寫入並行TPS可以去到2萬左右，這個已經是一個相當大的並行量。如果並行再提升也可以隨時擴充套件。

TIDB是國產資料庫，免費開源，使用KV底層實現上層關係型資料庫，設計理念非常先進。TIDB本身就是定位為分散式資料庫，可以根據自己業務量實現水平擴充套件，這個是相當了不起的產品。

使用TIDB的好處有哪些？

1、最大好處是原來的業務端程式碼基本不用改，切換資料來源就可以了，100%相容Mysql語法，當然如果你使用了Mysql一些特殊語法，如儲存過程，特殊函數是不支援的。

2、可以承載高並行業務場景資料庫水平擴充套件，多寫多讀都可以，可以高

 這種架構呢，基本在百萬級並行量也是能扛得住的，因應用可以實現水平擴充套件，資料庫也可以實現水平擴充套件，可以說是解決了兩大核心關鍵問題。

當然壞處也有的，就是需要增加一筆不少的伺服器資源費用，學習使用、運維有一定成本。說回來，如果說系統真有那麼大流量說明公司業務大，業績很好，也不必要在呼這點投入。

 

 

7、微服務體系下極簡之萬能架構

在SpringCloud體系下元件非常多，採用最簡基本元件註冊中心、設定中心和閘道器，其最簡組合：Eureka+Gateway+Redis+Mysql+MQ

當然註冊中心推薦nacos來代替。nacos是阿里團隊免費開源、穩定、也同時支援多種協定（http、dubbo等）；nacos除了註冊中心作用之外自帶設定中心，這樣好個好處是減少額外部署一個設定中心。

（1）最簡版SpringCloud微服務分層示意

（2）我們公司的微服務架構

這是幾年前我們公司搭的微服務架構，這幾年來沒有什麼太大改變。跑了幾年下來也說明架構是穩定可靠的。

不過近期在搞雲原生，是有較大改變，因還沒有上線，沒有驗證生產實際情況下，所以新的架構還等一段時間再來分享。

 

（3）微服務混合體架構

這個架構是混合springcloud和dubbo兩種微服務架構，曾經在我們的系統架構中存活過一段時間。因為有歷史，早期使用了dubbo，後面改用SpringCloud體系。中間存在切換週期，其實一直保持兩種微服務架構存在也是可以的。只不是呼叫者可能會混亂，當時我們為保持團隊統一認識，減少誤用的情況下，最後全切了SpringCloud體系。

 

8、總結

1、軟體世界裡沒有「萬金油」，選擇低成本最適合於業務場景的應用軟體架構就達到目的了；

2、所謂萬能架構也是帶有條件的，就是小規模業務量、存取量條件最低成本使用，推薦第一個極簡萬能方案；

3、微服務架構還有很多其他方案選擇，目前來說Springcloud是相對比較低成本的架構設計方案。