分布式|首发丨阿里云刘伟光：3.5万字拆解「核心系统转型」，核心从业者怎样寻得「出路」？(14)

云原生分布式核心中台化应用架构，可参考下图：

文章插图

2.强大、稳定的中台组件
每一个中台组件的设计，都承接自业务领域建模成果，具备丰富的业务功能。为确保中台组件集能支撑业务敏捷创新，中台组件应具备如下能力：

功能丰富：经过核心系统实际使用验证、具备能够支撑产品系统的必备业务功能；
迭代稳定：作为企业级能力共享组件，被大量产品系统复用，需要能够保持稳定、清晰的迭代升级路径；
非功能特性卓越：具备优秀的性能和可用性，为整个产品系统的性能和业务连续性提供保障。

3.3.2.2服务治理与组合
金融行业通常采用了分层、分域的IT架构，每一个层、每个域都提供了大量的服务。
架构转型的过程中，通过服务统一治理和运营，在技术层面支撑研发过程、确保安全生产运行；在业务层面通过金融业务中台提供服务复用能力，高效进行流程组装，支持业务敏捷、快速响应市场需求。
1.服务治理保障生产稳定运行
通过架构分层、能力域、系统、应用、服务等多级领域模型，全面梳理软件资产，建立服务目录，提升服务复用率；提供服务的全生命周期管理，覆盖事前、事中、事后环节，支持服务保鲜，建立服务反馈和优化闭环。
2.服务运营编排，支撑业务敏捷、快速创新
服务组合方面，通过业务中台提供的可复用原子金融服务使用可视化服务编排能力，实现低代码快速开发业务场景，缩减研发周期，提高产研效率，降低投产风险。
服务编排平台内置流程模型驱动业务开发，通过编排、执行两大核心能力取代研发过程中部分枯燥而重复的工作；同时，我们认为平台应该深度集成中间件，提供一个完整的金融级服务编排解决方案。服务编排能力大图如下：

分布式|首发丨阿里云刘伟光：3.5万字拆解「核心系统转型」，核心从业者怎样寻得「出路」？

文章插图

3.3.2.3异构应用集成
1.传统微服务、ServiceMesh和传统单体应用集成需求
在向云原生架构转型的过程中，传统单体应用也面临着迁移云原生分布式转型的挑战；同时，两种微服务架构（传统SDK微服务和Sidecar模式）并存已经是一个不可回避的现实问题。如何打通诸多异构应用系统，实现全面云原生分布式转型，需要有一套强大的技术支撑体系。
2. 基于服务网格(ServiceMesh)实现异构系统集成
在云原生架构下，服务网格可以轻松应对异构系统集成的问题。通过服务网格平台，提供与平台无关、语言无关、轻量无侵入的云原生架构集成与治理能力：兼容 Kubernetes和 Istio生态、支持传统SDK模式微服务框架的服务治理；支持物理机、虚拟机场景，兼容过渡阶段的容器化和虚拟化混合部署的场景，满足传统单体应用向Service Mesh转型的需求。
3.3.3应用系统建设
应用系统建设层提供标准化生产线，屏蔽复杂的云原生技术细节，规范云原生应用开发标准。
应用系统建设层面，应重点考虑以下几方面：

统一ISV（独立软件开发供应商）开发技术栈，避免技术管理失控，降低系统运行风险；
统一、易用的开发平台与框架，简化和规范化应用开发；
全流程覆盖的DevOps体系，涵盖需求结构化管理、代码版本与分支管理、质量管控与度量，自动化编译打包与部署等方方面面。

3.3.3.1统一开发体系
1.复杂的云原生技术细节和难以管理的ISV（独立软件开发供应商）多技术栈应用