作者：汪照辉 王作敬

路上看到阿里进行架构大调整的消息，把阿里云事业群升级为阿里云智能事业群，将中台的智能化能力（包括机器智能的计算平台、算法能力、数据库、基础架构平台、调度平台等核心能力）和阿里云全面结合，构建数字经济时代面向全社会基于云计算的智能化技术基础设施。不得不说还是非常佩服马老师的眼光和魄力。当前数字化时代已经从单体-集成逐步走向平台-融合，说到底就是把基础设施资源、数据、平台和应用这些能够有效的融合，然后为企业内、外部提供业务和管理服务。
我们做了很多年的集成，EAI、Messaging、ESB、BPM、MDM等从应用、传输、系统、流程、数据都在做集成，但集成存在的问题始终无法解决，那就是根源上的单体系统架构，单体系统再怎么集成也无法从根上拔除，它始终是瓶颈。无论扩展性，或者数据的有效治理，或者对新业务应用的敏捷支持，都无法真正做到。集成也导致系统逻辑更复杂、数据更加冗余、运维难度增大、成本增加。技术思想的进步也使集成已经阶段性的完成了其历史使命，需要逐步从基础设施资源的融合走向平台融合，以支持业务应用的融合，同时实现数据的融合。

我们提出过利用云计算平台，使用微服务架构重构业务单体系统，逐步构建企业服务中台，支撑企业业务应用。这就是一个从单体集成阶段到平台融合的过程。云计算平台可以看作是基础平台，其包括基础设施资源如CPU、内存、存储、网络、以及操作系统资源等。应用部署托管运营在云计算平台上，由云计算平台提供相应的管理、治理、运维能力。数据则通过服务中台的数据服务统一提供，以实现数据的唯一可信来源，在数据流转过程中实现数据治理能力。

一、 平台和服务中台

很多人都在讨论数字化中台战略，我们在讨论平台，那平台是不是就是中台？我们认为平台和中台的概念还是不一样。首先，平台更多是从技术角度来说的，中台从业务角度来说更合适。其次，平台可能有很多个，比如容器平台、大数据平台、消息平台、算法平台等等（客户管理平台、财务平台等等是业务应用，不是一个意思），而服务中台一家企业一个足矣。通常服务中台需要基于基础设施平台来构建，在其上实现业务应用全生命周期过程和业务运营管理、治理的能力。所有这些能力构成一个大中台，包括基础设施资源、数据和平台。业务应用则托管、运营在这个平台之上，由中台服务能力来支撑。

二、 基础设施资源

基础设施资源这些年也都做了不少，虚拟化、资源池、超融合、多云管理等等。其实我们觉得企业服务中台战略最重要的就是资源整合。当然不只是基础设施资源，包括数据资源、业务资源、人力资源和系统资源等。资源整合的过程就是融合的过程，就是蜕变的过程。但基础设施资源是基础，所以我们在构建基础平台、基于什么样平台来构建服务中台的时候需要规划、考虑基础设施资源的问题。
云计算平台给我们提供了一个很好的选择。IaaS层以基础设施资源作为服务，PaaS提供了应用开发、应用托管和应用运维的能力，PaaS同时利用IaaS层的资源服务能力，将平台和基础设施资源松耦合。IaaS基础设施资源层为平台提供支持业务应用所需的各种资源。这就需要将物理服务器、虚拟机、各种存储资源、超融合资源、公有私有云平台、云盘（云存储）等资源进行整合，统一来进行管理和调度。
我们在DevOps探讨中也讨论过，把资源运维从系统运维中分离出来，资源运维只关注企业基础设施资源的运营维护，为平台或应用团队提供各种资源服务，确保基础设施资源的高可用和自服务能力，其实也就是云计算的思想。不过这样可以把企业的运维流程和人员职责明确化，更好的主动地实现数字化转型。

三、 数据

阿里数据中台的概念让很多人都更加认识到了数据融合的重要性。阿里的数据中台ONEID概念其实还是数据集成，这个可以理解，毕竟树大根深，分支众多，想彻底重构也不现实。
那么数据融合该怎么做？我们也一直在考虑这个问题。我们在微服务构建中强调过，关注数据的产生、来源、消费。业务数据在什么地方生成，都有哪些数据和关联方，这是需要重点关注的。数据来源渠道多种多样，数据格式多种多样，那消费数据的地方需要什么样的数据也是需要考虑的。这其中的gap就是我们需要关注的数据治理的方面。这也是我们一直考虑的在数据流转的过程中实现数据治理，在数据融合过程中减少额外单体系统的介入以实现数据的平滑融合，而不是再建一套数据治理平台。
说起数据，离不开数据标准、数据质量、数据安全、数据采集、数据转换、元数据、主数据等数据治理的内容。我们也一直在考虑是否有必要再建一套数据治理平台，或者一个数据湖。我们始终认为数据的价值在于怎么去使用它，而不在于怎么去存储它。所以我们希望数据能流转起来，持续的流转，最好不需要那么多数据存储；数据在产生的时候或者在采集的时候就已经是满足数据质量要求的数据，可以对这些数据直接处理，直接使用，在需要的时候同步做持久化备份。无论是数据仓库或者大数据平台或者其他存储系统，甚至多个来源渠道同步提供数据存取服务，只要能提供快速的满足存取延迟要求的能力，都没有问题。
数据治理的目的是什么？我们觉得并不在于是否有数据治理平台，是否有数据湖，是否有大数据平台或者数据仓库。数据治理只是一种手段，可能需要借助于相应的工具比如数据治理平台来实现数据治理，但目的是为业务应用提供唯一可信的数据源，消除数据的错误、不一致、缺失和冗余等。不是没有大数据平台就没法做大数据应用，没有数据治理平台就没法做数据治理，数据融合的目的就是要消除单体系统数据的概念，消除集成的概念，代之以统一的数据服务平台，或者叫数据中台，持久化的数据可能也是基于微服务的思想独立存储，比如客户数据、账户数据、积分数据、交易数据、视频数据、图片数据等，虽然存储的方式和地方不同，但数据是满足治理要求的，能够快速的根据业务需要实现数据的存取。这就要求数据在生成或者采集或者流转的过程中实现数据治理，而不是先存储起来再考虑集成和数据治理。这样我们需要构建的也只是一些数据治理服务，而不用构建一个独立的数据治理平台或数据湖。

四、 平台

融合平台利用基础设施资源和数据中台服务支撑业务应用。平台上提供各种服务，比如计算服务、算法服务、搜索服务等以及最基础的日志、监控、配置、权限、认证、调度等服务，重要的是业务相关的中台服务，比如客户服务、产品服务等，这才是构建业务应用的关键服务。平台上不再有系统的概念，代之以不同的业务应用，基于云计算多租户隔离机制，不同的业务运营团队独立运营、运维自己的业务应用。业务应用的构建是由平台上的中台服务来编排实现的。
在运维方面，平台运维独立于资源运维和应用运维，我们考虑平台上的基础组件服务和中间件服务等中台服务（搜索、日志、监控、注册、消息中间件服务等）都划分到平台运维范畴，但业务应用用到的业务组件服务（客户服务、产品服务等）划分到应用运维范畴，由应用运维人员来运维。
PaaS平台是用来构建服务中台的合适选择，轻量化的容器平台可以快速的实现服务中台的大部分能力，特别是弹性伸缩的能力。但容器技术还不够成熟，对基础设施资源的支持还无法满足需要，开源的技术到生产就绪还有很长的路要走，还需要时间逐步的完善。

五、 应用

平台融合阶段，逐步重构单体应用系统，业务应用研发团队专注于业务应用逻辑，不再考虑应用运营运维所需的资源和环境。各个业务应用团队在重构业务应用的过程中逐步的沉淀公共业务服务，共享业务服务，逐步地加速业务应用的构建和部署。沉淀的服务越多，越能快速的编排业务应用，快速的响应业务需求。业务应用研发团队也不再准备测试和生产环境，只是在需要的时候申请租户账户来部署运维自己的应用，在资源不足时自动扩展，实现弹性伸缩能力。这样极大的减轻了业务应用研发团队的工作量，也就极大的提升了效率，实现了敏捷。