我对技术架构的理解与架构师角色的思考

原创
01/29 19:06
阅读数 3.8K

先自我介绍一下,我叫道延, 2014年进入阿里,在阿里通信呆了接近两年。2016年底到了业务平台,当时玄难找我的第一件事就是要解决大促的问题,第二件事就是解决安全生产的问题。

我带着这个命题进入业务平台,来做后续一系列的事。今天趁这个机会,和大家分享一下,关于这件事和这件事背后的一些想法,以及我对架构师的一些思考。

我对技术架构的理解

image.png

1.第一点就是顶层设计。 国家每5年有五年计划,这其实就是在国家整个层面的一个非常清晰的顶层架构设计,这里面对国民经济重大建设项目和生产力进行宏观的架构设计,它也是一种架构设计。在这里面,要做什么事要定义的非常清楚,要达到什么样的结果也要定义的非常清楚。

双11的保障也是需要设计的。双11本身是一个业务的活动事件,因为规模比较大,所以需要很多的技术来支撑这个东西。技术里面我们可能要考虑低成本、高效率、高稳定,并且还要引入一些更多的新技术来支撑,也要把这些东西整合好,架构设计好,让它很润滑、很流畅地保证我们的业务。

2.第二大块是物理架构。 大家在阿里可能都听说过,我们有一个比较有名的单元化架构,其实不光阿里有单元化架构,很多公司都有类似的架构。比如微信。阿里和他们的单元化架构其实有一些本质的区别。

阿里目前单元化架构达到一个什么目标呢?通过部署异地单元将生产流量完整运行在千里之外的独立机房,连续性的运行业务。这几句话里面包含了非常多的关键点,一个是异地,第二个是千里之外,第三个是独立,第四个是连续性。

单元化架构的总设计师是老毕,因为我们这块业务跟单元化的架构是非常相关的,所以要对它完成的掌握和吃透才能往下走。

3.第三大块是应用架构,目前我们中台里面做的比较多的叫星环,星环说白了,它想达到架构的本质目的就是将单纯的代码共建模式,抽象成横向和纵向的业务包模式,做到业务与业务隔离,业务与平台隔离。

这背后带来的问题是什么?我们原来产生用共建的方式支撑了50多个BU的会员、商品、交易、营销、资金、支付、库存逆向等等业务,其实每个里面都是遍地开花的if else。然后代码的合并也难,开发也难,测试也难,上线也难,整个过程都很痛苦。所以我们当时在2015年开始一直在做星环的架构,就是让这些东西不那么痛苦,慢慢的解决这个问题。当然了现在我们又用了新的痛苦点。

架构师的角色

关于架构师的角色,我来说说自己的想法。

image.png

1.第一个是形散而神不散。 架构其实是每个应用线每个业务线都有。有些技术同学本身就是有架构师的这种角色。阿里很早以前是专门有架构师岗位,专门的去做架构,但是做着做着架构师就做没了。因为很不接地气,它没有解决具体、真实、实际的问题。但现在可能更多的看到了,其实很多平台很多应用里面都会有一些架构师的角色,他们是在抽象这些技术问题,解决这些问题。所以第一点是行散神不散。优秀的技术同学一直在用架构的意识,解决实际的技术和业务问题,这就跟普通的技术同学有本质的区别。他不光是解决这一个问题,他可能解决这一类问题,用架构的思想去解决问题。

2.第二块是前瞻性。 为什么你能解决这个问题,并且能解决这一类问题?一定是你要看的多,你要想的多,这需要大量的实践和知识的积累,并且是站在过去的肩膀上。

阿里电商系统很早就开始建立了,我们这一代一代人在里面去做架构,都是站在前一代人的肩膀上。要去看前一代人为什么要这么设计,去想或跟他去聊,吸取他好的地方。现在可能遇到新的问题,通过其他的方法来解决一些新的问题,需要有实践和知识的积累。

接触更多的人和事,用新方法解决新问题。这个很关键。 不能只看代码看一个月,要找真实的业务方,你的上游,你的下游,你的合作伙伴。比如说做双11,我是2016年12月份到业务平台,我花了整整三个月,跟每年双11的大队长、重要人去聊双11。他们是怎么理解,怎么来思考的,他们认为什么地方有问题。我再找他们要一些建议:我应该怎么去做。跟他们聊的过程中才知道我们需要做什么样大促,要把握什么是关键点,这都是一些宝贵的财富。

3.第三点是解决复杂问题。 好的架构师都在解决复杂的问题。只有复杂的问题,它才需要更多不一样的技术或更新的技术彻底解决。高并发高可用是我们阿里电商面临的基本面问题,但是架构师要有不一样的高并发和高稳定性的解决思路。

当前最紧急的问题,比如说用户体验、提升效率、低成本。这些问题其实是非常复杂的。很多同学都想解决这个问题,很多种方法都在解决,但是整体来说效果不是特别明显。**因为它链路太长了,链路长代表影响的业务和影响的人更多,你必须得换一种新的思路来考虑这个问题。**同时用户分层,内部的技术人员增多,其实我们最终要化为一句话:要把解决复杂问题定义为架构师的一个典型角色。

架构师需要什么样的能力

架构师需要什么样的能力?我参考了很多外面一些同学的分享,总结出来其实就是发现问题、分析定义问题、解决问题。

image.png

  • 发现问题

对局部和全局的问题需要有发现的眼光,更应该有发现未发生问题的能力,哪些是需要治标,哪些需要治本,这个是发现问题的基本判断力。现在系统可能没什么大问题,但你要有发现的眼光,这些问题如果不解决,未来业务可能遇到更严重的问题。**架构师看问题的眼光和别人不一样,不要只看见这一个问题,还要看见这个问题背后是什么,这一类问题背后是什么,我怎么能用抽象的方法解决一类问题。**想好了以后,我就把当前的这个问题先解决掉,其他的问题用抽象的方式去解决它。

  • 定义和分析问题

阿里不缺解决问题的同学,但是缺定义问题的同学。你怎么知道这是个问题,并且把这个问题定义清楚。需要将发现的问题进行抽象和归纳,定义出问题的基本要素,同时定义出问题的短期和长期方案,推进技术整体的进步。

定义问题这个要求非常高。你们平时在解决业务技术问题的时候,也要去分析和定义问题的一些能力,把一个问题定义清楚了,可以真正的能推动业务往前进。

**解决问题是制定问题的实施路径和解决方案,协同团队和上下游,推进问题的解决。架构要解决的问题一定不是一个局部问题,一定是一个全局问题。**架构师一定会碰到各种各样的角色和链路,他要有这个能力去定义问题的解决方案和实施路径,同时要协同团队。他不能闷头做事,真的要抬头,并且是要有良好的沟通能力,跟所有的同学达成共识才能往前进。

第一点就是沟通能力非常关键。你怎么把这个问题说清楚,切中问题的点,同时也能帮助上下游带来实际的效果。第二点是架构需要能救火,但不仅仅是救眼前的火,应该救未来的火,架构师救火能力要很强。

我来阿里之前在做一个CRM的系统。刚开始前几年一直在做CRM系统的业务,后来我要解决很多业务的问题,要把它抽象出来,去做业务问题下面基础的平台。再后来发现基础平台的要解决更彻底,还要做下面的中间件。来阿里之前我做过业务,做过业务的开发平台,也做过开发平台下面的中间件。

从2017年到业务平台以后能学到系统它的链路是什么样的,数据链路是怎么样的,整个调用链路是怎么样的,它和底层的关系是什么样的,可能遇到什么样的问题了?现在可能出现这个问题,再往后运行是不是会出现其他的问题。通过救火的过程中积累对系统的了解。

也许我对当前系统也不是很清楚,但有很多以前技术的积累,现在的问题还是能非常快地解决掉,帮助团队解决当下问题的同时,也能让自己对全局有所了解。

架构师的挑战

image.png

  • 全局式的视角

比如看到一个会员,你不能仅仅只看到会员,你要看到会员上面的业务是什么,谁在用会员,这叫全局。同时,会员用的最多的是导购和交易,登录仅仅是会员本身一个很小的业务功能而已。基于会员,我们有导购有交易,把这些东西要串起来看明白,就能完整的认识到会员到底提供了什么,一定要有一个全局视角。

  • 技术广度

阿里的技术特别复杂,能入职到阿里来,把阿里的整个技术栈完整摸一遍的同学真的是很了不起。以单元化架构为例,我们可能需要了解端,有iOS、安卓端,有PC端,还要了解CDN、网络、接入层、服务发现、服务路由、HSF等的。数据库的储存同步、多点写,还有消息。这些东西其实平时同学们都在用,但架构师不仅在用,架构师真的是要去把玩,彻底了解透彻这些东西,这是关键点。

给大家举个例子,像数据库组成的强同步,对我们后续技术架构进和业务的改进都是有极大影响的。这个时候大家要对数据库有一个全局的认识。

2009年用Oracle数据库用的非常多。。我当时不是做数据库相关的,但是为了把Oracle数据库研究透,去学了非常多Oracle数据库相关的内容。了解里面的逻辑,知道它是什么开发态,是什么运行态,什么管理态,知识都是延续的,后来到了阿里,可能花很短的几个小时就能把现在阿里所有的数据库吃透。

技术的广度非常依赖于积累。 你一定要带着问题去想,这个时候你才有记忆力、有了积累,慢慢的你技术的广度就会越来越深。你要了解数据库,你必须对下层的网络了解,所以我们要对网络,CDN可能要更进一步的认识。

2009年以后我花了两年时间学习网络,对交换机、路由器、骨干网、城域网,运营商怎么建网的,我们的IDC是怎么建网的,除了实践以外,已经基本了解了。大家每天都跟网络有交互,为什么重传高?为什么延时高,TCP/IP第4层的下面IP第3层是怎么操作的,IP下面的MAC层是怎么操作的,大家都要深入了解一下。

救火很多时候就考验你这个能力。我去救火时根本不会用现在那些平台化的工具,直接上手用TCP代码抓原始发文,马上能分析出很多问题。这就是平时的积累,慢慢的你就会对全局有认知。

2019年整个核心系统上云的时候,同样跟技术的广度有关系,我们上云发生了什么变化?整个底座到云上去了,计算、存储、网络全到云上去了,那要了解云啊。我2018年在阿里云注册了个账号,基本把阿里云的云产品全摸了一遍,这时就会对阿里云的网络、技术有本质的了解。

**架构师一定要有技术的广度。**大家一定要学会积累,积累到一定程度以后,你会做到无师自通。比如你了解网络、数据库,然后你又了解了磁盘30%,当这些知识逐渐成体系了,你是有能力去消化和打通不同技术点背后的相关性,对于你的个人能力的提升和认知层面的提升有巨大的帮助。

  • 持续的学习

每时每刻都在发生技术的升级和变革,只有持续不断的学习,才能对老的架构有新的认识,对于老的问题产生新的解法,要了解业界最近在发生什么变化,这个领域最关键的项目和人在做什么,学习他们的技术,学习他们的论文。我以前每天大概2到3个小时是用来学习。这几个小时的学习时间是我最放松的时间,不用去想太多事。

学习也不是说去瞎学,一定要有体系化的。首先跟你工作相关的,要体系化的去学习,从最下到最上体系化的去学习,学习完了以后你会有新的不一样的认识。把你的想法可以向你的团队说出来,向你的主管说出来。

还有就是要去看论文。跟数据相关的,OLTP和OLAP都有非常好的论文。看了论文以后再看其他人对论文的理解。一定要去看一些比较好的东西,跟工作相关的都可以去看,每天去学习。每天花2到3个小时去学习,三年以后你就知道自己跟别人完全不一样。有人说过:在一个行业你能付出1万个小时,你会跟别人形成本质的区别。但是在我们这个领域,1000个小时就形成差别。

  • 业务理解

这个一定要到实践中去,不是业务离不开架构,而是架构离不开业务,业务、架构、技术要三位一体才能达到最佳的效果。我们平时学习、实践的过程就在磨刀,但你不能说你天天在磨刀,总得要用这个刀。这就是跟业务结合起来,用不一样的思路解决实际的业务问题,会带来更低的成本、更高的效率。

  • 结果

要将技术的先进性转化为业务的先进性,忘掉屁股。这个“忘掉屁股”就是你做很多事情不是你一个人能搞定的,复杂、越大的事情是要协同更多的人。如果你就是为了你自己,比如说KPI去做事,我告诉你,这个事情做一次两次可以,但后面就没人跟你配合。你一定要忘掉屁股,才能慢慢的把这个事情做成,真正做到你想要的结果。

**遇山开道、遇水架桥,这讲的是决心。很多时候问题确实很难解决,也需要协调更多的人。**很多人可能会放弃。我们最近在做架构的升级,用国产化芯片,从底到上全链路的。如果有一方配合不到位,这事情就很难推进了。从 4 月份一直到 7 月底被阻碍了两次,第三次如果再没办法开展下去,这个事情就彻底的结束了。我们当时把整个团队召集到一起,互相打气:一定要干成。遇山开道、遇水架桥,有什么问题抛出来,大家一起来解决,要有决心,更要果断。

【阿里巴巴中间件】专注于微服务、容器服务、Serverless……等云原生热门话题。 关注同名公众号获取更多精彩内容和福利!

展开阅读全文
打赏
2
4 收藏
分享
加载中
更多评论
打赏
0 评论
4 收藏
2
分享
返回顶部
顶部