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

某银行由于自研可控要求，只考虑了OA相关系统，核心系统不考虑。但是核心领域被卡脖子的问题依然存在，并且OA系统的自研可控成果对于核心领域而言，是无法借鉴的，这是完全两个不同领域的应用，架构完全不一样。导致未来核心应用转型仍然需要大量的探索和工作要做，总体支出会更大。
断言1：“从俭入奢易、从奢入俭难”。非核心领域的转型实践对于核心领域参考和借鉴意义有限，需要在核心领域架构体系上及早纳入自研可控等架构级别考量，避免2次迁移成本和时间成本。
误区2：追求技术架构完成解耦，碎片化供应商，不被绑定。某银行B在核心云原生分布式转型的过程中，对于核心技术平台要求能够完全的分层分模块解耦，例如在IaaS/PaaS/SaaS/核心数据库这些关键领域，在任何一层出现问题的时候都能够随时的切换到可替代的平台，不绑定任何一家技术平台供应商。但是实际上项目实施过程中IaaS/PaaS层适配虽然功能大体能够适配，但是在不同厂家的磨合方面，稳定性和性能等非功能性领域出现莫名其妙的问题，并且协调两家厂商的产品研发对接需要大量的沟通与适配成本。
断言2：“基础不牢、地动山摇”，底层架构的高效稳定是第一目标。底层架构在起步阶段从“统一架构”更加容易走稳，再逐步进行局部优化和解耦。
误区3：核心系统按照功能模块切分，再众包给不同的开发商来完成，避免被一家绑定。某银行C整个核心进行分布式改造的项目群极其庞大，平台技术部与各家核心应用开发商进行了充分的交流，然后选定各家较为擅长的领域来实施建设。这种众包方式的确没有绑定任何一家供应商，但带来的问题在日后实际核心下移开发中日渐突出。众包给众多核心应用开发商之后，由于开发商都只熟悉自己那一部分业务和技术框架，无法做到全局的架构管控和统一技术标准打通。例如：全链路跟踪与压测、业务染色、单元化、异地多活等。
断言3：核心架构中“非功能性需求”考虑要大于“功能性需求”。“非功功能性需求”应由技术架构来承载。业务模块可以解耦设计和分包，技术架构要统一规划和统一标准，实现核心领域的“统、分结合”。
误区4：业务应用是业务应用开发商的事情，技术平台是技术平台供应商的事情，两者没有关系。传统集中式环境下技术平台经过了经年累月的标准化以及适配，对于应用的普适性相对更强，所以应用开发不需要太多考虑底层架构的差异性，只需要当黑盒子来使用即可。但是在云原生架构时代，需要考虑分布式CAP原则的调整，适配与折中的设计。考虑分布式事务，分布式数据一致性，异地多活等难题对于业务模式，业务流程，业务底层数据模型的特殊影响与特殊设计，如热点账户，业务服务跟踪治理，全局业务序列号等专题。而这部分的专题设计，是传统上层应用与传统底层技术平台之间的灰色地带与结合带，它往往决定了整体系统的整体表现，尤其在极端情况下的非功能性表现。
断言4：传统集中式架构下的核心建设模式在云原生架构下大多数情况下并不适用，需要引入额外的框架、机制与设计来保障核心系统的整体表现。
误区5：选择应用平迁、不做架构大变化，更最简单和快捷。某银行D由于核心相关系统规模太大，应用数量众多，原来大量应用是在集中架构的封闭系统中，采用rpg，cobol等语言编写，行方为了想尽快将系统从封闭系统下移至开放平台，为了快速和简单起见，使用了一种并不成熟的代码翻译工具，将整个rpg语言翻译至java语言并部署在开放平台，底层使用分布式数据库承载数据。整体应用架构没有做太多的调整，基本上还是属于集中式架构的范畴。在后期的运行过程中发现较多的性能问题与可用性问题，以及集中式应用与分布式数据库的配合适配问题，只能让庞大的开发团队进行每个程序的代码的手工性能优化，导致开发力量80%以上的时间是在做代码的性能优化，根本无法承接新的功能或者业务的开发，拖累业务应用建设的整体进度。