IT2.0业务中台规划牵引客户IT基础设施投资随想 （十六）：中台的独特技术要求

协同、共享、自助、感知模式下的中台需要哪些技术支持呢？

一提到技术支持，大家首先想到的一定是云化、服务化的技术平台或技术中台，如下图所示，这是一个标准的技术架构，足以用来说明构建服务中台所需要的各种技术能力，可问题也在于，就算我们只是构建一般传统应用而非中台，依然可以用这张图来说明其技术能力要求。接下来的问题在于，在下图所示的较通用的技术平台或技术中台中，有哪些独特的技术能力或技术服务是协同、共享、自助、感知模式下的中台特别需要的？或者说我们在构建中台的时候需要对传统的技术能力或服务做出何种改变？

按照上图通用技术架构的规划，协同、共享、自助、感知模式下的中台属于SaaS层前中后台规划的一部分，而PaaS层则用于构建技术平台能力并提供通用技术服务支撑SaaS层的构建，IaaS层则是通过基础设施能力共享满足计算、存储、网络资源需求。如下图所示，构建SaaS层的前中后台特别需要关注的技术能力或服务包括：

• 前台应用需要统一UI组件。前台APP是面向角色的，不是面向软件包的，因此迫切需要统一UI组件，通过以用户为中心的设计（UCD），实现基于用户交互场景的一致体验；
• 中台需要统一服务管理，满足服务市场和服务编排的应用需求。除了利用SOA或微服务组件来构建并管理数据应用服务外，还应该注意到服务管理本质上依然是个业务问题，如何将业务服务标准落实到服务的全生命周期，这才是中台服务管理和治理的核心技术诉求。要实现基于业务标准的协同服务、共享服务、自助服务、感知服务的管理和治理，微软等公司提出过Contract First Design的理念和方法，即基于契约的服务设计、实施和持续运营，以此来确保中台对业务服务标准的遵从。

SaaS层协同、共享、自助、感知的业务中台和数据中台需要调用PaaS层技术中台的统一、通用技术服务。有一个趋势，部分原本SaaS层的通用业务应用能力或服务，逐步下沉到PaaS层作为aPaaS（application PaaS）能力或服务，例如工作流引擎、数据视图管理、事务处理、用户和权限管理、邮件和SMS等。

Contract First Design，CFD是一个很朴素的设计理念和方法，既然中台是以服务为中心满足业务协同、共享、自助、感知的需求，那么中台业务应用服务的管理模式就应该与通用的业务服务管理模式一致（与GST的管理模式很类似），即基于契约的服务设计与运营管理。各类业务应用服务的技术实现，本质上是利用通信技术，把计算机里面承载的Bit资源，完整地共享出去，给应用系统瘦身，减少重复投资。这里的Bit资源，包括用于记录业务状态的Data和用于描述业务处理逻辑的Code，需要将Data和Code封装成消息Message再传输。服务供给和消费方要有明确的服务责任边界，并以契约化的方式约定好消息的标准格式。如下图所示，CFD的核心要素包括：

• 服务设计时：服务化设计ABC。
  1. Address：用于规范化、标准化业务应用服务提供方和消费方的服务节点地址。
  2. Binding：用于规范化、标准化消息传输的规范，例如需要遵循的通信协议。
  3. Contract：用于规范化、标准化消息的内容。
     1. 数据契约Data Contract：用于描述“数据”类型的消息，即定义共享数据的结构。
     2. 服务契约Service Contract：用于描述“对数据进行逻辑操作”类型的消息，例如信令的格式。

• 其它契约：Fault Contract用于描述“Fault”类型的消息；Message Contract用于直接定义消息的结构，例如消息头和消息体的格式。

• 服务运营时：
  1. 达成服务协议：服务的供给、消费方基于服务化设计的ABC达成数据应用服务协议。

履行服务协议：当服务消费方提出服务请求的时候，服务供给和消费双方都应按照约定来履行服务协议。

我们在服务化技术架构和方案中经常提到的RESTful、SOAP、RPC等都可以视为按照CFD理念和方法形成的不同的服务风格，而SOA、微服务则更多地属于不同的服务化软件架构。

中台业务应用服务完整的契约化设计和运营技术实现方案，可以参考下图，这也是华为云PaaS提供的API管理和治理的标准能力或服务。至此，我们终于有了一个完整的故事，能够回答客户“业务协同、共享、自助、感知的中台规划和建设，需要华为云平台的技术方案支撑”。

最后讲一点感想，任何的技术方案、产品都需要对准客户的业务需求和价值，客户不会为了服务化而服务化，也不会为了云化而云化。要正确回答云化、服务化技术革新的命题，还是需要深刻理解客户企业中台规划建设的愿景目标和价值，以及能够帮助客户解决的业务问题。