企業軟體應用架構層出不窮（這裡的應用架構是指偏後端服務的軟體架構）每個企業由各自業務形態，技術棧，技術路線，技術實力不同，各自架構方案，技術選型各有各的不同，千姿百態，正所謂：“百花齊放，盡吐芬芳”。
沒有最好架構，只有當前最適合的架構方案，也沒有完美架構，只有持續迭代演進的架構。
有沒有一種萬能通用應用服務軟體架構呢？今天我們來聊聊我眼中的“萬能”架構。
所謂萬能，也不是真正的萬能！
這裡提兩個指標：
- 適用於大多數企業的大多數業務場景（70%以上）；
- 在滿足業務條件下企業投入成本要求最小化，包括：軟硬體成本+人員學習成本+實施成本+運維成本。
1、極簡之萬能架構
MySQL+Redis+ES（三件套）
這是極簡的架構搭配基本上可以滿足70~80%的企業應用業務場景，應用服務開發語言不限，企業根據自己團隊善長技術方向就行，例如：PHP，C#，JAVA，go，python，ruby等。
MYSQL開源免費、穩定、可靠、安裝簡單，只要搞過web開發的人都熟悉，接入成本極低、運維成本較低（相比其他關係型資料庫）；
Redis開源免費、高效能、穩定、可靠，基本搞過軟體開發的人都會，接入成本、運維成本極低；
ElasticSearch開源免費、高效能、穩定、可靠，大多數開發人員都會使用，接入成本低，運維成本有那麼點高。
MYSQL+Redis+ElasticSearch這三者組合，可以滿足大多數業務應用場景，一般企業都可以考慮這種架構方式，簡單高效。真的沒有必要追求複雜的架構。
Redis除了高效能之處，還經常可以用來做分散式鎖，快取一些少量熱點的資料，比如資料字典。
ES安裝稍微複雜一點，但也沒有多複雜，機器效能要求高一些，要求稍微高配一點的機器，記憶體大和高速SSD硬碟。它在查詢分頁資料列表，查詢億級資料量毫秒級（當然是要求正確建立分片和有效索引前提下）。
如下圖所示：
以上架構可以號稱最簡單的萬能架構，一般在萬級以內QPS可以頂得住的，而絕大多數企業應用實際上也沒有那麼大的併發量級；
但萬一有些特殊的業務場景併發遠不止是萬級的，特別面向網際網路消費者使用者量級就要高得多了，如：10萬級、百萬級、千萬級怎麼辦？
存在問題：
- 應用怎麼實現水平擴充套件？
- 三大件單點風險比較高，怎麼做高可用？
既然存在問題，那麼我們對以上架構需要進一步擴充套件，使它更高可用，承載更高的併發量。
2、極簡萬能架構之二
MySQL+Redis+ES+Nginx (四個元件配置群集版)
這個架構增加了Nginx代理，從而可以實現應用服務水平擴充套件的能力，而nginx本身是開源免費，高效能、穩定，安裝配置簡單特點，非常適合在高並場景中做反向代理應用。
而Nginx本身也可配置多節點，透過虛擬IP即VIP配置叢集，實現高可用。
同時ES和Redis都可以配置部署多個節點，從而實現叢集版本，這兩個元件本身單機效能非常強悍。加上叢集配置，幾乎可以高枕無憂一段時間了。
另外MySQL可以配置叢集版本，1主多從，為什麼要用1主呢？因為單一主節點簡單：程式實現簡單、寫入簡單、配置部署也簡單、運維也簡單。高併發場景一般都是查多寫少。
推薦：MySQL+Redis+ES+Nginx 四件套加叢集版本，簡單高效！
這種架構也能滿足絕大多數企業應用的高併發場景。所以讀多的情況下10萬級以下QPS可以頂住的。
一般企業應用如果日常業務能達到10萬級QPS，訪問量算已經非常大的了，能達到這個量級，業務量夠大，也必在意這點投入。
但是凡事有萬一，萬一真的是寫多了怎麼辦，主庫一個節點根本扛不住怎麼辦？
存在問題：
- 一個主庫寫入是不夠的？在高併發寫入的時候肯定扛不住。
3、多讀多寫方案一
MySQL部署多主多從
經過以上分析讀多的情況問題不大；那如果寫多呢？寫多的方案也有很多，可以使用MySQL多主架構部署，但是運維和部署複雜度也會高很多。若沒有那麼大的實際業務量的要求，建議謹慎考慮清楚。
應用程式不用太多改動，相當於主庫多一層代理，對上層呼叫透明。
多主其實帶來系統部署複雜度的提升，運維、升級維護等增加複雜度。
多主存在的問題：
- 主與主雙向同步複製問題；
- 主從複製同步問題
我們先從MySQL主從複製，主主複製流程原理上進一步深入分析具體問題和原因。
主從複製基本工作流程
MySQL主從複製工作流程
主從複製主要目的是實現資料庫讀寫分離，寫操作訪問主資料庫，讀操作訪問從資料庫，從而使資料庫具有更強⼤的訪問負載能⼒，⽀撐更多的⽤⼾訪問。
它的主要的複製原理是：當應⽤程式客⼾端傳送⼀條更新命令到資料庫的時候，資料庫會把這條更新命令同步記錄到Binlog中，然後由另外⼀個執行緒從Binlog中讀取這條⽇志，然後透過遠端通訊的⽅式將它複製到從伺服器上面去，從伺服器獲得這條更新⽇志後，將其加⼊到⾃⼰的Relay log中，然後由另外⼀個SQL執⾏執行緒從Relay log中讀取這條新的⽇志，並把它在本地的資料庫中重新執⾏⼀遍。
這樣當客⼾端應⽤程式執⾏⼀個update命令的時候，這個命令會在主資料庫和從資料庫上同步執⾏，從而實現了主資料庫向從資料庫的複製，讓從資料庫和主資料庫保持⼀樣的資料。
主主複製工作流程
主主複製⽅案是指兩臺伺服器都當 作主伺服器，任何⼀臺伺服器上收到的寫操作都會複製到另⼀臺伺服器上。
如上圖所示，當客⼾端程式對主伺服器A進⾏資料更新操作的時候，主伺服器A會把更新操作寫⼊到Binlog日誌中。然後Binlog會將資料日誌同步到主伺服器B，寫⼊到主伺服器的Relay log中，然後執Relay log，獲得Relay log中的更新日誌，執⾏SQL操作寫⼊到資料庫伺服器B的本地資料庫中。
B伺服器上的更新也同樣透過Binlog複製到了伺服器A的Relay log中，然後透過Relay log將資料更新到伺服器A中。
透過這種方式，伺服器A或者B任何⼀臺伺服器收到了資料的寫的操作都會同步更新到另⼀臺伺服器，實現了資料庫主主複製。主主複製可以提⾼系統的寫高可⽤。但處理邏輯、部署、運維會複雜很多。
主主複製存在問題：
- 不要對兩個資料庫同時進⾏資料寫操作，因為這種情況會導致資料衝突。
- 複製只是增加了資料的讀併發處理能⼒，並沒有增加寫併發的能⼒和系統儲存能⼒。
- 更新資料表的結構會導致巨⼤的同步延遲。
4、多讀多寫方案二
MySQL分庫分表
MySQL分庫分表也是相當成熟的方案，可以用一些開源的中介軟體如：MyCat，ShardingJdbc等進行代理。查詢和寫入都實現分庫分表，寫入和查詢效能能夠實現較大的提升。
因為資料都雜湊到各個分片，資料規模打散，資料伺服器處理資料能力會有較大的提升。
利用MyCat和ShardingJdbc元件作代理，相當中間有一層路由分發，對應用程式相對友好，原有程式程式碼不用太大的改動，進行基本規則配置即可實現。
相應帶的問題是：
- 應用程式處理邏輯會變得比較複雜；
- 資料打散之後，讀寫效能是提高了，但對資料運營和運維會帶來很多的不方面（例如：發現資料有一些問題，想上去查詢分析一下資料，這就比較麻煩了，得從程式邏輯解析打散的演算法，然後聚合起來再去查詢）。
5、多讀多寫方案三
增加其他中介軟體緩衝
在寫入多的情況，如果不想拆分資料庫，可以增加一些中間來做緩解。
如增加訊息中介軟體MQ，它可以進行錯峰填谷，使用程式非同步化，排隊慢慢處理；同時也可增加熔斷限制的元件，比如Sentinel元件。Sentinel免費開源、配置使用簡單、學習成本低。
Sentinel以流量為切入點，從流量控制、流量路由、熔斷降級、系統自適應過載保護、熱點流量防護等多個維度保護服務的穩定性。上面提到其他方案也可以增加Sentinel元件，可根據業務場景需要選擇是否使用，並不會衝突。
增加MQ元件（可以選擇RabbitMQ或RocketMQ都是免費開源的），一方面可以解耦服務間的依賴，另一方面起到限流緩衝作用，讓寫入佇列慢慢排隊操作，不至於衝跨資料庫。
增加MQ+Sentinel元件是起到限流熔斷降級作用，可保持在高併發條件下不至於服務被衝跨，但本質上只是保持服務高可用，並沒有整個體上提高系統的併發量。
如果在百萬級別以上併發量下，雖然系統可以實現高可用，但是大部分使用者限流了阻擋在外面，使用者體驗並不友好！
6、多讀多寫方案四
使用NOSQL資料庫替換
NOSQL資料庫也有很多可選方案，這裡推薦使用TIDB，不是廣告！我們在實際生產業務使用驗證過，按官方最低配置（一個叢集最小要求7臺高配伺服器）；
TIDB為大處理大規模資料而設計的，查詢效能非常優秀（比MySQL高效得多了），我們寫入併發TPS可以去到2萬左右，這個已經是一個相當大的併發量。如果併發再提升也可以隨時擴充套件。
TIDB是國產資料庫，免費開源，使用KV底層實現上層關係型資料庫，設計理念非常先進。TIDB本身就是定位為分散式資料庫，可以根據自己業務量實現水平擴充套件，這是個相當了不起的產品。
使用TIDB的好處有哪些？
1、最大好處是原來的業務端程式碼基本不用改，切換資料來源就可以了，100%相容Mysql語法，當然如果你使用了Mysql一些特殊語法，如儲存過程，特殊函式是不支援的。
2、可以承載高併發業務場景資料庫水平擴充套件，多寫多讀都可以。
這種架構呢，基本在百萬級併發量也是能扛得住的。因為應用可以實現水平擴充套件，資料庫也可以實現水平擴充套件，可以說是解決了兩大核心關鍵問題。
我們現有的業務場景中有一塊，設計應用BOM資料記錄，每天增量產生大約40億條記錄資料，24小時訪問量並不是均攤的，高峰時併發量QPS也接近70多萬。最開始是使用MySQL方案，一主多從，多主多從，分庫分表各方案都試過根本頂不住，線上經常出現假死、滿載等問題，搞得焦頭爛額的。最後沒有辦法試用TIDB，也類似上圖架構方案。跑了近2年沒有啥問題，從而驗證證明這種方案的可靠性。
所以一般業務併發訪問量在百萬級別的體量，都推薦使用這種架構省心省事，總體算下來成本也不高。
還是那個三原則：簡單、高效、低成本。
當然壞處也有的，就是需要增加一筆不少的伺服器資源費用，對團隊技術成員學習有一定成本、運維也有一定成本。
不過話說回來，如果說系統真有那麼大流量說明公司業務大，說明業績很好，這些投入不值一提。
假設併發量、訪問量進一步提升，達到千萬級訪問量，應該是怎麼辦呢？這種巨量併發訪問量是網際網路頭部那幾家公司才會有的，一般普通企業大機率沒有機會到達這個量級。
千萬級別併發方案是有的，先偷個懶，下回補上！這裡權當學習研究，因為我們公司的訪問量也沒有達到量級，不好證實方案有效性和可行性。
7、微服務體系下極簡之萬能架構
在SpringCloud體系下元件非常多，採用最簡基本元件註冊中心、配置中心和閘道器，其最簡組合：Eureka+Gateway+Redis+Mysql+MQ
當然註冊中心推薦nacos來代替。nacos是阿里團隊免費開源、穩定、也同時支援多種協議（http、dubbo等）；nacos除了註冊中心作用之外自帶配置中心，這樣好個好處是減少額外部署一個配置中心。
（1）最簡版SpringCloud微服務分層示意
（2）我們公司微服務架構
這是幾年前我們公司搭的微服務架構，這幾年來沒有什麼太大改變。跑了幾年下來也說明架構是穩定可靠的。
不過近期在搞雲原生，是有較大改變，因還沒有上線，沒有驗證生產實際情況下，所以新的架構還等一段時間再來分享。
（3）微服務混合體架構
這個架構是混合Springcloud和dubbo兩種微服務架構並存。這種曾經在我們的系統架構中存活過一段時間，為什麼要設計這樣的架構？其實有一定的歷史原因，平臺一開始使用了dubbo體系，後面改用SpringCloud體系。
原因如下：
- 早些年SpringCloud並不成熟，多少存一些問題，當時部署更多是出於試驗考慮，核心業務並不敢往生產上放；
- Dubbo有一段時間停更狀態（最後版本是2.5.3），隔了幾年之後再重啟更新的；
- 兩個體系架構中間存在切換週期，兩個註冊中心兩種架構共存了近一年。
其實一直保持兩種微服務架構存在也是可以的。只不過是呼叫者可能會混亂，當時我們為保持團隊統一認識，減少誤用的情況下，最後決定全切了SpringCloud體系。
建議各位在實際業務使用當中，也可以根據自己的業務實際情況需要，選擇合適的微服務架構。
8、總結
1、軟體世界裡沒有“萬金油”，選擇低成本最適合於業務場景的應用軟體架構就達到目的了；
2、所謂萬能架構也是帶有條件的，就是根據自己業務量規模大小、技術條件選擇最低成本架構方案；
3、微服務架構還有很多其他方案選擇，目前來說Springcloud是相對比較低成本的架構設計方案。