低成本通常被認為是架構設計過程中的一項約束，或者說低成本也是架構設計中的非功能目標之一，它跟高并發、高性能、高可用、安全性等非功能目標一樣，一直貫穿架構設計過程的始終。不同的是有些企業會把低成本以明確的目標方式提出，而有些企業則將其視為約定俗成的原則，只要不是偏離太多則默認算是達成了。

與高并發的加機器擴容剛好相反，低成本在硬件上則是盡量壓縮減少服務器的數量以降低成本。壓縮降低服務器數量的同時，還要提升性能，這怎么能做到呢？答案是創新。所以低成本的實現關鍵在于創新采用新技術，但是新技術也意味著要冒一定的技術風險，這樣系統的安全性或穩定性上可能又會有所影響。另外新技術對人的技能要求也會升級，意味著過去的技能與經驗也需要同步升級，這些因素都可能反過來又影響了項目的進度與質量。

低成本對大型系統的影響在于大基數下的小比例性能提高也能節省不少的成本，比如說某個系統共用了1000臺云主機，每臺每年費用為1萬塊錢，那一年就需要1000萬，采用了新技術后，系統的性能提升了20%，那就能節省1000*20%=200萬。再比如某個使用了XML作為接口協議的系統固定帶寬用了20Gbps，改為JSON作為新的接口協議后，由于報文平均縮小了30%，那相同條件下只需要14Gbps的帶寬即可。系統規模越是大，細微的技術創新引起的性能提升都能節省很高的成本，所以低成本通常會在系統規模發展到一定的階段后才會被提出來重點考慮。其實上面的例子如果是對于突發流量能用云計算按量付費或云原生的彈性伸縮還能更一步節省成本，但這都嚴重影響了我們的架構設計方案。

低成本除了硬件成本外，軟件成本更是不容忽視，對技術人員來說一個最常見的例子是要不要使用商業數據庫，比如Oracle數據庫。對早期很多大型電信、金融企業來說過去很長一段時間是實現系統的信息化而且單客價值也高，即便購買Oracle這些昂貴的商業數據庫，收入也能很好地夠覆蓋成本。但到了互聯網時代一切悄然發生了變化，許多互聯網公司采用長尾模式作為其盈利模式，不但單客價值低，平均單條數據的價值也要低得多，在這種情況下如果繼續使用Oracle那成本就太高了。所以在分布式數據庫普及前很多互聯網公司采用了Mysql + 分庫分表的廉價方案。在支持單表記錄數上，Oracle要比Mysql高一到兩個數量級，通常認為Mysql單表記錄數達到千萬級就要考慮分庫分表了，而Oracle單表記錄數達到億級也非常見，甚至在硬件配置不錯的情況下單表十億級仍然能高效快速查詢。在多表聯合查詢上，Oracle更是要強大得多，超過5張的大表聯合查詢仍然非常高效，這是Mysql這些開源數據庫短期內難以媲美的。在Oracle的長期培育下，涌現出一批以數據庫為中心的程序員。他們編寫的代碼主要面向數據庫，并且依賴于復雜的SQL語句來實現業務邏輯。

相比之下，互聯網程序員由于受限于性能較弱的Mysql數據庫，編寫的代碼更加小心謹慎，努力避免給數據庫帶來過多壓力。在分布式數據庫普及之前，在后端編程領域，我認為傳統程序員和互聯網程序員最大的區別在于前者是長期是在商業數據庫如Oracle的呵護下進行編程，而后者則是呵護著羸弱的開源數據庫如Mysql進行編程，所以你能在用Oracle的傳統項目中看到上百行的SQL,而在用了Mysql的高并發系統中總能看到大量保護或節省數據庫資源的優化技巧。

不同的企業類型類型面臨的低成本壓力顯然是不同的，同樣是支持10萬的QPS，民營企業和大型國有企業能付出的成本也大不相同。但我認為只要未來是在充分的市場經濟下，收入必然是要覆蓋成本的，只有這種情況下的的架構才能長久才能持續。很多著名的互聯網企業發生的P0線上故障看似是技術問題，其實倒不如說是在低成本限制下的技術問題。對互聯網公司來說硬件資源的日常的利用率高是常態，而災備也多半是互備，很多時候只有當故障發生時才知道真正能用的災備資源是多么的捉襟見肘。相比之下某些大型金融、電力的系統平時的硬件資源壓力則要低得多，而災備的資源更是充裕。所以不同的企業有不同的低成本目標，不同的低成本目標對架構師的挑戰也會各有不同。

低成本實現依靠創新，所以有了新技術的出現，互聯網企業面臨著更高的低成本壓力，所以有更多的技術創新。比如正是數據庫的like模糊匹配對全文搜索的支持不足，所以有了ElasticSearch。正是數據庫對高并發讀能力的支持不足，所以催生了NoSQL如Redis、Memcached 等技術。低成本目標的實現應該是一個持續的過程，從長遠來看只有最終達到了收益覆蓋成本才是穩定的狀態，2023年在互聯網企業中流行的降本增效，也可以認為是一種包括了人力資源的低成本目標，是對過去粗放式不計成本的增長的債務償還。但是在實現這個目標的過程中有些企業操之過急推之過快，導致了出現了不少的問題，導致相繼出現了被網友戲稱“降本增笑”的事故。

為了實現低成本，對于實力雄厚且領先的大企業來說，往往需要通過引領創新來實現，難度很高。而對于多數的普通企業來說，更多的是通過引進相對成熟的新技術實現，難度要低得多。對于我們架構師來說，保證系統的技術架構持續略微領先于業務發展除了更好的支持未來的發展之外，還能以更合理的成本來實現目標。作為架構師，需要不斷關注行業的最新動態和技術趨勢，結合企業的實際情況，做出恰當的技術選型和架構規劃。在保證系統技術架構略微領先的同時，也需要合理匹配成本，確保技術投入與業務發展的平衡，實現最佳的技術與商業價值的結合。