企業IT架構重新規劃 七種技術必不可少

　　企業IT基礎架構的重新平台化是不小的任務，重新平台化通常是由一組不斷變化的關鍵業務驅動因素引發的，簡而言之，就是目前支持企業業務的平台不能再處理和推動業務發展所需的工作負載。

　　數位化轉型的核心是數據，數據已經成為商業中最有價值的貨幣。由于格式不兼容、傳統資料庫的局限性以及無法靈活地合併來自多個來源的數據，企業長期以來一直受到其使用數據的困擾，而新技術則可以解決這一困境。

　　改善軟體部署模式是消除數據使用障礙的一個主要方面，更高的「數據靈活性」是需要更靈活的資料庫和更具可擴展性的實時流式傳輸平台。目前想要為企業提供靈活的實時「數據結構」需要至少七種基礎技術的相互結合。

　　與原先技術不同，這七種技術能夠擴展以滿足很多用戶和用例的需求，對於企業而言，能夠實現更快、更明智的決策並創造更好的用戶體驗。

　　1. NoSQL資料庫

　　RDBMS在資料庫市場上占據了近30年的主導地位。但是，面對數據量的不斷增長以及數據處理速度的加快，傳統關係數據庫已經顯示出不足。NoSQL資料庫由於其速度和擴展能力而漸漸嶄露頭角。就文檔資料庫而言，從軟體工程的角度提供了一個更簡單的模型。這種更簡單的開發模式可加快產品上市速度，並幫助企業更快響應客戶和內部用戶的需求。

　　2.實時流媒體平台

　　實時響應客戶對客戶體驗至關重要。在過去的10年中，面向消費者的行業經歷了巨大的破壞，這與公司對用戶實時作出反應的能力不無關係。

　　消息驅動的應用程式已存在多年，但流媒體平台的規模要遠遠好於前者，而且成本要低得多。流媒體技術的進步為許多優化業務的新方式打開了大門。流媒體平台不僅要實時響應客戶，還要為軟體開發和測試團隊提供實時反饋迴路，事件流還可以幫助公司提高產品質量、更快地獲得新的軟體。

　　3.Docker和容器

　　容器對開發人員、操作人員以及企業本身都有很大的好處。傳統的基礎設施隔離方法是靜態分區，即為每個工作負載分配一個單獨的固定資源片段(無論是物理伺服器還是虛擬機)。靜態分區更容易排除故障，但是不能充分利用硬體，導致成本較高，交付實質性未充分利用的硬體成本很高，例如，Web伺服器平均只消耗可用總計算量的10%。

　　容器技術的巨大優勢在於其創造了新型隔離的能力。不了解容器的人可能會認為他們通過使用Ansible，Puppet或Chef等工具也可以獲得同樣的效果，但事實上這些技術具有很強的互補性。

　　此外，無論你如何嘗試，這些自動化工具都無法創建在不同基礎架構和硬體設置之間自由移動工作負載所需的隔離。同一個容器可以在本地數據中心的裸機硬體上或公共雲中的虛擬機上運行，無需進行任何更改，這才是真正的工作負載移動。

　　4.容器存儲庫

　　容器存儲庫對于敏捷性至關重要，如果沒有用於構建容器映像的devops進程以及用於存儲它們的回購站，那麼每個容器都必須在該容器可以運行的機器上構建。通過存儲庫，可以在配置為從該存儲庫讀取的任何計算機上啟動容器映像。

　　在處理多個數據中心時，情況會變得更加複雜。如果在一個數據中心內建立一個容器圖像，那麼如何將圖像移動到另一個數據中心?理想情況下，通過利用融合數據平台，可以在數據中心之間對存儲庫進行鏡像。這裡的一個關鍵細節是，內部部署和雲之間的鏡像功能可能與原先內部部署數據中心之間的鏡像功能大不相同。

　　5.容器編排

　　不是靜態硬體分區，每個容器看起來都是它自己的私有作業系統。與虛擬機不同，容器不需要計算和內存的靜態分區，管理員能夠在伺服器上啟動大量容器，而無需擔心內存量。有了像Kubernetes這樣的容器編排工具，啟動、終止和移動容器，甚至是在其它重新啟動容器都會變得非常容易。

　　添加了新的基礎設施組件之後(例如MapR-DB或MongoDB等文檔資料庫)，容器中很多東西的部署問題就需要我們考慮了，例如，MapR-ES或Apache Kafka之類的事件流式傳輸平台、Kubernetes之類的編排工具以及實施用於構建和部署軟體的DevOps流程。這就引出了我們第六個要講的技術——微服務。

　　6.微服務

　　從歷史上看，微服務的概念並不新鮮，但是今天的不同之處是在於啟用技術(NoSQL資料庫，事件流，容器編排)可以隨著數千個微服務的創建而擴展。如果沒有數據存儲、事件流和架構編排的新方法，大規模微服務部署將不可能實現，管理大量數據、事件和容器實例所需的基礎架構將無法擴展到所需的級別。

　　微服務都是關於提供敏捷性，通常由一個功能或一小組功能組成。工作的功能單元越小且越集中，創建、測試和部署服務就越容易。這些服務必須解耦，否則就會失去敏捷性。

　　微服務可以依賴於其他服務，但通常是通過負載平衡的REST API或事件流。通過使用事件流，可以利用請求和響應主題輕鬆跟蹤事件的歷史記錄。由於整個請求流和請求中的所有數據都可以在任何時間點重播，因此這種方法對故障排除具有重大益處。

　　由於微服務封裝了一小部分工作，並且彼此分離，所以隨著時間的推移，更換或升級服務幾乎沒有障礙。在舊模式下，依賴像RPC這樣的緊密耦合就意味著必須關閉所有連接，才能重新建立，而負載均衡就成了一個大問題，手動配置非常容易出錯。

　　7. Function as a service

　　微服務在行業中已占據了主導地位，因此無伺服器計算也漸漸興起。以FaaS方式創建微服務，代碼可以包裝在輕量級框架中，並內置於容器中按需執行，然後自動進行負載平衡。FaaS的優點在於能夠使開發人員專注於功能。

　　觸發事件是FaaS的關鍵組成部分。如果沒有它，那麼只有在完成工作的情況下，才能調用函數和消耗資源。功能的自動調用使得FaaS真正具有價值。想像一下，每當有人讀取用戶的配置文件時，都會有一個審計事件，一個必須運行以通知安全團隊的功能。需要注意的是，使用像FaaS這樣的部署模型來完成工作流程是非常簡單的。

　　七劍合璧，天下無敵

　　觸發服務的其實是事件流中的事件，雖然某些類型的事件會被普遍的用作觸發器，但其實任何事件都可以作為觸發器，例如將文檔更新設置為觸發事件，對新文檔運行OCR過程，然後將OCR過程中的文本添加到NoSQL資料庫。如果我們以更有趣的方式思考，每當上傳圖像時，都可以通過機器學習框架進行圖像識別和評分，定義一個函數，該事件觸發該函數，並且函數完成其工作。

　　FaaS將成為採用微服務的下個階段。但是使用FaaS時要考慮一個問題，那就是供應商鎖定。FaaS隱藏了特定的存儲機制、特定的硬體基礎架構和編排，這對開發人員來說都是偉大的事情。但也由於這種抽象，託管的FaaS產品是行業有史以來最大的供應商鎖定機會之一。由於這些API不是標準化的，所以從公有雲提供的FaaS遷移而無需放棄已經執行的近100%工作，幾乎是不可能的。如果FaaS採用一種更有系統的方法，利用聚合數據平台中的事件，那麼在雲提供商之間移動就變得更容易了。