低成本通常被認為是架構設計過程中的一項約束，或者說低成本也是架構設計中的非功能目標之一，它跟高并發(fā)、高性能、高可用、安全性等非功能目標一樣，一直貫穿架構設計過程的始終。不同的是有些企業(yè)會把低成本以明確的目標方式提出，而有些企業(yè)則將其視為約定俗成的原則，只要不是偏離太多則默認算是達成了。
與高并發(fā)的加機器擴容剛好相反，低成本在硬件上則是盡量壓縮減少服務器的數(shù)量以降低成本。壓縮降低服務器數(shù)量的同時，還要提升性能，這怎么能做到呢？答案是創(chuàng)新。所以低成本的實現(xiàn)關鍵在于創(chuàng)新采用新技術，但是新技術也意味著要冒一定的技術風險，這樣系統(tǒng)的安全性或穩(wěn)定性上可能又會有所影響。另外新技術對人的技能要求也會升級，意味著過去的技能與經(jīng)驗也需要同步升級，這些因素都可能反過來又影響了項目的進度與質量。
低成本對大型系統(tǒng)的影響在于大基數(shù)下的小比例性能提高也能節(jié)省不少的成本，比如說某個系統(tǒng)共用了1000臺云主機，每臺每年費用為1萬塊錢，那一年就需要1000萬，采用了新技術后，系統(tǒng)的性能提升了20%，那就能節(jié)省1000*20%=200萬。再比如某個使用了XML作為接口協(xié)議的系統(tǒng)固定帶寬用了20Gbps，改為JSON作為新的接口協(xié)議后，由于報文平均縮小了30%，那相同條件下只需要14Gbps的帶寬即可。系統(tǒng)規(guī)模越是大，細微的技術創(chuàng)新引起的性能提升都能節(jié)省很高的成本，所以低成本通常會在系統(tǒng)規(guī)模發(fā)展到一定的階段后才會被提出來重點考慮。其實上面的例子如果是對于突發(fā)流量能用云計算按量付費或云原生的彈性伸縮還能更一步節(jié)省成本，但這都嚴重影響了我們的架構設計方案。
低成本除了硬件成本外，軟件成本更是不容忽視，對技術人員來說一個最常見的例子是要不要使用商業(yè)數(shù)據(jù)庫，比如Oracle數(shù)據(jù)庫。對早期很多大型電信、金融企業(yè)來說過去很長一段時間是實現(xiàn)系統(tǒng)的信息化而且單客價值也高，即便購買Oracle這些昂貴的商業(yè)數(shù)據(jù)庫，收入也能很好地夠覆蓋成本。但到了互聯(lián)網(wǎng)時代一切悄然發(fā)生了變化，許多互聯(lián)網(wǎng)公司采用長尾模式作為其盈利模式，不但單客價值低，平均單條數(shù)據(jù)的價值也要低得多，在這種情況下如果繼續(xù)使用Oracle那成本就太高了。所以在分布式數(shù)據(jù)庫普及前很多互聯(lián)網(wǎng)公司采用了MySQL + 分庫分表的廉價方案。在支持單表記錄數(shù)上，Oracle要比Mysql高一到兩個數(shù)量級，通常認為Mysql單表記錄數(shù)達到千萬級就要考慮分庫分表了，而Oracle單表記錄數(shù)達到億級也非常見，甚至在硬件配置不錯的情況下單表十億級仍然能高效快速查詢。在多表聯(lián)合查詢上，Oracle更是要強大得多，超過5張的大表聯(lián)合查詢仍然非常高效，這是Mysql這些開源數(shù)據(jù)庫短期內難以媲美的。在Oracle的長期培育下，涌現(xiàn)出一批以數(shù)據(jù)庫為中心的程序員。他們編寫的代碼主要面向數(shù)據(jù)庫，并且依賴于復雜的SQL語句來實現(xiàn)業(yè)務邏輯。
相比之下，互聯(lián)網(wǎng)程序員由于受限于性能較弱的Mysql數(shù)據(jù)庫，編寫的代碼更加小心謹慎，努力避免給數(shù)據(jù)庫帶來過多壓力。在分布式數(shù)據(jù)庫普及之前，在后端編程領域，我認為傳統(tǒng)程序員和互聯(lián)網(wǎng)程序員最大的區(qū)別在于前者是長期是在商業(yè)數(shù)據(jù)庫如Oracle的呵護下進行編程，而后者則是呵護著羸弱的開源數(shù)據(jù)庫如Mysql進行編程，所以你能在用Oracle的傳統(tǒng)項目中看到上百行的SQL,而在用了Mysql的高并發(fā)系統(tǒng)中總能看到大量保護或節(jié)省數(shù)據(jù)庫資源的優(yōu)化技巧。
不同的企業(yè)類型類型面臨的低成本壓力顯然是不同的，同樣是支持10萬的QPS，民營企業(yè)和大型國有企業(yè)能付出的成本也大不相同。但我認為只要未來是在充分的市場經(jīng)濟下，收入必然是要覆蓋成本的，只有這種情況下的的架構才能長久才能持續(xù)。很多著名的互聯(lián)網(wǎng)企業(yè)發(fā)生的P0線上故障看似是技術問題，其實倒不如說是在低成本限制下的技術問題。對互聯(lián)網(wǎng)公司來說硬件資源的日常的利用率高是常態(tài)，而災備也多半是互備，很多時候只有當故障發(fā)生時才知道真正能用的災備資源是多么的捉襟見肘。相比之下某些大型金融、電力的系統(tǒng)平時的硬件資源壓力則要低得多，而災備的資源更是充裕。所以不同的企業(yè)有不同的低成本目標，不同的低成本目標對架構師的挑戰(zhàn)也會各有不同。
低成本實現(xiàn)依靠創(chuàng)新，所以有了新技術的出現(xiàn)，互聯(lián)網(wǎng)企業(yè)面臨著更高的低成本壓力，所以有更多的技術創(chuàng)新。比如正是數(shù)據(jù)庫的like模糊匹配對全文搜索的支持不足，所以有了ElasticSearch。正是數(shù)據(jù)庫對高并發(fā)讀能力的支持不足，所以催生了NoSQL如redis、Memcached 等技術。低成本目標的實現(xiàn)應該是一個持續(xù)的過程，從長遠來看只有最終達到了收益覆蓋成本才是穩(wěn)定的狀態(tài)，2023年在互聯(lián)網(wǎng)企業(yè)中流行的降本增效，也可以認為是一種包括了人力資源的低成本目標，是對過去粗放式不計成本的增長的債務償還。但是在實現(xiàn)這個目標的過程中有些企業(yè)操之過急推之過快，導致了出現(xiàn)了不少的問題，導致相繼出現(xiàn)了被網(wǎng)友戲稱“降本增笑”的事故。
為了實現(xiàn)低成本，對于實力雄厚且領先的大企業(yè)來說，往往需要通過引領創(chuàng)新來實現(xiàn)，難度很高。而對于多數(shù)的普通企業(yè)來說，更多的是通過引進相對成熟的新技術實現(xiàn)，難度要低得多。對于我們架構師來說，保證系統(tǒng)的技術架構持續(xù)略微領先于業(yè)務發(fā)展除了更好的支持未來的發(fā)展之外，還能以更合理的成本來實現(xiàn)目標。作為架構師，需要不斷關注行業(yè)的最新動態(tài)和技術趨勢，結合企業(yè)的實際情況，做出恰當?shù)募夹g選型和架構規(guī)劃。在保證系統(tǒng)技術架構略微領先的同時，也需要合理匹配成本，確保技術投入與業(yè)務發(fā)展的平衡，實現(xiàn)最佳的技術與商業(yè)價值的結合。
