應用程式碼也決定系統架構

https://mp.weixin.qq.com/s/wl_OmYB8fWp8vGxgn18_Lw

公眾號原文

經常看我公眾號的朋友知道，我一直說單機資料庫是最好的架構（這裡單機不是說就一個機器，而是一套高可用的架構。支援節點切換，保證資料不丟失的）。分散式資料庫也是的，因為它是一套。

     所以我一直說資料決定架構。單套最怕的是什麼？因為是一套了不用過度擔心硬體了（其實都2022年了，誰家的機器天天壞）。（斷網斷電不考慮）除此之外最怕的，也是唯一怕的就是殺手級的SQL。往往一個SQL可以讓一個資料庫轟然倒地。

    我這麼多年從事了也不少行業和公司。挽救了不少系統，所以也積累了可以殺死系統的方法。只要不按照規範來，一定會出事。就是早晚而已。所以很多資料庫都為了防止這種節操碎了一地的SQL，推出了自己的解決方案。都採用機器學習等方式將殺手的SQL直接摁在地上，裝載盒子中。比如Oracle19C 用一體機實現。Polardb 、OceanBase、TDSQL我還沒查到怎麼實現，可能是我資料有限。

     所謂再牛逼的香水也幹不過韭菜盒子。沒有條件的怎麼辦呢？其實有兩種方法：

方案1：嚴控開發質量。代價是開發需要提升水平。收益是資料庫規模基本不變，成本可控。通常選擇這種路線的不少，比如網際網路公司、金融行業、運營商等。對資料非常敬畏而且系統就是公司的生命。

方案2：低成本開發高成本運維。代價是分庫分表、機器增加、資料匯聚、資料同步、異構資料庫、訊息佇列、大資料、流式計算。。。。。。。才疏學淺後面寫不下去了，可能還有很多沒考慮到或者沒馬上想到的。乍一看，方案2好像架構高大上了啊。可以出去吹牛了。也有不少選擇這個方案的。

       就一個分庫分表其實就足以讓開發和運維人員頭痛不已，有的時候發現架構層面甚至不一定能解決一致性的問題，即使解決了付出的代價之大和效能衰減是吃驚的。所謂效能不行架構湊。

方案1：對開發來說太low，還要提升能力，招不到開發，也沒人願意來。 

方案2：對運維來說太坑，招不到運維，不想填坑。

   不管怎麼說本期主題的結論出來了，應用寫的差，是真的可以改變架構的。但是應用寫的好，可以改變架構嗎？答案也是肯定的。