作者 | 汪志成

本文主要面向企業(yè)決策層。我會盡量用淺顯的語言和簡明的例子來表達(dá)主題。

在 2022 年，“云”早已不再是熱詞，似乎已經(jīng)成了像水和電一樣習(xí)以為常的基礎(chǔ)設(shè)施。但技術(shù)的陽光還遠(yuǎn)遠(yuǎn)沒有照亮世界的每一個角落，你，是否位于其中之一？

而今，云已不再是新潮，炒作已然落幕，浮躁已然平息。此刻，才是普通企業(yè)跟進(jìn)的大好時機。

作為資深軟件工程師，希望我的文章能為你的上云之路提供一些助力。

這些年，雖然已經(jīng)被“云”這個詞完成了信息轟炸，但是你是否認(rèn)真地想過怎么上云？基于云的開發(fā)運維模式和傳統(tǒng)的方案有何區(qū)別？不了解這些，上云就是一個盲目的跟風(fēng)而已，既無法充分發(fā)揮出其價值，也無法在遇到挫折時明智地決定是堅持還是止損。

要想全面的認(rèn)識云，可以從幾個視角來看云對企業(yè) IT 模式的影響。

一、新開發(fā)模式

云平臺的出現(xiàn)，深刻地影響了開發(fā)模式。無論是技術(shù)選型、系統(tǒng)架構(gòu)、研發(fā)組織架構(gòu)還是基礎(chǔ)設(shè)施，都要為上云做好準(zhǔn)備。

微服務(wù)

對于上云的應(yīng)用，微服務(wù)幾乎是必然之選，因為云平臺的基礎(chǔ)功能之一就在于動態(tài)調(diào)配計算資源（CPU、內(nèi)存等）。

我們知道，在一個應(yīng)用中的不同部分，所需要的計算資源是不一樣的。比如“查看商品”功能的使用頻度通常遠(yuǎn)高于“支付訂單”。如果使用傳統(tǒng)的方式，把所有功能都放在一個運行單元中（即單體應(yīng)用），那么就只能將其整體擴容（復(fù)制多份，負(fù)載共擔(dān)）才能實現(xiàn)，這將浪費大量的計算資源。而微服務(wù)技術(shù)可以把使用頻度不同的功能拆分成不同的運行單元，每個運行單元稱之為一個微服務(wù)。比如當(dāng)“查看商品”功能的使用頻度很高時，就可以只對它所在的運行單元進(jìn)行擴容；當(dāng)使用頻度降低時，就可以釋放不再需要的運行單元，把計算資源釋放回資源池。

但微服務(wù)也需要相應(yīng)的技術(shù)儲備。

微服務(wù)與架構(gòu)

要想實現(xiàn)微服務(wù)，首先要解決的問題就是如何合理地設(shè)計系統(tǒng)架構(gòu)。從“便于擴容”的目的出發(fā)來做架構(gòu)設(shè)計是個很自然的想法，但這還遠(yuǎn)遠(yuǎn)不夠?！氨阌跀U容”在架構(gòu)設(shè)計的術(shù)語中稱為“延展性”或“彈性”。而在架構(gòu)設(shè)計中，總是要在架構(gòu)的各種屬性之間做出一定的權(quán)衡和取舍，延展性也不例外。我們必須找到一種更加自然、更加科學(xué)的方式來確定架構(gòu)中模塊的彈性邊界。

通常來說，對于長線項目，擴展性（也就是容易增加新功能）高于延展性。因為前者的成本主要在于程序員，而后者的成本主要在于硬件平臺。當(dāng)兩者沖突的時候，除非延展性已經(jīng)到了投入再多資源也沒有效果的階段，否則還是程序員方面的人力成本更高一些。

因此，我們可以遵循一個原則：在架構(gòu)設(shè)計上優(yōu)先考慮擴展性，擴展性滿足要求的前提下，針對延展性做局部優(yōu)化。比如，先針對擴展性設(shè)計一級模塊，然后找出這個一級模塊中對彈性要求較高的部分，單獨提取成二級模塊。

那么，如何實現(xiàn)擴展性優(yōu)先的架構(gòu)設(shè)計呢？

首先，我們要弄明白“擴展”的來源 —— 一個系統(tǒng)為什么會需要擴展呢？最簡單直接的回答是“因為業(yè)務(wù)需求變了”。所以，我們得到了一個前提：“充分理解業(yè)務(wù)及其領(lǐng)域知識，包括業(yè)務(wù)及其領(lǐng)域知識的現(xiàn)狀和發(fā)展趨勢”。

然后，我們要想清楚“擴展”的成本來自哪里？為什么進(jìn)行擴展會很昂貴？這有兩方面的因素：技術(shù)上的和管理上的。

從技術(shù)上看，當(dāng)業(yè)務(wù)需求發(fā)生變化時，就需要對現(xiàn)有代碼進(jìn)行調(diào)整。這種調(diào)整最好聚焦在一個較小的范圍內(nèi)，這樣一來它所需的設(shè)計、開發(fā)、測試、部署等工作量都比較小。這個“較小的范圍”，最好集中在一個或少數(shù)幾個微服務(wù)。當(dāng)然，也不要因此而設(shè)計過大的微服務(wù)，那樣就會導(dǎo)致很多不相關(guān)的代碼在變更時被迫“陪綁”。

從管理上看，當(dāng)業(yè)務(wù)需求發(fā)生變化時，就需要和相關(guān)的開發(fā)團隊進(jìn)行溝通。在開發(fā)過程中，這些開發(fā)團隊之間還需要互相溝通，而這些溝通都是額外的成本，當(dāng)需要做的跨團隊溝通很多時，這些成本就會出現(xiàn)非線性增長。

因此，我們應(yīng)該得到這樣一個架構(gòu)：無論從技術(shù)視角看還是從管理視角看，這個架構(gòu)都應(yīng)該對齊到業(yè)務(wù)自身的本征架構(gòu)。這樣一來，只要業(yè)務(wù)的變化只會發(fā)生在局部，那么對代碼的調(diào)整也只會發(fā)生在局部，對團隊的影響也同樣只會發(fā)生在局部。

所以，問題歸結(jié)為一個：“如何準(zhǔn)確的認(rèn)識和表達(dá)業(yè)務(wù)自身的本征架構(gòu)”。而答案也很簡單：“交給專家”。讓領(lǐng)域?qū)＜襾碜R別并表達(dá)業(yè)務(wù)自身的領(lǐng)域知識，從這些領(lǐng)域知識中提煉出其本征架構(gòu)。

架構(gòu)、DDD 與演進(jìn)式架構(gòu)

然而，簡單的答案往往意味著復(fù)雜的行動。領(lǐng)域?qū)＜以谧陨淼臉I(yè)務(wù)領(lǐng)域固然是專家，但是往往也只懂其業(yè)務(wù)領(lǐng)域的一小部分，整合多位領(lǐng)域?qū)＜业闹R，是一大難題。即使我們能整合，如何通過領(lǐng)域模型把它準(zhǔn)確全面地表達(dá)出來又是一個更大的難題。因為業(yè)務(wù)專家不一定都有很強的邏輯性，如果沒有受過專門的訓(xùn)練，很難駕馭和表達(dá)復(fù)雜的領(lǐng)域知識，更不用說大規(guī)模的領(lǐng)域知識了。那么，還有更大的難題嗎？有！那就是長期維護這個領(lǐng)域模型。

前兩個問題的答案就是“領(lǐng)域驅(qū)動設(shè)計”，也就是最近大火的 DDD；而后一個問題的答案是“演進(jìn)式架構(gòu)”。

“領(lǐng)域驅(qū)動設(shè)計”的基本思想，是讓業(yè)務(wù)方面的領(lǐng)域?qū)＜液蛙浖夹g(shù)方面的架構(gòu)師來共同梳理領(lǐng)域知識，以便建立一個容易被開發(fā)團隊成員理解的領(lǐng)域模型。而演進(jìn)式架構(gòu)則是強調(diào)，不要把架構(gòu)看做靜態(tài)的、一成不變的產(chǎn)物，不要追求一步到位，而應(yīng)該用各種手段來監(jiān)測、守護它，提早發(fā)現(xiàn)架構(gòu)問題的時機，降低發(fā)現(xiàn)和修正架構(gòu)問題的成本。

這兩個話題都很大，這里就不展開了。感興趣的可以自己進(jìn)一步研究。

二、新投資模式

在云生態(tài)下，大量采用按需付費模式。在這種模式下，基本上不需要多少前期投入 —— 用戶量小的時候就少買資源，隨著用戶規(guī)模的提升，逐漸擴大投入即可。這樣可以降低試驗新商業(yè)應(yīng)用的成本和風(fēng)險。

按需付費通常又分為三種子模式：

按需付費模式

這種模式非常簡單：邊用邊計費，隨時停用隨時停止計費。一般精確到小時或秒級（取決于資源類型）。但是，像流量這樣的資源比較特殊，它的按需計費不是按小時或秒計費，而是按實際流量計費。

但是要注意，不同的資源的停用標(biāo)準(zhǔn)不一樣，比如 ECS（相當(dāng)于虛擬機）只要停止就會針對 CPU、內(nèi)存等停止計費，但是掛載的云硬盤、IP 地址、包年包月帶寬等仍然會繼續(xù)計費。要想釋放這些，就要專門把它們停用。

另外，由于運營成本的不同，所在可用區(qū)對計費，甚至開通的服務(wù)也有著顯著影響。一般來說，發(fā)達(dá)地區(qū)的可用區(qū)比較貴，偏遠(yuǎn)地區(qū)則比較便宜。具體的選擇要視多方面的因素而定，必要時可以先做一下測速。

按需計費類似于零售模式，因此單位費率通常都是最高的，只適合做一些短于一個月的試驗性項目。

包年包月模式

相當(dāng)于按需計費的批發(fā)模式。在按需計費的基礎(chǔ)上，包年包月模式會提供一些額外的優(yōu)惠。

但要注意，包年包月的流量是根據(jù)最大帶寬檔位進(jìn)行逐月逐年計費的。對于流量很小的應(yīng)用，這種方式的實際費用反倒會高于按需付費模式。因此，對于流量很小的應(yīng)用，即使要長期運營，也可能要選擇按需付費模式的流量。當(dāng)然，對于大部分應(yīng)用來說，包年包月總是要比按需付費便宜一些的。

在云平臺里，包年包月模式和按需付費模式通常是可以互相轉(zhuǎn)換的，因此在首次選擇時也不必猶豫再三，因為費用差異沒那么大，為此耽誤商機就不值得了。

競價計費模式

這是一種閑置資源拍賣模式。選擇競價計費時，你的出價并不是你的實際出價，而是你愿意為保留實例而出的最高價。平臺會定期對競拍者按出價進(jìn)行排序，然后依次分配資源使用權(quán)，那些分配不到使用權(quán)的，就會自動被平臺釋放。

這就意味著，要用不確定性來換取優(yōu)惠。因此，它的適用場景和前兩種模式有著顯著的差異。競價計費模式通常用于一些隨時可以啟停的批處理任務(wù)，比如一些非緊急統(tǒng)計報表的生成任務(wù)。云平臺會保證競價計費的單價不會超過按需計費模式，可以放心嘗試。

舉例

以華為云的 ECS 服務(wù)的報價為例（2022-12-06）：

當(dāng)選擇華北“烏蘭察布”區(qū)的 c7.large.2 配置時（2vCPUs，內(nèi)存 4GiB，CPU 型號 Intel Ice Lake，最大帶寬 4 Gbit/s），包一個月的費用是 184.95 元/月，包一年的費用則是 2,129.50 元/年，相當(dāng)于優(yōu)惠了425.90 元。

如果選擇按需付費模式，則為 0.4238 元/小時。折算到月（按 30 天算）就是 305.136 元。也就是說，只要按需付費超過 18 天，費用就已經(jīng)和包月持平了。

華為云的“北京四區(qū)”開通了競價計費模式，并且支持自動競價模式，自動競價會自動對標(biāo)當(dāng)前市場價格。自動競價通常是比較劃算的，否則也不會有用戶選擇。當(dāng)然，有經(jīng)驗之后最好根據(jù)自己對服務(wù)中斷的容忍度，自行設(shè)定競標(biāo)價格，以達(dá)到“恰好夠用”的出價級別。

三、新運維模式

云平臺會幫你完成服務(wù)器、網(wǎng)絡(luò)等基礎(chǔ)設(shè)施的運維，通過這種集約化的運維方式，可以省去全部硬件運維工作以及大部分系統(tǒng)運維工作。但是應(yīng)用層的運維仍然只能由運維人員自己做。

不過，好在云平臺基本上都提供了應(yīng)用運維平臺，比如華為云就提供了“應(yīng)用管理與運維平臺 ServiceStage”，它提供了應(yīng)用開發(fā)、構(gòu)建、發(fā)布、監(jiān)控及運維等一站式解決方案。當(dāng)運維任務(wù)比較重的時候，可以考慮按需采購此項服務(wù)。

如果預(yù)算有限，可以考慮基于開源軟件來自行搭建，有的平臺（比如華為云 CCE）提供了插件。比如：

• 用 ELK 來支持日志收集與分析工作，通過日志，可以對應(yīng)用的運行狀況進(jìn)行剖析，定位并診斷錯誤，識別潛在威脅等。
• 用 Prometheus 對系統(tǒng)和應(yīng)用的運維數(shù)據(jù)進(jìn)行監(jiān)控和預(yù)警，以便觸發(fā)對特定運維事件的自動化處理。
• 用 Grafana 對運維監(jiān)控數(shù)據(jù)進(jìn)行可視化，以便讓各個干系人可以憑直覺發(fā)現(xiàn)運維問題，主動提供不同力度的人為介入。

這些軟件通常會搭配使用，但其自身需要有人維護，而且其整體性仍然不理想，對運維數(shù)據(jù)的挖掘也不夠深入。

如果應(yīng)用系統(tǒng)更加復(fù)雜，那就不能指望這些通用的應(yīng)用運維平臺了，而應(yīng)該在應(yīng)用系統(tǒng)的設(shè)計之初就直接把特有的運維需求包含進(jìn)去。對于開源方案，可以更好地進(jìn)行深度定制，不過需要的技術(shù)水平通常會比較高。對于云平臺方案，由于進(jìn)行了專門的 API 封裝，通?？梢愿唵蔚剡M(jìn)行定制，但是深度受限。

四、未曾設(shè)想的道路

云平臺的意義，不僅僅在于代替了傳統(tǒng)的開發(fā)方式和基礎(chǔ)設(shè)施，更重要的是它打開了許多未曾設(shè)想的道路。比如：

不再自建數(shù)據(jù)庫，而是直接使用云平臺提供的數(shù)據(jù)庫服務(wù)，這樣一來，數(shù)據(jù)庫本身的運維工作也交給云平臺去“集約化”了。

對于流量波動巨大的系統(tǒng)，不需要再基于最大流量自建消息隊列，而是把這部分容量交給云平臺來統(tǒng)一調(diào)配。

對于像人工智能這樣的“新興”技術(shù)，不需要再自己搭建和運維，而是讓云平臺來搭建這些基礎(chǔ)設(shè)施，自己只做應(yīng)用層開發(fā)即可。甚至連應(yīng)用層編碼都不必做，而是直接使用云平臺提供的可視化工具，由業(yè)務(wù)專家來進(jìn)行分析和預(yù)測。

這種模式稱為 PaaS（平臺即服務(wù)）。

對于一些中小企業(yè)，甚至可以考慮不再自建應(yīng)用軟件，而是使用云平臺提供的 CRM 等在線版軟件，自己只需要在其中開一個租戶即可。但是，如果涉及到商業(yè)機密數(shù)據(jù)，就必須找一個可信的提供商，保證自己的數(shù)據(jù)不會被軟件的運營方泄露。非專業(yè)用戶很難判斷運營方的可靠性，只能靠運營方的商譽和運營記錄來判斷了。

不過，對于中小企業(yè)，除非自身非常有特色，否則通常不用過早擔(dān)心數(shù)據(jù)泄露問題。等成長到一定級別，可以花錢請軟件提供商進(jìn)行私有化部署，把運營權(quán)限完全收歸自己。甚至可以重新開發(fā)一套私有系統(tǒng)。

這種模式稱為 SaaS（軟件即服務(wù)）。

除此之外，還有一種更激進(jìn)的 FaaS（函數(shù)即服務(wù)）模式。在這種模式下，應(yīng)用開發(fā)者甚至都不必關(guān)心部署、運維等細(xì)節(jié)，只需要關(guān)心業(yè)務(wù)邏輯就可以了。不過，這部分的能力和方法論體系還不如 IaaS、SaaS、PaaS 那樣成熟，因此可以做一些技術(shù)儲備，但是要想落地還需要謹(jǐn)慎評估。

五、結(jié)語

本文還遠(yuǎn)遠(yuǎn)不足以展現(xiàn)云對于商業(yè)的影響，甚至，都無法判斷云還會有哪些新奇的玩法。正如前一節(jié)所說，無論從商業(yè)意義上還是技術(shù)意義上，云都向我們展現(xiàn)了一些未曾設(shè)想的道路。你，是否會成為某一條新道路的開拓者？讓我們拭目以待！