揭秘云計(jì)算| 08· 云向何處去？

時(shí)間：2023-03-13 03:22:01 | 來(lái)源：電子商務(wù)

時(shí)間：2023-03-13 03:22:01 來(lái)源：電子商務(wù)

了解云計(jì)算服務(wù)、產(chǎn)品與解決方案的演進(jìn)歷程可以從服務(wù)提供方或需求方入手。

以服務(wù)需求方為例，業(yè)務(wù)需求出發(fā)點(diǎn)的不同導(dǎo)致選擇云計(jì)算解決方案的切入點(diǎn)不同，我們以不同類(lèi)型的XaaS作為切入點(diǎn)，對(duì)于某些用戶而言提供遠(yuǎn)程桌面、瘦客戶端（取代現(xiàn)有PC主機(jī)、筆記本電腦）是日常辦公云化的第一步，而其他用戶，特別是一些對(duì)于流程較注重的公司可能會(huì)從購(gòu)買(mǎi)SaaS化的辦公自動(dòng)化系統(tǒng)、CRM或ERP系統(tǒng)入手。研發(fā)型機(jī)構(gòu)或IT公司接入云的方式則更有可能是直接購(gòu)買(mǎi)虛擬化的IaaS資源，如云主機(jī)、云數(shù)據(jù)庫(kù)服務(wù)等（當(dāng)然，對(duì)于部門(mén)內(nèi)、部門(mén)間協(xié)同工作要求較高的機(jī)構(gòu)，也可能會(huì)從類(lèi)似于白板、通信錄、日歷、庫(kù)存、訂單管理、共享桌面等服務(wù)切入。這一類(lèi)服務(wù)都被冠以“科研云”的名頭，實(shí)質(zhì)上是不折不扣的SaaS服務(wù)）。

無(wú)論是從底層的IaaS還是從上層的SaaS接入云，它們都會(huì)向中間層的PaaS平臺(tái)演進(jìn)。 PaaS提供的核心服務(wù)可以分為兩大類(lèi)：

集成化的服務(wù)（部署、維護(hù)、升級(jí)、兼容性管理、服務(wù)目錄等）；
l一體化開(kāi)發(fā)+運(yùn)維（DevOps）、持續(xù)集成、持續(xù)部署（CI/CD）。

DevOps的概念本身于2008年9被正式提出，但是業(yè)界巨頭如Yahoo!等早在2004年就已經(jīng)廣泛采用DevOps的模式運(yùn)營(yíng)筆者在Yahoo!工作的時(shí)候印象最深刻的就是每個(gè)開(kāi)發(fā)人員都要輪流佩戴BB機(jī)一周，“24×7”值班，發(fā)生問(wèn)題時(shí)遠(yuǎn)程登錄主機(jī)依然不能解決的問(wèn)題就需要親自去機(jī)房排查物理機(jī)問(wèn)題。DevOps對(duì)于開(kāi)發(fā)人員是一種典型的一身兼數(shù)職（對(duì)細(xì)化分工的一種逆向操作），而對(duì)于測(cè)試與運(yùn)維而言則是意味著弱化甚至消滅這些工種。

如果從云的基本屬性角度出發(fā)，云服務(wù)提供商（建設(shè)者）與云的客戶（使用者）的訴求有不同的演進(jìn)階段。前者通常把基礎(chǔ)架構(gòu)、平臺(tái)、服務(wù)與應(yīng)用的彈性放到第一位，而后系統(tǒng)健壯性，再之后是各項(xiàng)性能指標(biāo)的提高，最后會(huì)提高安全性；而對(duì)于后者通常在進(jìn)入云初期，低成本是第一考量，彈性、敏捷性、可伸縮性緊隨其后，再之后是健壯性與安全性。兩者的優(yōu)先級(jí)看似有很大差異，實(shí)則對(duì)立統(tǒng)一。（如下圖所見(jiàn)）

此外，老孫一再?gòu)?qiáng)調(diào)安全問(wèn)題！早在2018年，Gartner（全球最具權(quán)威的IT研究與顧問(wèn)咨詢公司）就提出過(guò)“安全性將成為云計(jì)算考量的首要因素正是云逐漸趨于成熟的標(biāo)志之一”的論斷，現(xiàn)在看來(lái)，確實(shí)如此——在性價(jià)比、彈性、敏捷性、健壯性、性能這些難題都已經(jīng)被攻克后，安全問(wèn)題已經(jīng)被提上了議事日程。

很多時(shí)候，云的安全問(wèn)題，尤其是公有云安全，比大家想象的要嚴(yán)重的多。曾經(jīng)有家公司在某公有云上面部署了公司的代碼管理服務(wù)器以及全部開(kāi)發(fā)服務(wù)器，但是赫然發(fā)現(xiàn)某天多臺(tái)系統(tǒng)宕機(jī)，并發(fā)現(xiàn)有該云服務(wù)商方面的root賬戶登錄。該公司隨即把所有的代碼及服務(wù)器下線并遷移回公司內(nèi)網(wǎng)。類(lèi)似的事件讓云的安全性和可信任問(wèn)題顯得格外突出。

對(duì)于云的彈性（Elasticity）有幾個(gè)重要的衡量指標(biāo)：

提供資源所需的時(shí)間（Provisioning Time）。
提供可伸縮資源的全面性—左右水平、上下垂直、計(jì)算、網(wǎng)絡(luò)、存儲(chǔ)、服務(wù)及應(yīng)用等。
對(duì)于彈性資源的監(jiān)控粒度。傳統(tǒng)的監(jiān)控方式的顆粒度是基于物理機(jī)或虛擬機(jī)的資源組件（如Nagios、Ganglia等），但是在云計(jì)算框架下對(duì)于一個(gè)可能跨越了多個(gè)物理機(jī)、虛機(jī)或容器的應(yīng)用或服務(wù)而言，對(duì)其監(jiān)控的復(fù)雜度大增，需要在對(duì)整個(gè)應(yīng)用或服務(wù)的各項(xiàng)指標(biāo)做綜合甚至是加權(quán)計(jì)算后呈現(xiàn)給用戶。
資源供應(yīng)的準(zhǔn)確性，避免過(guò)度供應(yīng)（Over-Provisioning）或供應(yīng)不足（Under- Provisioning）。

云的性能評(píng)測(cè)（Performance Benchmark）可以從多個(gè)維度展開(kāi)：

傳統(tǒng)指標(biāo)的評(píng)測(cè)：CPU/VCPU、網(wǎng)絡(luò)、磁盤(pán)吞吐率指標(biāo)。
云化工作負(fù)載（Workloads）性能評(píng)測(cè)：如數(shù)據(jù)庫(kù)、大數(shù)據(jù)或某個(gè)具體應(yīng)用的性能（吞吐率、啟動(dòng)速度等）評(píng)測(cè)。
其他功能的支持及指標(biāo)：如是否支持實(shí)時(shí)的塊數(shù)據(jù)復(fù)制（SAN Replication）、系統(tǒng)的IOPS（每秒讀寫(xiě)操作次數(shù)）、對(duì)傳統(tǒng)應(yīng)用向云遷移的支持、云內(nèi)及跨云數(shù)據(jù)遷移速度等。

談到云的性能，其核心就是云上工作負(fù)載的性能，在這里，我們需要引入和澄清一個(gè)重要的概念：云本地應(yīng)用、云原生應(yīng)用（Cloud Native Application，CNA）。并非所有的應(yīng)用都是為云而生的，傳統(tǒng)應(yīng)用的一個(gè)重要特點(diǎn)是Monolithic （獨(dú)立性、封閉性），而在云基礎(chǔ)架構(gòu)上運(yùn)行應(yīng)用分為兩類(lèi)：傳統(tǒng)應(yīng)用的云化遷移與創(chuàng)建云本地應(yīng)用。傳統(tǒng)應(yīng)用通常對(duì)底層硬件有很多需求，因此遷移并非是像搬箱子（Lift-n-Move）那么簡(jiǎn)單的事情，通常需要對(duì)其進(jìn)行虛擬機(jī)或容器封裝（有些甚至需要在符合規(guī)格的裸機(jī)上直接運(yùn)行才能保證效率，如大數(shù)據(jù)類(lèi)應(yīng)用），并且這些傳統(tǒng)應(yīng)用很難進(jìn)行彈性擴(kuò)展，如此一來(lái)它們的云化遷移更多的是為了云化而云化。

云原生應(yīng)用（Cloud Native Applications）又被稱為云本地應(yīng)用。

云原生應(yīng)用具有五大特點(diǎn)：

（1）MSA（Micro-Service Architecture，微服務(wù)架構(gòu)）：

MSA是云本地應(yīng)用的最重要的特點(diǎn)，它源自于SOA（Service Oriented Architecture，面向服務(wù)的架構(gòu)），可以認(rèn)為是SOA整體框架中的一部分，在云化的過(guò)程中逐漸演變?yōu)楦鱾€(gè)云組件之間通過(guò)可獨(dú)立部署的服務(wù)接口來(lái)實(shí)現(xiàn)通信。圖1-39形象地展示了傳統(tǒng)獨(dú)立應(yīng)用與微服務(wù)架構(gòu)應(yīng)用間的差異。獨(dú)立應(yīng)用是一個(gè)“大包大攬”的整體，每一個(gè)應(yīng)用進(jìn)程（Process）會(huì)把多個(gè)功能集成在一起，獨(dú)立應(yīng)用的擴(kuò)展也是以應(yīng)用進(jìn)程為單位擴(kuò)展到多臺(tái)主機(jī)上；而微服務(wù)的最大區(qū)別在于把每一個(gè)功能元素作為一個(gè)獨(dú)立的服務(wù)，這些服務(wù)可以部署在不同的主機(jī)上，每個(gè)服務(wù)只要保證通信接口不變，它們可以各自獨(dú)立進(jìn)化。從DevOps的角度出發(fā)，MSA架構(gòu)也具有非常明顯的優(yōu)勢(shì)——一個(gè)服務(wù)的故障不至于會(huì)導(dǎo)致整個(gè)應(yīng)用下線，而在獨(dú)立應(yīng)用架構(gòu)中，任何一個(gè)單一功能的維護(hù)、升級(jí)都要求整個(gè)應(yīng)用進(jìn)程下線、重啟……
然而，一味鼓吹MSA的以上的優(yōu)勢(shì)，并不等于MSA可以通吃，或者說(shuō)毫無(wú)缺點(diǎn)可言，在HPC（高性能計(jì)算）的很多場(chǎng)景中，關(guān)注每一微秒的吞吐率、時(shí)耗的時(shí)候，MSA平日里靈活、健壯的優(yōu)勢(shì)就無(wú)法體現(xiàn)了，相對(duì)而言，更緊耦合的系統(tǒng)（例如更少的網(wǎng)絡(luò)層數(shù)據(jù)交換）的性能可能會(huì)更好。

（2）云應(yīng)用12要素：

12-Factor Application（云應(yīng)用12要素）是業(yè)界被廣泛引用的CNA類(lèi)型應(yīng)用的通用特點(diǎn)，由Adam Wiggins在2012年提出10。他總結(jié)了CNA的12要素：?jiǎn)未a庫(kù)多次部署、明確定義依賴關(guān)系、在環(huán)境中存儲(chǔ)配置、后端服務(wù)作為附加資源、建設(shè)發(fā)布及上線運(yùn)行分段、以無(wú)狀態(tài)進(jìn)程來(lái)運(yùn)行應(yīng)用、通過(guò)端口綁定來(lái)暴露服務(wù)、通過(guò)進(jìn)程模型擴(kuò)展來(lái)實(shí)現(xiàn)并發(fā)、通過(guò)快速啟動(dòng)與優(yōu)雅終止來(lái)實(shí)現(xiàn)最大化健壯性、開(kāi)發(fā)環(huán)境=線上環(huán)境、日志=事件流、后臺(tái)管理任務(wù)=一次性進(jìn)程。以上12要素在業(yè)界被廣泛引用，有些人甚至稱之為建設(shè)與運(yùn)行云應(yīng)用最佳實(shí)踐的金標(biāo)準(zhǔn)。

（3）自服務(wù)敏捷基礎(chǔ)架構(gòu)：

自服務(wù)敏捷基礎(chǔ)架構(gòu)（Self-Service Agile Infrastructure）的概念最早由筆者的同事Matt Stine在他2015年的Migrating to Cloud-Native Application Architectures11一書(shū)中提出，自服務(wù)敏捷架構(gòu)的另一個(gè)叫法是PaaS（平臺(tái)即服務(wù)），它幫助程序員完成四件事情：
· 自動(dòng)化、按需的應(yīng)用實(shí)例伸縮（Automated & On-demand Scaling）；
· 應(yīng)用程序健康管理（Health Management）；
· 對(duì)應(yīng)用實(shí)例訪問(wèn)的自動(dòng)路由與負(fù)載均衡（Routing&Load-Balancing）；
· 對(duì)日志與度量數(shù)據(jù)的集結(jié)（Aggregation）。

（4）面向API的協(xié)作模式：

面向API的協(xié)作模式是在完成向微服務(wù)架構(gòu)、12要素應(yīng)用建設(shè)、自服務(wù)敏捷基礎(chǔ)架構(gòu)三大模式轉(zhuǎn)變過(guò)程中必然出現(xiàn)的新型協(xié)同工作模式。傳統(tǒng)的協(xié)同開(kāi)發(fā)模式是基于應(yīng)用部件間的方法調(diào)用（Method Calls），而在云架構(gòu)中，更多的是通過(guò)調(diào)用某種APIs的方式來(lái)實(shí)現(xiàn)組件間的通信，而API版本之間的兼容關(guān)系通過(guò)版本號(hào)來(lái)定義與協(xié)調(diào)，REST APIs12就是一種非常流行的方式——它也是整個(gè)WWW的軟件架構(gòu)標(biāo)志性風(fēng)格——無(wú)獨(dú)有偶，REST的作者Roy Fielding在他的博士答辯論文中對(duì)RESTful API進(jìn)行了定義，而他同時(shí)也是HTTP/1.113的主要作者。REST與HTTP之間有如此千絲萬(wàn)縷的聯(lián)系，以至于很多人將二者混為一談，在這里需要做一下簡(jiǎn)單的澄清，區(qū)別如下：
· HTTP是傳輸層協(xié)議；REST是一組架構(gòu)約束條件（Constraints），它可以使用HTTP或任意其他傳輸層協(xié)議來(lái)實(shí)現(xiàn)。
· HTTP API與REST API間存在本質(zhì)區(qū)別。任何使用HTTP作為傳輸層協(xié)議的API，如SOAP，都是HTTP API，而REST API則遵循REST的約束條件，它更多的是一種圍繞資源的設(shè)計(jì)風(fēng)格而不是標(biāo)準(zhǔn)。

（5）面向故障：

面向故障（Anti-fragile-Design for Failure）是云計(jì)算彈性與敏捷性的終極體現(xiàn)，在遵循微服務(wù)架構(gòu)、12要素、自服務(wù)、面向API的設(shè)計(jì)原則下，云本地應(yīng)用可以做到零下線時(shí)間，也就是說(shuō)在故障甚至災(zāi)難發(fā)生時(shí)系統(tǒng)有足夠的冗余來(lái)確保服務(wù)保持在線。業(yè)界最著名的面向故障的實(shí)踐案例是Netflix工程師為了測(cè)試他們?cè)趤嗰R遜AWS上的服務(wù)的健壯性而開(kāi)發(fā)的一套叫作Chaos Monkey14的開(kāi)源軟件——它會(huì)發(fā)現(xiàn)并隨機(jī)終止系統(tǒng)中的云服務(wù)，以此來(lái)測(cè)試系統(tǒng)的自我恢復(fù)能力。

云的發(fā)展過(guò)程就像一次旅程（如上圖所見(jiàn)）。為了提供云服務(wù)，就需要改造現(xiàn)有的數(shù)據(jù)中心（傳統(tǒng)數(shù)據(jù)中心，Conventional Data-Center）。在傳統(tǒng)數(shù)據(jù)中心內(nèi)，計(jì)算、網(wǎng)絡(luò)和存儲(chǔ)等資源通常專(zhuān)供各個(gè)業(yè)務(wù)單元或應(yīng)用程序使用，這會(huì)導(dǎo)致管理復(fù)雜以及資源非充分利用。CDC所存在的限制促使了虛擬化數(shù)據(jù)中心（Virtualized Data-Center，VDC），在虛擬化進(jìn)程中一般遵循的是計(jì)算虛擬化、網(wǎng)絡(luò)虛擬化、存儲(chǔ)虛擬化分階段實(shí)施。持續(xù)的IT成本壓力以及業(yè)務(wù)的按需數(shù)據(jù)處理需求最終催生了云數(shù)據(jù)中心，我們也稱之為軟件定義的數(shù)據(jù)中心（SDDC，Software-Defined Data-Center）——它的核心機(jī)制是以服務(wù)和應(yīng)用為導(dǎo)向——在硬件層面并沒(méi)有和前面的VDC與CDC有本質(zhì)區(qū)別，主要的飛躍通過(guò)軟件工程的高度發(fā)展來(lái)實(shí)現(xiàn)，也就是我們前面提到CNA的5大原則——MSA、12-factor、Self-Service Agile、API Collaboration與Anti-fragile。

老孫再?gòu)脑频男螒B(tài)入手分析一下云的演變歷程：

通常一條完整的進(jìn)化曲線（如下圖所見(jiàn)）是從數(shù)據(jù)中心（無(wú)論是場(chǎng)內(nèi)還是場(chǎng)外）到私有云，再到公有云，最終演化為混合云。

不同的機(jī)構(gòu)和組織進(jìn)入云的切入點(diǎn)可能會(huì)因需求與能力的差異而不同，無(wú)論是從相對(duì)原始的傳統(tǒng)數(shù)據(jù)中心開(kāi)始還是從私有云或公有云服務(wù)切入，獲取云服務(wù)通常不會(huì)以一種單一的云形態(tài)來(lái)獲得，個(gè)中原因值得深思。

以中小企業(yè)為例，最先使用的云服務(wù)可能是公有云的虛擬主機(jī)，而后逐步演進(jìn)到使用公有云的存儲(chǔ)服務(wù)、數(shù)據(jù)庫(kù)服務(wù)、網(wǎng)絡(luò)服務(wù)，直至大數(shù)據(jù)服務(wù)，但是，有多重原因可能會(huì)造成該企業(yè)考慮其他云服務(wù)提供商或云形態(tài)，如云計(jì)算的如下隱藏成本可能會(huì)讓你拿到賬單的時(shí)候大吃一驚：

·過(guò)度部署（Over-Provisioning）；
·缺少實(shí)時(shí)審計(jì)（Auditing）導(dǎo)致的空轉(zhuǎn)與浪費(fèi)；
·存儲(chǔ)浪費(fèi)（不同熱度的數(shù)據(jù)訪問(wèn)代價(jià)差異巨大）；
·一切免費(fèi)都是有代價(jià)的（互聯(lián)網(wǎng)推廣本性所致）；
·復(fù)雜的計(jì)費(fèi)方式；
·進(jìn)場(chǎng)免費(fèi)離場(chǎng)代價(jià)高昂（數(shù)據(jù)遷移高代價(jià)）；
·高昂的故障修復(fù)成本；
·不可定制。

另外，當(dāng)公有云的成本達(dá)到一定階段或某些任務(wù)無(wú)法在現(xiàn)有云服務(wù)目錄中得到滿足（老孫與同事做過(guò)一些市場(chǎng)調(diào)查，發(fā)現(xiàn)很多企業(yè)把每年100萬(wàn)美元在公有云上的消費(fèi)作為一條警戒線，一旦達(dá)到或超過(guò)就會(huì)開(kāi)始把部分業(yè)務(wù)向私有云環(huán)境遷移。

最典型的是那些對(duì)于單機(jī)配置與性能要求高的大數(shù)據(jù)分析類(lèi)業(yè)務(wù)，這些業(yè)務(wù)更適合直接在物理機(jī)上運(yùn)行，而且運(yùn)行時(shí)間較長(zhǎng)，在公有云環(huán)境中通常很難獲得足夠高的配置，也很難保證長(zhǎng)時(shí)間運(yùn)行的業(yè)務(wù)不被強(qiáng)行中斷—云計(jì)算、大數(shù)據(jù)服務(wù)之豐富如亞馬遜AWS也不能保證所有的業(yè)務(wù)需求都可以被滿足，那種One-Stop-Shop的觀念老孫以為對(duì)于需求單純的初創(chuàng)企業(yè)可行，對(duì)于業(yè)務(wù)需求日漸豐富、復(fù)雜化的組織而言，很難做到。

也就是說(shuō)，通常需要異構(gòu)的數(shù)據(jù)中心或兩種以上的云、虛擬化環(huán)境來(lái)滿足業(yè)務(wù)需求），大多數(shù)企業(yè)的CIO會(huì)考慮通過(guò)遷移一部分任務(wù)到其他云來(lái)實(shí)現(xiàn)成本控制和完成任務(wù)。至此，我們也達(dá)到了云旅程的一個(gè)穩(wěn)定狀態(tài)—混合云，老孫深以為混合云將會(huì)是未來(lái)相當(dāng)長(zhǎng)一段時(shí)間內(nèi)大多數(shù)云旅程的主要趨勢(shì)，而作為業(yè)務(wù)部門(mén)和IT部門(mén)而言，這也意味著更復(fù)雜的面向多云環(huán)境的業(yè)務(wù)管理與運(yùn)維。

·END·

往期回顧：