Jim Scott 陳琳華

這些關(guān)鍵技術(shù)正在“重塑”企業(yè)IT基礎(chǔ)架構(gòu)以實(shí)現(xiàn)對大量寶貴數(shù)據(jù)更加快捷和更加靈活的訪問。

重新構(gòu)建企業(yè)IT基礎(chǔ)架構(gòu)不是一件小事，其通常是由一系列不斷變化的關(guān)鍵業(yè)務(wù)驅(qū)動(dòng)因素引發(fā)的。如今企業(yè)的處境正是如此。簡而言之，目前已經(jīng)主導(dǎo)企業(yè)IT近30年的平臺(tái)再也無法處理推動(dòng)業(yè)務(wù)發(fā)展所需的工作負(fù)載。

數(shù)字化轉(zhuǎn)型的核心是數(shù)據(jù)，而數(shù)據(jù)已成為了商業(yè)活動(dòng)中最有價(jià)值的東西。長期以來，由于格式不兼容、傳統(tǒng)數(shù)據(jù)庫的局限性以及無法靈活地合并來自多個(gè)來源的數(shù)據(jù)導(dǎo)致企業(yè)未能充分利用數(shù)據(jù)。如今新出現(xiàn)的技術(shù)有望改變這種局面。

改進(jìn)軟件部署模型是消除數(shù)據(jù)使用障礙的一個(gè)主要環(huán)節(jié)。更高的“數(shù)據(jù)敏捷性”需要更加靈活的數(shù)據(jù)庫和更具擴(kuò)展性的實(shí)時(shí)流平臺(tái)。事實(shí)上，至少有七種基礎(chǔ)技術(shù)可以為企業(yè)提供靈活的實(shí)時(shí)“數(shù)據(jù)結(jié)構(gòu)”。

與正在被取代的技術(shù)不同，這七項(xiàng)軟件創(chuàng)新具有可擴(kuò)展性，可滿足眾多用戶和用例的需求。對于企業(yè)而言，這些技術(shù)可讓他們做出更快且更明智的決策，從而帶來更好的客戶體驗(yàn)。

1. NoSQL數(shù)據(jù)庫

RDBMS已經(jīng)在數(shù)據(jù)庫市場占據(jù)了近30年的主導(dǎo)地位。然而面對不斷增長的數(shù)據(jù)量和越來越快的數(shù)據(jù)處理速度，傳統(tǒng)的關(guān)系型數(shù)據(jù)庫已經(jīng)顯得力不從心。得益于出色的處理速度和可擴(kuò)展性，NoSQL數(shù)據(jù)庫正在逐步占據(jù)主導(dǎo)地位。對于文檔數(shù)據(jù)庫，它們從軟件工程角度提供了一個(gè)更為簡單的模式。這種簡單的開發(fā)模式不僅可加快產(chǎn)品上市速度，還可幫助企業(yè)更快地響應(yīng)客戶和內(nèi)部用戶的需求。

2.實(shí)時(shí)流平臺(tái)

實(shí)時(shí)對客戶做出響應(yīng)對于客戶體驗(yàn)來說至關(guān)重要。這也是為什么以消費(fèi)者為導(dǎo)向的行業(yè)在過去十年中被全面顛覆的原因。它們與企業(yè)實(shí)時(shí)響應(yīng)用戶的能力密切相關(guān)。告之客戶自己將在24小時(shí)內(nèi)提供解決方案是一種非常糟糕的客戶體驗(yàn)，因?yàn)榭蛻粢呀?jīng)在執(zhí)行他們在23小時(shí)前做出的決定了。然而轉(zhuǎn)向?qū)崟r(shí)模式需要事件流。

雖然由消息驅(qū)動(dòng)的應(yīng)用程序已經(jīng)出現(xiàn)了多年時(shí)間，但是今天的流平臺(tái)與它們的前輩相比規(guī)模更大且成本更低。流處理技術(shù)近期取得的進(jìn)步為許多新的業(yè)務(wù)優(yōu)化方法奠定了堅(jiān)實(shí)的基礎(chǔ)。及時(shí)響應(yīng)客戶只是一個(gè)方面。通過為軟件開發(fā)和測試團(tuán)隊(duì)提供實(shí)時(shí)反饋環(huán)路，事件流還可以幫助企業(yè)提高產(chǎn)品質(zhì)量，以及更加迅速地開發(fā)出新的軟件。

3. Docker和容器

容器對開發(fā)人員和運(yùn)維人員以及企業(yè)本身都有很大的好處。傳統(tǒng)的基礎(chǔ)設(shè)施隔離方法是靜態(tài)分區(qū)，即為每個(gè)工作負(fù)載分配一個(gè)獨(dú)立且固定的資源（無論是物理服務(wù)器還是虛擬機(jī)）。靜態(tài)分區(qū)的好處是更容易排除故障，但是提供大量未被充分利用的硬件需要很高的成本。例如，Web服務(wù)器平均僅使用10%左右的總可用計(jì)算資源。

容器技術(shù)最大的優(yōu)勢是它們能夠創(chuàng)建一種新型隔離方式。那些對容器不甚了解的人可能會(huì)認(rèn)為他們可以通過Ansible、Puppet或Chef等工具獲得同樣的優(yōu)勢，但是事實(shí)上這些技術(shù)相互間具有高度的互補(bǔ)性。此外，無論如何嘗試，這些自動(dòng)化工具都無法為那些在不同的基礎(chǔ)設(shè)施和硬件設(shè)置之間自由移動(dòng)工作負(fù)載創(chuàng)建所需的隔離性。同一容器可在本地?cái)?shù)據(jù)中心的裸機(jī)硬件上運(yùn)行，也可以在無需任何更改的情況下在公有云上的虛擬機(jī)中運(yùn)行，而這是才是真正的工作負(fù)載移動(dòng)性。

4.容器倉庫

容器倉庫對敏捷性至關(guān)重要。如果沒有用于創(chuàng)建容器鏡像的devops進(jìn)程和用于存儲(chǔ)容器鏡像的倉庫，那么每臺(tái)運(yùn)行容器的機(jī)器上都必須創(chuàng)建相應(yīng)的容器。通過容器倉庫，容器鏡像可以從任意一臺(tái)配置為從該倉庫讀取的機(jī)器上啟動(dòng)。在處理多個(gè)數(shù)據(jù)中心時(shí)，情況會(huì)變得十分復(fù)雜。如果在某個(gè)數(shù)據(jù)中心上創(chuàng)建了容器鏡像，那么如何將該鏡像移動(dòng)到另一個(gè)數(shù)據(jù)中心上呢？理想情況下，企業(yè)可以通過聚合數(shù)據(jù)平臺(tái)在數(shù)據(jù)中心之間映射該容器倉庫。

其中的一個(gè)關(guān)鍵問題是，在本地部署和云端之間進(jìn)行映射與在兩個(gè)本地?cái)?shù)據(jù)中心之間映射存在著很大的差異。不過，無論企業(yè)使用的是物理基礎(chǔ)設(shè)施還是云基礎(chǔ)設(shè)施，聚合數(shù)據(jù)平臺(tái)提供的功能均可解決這一問題。

5.容器編排

與靜態(tài)硬件分區(qū)不同的是，每個(gè)容器似乎都有自己專用的操作系統(tǒng)。而與虛擬機(jī)不同的是，容器不需要對計(jì)算和內(nèi)存進(jìn)行靜態(tài)分區(qū)。這使得管理員可以在服務(wù)器上啟動(dòng)大量容器，而不必?fù)?dān)心內(nèi)存不足。在使用像Kubernetes這樣的容器編排工具時(shí)，管理員可以非常容易地啟動(dòng)、關(guān)閉和移動(dòng)容器，或是在環(huán)境中的某個(gè)地方重新啟動(dòng)容器。

在引入了新的基礎(chǔ)設(shè)施組件，例如MapR-DB或MongoDB文檔數(shù)據(jù)庫、MapR-ES或Apache Kafka等事件流平臺(tái)、Kubernetes等編排工具以及用于在Docker容器中創(chuàng)建和部署軟件的devops流程之后，我們必須要將重點(diǎn)轉(zhuǎn)向另一個(gè)問題，即我們應(yīng)當(dāng)在這些容器中部署些什么東西。下面就讓我們了解一下微服務(wù)。

6.微服務(wù)

從歷史上看，微服務(wù)并不是一個(gè)新出現(xiàn)的概念。今天的微服務(wù)與以前的不同之處在于NoSQL數(shù)據(jù)庫、事件流、容器編排等技術(shù)可隨著數(shù)以千計(jì)的微服務(wù)的創(chuàng)建而不斷擴(kuò)展。如果沒有這些新的數(shù)據(jù)存儲(chǔ)、事件流和基礎(chǔ)設(shè)施編排方式，那么大規(guī)模部署微服務(wù)是不可能的。管理海量數(shù)據(jù)、事件和容器實(shí)例所需的基礎(chǔ)設(shè)施將無法擴(kuò)展到需要的級(jí)別。

所有的微服務(wù)都是為了提供敏捷性。微觀上，一項(xiàng)服務(wù)通常由單個(gè)功能或一組功能組成。微服務(wù)的功能越小越單一，那么創(chuàng)建、測試和部署起來就越容易。這些服務(wù)必須互不掛鉤，否則企業(yè)將無法享受到微服務(wù)承諾的靈活性。微服務(wù)可以依賴于其他服務(wù)，但通常是通過負(fù)載平衡的REST API或事件流。事件流可讓企業(yè)通過請求和響應(yīng)主題輕松跟蹤事件的歷史記錄。這種方法對于故障排除具有很大的好處，因?yàn)檎麄€(gè)請求流和請求中的所有數(shù)據(jù)都可以在隨意回放。

由于微服務(wù)僅有很小的工作單元，并且由于彼此分離，因此隨著時(shí)間的推移更換或升級(jí)服務(wù)幾乎不會(huì)遇到什么障礙。在老模式下，由于對RPC等嚴(yán)重依賴，因此在進(jìn)行更換可升級(jí)時(shí)必須要關(guān)閉所有連接，然后再重新建立連接。此外，負(fù)載平衡也一個(gè)很大的問題，因?yàn)槭謩?dòng)配置非常容易出錯(cuò)。

7.函數(shù)即服務(wù)

我們已經(jīng)看到微服務(wù)正逐步在整個(gè)行業(yè)中占據(jù)一席之地，同樣我們也看到了無服務(wù)器計(jì)算正在興起，或許將無服務(wù)器計(jì)算稱之為函數(shù)即服務(wù)（FaaS）更為準(zhǔn)確些。FaaS可通過將代碼打包在輕量級(jí)架構(gòu)中，內(nèi)置在容器內(nèi)，（基于某些觸發(fā)器）進(jìn)行按需執(zhí)行并自動(dòng)進(jìn)行負(fù)載平衡的方式創(chuàng)建微服務(wù)，這些要?dú)w功于輕量級(jí)架構(gòu)。FaaS的魅力在于它們可讓開發(fā)人員幾乎完全專注于函數(shù)。因此FaaS可以被視為由微服務(wù)催生而來的東西。

觸發(fā)事件是FaaS的關(guān)鍵組成部分。沒有它們，函數(shù)就無法被調(diào)用，只有當(dāng)工作需要時(shí)資源才會(huì)被使用。自動(dòng)調(diào)用函數(shù)是FaaS真正的價(jià)值所在。想象一下，每次讀取用戶的配置文件時(shí)都會(huì)生成一個(gè)審計(jì)事件，這是一個(gè)必須運(yùn)行以通知安全團(tuán)隊(duì)的函數(shù)。更具體地說，它們可能只會(huì)過濾掉某些類型的記錄。用戶還可以對它們進(jìn)行選擇，因此它們畢竟是一個(gè)可完全定制的業(yè)務(wù)函數(shù)。值得關(guān)注的是，通過FaaS部署模式正確配置工作流會(huì)變得非常簡單。

進(jìn)行整合

觸發(fā)服務(wù)背后的東西實(shí)際上只不過是事件流中的事件。雖然某些類型的事件會(huì)比其他事件被更頻繁地用作觸發(fā)器，但是對于任何事件來說只要用戶希望它們成為觸發(fā)器，那么它們都可以被作為觸發(fā)器使用。觸發(fā)器事件可以是文檔更新，或是在新文檔上運(yùn)行OCR進(jìn)程，也可以是向NoSQL數(shù)據(jù)庫添加OCR進(jìn)程文本。我們可以設(shè)想一些更為有意思的方式，如每當(dāng)上傳圖像時(shí)都可以通過機(jī)器學(xué)習(xí)框架對圖像進(jìn)行識(shí)別和評(píng)分。這方面沒有什么限制。在定義了觸發(fā)器事件后，一旦事件發(fā)生，那么函數(shù)就會(huì)被觸發(fā)，隨后函數(shù)將開始工作。

FaaS將成為微服務(wù)使用的下一個(gè)階段。然而，用戶在部署FaaS時(shí)必須考慮一個(gè)重要因素，那就是供應(yīng)商鎖定。FaaS隱藏了具體的存儲(chǔ)機(jī)制、特定的硬件基礎(chǔ)設(shè)施以及編排方式，而這些對開發(fā)人員來說都是非常重要的東西。這種抽象會(huì)導(dǎo)致托管的FaaS產(chǎn)品為整個(gè)行業(yè)制造出有史以來最大的供應(yīng)商鎖定機(jī)會(huì)。由于API未標(biāo)準(zhǔn)化，因此用戶在不徹底放棄原來運(yùn)行的東西之前想從公有云上的FaaS產(chǎn)品中遷移走幾乎是不可能的。如果用戶通過聚合數(shù)據(jù)平臺(tái)中的事件以一種更為系統(tǒng)的方式使用FaaS，那么在云提供商之間遷移將會(huì)變得更加容易。