企业IT架构云平台实践内容
1、 IT架构转型背景
新基建和数字化现在已经上升到国家的战略层面，我们作为一家传统的大型国有机场集团化企业，更是航空市场变化和用户迫切需求倒逼进行数字化。下面这张图是我们企业的总体概要架构图：
很多传统企业没有自己的研发团队，IT 系统基本都依靠第三方供应商提供和服务支撑，而且大多是以传统项目制和采购产品的方式经过多年实施逐步形成的。
这是非常典型的传统集团企业 IT 架构，共分为四个业务域：
● 生产运行保障域：完成航班在本机场的正常起落保障。这也是集团的收益主要来源
● 办公管理域：完成全集团日常办公管理。
● 旅客服务域：完成旅客在机场出行全流程服务。
● 数据中心从以上 3 个业务领域获取数据，形成集团最核心的数据资产和服务目录。
四个域逻辑关系清晰，层次分明，职责明确。各域内部及域之间的系统采用传统中心化的企业服务总线ESB中间件进行交互，办公管理域和生产运行保障的数据通过接口方式沉淀到数据中心，进行主题划分和决策分析。那这种传统架构有什么问题呢？我们打开旅客服务域看看，如下图所示：
此架构中的各系统实施过程基本是甲方提出需求，乙方设计实施，甲方验收。这种模
式是由业务和职能单位提出自己的问题，然后确定方案，这些单位很难主动去考虑与其他
业务实体间的协同交互，这种组织架构形成了“部门墙”，数据和业务也是“烟囱式”的，
相互协作困难。
基础资源方面：
● 独立的组织，投资巨大
● 运维困难，资源浪费
● 重复建设，不可复用
应用系统方面：
● 上线慢，创新难
● 封闭多，变更难
● 信息孤岛，协调困难
各系统解决方案和技术标准完全依赖乙方，甲方无体系无标准，IT整体架构混乱，数据口径不一管控乏力，对每位旅客的真情服务，需要机场将所有服务触点串联起来。目前通过ESB企业服务总线对已有遗留系统的业务能力进行一定的集成，但本质上SOA架构为了遗留系统的交互对传统架构的补充，重点是集成，但是业务系统仍然是纵向独立构建，所以以上架构难为支持业务的发展，更别提技术引领和创新业务了。
2、IT架构技术路线
一家集团化的传统企业要数字化转型，这个问题极为复杂。单从技术角度看，需要用好大数据、云计算、人工智能、物联网等新兴技术，利用云计算的计算能力让大量在线的服务数据产生价值并持续优化或重构业务流程。
1、 SOA架构的核心思想是解耦，通过ESB企业服务总线对已有遗留系统的业务能力进行集成，再以服务方式进行接口能力开放。对传统系统的交互补充，系统仍然是纵向独立构建。
2、 微服务架构的核心是拆分，重点不是集成，而是识别共享能力进行集中化建设。侧重点在于传统业务系统里面涉及到的数据库，中间件，平台层技术组件和服务等全部都集中化到PaaS云平台进行建设。实现中间件资源池化。
3、 中台架构的核心是共享复用，侧重点在于业务和数据，业务中台的微服务并不是针对某一个业务系统的，所有的前台应用都可以复用，能力开放平台通过API网关实现。对于中台规划重点是如何找到共性业务能力，其次才是如何进行能力拆分进一步解耦。而对于微服务架构规划重点是传统遗留系统如何拆分和解耦，其次才是是否可以复用。因此两者的先后顺序有明显的差异。
4、 云原生架构的核心是IT系统开发只需要关注业务功能需求实现，而对于其它的IT基础设施，技术平台，消息缓存等各类技术服务等和业务无关的东西都不需要关心，由底层平台提供。serverless是云原生的高级实现。DevOps是衔接微服务和容器云关键桥梁，实现整个集成和容器部署过程自动化。
3、传统企业架构
整个IT架构的发展线路就是底层技术的逐步抽象，非业务功能一步步透明化，而对业务功能进行大拆小。
IT整体规划：平台+应用
≈（技术中台+业务中台+数据中台）+（业务场景应用+数据赋能应用）
统一技术开发运维平台
技术组件能力标准化和复用化，形成企业自有标准技术体系
统一业务模型
整合端到端业务链，实现业务能力组件化，组件能力服务化
数据天然集成
基于大数据技术，自动衔接全业务数据，全域整合数据服务赋能业务侧
业务系统将变化为一个个独立松耦合的业务能力组件，这些业务组件的组合和集成既为企业提供端到端业务的完整支撑能力，又能通过业务组件重新组装和编排来灵活适应业务流程和需求的变化
统一建设集团化信息基础设施，先大后小，以大带小，全面实现数字化
统筹规划、投入合理、不过度超前，可迭代、易升级、能兼容。
