写点什么

一个架构师在 2023 年需要掌握哪些“必杀技”?

  • 2023-01-18
    北京
  • 本文字数:9052 字

    阅读完需:约 30 分钟

一个架构师在2023年需要掌握哪些“必杀技”?

2022 年,架构领域发生了哪些值得关注的事情?一位架构师必备哪些技能?哪些架构趋势需要掌握?1 月 6 日晚 8 点,Nacos 和 MSE 创始人、阿里云高级技术专家彦林彦林为我们带来 2023 年的架构师发展指南。以下根据直播内容整理,有不改变原意的删减,完整内容可点击查看完整回放视频。

 

主持人:今天的主题是 2022 年架构发展的亮点,以及架构师成长的路径。我们请到了老朋友彦林老师,先请彦老师来给大家打招呼。

 

彦林:我是来自阿里云的彦林,很荣幸有机会跟大家一起聊聊今年架构的一些趋势。我从事软件开发 10 多年,然后赶上了在阿里做百万实例架构的演进,包括最近 3 年帮助阿里云从自建 IDC 全部搬到了公有云。我也有幸参与到阿里巴巴内部的中间件产品的开源,然后通过开源做技术影响力,也因此和我们 InfoQ 的小伙伴结缘,和更多的开发者结缘。随着开源的影响力越做越大,我们也把开源的一些技术解决方案,使用产品化的模式,通过阿里云去做输出。

 

目前我主要在阿里云负责微服务产品相关的开发工作,希望后面有更多机会交流。今天晚上主要跟大家聊一聊技术架构的一些趋势。

详解架构技术发展

 

主持人:彦林老师先带我们回顾下,今年架构领域都有哪些比较重要的进展和亮点?

 

彦林:我在阿里云每天见非常多的客户,经常跟客户聊架构选型相关的事情,今天以我的视角带大家做一个简单的回顾。一般找我们聊架构,大家都会讲到不同类型的架构,比如单体架构、微服务架构、Serverless 架构以及低代码等等,在不同的场景怎么去选型?哪些场景适合哪些领域?现在每个领域的业务成熟度是什么情况?

 

面对这几个问题,我们会简单进行分解。首先,单体架构现在基本已经成熟了,各个语言包括 Java、Golang 做单体开发都比较成熟。所以在过去一年 Java 做了一些变化,为了更好地适应云原生,它会通过 GraalVM 技术、Spring 3.0 等关键大版本的发布,让 Java 变得更轻量、启动速度更快。其他的语言比如 Go,天然就是云原生的语言,所以它在做单体分布式开发的时候,整个启动速度都比较快,相对会比较成熟一些。

 

第二,微服务。微服务整个领域在过去一年还是发生一些变化。在最早的时候,大多数都是一些互联网大厂在使用微服务,但是去年看到各行各业开始更加深入地去使用微服务。因为疫情虽然给大家带来了一些痛苦,但也给整个数字化的进程带来了一些助力,包括数字化系统的迭代在变快、复杂度在变高,因此微服务在加速渗透到各行各业。在微服务架构的选型过程中我们也可以看到,由于 Spring Cloud 现在成熟度已经比较高、Spring Boot 3.0 最新的架构再往前演进,Java 在解决云原生应用的一些启动速度和加载速度问题。

 

我们还看到另外一个非常有意思的现象:大家都在往 Go 语言发力。微服务在 Go 语言的整个发展趋势在变快,也标志着今天 Go 语言在做微服务分布式开发方面,进入了一个爆发阶段。

 

互联网最早以阿里为代表的一些做交易系统的厂商采用 Java 较多,但是随着传统厂商慢慢进入数字化演进过程,他们就从 C++、 PHP 开始向 Go 转型,而且转得速度在变快,包括阿里微服务在这方面也做了一些布局,这是今天后端开发方面的一些变化。

 

在前端,Node.JS 现在也越来越成熟。一般在架构简单的时候,可能采用前端网关直接挂后端应用的方式。随着客户规模变大,就会用 Node.JS 做一代理层,这样有利于前后端的分离,让前端的整个迭代速度更快。在阿里内部分中台、后台、前台分三层,后台应用需要的是稳定性,中台需要的是支撑效率可复用性,前台需要的是业务要跑得足够快,这方面微服务也比较成熟了。

 

最后讲两个技术趋势。

 

第一,Serverless。2022 年可以被认为是整个 Serverless 的元年,阿里云在 2022 年 11 月份的云栖大会上,阿里云总裁发布 Serverless 的战略,提供了一系列 Serverless 的产品,从整个计算、存储、网络,到上层的 FC 产品,一直到数据库的 Serverless,演进速度都在持续加快,相信在 2023 年速度会更快。

 

在 Serverless 架构方向引导之下,我们可以看到事件驱动也在慢慢变成主流。一个个函数之间通过事件驱动模式进行解耦,架构的容错率会非常好。在云厂商推动下,我们可以看到一些新兴的中小型业务、偏前台的业务,包括计算性的任务,都大规模采用了 Serverless 的架构。

 

第二,低代码。低代码现在每年的增长速度有 40%,速度很快。阿里最早推出的一些产品叫宜搭,基于行业性的解决方案,它有行业属性、业务属性,现在也比较成熟。

 

从技术上来说,低代码是一个趋势。举例来说,它会通过一些图形化的拖拖拽拽,将模块进行组装,对于业务比较简单的场景,开发效率还是比较高的。低代码和无代码这种拼装的模式,可以让更多的人参与设计数字化的建设过程。阿里在微服务上也做了一些事情,比如开源了一个云原生应用脚手架(https://start.aliyun.com/),能够帮助开发者快速地勾勾拽拽,把一个依赖包快速组建起来,这也是低代码的一种模式。

 

相信随着整个技术基础架构中间件稳定成熟之后,在 IaaS、PaaS 之上,基于更高层的低代码会成为未来的趋势。从业务方面说,各个行业的 SaaS 会成为一个趋势。

 

社区:多长时间重构一次?

 

彦林:重构不是按照时间决定的。重构的第一个原因是迭代效率变低了,比如代码的研发效率越来越低,严重阻碍了它的迭代速度。第二个原因是稳定性,比如开发者修改一 Bug 引出了多个新 Bug,代码变得很复杂了。第三个原因是扩展性不足,性能无法满足要求,比如做大型运营活动时,单体无法满足需求,企业就需要做一些分布式的改造,把主链路和分支链路分开,做更好的扩展性和弹性。

 

微服务:真的被滥用了?

 

主持人:您在去年的分享中谈到,微服务每年有差不多 20% 以上的增长。今年,微服务的增长趋势如何?

 

彦林:从三方报告、阿里、官网以及 Star 上的数字来看,今年的增长速度是 15%左右,比去年同比增长速度稍微慢了一点点,和疫情有很大的关系,但其实绝对数字差不多。在中国,每年采用微服务架构的有几十万家企业,虽然增速变慢了,但是每年采用微服务架构的绝对数字依然非常大。另外,整个技术的热度也在持续加强。

 

主持人:今年有一个争议点,马斯克接手推特之后,吐槽过推特的微服务架构,说运行要调用 1200 多个 RPC,但其实真正需要的微服务不到 20%。其实像 GitHub 前 CTO 也提到过微服务滥用的问题。这就会引发大家一个思考,今年的微服务真的在被滥用吗,您怎么看?

 

彦林:从我们的角度看,无论是微服务还是单体应用,都是一个技术选型。随着业务公司的发展、需求的不断增多,业务变得更复杂,我认为更多是管理和产品的问题,不是技术的问题,我们要把技术和业务分开。

 

“什么时候采用微服务”是技术人要回答的,比如企业只有一个业务系统,其实是不需要上微服务的。那一个公司几十号人、几十个子系统,还要单体应用吗?效率能解决吗?架构其实是一个拆分,服务规模大了后架构师在做架构的时候,就会向两个方向去解决业务的复杂性问题。针对有几十个研发同学、几十个子系统的情况,就需要做一些分支,这个时候用微服务的投入产出比会比较高。单体到微服务有一个交叉的技术曲线,可能是 10 个应用、10 个子系统,达到拐点之后采用微服务确实效率比较高。但在没有达到拐点时,提前采用微服务可能会发现一些问题,随着业务规模增大,微服务后面才可以慢慢释放红利,这是一个技术选择问题。

 

总的来说,没有最好的,只有最合适的,当系统的复杂度达到 10 个研发、10 个子系统以上,可能就适合用微服务了;当达到 100 个研发、100 个子系统以上,可能就要把公共服务抽成一些中台服务去做,这是架构师基本的服务化、分层设计理念。用这样的理念设计后,我们的组织架构也随着技术架构去调整,让业务尽可能跑得快。

 

社区:传统项目准备使用微服务,在转型时主要从几方面去转?

 

彦林:互联网的第一波,包括云的第一波、数字化的第一波已经过去了,第二波就是传统客户包括政企。大部分客户会问,CTO 应该怎么决策?最佳的解决方案是:第一,新老架构前面都加一层网关,用网关将老的服务路由到老的单体架构上面,新的架构采用微服务,让新的业务先跑到新的架构上,老的架构慢慢往前演进,这是一个长期的过程。

 

第二,新老架构之间也可以通过网关进行代理。有许多厂商向传统公司提供服务,多个服务之间怎么进行快速组装、相互调用健全,怎么组装更高级、更丰富的上层服务?都是通过网关快速做 API 的聚合与整理等,这都是这些传统企业的诉求。通过网关可以把新老系统、多个 ISV 系统全部互联互通,这是做现代化架构演进或者云原生架构演进最快的模式,让新的架构、新的模式讲清价值、慢慢迭代,把老的架构进行收敛。这就是我们现在看到最好的一种模式。

 

主持人:马斯克说推特在一些国外地区会比在美国的运营速度要慢很多,产生速度差异的原因是什么?

 

彦林:从理论上来说大家应该都是一样的,但是当组织离核心业务、权力机构远的时候,很多的组织效能会做一些弱化的事情。我认为更多的是组织的问题,技术的问题并不大。马斯克只是说了一个现象,被一些人拿出来做新闻热点炒作而已。

 

其实我们也能感觉到,技术和产品有时候有一些博弈,产品总想让技术多做需求,但是需求越多系统就越复杂,随之依赖越多、链路越长,风险也就越大。

 

阿里巴巴在 2012 年左右的时候,链路也很长、很复杂,所以我们当时抓体验,比如做一秒钟战役,即所有的请求要在一秒钟之内做完。为此,架构做了很多改变,比如分布式架构分为核心链路和非核心链路,核心链路我们用 RPC 微服务同步解决,非核心业务通过异步发消息去解决、通过事件去解决。这样做稳定性、扩展性会有大幅提升。

 

社区:微服务的注册中心跟 K8S 云原生是不是有些冲突?

 

彦林:这个问题非常专业。其实没有冲突的,有一些交集。 因为容器和微服务是正交关系。注册中心是微服务的存储,etcd 是 K8S 的存储,是分层的。 

 

云原生架构:容器和微服务搭配提效

 

主持人:云原生架构的技术体系是怎样构成的,怎样才算是云原生架构?

 

彦林:最早提出云原生概念的是一家小公司,他们以 Spring Cloud 为理念去宣传了云原生技术。在之后 3-5 年的发展过程中,CNCF 重新定义了云原生,大家有了主流的认知,即采用了容器、微服务和不可变基础设施这些关键技术栈的,我们就认为是一个云原生架构。

 

在做架构演进和变化的过程中,为什么采用云原生架构?云的本质是弹性,每个公司都有低峰和高峰,怎么更好地利用云的弹性、让自己的资源成本和研发效率得到进一步提升才是本质问题。云原生架构比如微服务,解决的核心问题是研发效率问题,因为业务规模上去,复杂度提升,所以需要微服务这样解耦的方式去解决研发效率问题。容器解决的是运维效率,它可以让运维效率得到空前释放,使运维从体力活变成了技术活。

 

容器和微服务搭配使用的原因在于:第一,一个巨大的单体应用没有调度空间,只有把资源打碎、拆分之后,才可以充分使用资源池,即业务拆分合理之后,能够让开发者更好地调度、提高资金利用率,这是微服务对容器的一个好处;第二,使用微服务后,运维可能会从早期的 1 人运维变成 10 人运维,成本会上升。而容器能帮助微服务解决运维的问题,让每个开发有工具自己写代码自己运维,把整个生命周期管理起来。因此,容器帮助微服务解决了最核心的运维痛点。

 

总的来说,容器和微服务做搭配,一个解决运维效率,一个解决研发效率。容器帮助微服务解决了最大的运维痛点;微服务把资源打碎,让容器充分地进行资源调度,提高整个资源利用率,所以它们是相辅相成的技术。

 

社区:云原生网关很热,能展开聊下选型么?

 

彦林:传统的网关在云原生时代确实遇到了一些挑战,这些挑战在于传统的网关包括最早的单体架构,在不用容器的时候,它的调度和发布都不频繁,因此发布过程中有一些流量的损失问题,但也不大;老的业务,不是端到端的业务、视频的业务,对稳定性要求也不是特别高。

 

但随着数字化深入,云原生技术的采用就会引发一些问题。第一,对整个连接的稳定性、规则热更新有实时的要求,对网络稳定性的要求会更高。第二,云原生背后隐藏了一个标准化的事情。在云原生时代,未来的网关的 API 标准到底是什么?其实 K8S 通过 Ingress 的 API 定义了网关的标准,这就解决了技术选型的一个痛点。第三,多语言的扩展性。传统的网关在语言扩展性以及热更新上有很大区别,所以面对未来的云原生网关,必须解决掉这些问题。

 

我们认为云原生网关可能是代表下一代网关的技术,不仅阿里巴巴开源 Higress 进入这个领域,CNCF、APISIX 等等都在加速这个过程的发生,如雨后春笋般地进入云原生网关领域。大家也意识到今天在微服务里,网关是非常重要的角色。云原生网关已经形成了一个技术热点,相信在 2023 年会得到高速发展。

 

社区:IaaS、PaaS 和 SaaS 的商业模式哪个更好?

 

彦林:当前来看,IaaS 是技术门槛最高、投入产出比最高模式,需要规模化;PaaS 是技术门槛居中、投入产出比中等模式,需要可复制、解决服务效率问题; SaaS 目前核心是看业务领域创新,如果能搞出钉钉类似的 SaaS 平台,价值是巨大的。未来机会在 SaaS。 

 

“降本增效”对架构有影响吗?

 

主持人:今年各大厂奉行的宗旨是降本增效,这种内部政策导向的变化会对企业在架构选择上产生什么影响吗?

 

彦林:其实有影响,包括正向和负向的。如果一个企业真的运营不下去了就不会再为未来投资,如果要投资未来,技术架构就要演进,公司基本上都是要降本增效。采用云原生架构之后,复杂性略有上升,但是多家数据也表明成本至少下降 30%。因为容器解决了成本效率、运维效率的问题,微服务解决了研发效率问题。

 

但是最近我在想一个事情,云不断地把算力成本降下来了,但是人力成本却一直在提升。很多人可能在关心资源成本,但其实大部分公司现在应该更关心研发效率、研发成本,因为人力成本在不断提升,算力成本在不断下降,杠杆的拐点已经到来了,这就是为什么越来越多的人采用微服务的原因。首先,云原生架构能降本,这是一个事实;第二,提升人的效率其实也就是降低人力成本。

 

主持人:云原生虽然降低了成本,但是却提高了复杂度,我们应该怎么去平衡?

 

彦林:这其实很简单。我们要相信后浪能推倒前浪,现在的新人很多都对云原生有了解,一些培训班也在基于云未来做软件开发,新人的学习能力和知识储备都是够的。而对于我们这些老程序员来说,不跟上时代确实会有压力。技术虽然有门槛,但是通过 2-3 个月的学习,突破技术门槛和拐点之后,就能柳暗花明,充分利用工具的优势。

 

当然,比如在组织做一些变革和技术架构升级时,一定会有很多人阻碍你,因为大家都喜欢不变。但是不变不能带来任何变化,为了做降本增效、技术架构先进性就必须要变,而在变的过程中自然有一些人会感到不适,但这都是短暂的,当你迈过拐点、享受到红利之后,就自然而然地会加入到推动技术浪潮的过程中。

 

社区:性能上升了,对于复杂业务,Go 相比 Java 开发维护效率会下降吗?

 

彦林:会有一些代价,Go 偏系统一些,Java 偏业务一些。根据不同分层选择合适的。

 

架构下一年发展趋势

 

主持人:下一年架构领域可能会有什么趋势?

 

彦林:在微服务领域也会发生很大的变化。比如大家可能觉得微服务很先进,云原生现在虽然讲得很火,一些掌握先进技术的大公司、掌握话语权的人在使用,但今年全世界的采用率可能也就 5%左右,普及度远远不够,这是一个现状。

 

标准化上,我们可以看到云从 IaaS 到 PaaS,再到容器(当时定义为 CaaS Container as a Service)、微服务都在做这件事。海外也有一些公司比如 Google,也想通过服务网格去定义微服务的标准,但目前大家得到的一致结论是,它不是未来的标准,未来微服务的标准还在定义的过程中。

 

整个行业在一起定义下一代的微服务体系。相信在 2023 年,下一代微服务的雏形和标准化会慢慢开始呈现。我认为 2023 年不仅是 Serverless 的元年,也可能是下一代微服务到来的前夕。

 

另外说到云原生网关,其实云原生网关是阿里巴巴在 2022 年提出的,也快速得到了行业上下游的响应,因为相对于传统的流量网关、微服务网关、API 网关,云原生网关定义了一个新的领域,是一个新的、云时代定义的下代网关雏形。

 

其实阿里在 2018 年就有了云原生网关的雏形,我们经过 3 年的打磨才有的一个雏形。阿里做网关做了十几年,云原生网关领域也做了 3、4 年,基于之前的积累,我们才去尝试定义云原生网关领域,帮助传统企业在云原生时代做架构的演进,也帮助现在上微服务及云原生架构的客户更好地享受云原生的红利。我相信在微服务领域,统一控制面、标准化和云原生网关会得到空前的发展。

 

另外,Serverless 目前是阿里云的战略级项目,今天它的标杆和可复制的场景已经非常大了。所以,事件驱动加上 Serverless 的架构,会在未来一年得到非常好的发展。

 

编程语言上,目前来看 Go 语言真的挺有希望。我们拜访很多大客户,Golang CPU 的利用率能比企业 Java 高一倍,这个数字还是比较可观的。Go 语言作为微服务或者云原生的一个主导语言,未来会得到很好的发展。

 

社区:微服务和 Serverless 会有冲突吗?

 

彦林:单体应用、微服务和 Serverless 其实不是互斥关系,它们都有各自的场景。对于微服务,单体应用是相对通用的一个技术架构,目前得到了行业的广泛认识,只是说有一个拐点决定了哪个时候采用它最好。Serverless 是一个架构选型,它是一个新技术,有它的适用场景。比如偏前端、简单一点的比如小程序,偏计算性的任务适合跑 Serverless;对一些大型的比如阿里巴巴大型交易系统 Serverless 是不适用的。所以这些技术有各自的适用场景,存在互补关系,而不是互斥关系。

 

职业成长

 

主持人:架构师这个职业具体是做什么的?

 

彦林:在互联网中,虽然我们也叫技术专家,但实际上是架构师。举例来说,有人盖房、有人设计图纸,架构师是设计图纸的,对于一家网站来说是设计网站骨骼架构的。做架构师要有设计架构的能力、画图的能力,比其他所有技术实践的人要先行一步。

 

主持人:有观点是架构师关注技术的广度比深度更重要,您如何看待这种说法?

 

彦林:从整个学习习惯或规律上来看,一般都是先有深度再有广度。只要深入地把一个技术、一个语言、一个架构吃透,做其他的很多事情都会触类旁通。如果做任何事情都蜻蜓点水,就很难把一个事情做深。我建议工作的前三年一定要把技术的基础先打牢,这对架构师的成长会比较好。在早期可能 80%是深度、20%是广度,随着技术成长足够了,这个比例再不断去调整。另外,对技术的热情也一定要有。

 

主持人:架构师是一个长期主义的事情,不可能在 1-2 年就完成一个蜕变。

 

彦林:是的。架构师是站在开发、产品、运营、技术等等最前面的人,对人的综合素质要求比较高,一般在阿里内部架构师的是点线面体的发展规律。

 

第一,最早进入这个领域之时,最基本的要求先是“见问题解问题”,掌握一门好的语言,能修复 Bug,但是到后面大家的发展方向、成长速度会不一样。

 

第二,从点到线。这对开发的抽象能力是一种考验。当每天面对很多问题的时候,能不能把问题抽象成需求,横向拉通所有问题做一层抽象?

 

第三,从线到面。比如把所有的需求聚集成了 10 个需求,要再从整个产品角度,把需求砍下 4-5 个,要知道做什么不做什么,有产品视角。

 

第四,从面到体。当技术问题解决完之后,要考虑哪个投入产出比是比较高的,怎么拉通研发团队的前端、后端、产品、技术、运营,做一个很好的技术排期,最快拿到技术结果。这里就涉及到人的协同与沟通,但并不是说沟通能力好就能当架构师,还要懂得画图纸。其实还是要以产品为核心去和上下游沟通,因为用技术语言无法和运营、产品对话,也无法和客户去对话,至少要能抽象到产品,用产品的语言才能和客户对话。

 

走到“体”这一步后,解决技术、产品、协同以及人等问题的能力基本上会得到一个全面的提升,至少需要 5 年的积累。所以大家不要急,一步一个脚印往前走,只要你有这样的技术情怀和追求,一定可以搞定。

 

我认为有技术情怀的人才能当架构师,因为我发现很多人随着工作时间增多,慢慢地淡化技术变成了管理者,变成了 PM,这就会有问题。因为如果你画的图纸不合理,最主营的技术业务不行,就会把所有的人拖下水,这就很危险。

 

社区:架构方面,质量工程师能做什么?如何搭建好 IT 系统的业务架构?

 

彦林:一般只有大厂有质量工程师角色,核心协同开发、测试、安全做好产品或者版本质量,宣传质量文化。

 

社区:为什么绝大多数架构师都是后端?

 

彦林:因为后端技术架构更复杂,能更全局的技术架构。

 

社区:一定要很强的编码能力之后才能当架构师吗?

 

彦林:不一定很强, 但是需要有一定的技术积累,不然比较难与程序员对话。

 

社区:架构师平时怎么积累相关领域最前瞻性的一些技术?

 

彦林:积累深度可以看一些 paper、专利行业的动向,这在子领域里会有很多上下游的竞对、海外竞对的分析;积累广度可以看 InfoQ 以及海外架构师等最顶级的技术媒体信息,也可以看大厂分享的公众号,因为大厂有很多场景,并会根据它的场景做很多技术分享。

 

之后大家也可以去逛一逛线下的技术 Meetup 以及行业的论坛、分享会等等,参与开源共建,相当于跟全世界一流的工程师一起工作。在和别人沟通的过程中,也能了解到好的技术以及别人在思考哪些事情,这也是学习技术先进性、前瞻性的一个很好的模式。在参加各种论坛、与开发者相互碰撞的过程中,可以很好地帮助你进行架构规划。比如和大厂的人沟通,你可以了解他们怎么一步步走过来的,还可以根据自己公司的发展情况一步步向前演进。如果你已经在大厂,就可以深入想一些比如如何代表中国的技术,在今天的开源、技术影响力、先进性工具上,给世界做一些贡献,打造一些世界性的产品等问题。

 

主持人:如何理解 Serverless、低代码等对架构的影响,它们会降低对架构师的要求吗?

 

彦林:我认为是不会的。现在有 10 种技术选型,最早大家写代码的时候有 20 种设计模式,你只有充分掌握哪个工具适合哪种场景,才能画出最好的图纸、做出最适合的架构,只不过早期没有这些技术和工具时,做架构需要更多的思考。而今天在市面上有很多主流选择,在选择过程中,如何根据自己的业务选择最好的架构和技术,这对架构师是一个考验。

 

另外,很多人做技术架构师、业务架构师,要对业务很熟悉。微服务的主要挑战不是技术有多难,而是你的业务拆分是否合理。很多人做了微服务之后拆分不合理,就会导致代价变大。所以,对领域模型要有更好地了解,有架构师底蕴,理解业务模型、技术模型,这样的人才能做好一个架构师。

 

如果你对本文感兴趣,欢迎在文末留言,或加入 InfoQ 写作平台话题讨论。后续,迷你书、专题将集合发布于 InfoQ 官网,登录InfoQ 官网注册并将 InfoQ 添加进收藏夹,精彩不错过。更多内容可点击查看系列专题文章

 

2023-01-18 14:509478

评论 1 条评论

发布
用户头像
私有云的云原生价值体现跟公有云不同,如何衡量?
2023-01-19 07:51 · 北京
回复
没有更多了
发现更多内容
一个架构师在2023年需要掌握哪些“必杀技”?_技术管理_褚杏娟_InfoQ精选文章