初心

作为金融行业的 IT 从业者，参与着传统企业数字化转型进程，我们一直在思考两个问题：一是什么是数字化，为什么要数字化？二是如何推进数字化转型，路径、工具、组织等方面该如何规划调整？

大家常常会混淆信息化与数字化的概念，以为上线了一些业务系统或是投放了一些数字大盘，就完成了 IT 建设目标。但实际上这可能只是改变了一些信息数据向领导层流转的形式，整个业务的工作模式并没有什么变化；原来需要人工操作的依然需要人工操作，该走的流程还得接着走（甚至新建的系统还新增了一些流程），效率没有明显变化；企业的业绩是否有提升，若有提升那与 IT 建设是否正相关，性价比是否划算等等，这些往往也缺乏有效的评价方式，很容易陷入伪数字化的坑。

“
任何架构都必须服务于企业战略，云原生架构也不例外！

企业必须清楚业务战略与云 IT 战略之间的关系，即云IT战略只是对业务战略进行必要的技术支撑，还是云 IT 战略本身也是业务战略的一部分。
”

非常赞同《阿里云云原生架构实践》一书中提到的观点，技术终归是服务于企业价值的。因此，我们认为，数字化是基于信息化的能力改进业务模式，聚合全价值链上的各个环节和数据，把着力点放在指导业务运营和决策上；最终表现形式，就是“全量全要素数据+自动化+实时化”的智能形态。

“
数字化业务对技术架构的主要诉求是保证业务连续性、业务快速上线、业务成本控制，以及科技赋能业务创新。
”

为了让业务开发团队能够更快更稳的进行高质量交付，以满足越来越快的业务需求，“小前端、大中台/大后端”是必选之路。因为只有让前端更轻，业务开发团队才能更聚焦业务，交付也才能更敏捷；而中台和后端做重一点，高质量的设计与规范都沉淀其中，其中的最佳实践复用度也就更高。

核心思想可以用一个词概括——“下沉”。

当我们把公共技术能力与方法下沉到开发框架、下沉到基础平台、下沉到自动化的规范流程中，基于这些能力构建的应用就可以很敏捷了，且生来就处于一个高质量的架构体系中（正所谓赢在起跑线上），而云原生架构是这种能力下沉落地的最佳实践方法论。

出发

“
云原生架构是基于云原生技术的一组架构原则和设计模式的集合，旨在帮助企业和开发人员充分利用云平台所提供的平台化能力和弹性资源能力。

云原生包括云原生技术、云原生产品、云原生架构以及构建现代化应用的开发理念。
”

现代化应用和云原生应用是基于云原生的架构和开发理念构建或实现的，如服务化原则、弹性原则等 7 大架构原则，计算存储分离模式、事件驱动模式等 10 种架构模式，以及 DevOps、GitOps 等研发理念。

云原生架构和云原生开发理念是基于云原生技术和产品构建或实现的，包括容器技术、DevOps 技术、微服务、Service Mesh、Serverless、云原生大数据、云原生AI、云原生安全等十余项技术和产品。其中，开放应用模型（Open Application Model，OAM）的概念让人耳目一新，将 PaaS 中对资源的标准化声明拓展到对应用、配置的标准化声明，“让简单的应用程序变得更简单，让复杂的应用程序更易于管理”。

最后，云原生产品和云原生技术又是需要基于公有云、私有云或混合云的云基础设施。云原生的组成，就是如此层层递进的关系。

走过的路

“
云原生架构升级是对企业的整个IT架构的彻底升级，每个组织在进行云原生架构升级时，必须根据企业自身的情况量体裁衣，其中，组织能力和技术栈处于同等重要的地位。
”
在数字化转型的道路上，传统企业的历史包袱着实不小，在不能停业务的情况下进行架构改造无异于给飞行中的飞机换发动机、换操作流程，乃至换机组人员。

笔者来自于中国人寿保险股份有限公司，亲身经历过一个服务化技术升级的案例，是不得已的情况下，云原生技术给了我们新的答案。

IT 建设初期，烟囱式系统林立；随着系统越来越多，系统间交互需求越来越大，服务化需求被提上议程，十多年前，以总线型架构为代表 SOA 理念风靡，各系统纷纷对接服务总线。但随着移动互联网的兴起，服务压力逐年倍增，总线型架构的瓶颈逐步显现了出来，总线的一个抖动很容易造成各类服务的阻塞，微服务架构的引入更加剧了这种现象。

此时，服务注册发现模式已然成熟，新建系统均采用 Spring Cloud 及类似产品来实施，但既有系统却无法采用这种侵入性很强的方式来改造，成本高、风险大；而且多编程语言开始出现，不同语言间要实现相同的服务治理也很困难。我们一筹莫展，只能艰难的维护着服务总线，尽量从架构层面提升它的健壮性。直到几年前听闻服务网格的概念，准确说是非侵入式的 SideCar 模式，我们意识到答案来了。目前，我们正在全面网格化的进程中。

SideCar 模式本身并不是新鲜事，但为何近些年又火起来了？归根到底，还是容器技术、DevOps 等云原生技术的成熟，解决了海量 SideCar 运维成本与效率的问题。所以，云原生技术本身也是讲究时机、相辅相成的，而我们作为应用方则顺势而为，“打破原稳态并构建新稳态”。

“
此外，云原生架构的设计还需要考虑组织结构的改变。前面提到一个非常重要的云原生架构原则就是服务化（包括微服务、小服务等），这个领域的一个典型原则就是康威定律，要求企业的技术架构与沟通架构必须保持一致，否则会导致畸形的服务化架构，甚至导致组织沟通成本上升和“扯皮”现象增多的问题。
”
任何方案的落地，人都是第一要素。给新同事上技术课或是做架构分享的时候，都会提到康威定律。产品的结构就是组织结构的缩影，再大白话一些就是“屁股决定脑袋”。推行一些技术架构或管理流程，组织架构都是绕不过去的坎；在不对组织架构做重大调整的情况下，我们选择的方案不一定是最理想的，而是在当前组织架构下最合适的。

至于我们自身，则需要时刻提醒自己，跳出组织架构给我们划定的圈子，从全流程、全场景、更高的层面来看待问题、思考方案。

自己的路

“
但是，有一点需要注意，包括 AWS 、阿里云、微软等在内的云计算服务公司，都没有完全按照这些软件架构标准来构建其云服务的软件架构体系。这完全不是出于偶然，因为这些公司充分意识到，基于云计算的软件架构应该是一种适用于非中心化组织的软件架构，而不是传统的基于中心化组织的软件架构。所以，传统的软件架构标准对于云原生架构而言，需要进一步定制和裁剪，才能更好地发挥价值。软件架构设计模式会有传统软件架构设计方法用到的利益关注点，但是在具体设计方法上又有所不同。
”

当然，有了一张地图，并不代表就不会迷路了。上至企业，下至团队，每个组织都有自己的痛点和诉求，也有相应的文化和优势。在选对方向之后，具体落地还得探索符合企业自身特色的道路，这是需要不断实践和试错的。阿里 ACNA 架构设计方法及其成熟度模型评价体系，可作为数字化转型中技术架构演进程度及效果的参考。