企業軟件應用架構層出不窮（這裏的應用架構是指偏後端服務的軟件架構）每個企業由各自業務形態，技術棧，技術路線，技術實力不同，各自架構方案，技術選型各有各的不同，千姿百態，正所謂：“百花齊放，盡吐芬芳”。
沒有最好架構，只有當前最適合的架構方案，也沒有完美架構，只有持續迭代演進的架構。
有沒有一種萬能通用應用服務軟件架構呢？今天我們來聊聊我眼中的“萬能”架構。
所謂萬能，也不是真正的萬能！
我這裏提兩個指標：
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是相對比較低成本的架構設計方案。