雖然老舊的計(jì)算模式往往歷久而彌新，但客戶端-服務(wù)器機(jī)制卻不在此列——它就是種錯誤，且需要盡早被時(shí)代所淘汰。

這篇文章是我在參加本周于拉斯維加期召開的IBM Insight大會時(shí)寫下的。還記得當(dāng)初曾有人斷言，全世界最后一臺大型機(jī)會在1996年正式關(guān)停。但就在這個(gè)禮拜，我還親眼看到IBM公司在一臺大型機(jī)上運(yùn)行Apace Spark——而且其性能依然強(qiáng)大到令人嘆服。

是的，大型機(jī)上的Spark，這就是本周藍(lán)色巨人給出的對話主題。IBM公司熱愛大型機(jī)，因?yàn)樗麄兿矚g在這一領(lǐng)域維持自身無可匹敵的硬件業(yè)務(wù)王者地位——截至目前，IBM的大型機(jī)業(yè)務(wù)仍然占全球總體份額的近50%。

而大型機(jī)業(yè)務(wù)同時(shí)也是目前惟一一類仍然會在啟動屏幕上顯示“1980”字樣的計(jì)算解決方案?？蛻舳?服務(wù)器計(jì)算模式并不取決于特定硬件。相反，其只是一種單純的計(jì)算實(shí)現(xiàn)思路，其中包含有多種多樣的硬件以及網(wǎng)絡(luò)元素。

我敢肯定，對于客戶端-服務(wù)器以及與之針鋒相對的所謂“純分布式”計(jì)算模式在具體定義方面還有很大的探討空間。因此請讓我首先對客戶端-服務(wù)器模式做出定義：這代表著單一或者多個(gè)客戶端與某臺持續(xù)監(jiān)聽插槽集合或者資源池的服務(wù)器相對接，其主要采取縱向擴(kuò)展模式且通常配備有集中式數(shù)據(jù)存儲體系?？偠灾@是一種LAN模式。

而對于分布式模式，我將其描述為N個(gè)客戶端或者同類機(jī)制同N臺服務(wù)器相對接，后者主要以橫向方式進(jìn)行規(guī)模擴(kuò)展且采用共享及分布式處理的數(shù)據(jù)存儲方式。這種模式的設(shè)計(jì)思路在于提高容錯能力并承受資源需求峰值，同時(shí)允許大家根據(jù)實(shí)際需要添加更多節(jié)點(diǎn)(通常以線性方式增加)并重新規(guī)劃基礎(chǔ)設(shè)施位置。而這也正是云計(jì)算的核心實(shí)現(xiàn)模式。

這種分布式模式相較純向上擴(kuò)展模式更為強(qiáng)大，因?yàn)槠淠軌蜉p松實(shí)現(xiàn)規(guī)模伸縮。這種能力之所以如此重要，是因?yàn)榭蛻舳?服務(wù)器模式的最大弊端之一就是將工作負(fù)載的可預(yù)測性作為構(gòu)建前提。

然而這種前提從早年間就被證明是一種誤區(qū)。遙想當(dāng)年，我曾經(jīng)負(fù)責(zé)過系統(tǒng)管理方面的工作，那時(shí)候EoM報(bào)告當(dāng)中幾乎就沒什么真正有用的信息，惟一的作用就是不斷閃燈然后提示我們距離本月周期末還有多少天。頗具諷刺意味的是，這也正是大型機(jī)TPC無法發(fā)揮就有作用的主要原因。還記得那時(shí)候我們都會把Slashdot設(shè)為自己的瀏覽器主頁，而且站點(diǎn)由于峰值流量而引發(fā)的停機(jī)則會被稱為Slashdot效應(yīng)。現(xiàn)在的互聯(lián)網(wǎng)與當(dāng)初的狀況簡直一模一樣。

不知道大家有沒有嘗試建立起一套大型的、基于甲骨文方案的現(xiàn)有測試數(shù)據(jù)庫項(xiàng)目。要達(dá)成這一目標(biāo)，我們需要能夠在出現(xiàn)預(yù)料之外的互聯(lián)網(wǎng)數(shù)據(jù)流量及使用規(guī)模峰值時(shí)進(jìn)行向上擴(kuò)展，但同時(shí)又需要在資源需求趨于平穩(wěn)時(shí)進(jìn)行規(guī)模收縮(主要為了節(jié)約AWS開銷)并實(shí)現(xiàn)靈活的適配性(有時(shí)候我們甚至需要在筆記本電腦上測試自己的項(xiàng)目)。

總體而言，如今的工作負(fù)載已經(jīng)呈現(xiàn)出愈發(fā)夸張的不可預(yù)測性，而且大多數(shù)情況下其規(guī)模非常可觀。此外，我們對于網(wǎng)絡(luò)服務(wù)表現(xiàn)的預(yù)期也開始上升?？菰锏捻憫?yīng)等待已經(jīng)無法被用戶所接受，而谷歌時(shí)代下常見的服務(wù)中斷如今被視為非常嚴(yán)重的事故。目前技術(shù)競爭已經(jīng)愈演愈烈且擴(kuò)散到全球范圍，而監(jiān)控要求也變得更加嚴(yán)格(至少在Trump當(dāng)選總統(tǒng)之前是這樣)。

我們的客戶端-服務(wù)器系統(tǒng)根本無法以實(shí)時(shí)需求為依據(jù)進(jìn)行規(guī)模伸縮。它們不具備彈性能力，而且在大多數(shù)情況下不能實(shí)現(xiàn)云體系的基本要求。與此同時(shí)，編寫分布式系統(tǒng)本身也要更加簡便易行。相較于甲骨文甚至是SQL Server，MongoDB實(shí)例的部署工作顯然要輕松得多得多。Spark擁有極易上手的API。NodeJS能夠幫助我們編寫出事件驅(qū)動型彈性分布式系統(tǒng);另外，這些方案的易用性都要比其前輩們好得多。

反對者們可能會指出，這些新興技術(shù)目前的市場占用率還比較有限，不過必須承認(rèn)其普及規(guī)模正在逐步擴(kuò)大。有些人認(rèn)為當(dāng)相關(guān)開發(fā)人員退休之后，與之對應(yīng)的技術(shù)就會徹底消亡。誠然，甲骨文那幫“老不死”的PL/SQL開發(fā)人員一個(gè)賽一個(gè)的長命，但他們終將退位——這是無法改變的現(xiàn)實(shí)。就目前而言，千禧一代技術(shù)人員們普遍認(rèn)為MongoDB要比MySQL更易于使用及打理。

客戶端-服務(wù)器的時(shí)代將在云計(jì)算的全面普及之下終結(jié)。在未來20年中，根據(jù)我的個(gè)人觀察，除了特殊領(lǐng)域之外不會再有新的客戶端-服務(wù)器系統(tǒng)與廣大用戶見面。而新一代解決方案則會以更為出色的表現(xiàn)取代那些老古董。這并不是說非要在部署方式層面有所突破，新方案只需更易用且成本更低廉，同時(shí)能夠滿足現(xiàn)代業(yè)務(wù)領(lǐng)域的期望及具體用例即可。

那么最后一套客戶端-服務(wù)器系統(tǒng)是否會在未來20年內(nèi)正式關(guān)停?答案恐怕是否定的——某些業(yè)界領(lǐng)域的發(fā)展速度并不會太快，競爭關(guān)系可能起到一定的保護(hù)作用，或者是需要滿足某些新型監(jiān)管要求抑或?qū)?yīng)行業(yè)不需要編寫或者購置太多新型軟件方案。從這個(gè)角度講，仍將有很多領(lǐng)域始終持續(xù)使用傳統(tǒng)的客戶端-服務(wù)器實(shí)現(xiàn)模式。

不過作為技術(shù)行業(yè)的從業(yè)人員，我們并不需要為以上情況太過分心——畢竟他們不是咱們的核心客戶群體。相反，我希望他們像出租車行業(yè)被Uber屠殺那樣倒在歷史的車輪之下——抱歉，我這個(gè)人就是這么直率啦。