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

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

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

低成本除了硬件成本外，軟件成本更是不容忽視，對技術(shù)人員來說一個最常見的例子是要不要使用商業(yè)數(shù)據(jù)庫，比如Oracle數(shù)據(jù)庫。對早期很多大型電信、金融企業(yè)來說過去很長一段時間是實(shí)現(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ù)量級，通常認(rèn)為Mysql單表記錄數(shù)達(dá)到千萬級就要考慮分庫分表了，而Oracle單表記錄數(shù)達(dá)到億級也非常見，甚至在硬件配置不錯的情況下單表十億級仍然能高效快速查詢。在多表聯(lián)合查詢上，Oracle更是要強(qiáng)大得多，超過5張的大表聯(lián)合查詢?nèi)匀环浅８咝В@是Mysql這些開源數(shù)據(jù)庫短期內(nèi)難以媲美的。在Oracle的長期培育下，涌現(xiàn)出一批以數(shù)據(jù)庫為中心的程序員。他們編寫的代碼主要面向數(shù)據(jù)庫，并且依賴于復(fù)雜的SQL語句來實(shí)現(xiàn)業(yè)務(wù)邏輯。

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

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

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

為了實(shí)現(xiàn)低成本，對于實(shí)力雄厚且領(lǐng)先的大企業(yè)來說，往往需要通過引領(lǐng)創(chuàng)新來實(shí)現(xiàn)，難度很高。而對于多數(shù)的普通企業(yè)來說，更多的是通過引進(jìn)相對成熟的新技術(shù)實(shí)現(xiàn)，難度要低得多。對于我們架構(gòu)師來說，保證系統(tǒng)的技術(shù)架構(gòu)持續(xù)略微領(lǐng)先于業(yè)務(wù)發(fā)展除了更好的支持未來的發(fā)展之外，還能以更合理的成本來實(shí)現(xiàn)目標(biāo)。作為架構(gòu)師，需要不斷關(guān)注行業(yè)的最新動態(tài)和技術(shù)趨勢，結(jié)合企業(yè)的實(shí)際情況，做出恰當(dāng)?shù)募夹g(shù)選型和架構(gòu)規(guī)劃。在保證系統(tǒng)技術(shù)架構(gòu)略微領(lǐng)先的同時，也需要合理匹配成本，確保技術(shù)投入與業(yè)務(wù)發(fā)展的平衡，實(shí)現(xiàn)最佳的技術(shù)與商業(yè)價值的結(jié)合。