作者 | 汪志成

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

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

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

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

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

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

一、新開發模式

云平臺的出現，深刻地影響了開發模式。無論是技術選型、系統架構、研發組織架構還是基礎設施，都要為上云做好準備。

微服務

對于上云的應用，微服務幾乎是必然之選，因為云平臺的基礎功能之一就在于動態調配計算資源（CPU、內存等）。

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

但微服務也需要相應的技術儲備。

微服務與架構

要想實現微服務，首先要解決的問題就是如何合理地設計系統架構。從“便于擴容”的目的出發來做架構設計是個很自然的想法，但這還遠遠不夠。“便于擴容”在架構設計的術語中稱為“延展性”或“彈性”。而在架構設計中，總是要在架構的各種屬性之間做出一定的權衡和取舍，延展性也不例外。我們必須找到一種更加自然、更加科學的方式來確定架構中模塊的彈性邊界。

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

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

那么，如何實現擴展性優先的架構設計呢？

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

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

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

從管理上看，當業務需求發生變化時，就需要和相關的開發團隊進行溝通。在開發過程中，這些開發團隊之間還需要互相溝通，而這些溝通都是額外的成本，當需要做的跨團隊溝通很多時，這些成本就會出現非線性增長。

因此，我們應該得到這樣一個架構：無論從技術視角看還是從管理視角看，這個架構都應該對齊到業務自身的本征架構。這樣一來，只要業務的變化只會發生在局部，那么對代碼的調整也只會發生在局部，對團隊的影響也同樣只會發生在局部。

所以，問題歸結為一個：“如何準確的認識和表達業務自身的本征架構”。而答案也很簡單：“交給專家”。讓領域專家來識別并表達業務自身的領域知識，從這些領域知識中提煉出其本征架構。

架構、DDD 與演進式架構

然而，簡單的答案往往意味著復雜的行動。領域專家在自身的業務領域固然是專家，但是往往也只懂其業務領域的一小部分，整合多位領域專家的知識，是一大難題。即使我們能整合，如何通過領域模型把它準確全面地表達出來又是一個更大的難題。因為業務專家不一定都有很強的邏輯性，如果沒有受過專門的訓練，很難駕馭和表達復雜的領域知識，更不用說大規模的領域知識了。那么，還有更大的難題嗎？有！那就是長期維護這個領域模型。

前兩個問題的答案就是“領域驅動設計”，也就是最近大火的 DDD；而后一個問題的答案是“演進式架構”。

“領域驅動設計”的基本思想，是讓業務方面的領域專家和軟件技術方面的架構師來共同梳理領域知識，以便建立一個容易被開發團隊成員理解的領域模型。而演進式架構則是強調，不要把架構看做靜態的、一成不變的產物，不要追求一步到位，而應該用各種手段來監測、守護它，提早發現架構問題的時機，降低發現和修正架構問題的成本。

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

二、新投資模式

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

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

按需付費模式

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

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

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

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

包年包月模式

相當于按需計費的批發模式。在按需計費的基礎上，包年包月模式會提供一些額外的優惠。

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

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

競價計費模式

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

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

舉例

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

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

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

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

三、新運維模式

云平臺會幫你完成服務器、網絡等基礎設施的運維，通過這種集約化的運維方式，可以省去全部硬件運維工作以及大部分系統運維工作。但是應用層的運維仍然只能由運維人員自己做。

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

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

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

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

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

四、未曾設想的道路

云平臺的意義，不僅僅在于代替了傳統的開發方式和基礎設施，更重要的是它打開了許多未曾設想的道路。比如：

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

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

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

這種模式稱為 PaaS（平臺即服務）。

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

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

這種模式稱為 SaaS（軟件即服務）。

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

五、結語

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