云泥之別：糧食云實質辨析

文/胡永光

云泥之別：糧食云實質辨析

文/胡永光

一、云計算落地糧食行業的背景

近年來，國家糧食局和全國各地區各單位積極探索以數字糧庫為主要內容的糧食行業信息化建設，全國糧食行業提升了糧食收儲企業運營效能，提高了政府宏觀調控能力和糧食安全保障水平，為全面推進糧食行業信息化發展奠定了基礎。但是，傳統糧食行業信息化建設也存在發展不平衡、建設不規范、標準不統一、可復制性不強、與業務結合不緊密、投資效率不高、單項突進、互聯互通不足以及重建設輕運維等問題。為解決信息化建設過程中出現的問題，國家糧食局適時發布了《國家糧食局關于規范糧食行業信息化建設的意見》，提出全國糧食信息化加強頂層設計、加大新技術創新應用，優先考慮大數據、云計算等技術手段的建設意見，并提出國家平臺、省級平臺兩級架構的建設思路。

在有關糧食行業“十三五”規劃文件中，再次強調了在糧食信息化建設中要將云計算、物聯網等新一代信息技術與糧食業務深度融合、全面推進“互聯網+糧食”的要求。

隨著糧食信息化實踐的深入，國家深入總結信息化建設先行省份的正反面經驗，進一步確認“云模式”是解決一系列糧食信息化典型問題的鑰匙。因此，國家糧食局于2 0 1 7年9月發布地方糧食信息化建設的四個“指引”與“規范”文件（《糧食行業省級平臺建設技術指引（試行）》《糧食行業省級平臺建設驗收規范（試行）》《地方糧庫信息化建設技術指引（試行）》《地方糧庫信息化建設驗收規范（試行）》），明確推行云模式，并明晰了糧食云架構的詳細技術框架、技術路線。

二、云模式真偽辨析

與國家快馬加鞭推行糧食云架構的節奏相反襯的是，由于糧食行業的傳統屬性，活躍于糧食信息化領域的傳統廠商大部分不具備互聯網基因，對云計算缺乏敏感性，技術轉型動力有所欠缺。在國家明確推行云模式后，一些來不及轉型的傳統廠商也將傳統方案包裝成云方案。而受限于糧食從業人員對云計算的理解深度，以及云計算本身作為新技術模式、在糧食行業案例相對較少、評價標準也并未全面普及的客觀事實，因此，糧食部門往往難以甄別方案優劣。在實際項目方案選型過程中，除了國家指引提到的“云模式”與“非云模式”之外，很可能還會遇到第三種模式：“偽云模式”。它本質上是一種新瓶裝舊酒的“非云模式”，但它通過混淆概念、混淆標準，來模糊云模式與傳統模式的界線，導致項目陷入“四不像”。

筆者從以下幾個方面辨析“云模式”真偽，可作為參考。

“偽云模式”的幾種表現

1.將云化等同于虛擬化。云模式除了實現了底層硬件資源的虛擬化，更關鍵的是實現應用能力的云化，具體來說是通過P a a S組件和微服務模式，實現應用的解耦和服務化。傳統廠商由于很難在短期內提供完善的P a a S能力，所以經常將I a a S層的資源虛擬化概念，等同于“云模式”。事實上，虛擬化只是云架構下I a a S層的一部分基礎功能，遠遠不是“云模式”的全部。

2.將云架構等同于S O A、E S B。S O A是傳統的多系統集成思維。其本質是先建“煙囪”再“搭橋”，走的是傳統集成的老路。E S B總線模式，則是實現S O A的具體技術手段。這種集成思維與集成手段，與云模式有本質區別。云模式強調“集中”而非“集成”，通過統一的基礎云平臺實現各類應用的協同一體、數據的天然集中。云模式建設的省級平臺與糧庫系統，本身就是集中一體的，是基于統一平臺上的兩朵應用云。并不需要建立各種“接口”來進行數據的二次匯聚。所以，凡是需要通過大量接口來進行系統集成的，均非真正的云模式。

3.將云平臺等同于“集中管理系統”。在傳統的糧食信息化實踐中，為了滿足省局集中監管、省儲備糧公司集中管理糧庫等等需求，也建設了一些“集中式”系統。從表象上，這些系統也能以集中方式解決某類特定用戶的特定需求，容易被誤導為云架構。比如，有些省份建立了跨糧庫的視頻集中監控平臺，或省局集中監管系統。這種系統在一定程度上實現了運行環境的物理集中，帶來了一定的管理便利性。但運行環境物理集中，并不必然產生云架構。它有幾個明顯局限，與云架構仍有本質之別。

局限一，是其功能邊界的僵化。這些集中系統由于仍采用的是傳統技術模式，采用“組織定義業務”而非“軟件定義業務”，業務流轉與組織結構緊耦合，屬于“一次成型”的靜態產品，只能滿足項目建設時點的特定需求，卻不能持續地、低成本地滿足業務拓展需要，所以仍是“系統”而非“平臺”。經過一段時間的運行之后，這些系統的功能局限性、不可拓展性將越來越成為致命缺陷。真正的糧食云，是技術平臺與應用的統一。通過云技術平臺，實現應用邊界不固化、柔性可拓展。所以一朵真正的省級糧食云，應該是一個糧食能力投放平臺，能持續滿足糧食生態各方參與者信息化需求，而不僅僅是針對某一特定時點、某類特定用戶、某些特定需求的“功能切片”。云模式下的應用布局如下圖：

局限二，是其不能實現I T資產復用。云模式下，業務解耦和服務化是實現應用可拼裝、可復用的前提。通過分層的微服務體系，云模式能夠將業務拆解成最細粒度的微服務，并按需組合服務，微服務可重復利用，成為真正的I T資產，實現投資效益最大化。而“偽云模式”的傳統集中式系統只實現了表層功能的集中，并未將業務邏輯解耦成服務體系，仍然屬于“一次性產品”，無法實現I T資產可復用，從而大幅推高項目長期成本。

局限三，是其不能高效解決互聯互通問題。由于沒有微服務體系的支撐，“偽云模式”的傳統集中式系統很難以標準A P I方式對外開放服務，因而導致其在與國家平臺、省級糧食云平臺、其他相關單位系統之間互聯互通時困難重重。

云模式 偽云模式傳統模式設計思維 軟件定義業務 組織定義業務云化方式 標準微服務、徹底解耦 S O A或完全未解耦開發模式 敏捷開發 瀑布式開發平臺生態 開放生態 封閉固化使用效果 資源共享、能力共享、數據共享 獨立煙囪配套硬件 硬件通用化 采用刀片服務器、小機、專用存儲設備等配套軟件 軟件輕量化 采用O r a c l e、W e b l o g i c、W A S等重型軟件應用形態 輕應用、可獨立部署和升級 重應用擴容方式 橫向擴容、底層資源按需拓展、無需停機縱向擴容，需要停機升級

局限四，在標準規范的落地、開發運維一體化等方面，“偽云模式”的傳統集中式系統與“非云模式”并無二致，也沒有好的技術手段可以實現；在建設周期方面，相比于云模式的快速迭代、快速開發，“偽云模式”不具備快速上線的技術能力，不滿足國家“加快糧食信息化建設”的意見要求。

如何甄別云模式

1.要點辨識：

各方對糧食云的枝節層面的理解可能觀點眾多。拋開眾說紛“云”的細枝末節，糧食云化架構有一些關鍵要點是無法繞過的：

設計思維上，是否堅持“軟件定義”，即是否以軟件為中心定義業務邏輯，而非以人或組織為中心定義業務邏輯；

云化方式上，是否堅持“微服務”標準，即是否將業務進行了最細粒度的解耦、是否依托“微服務”這一靈魂構建了完善的服務識別、服務設計、服務交付、服務運維體系；

開發模式上，能否做到“敏捷開發”，即依托柔性云架構，實現軟件開發的快速迭代、快速交付、敏捷開發；

平臺生態上，能否做到“開放生態”，即基于統一標準、實現對各類主流供應廠商產品的開放兼容，不被廠商綁架；

使用效果上，能否實現“三個共享”，即通過云平臺實現全省糧食信息化底層資源共享、業務能力共享、數據共享。

配套設施上，能否做到“輕量通用”。云架構通過標準化、輕量化、通用化設計，擺脫了對特定大型商業軟硬件的依賴，避免廠商綁架。而傳統架構和偽云架構通常需要采購大型商業軟硬件，比如O r a c l e、S q l S e r v e r、E M C存儲等，采購這些軟硬件的解決方案必然是偽云架構，并且推高了項目實施成本，不符合自主可控的精神。

云模式與非云模式更多差異可總結為9點，如上圖所示。

2.實證檢驗：

在方案甄別的過程中，除了檢驗紙面上的技術要點，同時也要強調技術能力的系統展示和演示，避免空談。具體而言，可以從技術平臺、業務能力兩方面進行系統查驗。

技術平臺查驗主要是按照技術指引明確的技術架構、技術路線來查驗系統，包括省級糧食云架構設計的七大原則要求（實時性、資源共享、流程再造、縮短時空、運維監控、技術約束、平臺定位），以及I a a SP a a S服務管理應用管理公共服務D e v O p s等具體功能要點逐一查驗。

業務能力查驗則主要從監管功能和糧庫作業管理功能完備程度、靈活程度，尤其是糧庫業務的云化程度等方面檢驗。在現階段以“糧庫智能化升級改造”為主要抓手的信息化建設過程中，能否實現糧庫軟件的云化，能否在滿足糧庫個性需求的同時實現統一版本、統一部署、統一升級、統一運維，是判斷是否為“云模式”的關鍵。

此外，云模式并非一夜之間誕生的，國家推行云模式，除了其技術先進性，同時也是因為經過了一定的實踐檢驗。因此，云計算產品有沒有經過實踐檢驗、廠商有沒有通過行業認證（云廠商認證主要包括C-S T A R和I S O 2 7 0 0 1認證）、有沒有滿足指引技術要點的實際案例，也是區分云模式與“偽云模式”的重要參考。

怡和祥云（北京）科技有限公司