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

文章插图

同时，技术重构由于涉及的方面太多，我们进一步的进行层次化的拆解与明确，定义了五层十二大能力体系，帮助金融机构进行相应的落地设计。

文章插图

企业自身可能不太具备这样的技术能力和相应匹配的团队，需要借助大量的外部资源与伙伴来完成整个理想中的蓝图。整体的价值，优势的可获得性相对比较低。我们建议在建设过程中配套匹配的工场，流水线，实施工艺等模式，降低整体的设计，开发，部署，运营，运维的难度。让这些先进的技术真正可以落地，可以自主的掌控。建议增加中间框架体系与流水线体系，进一步降低落地难度，增加技术的可获得性，让终端的开发、运维等技术人员更容易上手，更容易使用。

文章插图

4.2.2平行迁移模式
平迁模式实施的原则和前提是对业务不产生影响。业务流程不变、业务功能不变、应用处理逻辑不变、与外围系统接口不变以及数据逻辑模型不变。
在这种模式下，主要解决的是国家一些指引的要求，同时解决集中式架构的非功能层面带来的一些挑战，例如性能、扩展性这些阻碍业务发展和损害客户体验的障碍。但从助力业务发展的视角来看，平迁模式是一个过渡性的中间状态，从长远来说，最终还是要解决业务敏捷带来的挑战。
从目前行业目前的实践来看，目前具体有这么几种平行迁移形式
1）数据不动，应用下移
数据架构不动，应用按照一个一个模块进行下移和分布式改造，在过程中建立起全局的注册中心，基础微服务框架体系，同时引入分布式中间件相关技术来支持交易路由、交易熔断降级、安全中心、统一配置中心等功能。此外，为更好应对核心下移，运维体系需要相关改造完成相应日志监控、链路追踪和监控报警等功能。
这种模式的利：
数据体系和架构一般与业务和应用关联度比较高，尤其经过长期的运行之后，数据体系非常复杂，牵一发可能会动全身，回归测试等成本也会非常高。所以不动数据的模式相对比较简单，业务人员的参与程度非常低。基本上技术可控，在过程中锻炼了技术人员的分布式，云原生能力，锻炼了团队。
这种模式的弊端：
没有新的业务价值的过多体现，并且整体架构没有太多变更，转型不彻底，尤其是数据架构容易造成各种瓶颈，无论是对业务敏捷而言，还是性能角度而言。并且代码的自动化翻译工具等体系无法很好的应对领域建模等中台化要求，翻译代码需要大量的性能优化与调整，采取这种模式的开发人员通常需要花费70%的经历在代码的性能结构优化上，无暇应对新业务应用的开发。
2）应用不动，数据下移
为了灵活应对海量交易和超量数据的冲击，需要使用分布式数据技术来解决数据一致性问题。这种核心下移和分布式改造模式多辅以少量人工完成主机核心应用程序改造，或者自身已经在x86虚拟机等集中式架构下。通过接口改造与适配等来对接分布式数据库体系。这种模式对于底层的分布式，云原生数据库的技术要求非常高。
这种模式的利：
底层的交易瓶颈比较容易解除，并且实现了分布式情况下的最大挑战之一的数据一致性挑战。
这种模式的弊端：
对于分布式数据库的技术要求，成熟度要求太高，可供选择的供应商不太多。同时从业务角度而言，没有新的价值体现，也无法做到业务敏捷。
4.2.3 SaaS化批量模式