简介：本文作者来自于中国人寿保险股份有限公司研发核心，对企业数字化转型、云原生实际有比拟资深的教训。以下内容整顿自作者对最新出版的《阿里云云原生架构实际》的读后感。
作者|肖晟
本文作者来自于中国人寿保险股份有限公司研发核心，对企业数字化转型、云原生实际有比拟资深的教训。以下内容整顿自作者对最新出版的《阿里云云原生架构实际》的读后感。
初心
作为金融行业的 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 架构设计办法及其成熟度模型评估体系，可作为数字化转型中技术架构演进水平及成果的参考。
“
企业的技术策略逐步向业务架构及其治理方向转移”。随着 DevOps 的深入遍及，利用交付流程将会更加标准化。而云服务类型的增多也将催生新的开发模式和开发框架。
”
最初，还是想强调归回初心。技术服务于企业价值，综合评估投资回报率，最终实现帮忙企业降本增效，升高危险，晋升体验的成果。
原文链接
本文为阿里云原创内容，未经容许不得转载。