微网站开发策划,移动端的优势,wordpress随机评论插件,音乐制作软件手机版简介#xff1a; 本文作者来自于中国人寿保险股份有限公司研发中心#xff0c;对企业数字化转型、云原生实践有比较资深的经验。以下内容整理自作者对最新出版的《阿里云云原生架构实践》的读后感。
作者#xff5c;肖晟
本文作者来自于中国人寿保险股份有限公司研发中…简介 本文作者来自于中国人寿保险股份有限公司研发中心对企业数字化转型、云原生实践有比较资深的经验。以下内容整理自作者对最新出版的《阿里云云原生架构实践》的读后感。
作者肖晟
本文作者来自于中国人寿保险股份有限公司研发中心对企业数字化转型、云原生实践有比较资深的经验。以下内容整理自作者对最新出版的《阿里云云原生架构实践》的读后感。
初心
作为金融行业的 IT 从业者参与着传统企业数字化转型进程我们一直在思考两个问题一是什么是数字化为什么要数字化二是如何推进数字化转型路径、工具、组织等方面该如何规划调整
大家常常会混淆信息化与数字化的概念以为上线了一些业务系统或是投放了一些数字大盘就完成了 IT 建设目标。但实际上这可能只是改变了一些信息数据向领导层流转的形式整个业务的工作模式并没有什么变化原来需要人工操作的依然需要人工操作该走的流程还得接着走甚至新建的系统还新增了一些流程效率没有明显变化企业的业绩是否有提升若有提升那与 IT 建设是否正相关性价比是否划算等等这些往往也缺乏有效的评价方式很容易陷入伪数字化的坑。
“ 任何架构都必须服务于企业战略云原生架构也不例外
企业必须清楚业务战略与云 IT 战略之间的关系即云IT战略只是对业务战略进行必要的技术支撑还是云 IT 战略本身也是业务战略的一部分。 ”
非常赞同《阿里云云原生架构实践》一书中提到的观点技术终归是服务于企业价值的。因此我们认为数字化是基于信息化的能力改进业务模式聚合全价值链上的各个环节和数据把着力点放在指导业务运营和决策上最终表现形式就是“全量全要素数据自动化实时化”的智能形态。
“ 数字化业务对技术架构的主要诉求是保证业务连续性、业务快速上线、业务成本控制以及科技赋能业务创新。 ”
为了让业务开发团队能够更快更稳的进行高质量交付以满足越来越快的业务需求“小前端、大中台/大后端”是必选之路。因为只有让前端更轻业务开发团队才能更聚焦业务交付也才能更敏捷而中台和后端做重一点高质量的设计与规范都沉淀其中其中的最佳实践复用度也就更高。
核心思想可以用一个词概括——“下沉”。
当我们把公共技术能力与方法下沉到开发框架、下沉到基础平台、下沉到自动化的规范流程中基于这些能力构建的应用就可以很敏捷了且生来就处于一个高质量的架构体系中正所谓赢在起跑线上而云原生架构是这种能力下沉落地的最佳实践方法论。
出发
“ 云原生架构是基于云原生技术的一组架构原则和设计模式的集合旨在帮助企业和开发人员充分利用云平台所提供的平台化能力和弹性资源能力。
云原生包括云原生技术、云原生产品、云原生架构以及构建现代化应用的开发理念。 ”
现代化应用和云原生应用是基于云原生的架构和开发理念构建或实现的如服务化原则、弹性原则等 7 大架构原则计算存储分离模式、事件驱动模式等 10 种架构模式以及 DevOps、GitOps 等研发理念。
云原生架构和云原生开发理念是基于云原生技术和产品构建或实现的包括容器技术、DevOps 技术、微服务、Service Mesh、Serverless、云原生大数据、云原生AI、云原生安全等十余项技术和产品。其中开放应用模型Open Application ModelOAM的概念让人耳目一新将 PaaS 中对资源的标准化声明拓展到对应用、配置的标准化声明“让简单的应用程序变得更简单让复杂的应用程序更易于管理”。
最后云原生产品和云原生技术又是需要基于公有云、私有云或混合云的云基础设施。云原生的组成就是如此层层递进的关系。
走过的路
“ 云原生架构升级是对企业的整个IT架构的彻底升级每个组织在进行云原生架构升级时必须根据企业自身的情况量体裁衣其中组织能力和技术栈处于同等重要的地位。 ” 在数字化转型的道路上传统企业的历史包袱着实不小在不能停业务的情况下进行架构改造无异于给飞行中的飞机换发动机、换操作流程乃至换机组人员。
笔者来自于中国人寿保险股份有限公司亲身经历过一个服务化技术升级的案例是不得已的情况下云原生技术给了我们新的答案。
IT 建设初期烟囱式系统林立随着系统越来越多系统间交互需求越来越大服务化需求被提上议程十多年前以总线型架构为代表 SOA 理念风靡各系统纷纷对接服务总线。但随着移动互联网的兴起服务压力逐年倍增总线型架构的瓶颈逐步显现了出来总线的一个抖动很容易造成各类服务的阻塞微服务架构的引入更加剧了这种现象。
此时服务注册发现模式已然成熟新建系统均采用 Spring Cloud 及类似产品来实施但既有系统却无法采用这种侵入性很强的方式来改造成本高、风险大而且多编程语言开始出现不同语言间要实现相同的服务治理也很困难。我们一筹莫展只能艰难的维护着服务总线尽量从架构层面提升它的健壮性。直到几年前听闻服务网格的概念准确说是非侵入式的 SideCar 模式我们意识到答案来了。目前我们正在全面网格化的进程中。
SideCar 模式本身并不是新鲜事但为何近些年又火起来了归根到底还是容器技术、DevOps 等云原生技术的成熟解决了海量 SideCar 运维成本与效率的问题。所以云原生技术本身也是讲究时机、相辅相成的而我们作为应用方则顺势而为“打破原稳态并构建新稳态”。
“ 此外云原生架构的设计还需要考虑组织结构的改变。前面提到一个非常重要的云原生架构原则就是服务化包括微服务、小服务等这个领域的一个典型原则就是康威定律要求企业的技术架构与沟通架构必须保持一致否则会导致畸形的服务化架构甚至导致组织沟通成本上升和“扯皮”现象增多的问题。 ” 任何方案的落地人都是第一要素。给新同事上技术课或是做架构分享的时候都会提到康威定律。产品的结构就是组织结构的缩影再大白话一些就是“屁股决定脑袋”。推行一些技术架构或管理流程组织架构都是绕不过去的坎在不对组织架构做重大调整的情况下我们选择的方案不一定是最理想的而是在当前组织架构下最合适的。
至于我们自身则需要时刻提醒自己跳出组织架构给我们划定的圈子从全流程、全场景、更高的层面来看待问题、思考方案。
自己的路
“ 但是有一点需要注意包括 AWS 、阿里云、微软等在内的云计算服务公司都没有完全按照这些软件架构标准来构建其云服务的软件架构体系。这完全不是出于偶然因为这些公司充分意识到基于云计算的软件架构应该是一种适用于非中心化组织的软件架构而不是传统的基于中心化组织的软件架构。所以传统的软件架构标准对于云原生架构而言需要进一步定制和裁剪才能更好地发挥价值。软件架构设计模式会有传统软件架构设计方法用到的利益关注点但是在具体设计方法上又有所不同。 ”
当然有了一张地图并不代表就不会迷路了。上至企业下至团队每个组织都有自己的痛点和诉求也有相应的文化和优势。在选对方向之后具体落地还得探索符合企业自身特色的道路这是需要不断实践和试错的。阿里 ACNA 架构设计方法及其成熟度模型评价体系可作为数字化转型中技术架构演进程度及效果的参考。 “ 企业的技术战略逐渐向业务架构及其治理方向转移”。随着 DevOps 的深化普及应用交付流程将会更加标准化。而云服务类型的增多也将催生新的开发模式和开发框架。 ” 最后还是想强调归回初心。技术服务于企业价值综合评估投资回报率最终实现帮助企业降本增效降低风险提升体验的效果。
原文链接
本文为阿里云原创内容未经允许不得转载。
