云泥之别：粮食云实质辨析

文/胡永光

云泥之别：粮食云实质辨析

文/胡永光

一、云计算落地粮食行业的背景

近年来，国家粮食局和全国各地区各单位积极探索以数字粮库为主要内容的粮食行业信息化建设，全国粮食行业提升了粮食收储企业运营效能，提高了政府宏观调控能力和粮食安全保障水平，为全面推进粮食行业信息化发展奠定了基础。但是，传统粮食行业信息化建设也存在发展不平衡、建设不规范、标准不统一、可复制性不强、与业务结合不紧密、投资效率不高、单项突进、互联互通不足以及重建设轻运维等问题。为解决信息化建设过程中出现的问题，国家粮食局适时发布了《国家粮食局关于规范粮食行业信息化建设的意见》，提出全国粮食信息化加强顶层设计、加大新技术创新应用，优先考虑大数据、云计算等技术手段的建设意见，并提出国家平台、省级平台两级架构的建设思路。

在有关粮食行业“十三五”规划文件中，再次强调了在粮食信息化建设中要将云计算、物联网等新一代信息技术与粮食业务深度融合、全面推进“互联网+粮食”的要求。

随着粮食信息化实践的深入，国家深入总结信息化建设先行省份的正反面经验，进一步确认“云模式”是解决一系列粮食信息化典型问题的钥匙。因此，国家粮食局于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认证）、有没有满足指引技术要点的实际案例，也是区分云模式与“伪云模式”的重要参考。

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