写点什么

浅谈架构现状:设计越来越复杂,行业缺乏系统性思考

  • 2021 年 6 月 17 日
  • 本文字数:3472 字

    阅读完需:约 11 分钟

浅谈架构现状:设计越来越复杂,行业缺乏系统性思考

采访嘉宾 | 黄浩


从之前单纯的高流量到现在高流量、高并发,企业面对的业务场景越来越多,对系统的各项要求也越来越高,这意味着对系统架构的要求也越来越高。


在过去很长的时间里,集中式单体架构是主流。单体架构设计难度小、响应时间快,但系统吞吐量小、扩展性也比较差,在面对新的业务挑战时,显得力不从心。随着云计算的发展,高系统容量和高可用性的分布式架构越来越受欢迎。但越流行就越好吗?现在架构领域都面临着哪些问题?近日,InfoQ 采访了在分布式架构领域拥有二十年从业经验的阿里巴巴资深技术专家黄浩,来谈谈他所看到的架构现状和挑战。


新架构模式的技术局限


架构领域在经历了模块化编程、面向事件设计、面向接口设计等一系列发展后,1996 年,Garnter 提出了 SOA 概念,将应用程序的不同功能单元(称为服务)进行拆分,并通过这些服务将不同接口和协议联系起来。现在,SOA 已经被很少提及,大家提到最多的是往往微服务。


分布式架构系统使模块重用度更高,开发和发布速度变得更快。但新的架构模式在解决问题的同时,也会带来新的问题。分布式架构首先就面临着高复杂度的问题,这主要体现在以下三个方面:


l 协作模式。多台机器之间如何协作是非常重要的,选择主从模式、对等模式还是其他协作方式,直接决定了系统最后的运行效率。l 数据一致性。单体架构中,数据的存储、读取和计算等都在一处,处理起来很方便,但在分布式架构中,会有多处进行数据处理,那如何保证服务器间数据在同一时刻是一致的、客户端读取的都是最新结果?l 效率问题。限制效率的因素有很多,除了跨机房、跨地域的分布式架构自带的物理限制,还有节点规模越来越大而带来的沟通效率等问题。


为了解决上述问题,一开始企业采用了简单的主从结构协作模式,即设置一个中心节点来处理相应的事务,类似班级里班长的角色。但这种架构天生带有一种危险因素:中心依赖。中心节点对吞吐量要求很高,一旦挂掉系统就会处于“群龙无首”的状态。


随着进一步演化,这个“班长”不再固定,变成各节点动态“轮值”,类似企业 CEO 轮值,然后再通过层层分级的管理方式实现整体管控。


这里就要提到分布式系统中的 CAP 原理:一致性(Consisteny )、可用性(Availability)和分区容错性(Partition Tolerance ),这三者是无法同时满足的。比如,分区容错性能够解决集群分区问题,但网络故障导致分布式系统各组件之间产生分区,便无法同时满足一致性和可用性。


在典型的区块链分布式账本技术中,虽然强调不存在中心节点,但也有分区政策。比如一笔交易并不会让所有节点记录,达到一定比例即可被加到账本中。完全的分布式账本思路很优秀,但现实适用性还不够好。拿现在分布式账本上做得最好的比特币网络来说,因为系统采用了简单的存储和计算模型,在效率等方面就做出了牺牲。


回归到分布式架构,层层分级的管理方式虽然保证了一定的分布式理念,也避免了节点数量过多而使架构整体更加复杂,但却不是真正的“去中心化”。


互联网最核心的思想是去中心化,但全部去中心化是不现实的,所以弱中心化称为当前企业普遍采取的折中策略。哪些该集中,哪些该去中心化是企业需要思考的问题,但很少有人认真思考这个问题。



传统单体架构与分布式架构的对比,来源:陈皓《左耳听风》


分布式架构带来的数据可信和一致性问题,一直是困扰各企业的问题。据黄浩介绍,目前常见的方案主要是采用双保险策略,一个链路(RPC 或消息)进行数据正常的访问,而另一个链路(RPC 或消息)进行请求的重试或者稽核对比。。另外就是选出中心节点的方式,但问题还是前面提到的的偏中心化。当然现在也有些企业也将目光放到了区块链技术上,希望从分布式账本中得到启发。


“分布式架构的初衷是通过减少彼此联动来提升效率,但我们往往在架构设计上没有把应用架构和技术架构之间进行解耦,一个纵向上下牵连因为分布式横向的扩张,其实是将原本清楚的世界变得混沌,这也使得系统变得不可预测。”黄浩说道。


据观察,分布式架构面临的问题在发展之初就已存在,但经过多年发展,技术突破并不大。很多前几年就已经在讨论的问题至今仍在困扰着架构师们。


架构变得越来越复杂


虽然技术迎来重大突破需要时间,但企业发展不等人,该做的升级还是要做。从单体架构到分布式架构演进并不太难,但难的是如何在业务快速发展变化的情况下,及时升级架构。


去年,新泽西州政府急聘能够使用 COBOL 语言的程序员,帮助修复已经使用了 40 多年的失业保险系统,时薪 55 美元至 85 美元。COBOL 的鼎盛时期是在上世纪 70 年代,这意味着美国大部分 COBOL 程序员可能已超过 60 岁。同样在很多成熟科技企业内部,也还在使用很久之前的语言版本。这些遗留问题都会是架构升级中的障碍。


另外,固化的企业架构注定是难以改变的。以同样是电商的淘宝和拼多多来说,淘宝是面向商家,基于店铺体系,而拼多多更加面向商品,弱化了店铺、购物车等,这些都决定了两者的底层架构是完全不同的。定型的底层架构已经形成了自己的理念体系,牵一发而动全身,架构师要跨出这个体系做改变会很难。


黄浩建议,任何企业如果要做持续演进就需要事先做好架构强管控。越成熟的企业到后期越难进行架构升级,适当提前考虑未来几年的企业变化并为此做好准备是很有必要的。“比如现在蚂蚁的架构从 1.0 演进到 3.0,虽然现在并不知道 4.0 的架构会是怎样,但通过强管控,未来任何升级都有很强的可操作性。”


与此同时,很多架构的理念正在被误解和滥用。以分布式架构中常见的的分层架构模式,在很多应用的服务端开发时,会人为创建好几层的所谓接口和服务定义隔离层,然后每层都进行重复的对象复制,把一个应该内聚的问题变成松耦合。这样反而将原本简单的问题复杂化,开发实现实际上是非常低效的。


在黄浩看来,“这是一个很重要的问题,也是一个很普遍的现象。”


虽然整个行业并没有统一的标准,但每个架构应该有自己的标准。“加什么、不加什么应该有相应的规范,开发者不能随心所欲,架构师也需要被约束。”黄浩表示,现在互联网已经越做越复杂,企业在架构设计上更应该做的是减法。


黄浩根据自己的观察得出了一个观点,互联网的工程应用方式在未来的场景里会有越来越强的冲突感。比如现在微服务很受欢迎,但它在一定程度上其实是在破坏架构,碎片化的东西是没有架构可言的。


需要更多系统性思考


目前,国内企业在架构设计上存在一个很普遍的现象:一个业务一个架构,业务一换架构就要从零重新开始。


这主要是由于国内企业大多都是业务驱动型,包括现在头部的互联网企业,基本都是围绕业务来做技术应用输出。这种业务垂直的技术一旦环境改变就无法继续使用,企业有新业务时只能再花费人力、物力开发新架构。内部如此,对外更难将自己的技术沉淀形成技术模型输出,并被其他企业复用。


反观国外的一些企业,比如 IBM、Google、微软和 Oracle 就是典型的产品型企业,这些企业在一开始的定位就不是服务自己的业务,而是其他企业。他们的架构设计思路更偏向工程思维,不只考虑当下的业务场景,还会将整个行业面临的问题也囊括其中。


国外更擅长生产“一类产品”而非“一个产品”,虽然简单但可以被快速复用,天然具备了基础设施特质。


Amazon 的前员工 Steve Yegge 在早年间发文透露,2000 年初,亚马逊的目标就已经是要做一个可以输出基础能力的平台。在贝佐斯看来,产品并不能受每个人欢迎,但基础平台却可以被广泛应用。


这种思维差距导致了现在很多架构模式都是国外先创建然后国内再引进使用的现象,虽然国内有更丰富的应用场景。


在黄浩看来,根据实践总结出自己的业务模型和设计理念,这才是架构师应该具备的最核心的能力。但可惜的是,现在很多架构师都是在重复前人的经验,并没有对未来进行思考。


“分布式架构有很多问题需要时间来解决,但这个过程中,我们能否提出自己的创新思路和解决方案呢?”


黄浩指出,现在架构师普遍存在三个问题。首先是职责不清,业务架构、应用架构和技术架构三者其实并不相同,但很多架构师并不清楚自己在其中究竟扮演着什么角色;其次是一致性匹配问题,现在 PPT 上的架构图和现实应用的架构之间有很大的差异,架构师很难在两者之间建立联系。但最重要的还是缺乏系统性思考。


“国内很多分布式架构直接照搬国外,这样是不行的。架构师应该多观察、多思考、多分析和多探讨,从问题的解决者变成问题的分析者,最终成为问题的定义者。”黄浩表示。


架构领域有很多技术问题需要解决,需要更多的创新思维打破现状。架构师不是简单的执行者,更是企业蓝图的规划者,其实任重道远。


采访嘉宾:


黄浩,阿里巴巴资深技术专家,TOGAF 认证架构师,现任阿里巴巴数字供应链平台供应链技术负责人。


2021 年 6 月 17 日 07:004174

评论 2 条评论

发布
用户头像
用了40多年的COBOL系统,真的还挺稳的😄
2021 年 06 月 25 日 10:16
回复
用户头像
太虚了。说了和没说一样
2021 年 06 月 23 日 09:58
回复
没有更多了
发现更多内容

啃碎并发(三):Java线程上下文切换

猿灯塔

Scrum Master与Project Manager的区别

Mew151

Scrum

游戏夜读 | 关卡设计的难点

game1night

架构师训练营第五周作业

一剑

第 5 周作业:一致性 Hash 算法

姜 某某

作业

chenzt

架构师训练营——第5周学习总结

jiangnanage

第5周结构师训练营——作业

jiangnanage

Redis-进阶篇一

多选参数

数据库 redis redis高可用 redis6.0.0 Redis项目

kafka监听mysql实时数据变更

爱java爱自己

MySQL mysql事务

SpringBoot 中使用 Filter 的正确姿势

Java课代表

女同事问哪吒什么是 Spring 循环依赖?我...

通天哪吒

干货 | 如何评估Kubernetes持久化存储方案

焱融科技

Kubernetes 容器 云原生 k8s

第五周作业

Linuxer

极客大学架构师训练营

一致性hash的理解与实现

dongge

架构师训练营第五周作业

talen

计算机中短期学习路线

zack

架构师训练营 W5 作业

Kun

极客大学架构师训练营

你可能还不知道自己无知

小天同学

读书 智能时代 信息噪声 高考

Spring核心原理解析

Chank

Java spring

让Go“恐慌”的十种方法

博文视点Broadview

Go 语言

朱嘉明教授获2020杭州区块链国际周“特别致敬奖”

Geek_987812

CECBC 朱嘉明 区块链国际周 特别致敬

这份高考卷,只有程序员能得满分...

程序员生活志

程序员 高考

Ceph数据恢复初探

焱融科技

焱融科技 文件存储 分布式存储 数据恢复 Ceph

架构师训练营第5周

大丁💸💵💴💶🚀🐟

一口气说出 OAuth2.0 的四种授权方式

程序员内点事

Java oauth2.0

国内首本CTF赛事技术解析书籍,五年之约,兑现了!

华章IT

网络安全 Web CTF Reverse PWN

分布式缓存总结

罗亮

很多人毕业多年以后,还是改不掉学生思维

小智

职场 思维方式 高考

计算机操作系统基础(十四)---线程同步之条件变量

书旅

php laravel 操作系统 进程 线程’

话题讨论|作为一名程序员,你下班之后都会做些什么?

InfoQ写作平台官方

写作平台 话题讨论 话题

浅谈架构现状:设计越来越复杂,行业缺乏系统性思考-InfoQ