架构师成长之路:如何提升技术掌控力?-阿里云开发者社区

开发者社区> 阿里云MVP> 正文

架构师成长之路:如何提升技术掌控力?

简介: 在很多人眼里,架构师就犹如古代的将军一般,既能运筹帷幄决胜千里,又能独闯敌营取人首级,是所有士兵们崇拜的偶像...好了,其实我只是想说:能成为一名优秀的架构师,确实是所有工程师的梦想。那么,架构师应该具备什么能力呢?

聊聊自己


前几天看到阿里云小编姐姐在群里抛出了《架构师成长之路》这个专题,其实蛮开心的,因为我终于可以“被迫”总结下这些年的经验了,所谓压力才是生产力,偶尔对自己施压总结,提升最大的还是自己,假如读者也能从中有一点收获,那我大概是赚翻了:-)

在这之前,我先卖卖自己。

我大约10年前入行,一直从事软件开发类工作,以Java技术栈为主,偶尔用Node,其他技术也略有涉及。期间做过各式各样的产品,包括但不仅限于政务、电商、教育、社交、金融及区块链等等。18年出版过一本技术书籍《Akka实战》(机械工业出版社),今年也可能会出一本译作。我目前坐标上海,担任多家公司高级技术顾问,提供技术分享、培训和咨询等服务。同时今年也非常荣幸,被授予阿里云最有价值专家(MVP),希望能在自我提升的同时,也带给大家一些有价值的思考。

我算是一个典型的白羊座,以及非典型的工程师。为什么这么说呢?因为我多多少少有点冒险精神,也擅长折腾,中途曾多次尝试过创业,有的是自己主导的,有的是跟随合伙创业,但无论怎样,都一直没有脱离技术圈。在任何组织里,都是以技术负责人或者架构师的角色存在,算是见证了多个产品从0到1,然后从1到100的成长过程。在这个过程中,无论是研发体系还是业务体系,甚至HR体系,都会快速发生变化,正是因为我亲历过这些变化,才使得我能以业务全局和团队整体情况来考虑技术架构问题,而不会从最开始就陷入技术细节之中。

我是一个非常喜欢写作和分享的人,这算是我迄今为止养成的一个最重要的习惯。互联网行业发展太快,要学习的东西非常多,我们每天都能接收到来自四面八方的信息,仅依靠大脑来做瞬时的过滤分析,已基本不可能,甚至会出现思维钝化的情况。写作,可以让自己内心平静,对信息进行有效去噪,然后将所思所想真实的记录下来,形成自己的知识财富。同时,分享给其他人,看起来是帮助别人,但可能会因为收到有价值的反馈,反而提升了自己。所以说,分享者往往是最大受益者,正如我写本篇文章一样。

回到架构师成长之路这个话题,在很多人眼里,架构师就犹如古代的将军一般,既能运筹帷幄决胜千里,又能独闯敌营取人首级,是所有士兵们崇拜的偶像...好了,其实我只是想说:能成为一名优秀的架构师,确实是所有工程师的梦想。架构师这个title,没有一个统一的标准,大多数都是公司内部按照一定职级设定的,甚至有的工程师一直在做架构师的事情,但仍然没有架构师的title,这都很正常。我相信大多数人不是为了混title才想当架构师的,最终还是希望自己能达到架构师的能力级别。那么,架构师应该具备哪些能力呢?基于我近几年来的一些血泪经验,大致总结出了下面几点:

1.有扎实的技术功底,对底层有庖丁解牛的能力;
2.对领域内的技术栈有全面的了解,能做合理的架构评估;
3.对新技术敏感多情,并能预判其引入风险;
4.有较强沟通、学习、分享、协作能力;
5.有较强业务分析能力,深刻理解业务及产品价值;

大家会看到,这里面大概有一半儿与技术有关,另外一半儿纯属软技能,这些都非常重要。我们以前评价一个技术牛人,都会以【技术实力】强来描述他,但实际上,作为一个架构师,技术实力只是他能力模型的一部分,我认为,一个更能描述架构师能力的词汇应该是【技术掌控力】,上面列的这5点,其实都属于其范畴。本篇我们主要看看,什么是技术掌控力?以及如何提升技术掌控力?

什么是技术掌控力?


大家都知道,技术实力是架构师安身立命的基础,也是你的同仁或朋友对你打的最重要的一个标签,你在团队内的影响力大概率由你的技术实力来决定,假如在技术上有明显问题,那么在这个团队内基本上没有未来。那么,技术实力是怎么体现的呢?

tl.png

图中两个妹子虽然是外行,但是有时候“写代码快”,确实也会被认为是技术实力强劲的表现(虽然不一定准确),不过更多的,可能是下面这类同行们的评价:

“张某某的算法写的真好哎,技术牛人一枚啊。。。”

“李某某刚才解决了一个并发问题,技术真牛逼啊。。。”

“王某某刚采用了一个新的中间件,一下解决了耦合度过高的问题,膜拜一下。。。”

不得不说,这三个人的技术实力肯定是不错的,他们都能在自己的方向上解决产品上的问题,但是,假如要做一个优秀的通用型架构师,仅仅在某一方向偏科是不行的。架构师不仅要能在某一方向上做到顶尖,更应该【对领域下的技术栈有全面的掌控力,并有能力通过技术手段让业务及产品发挥出最大价值】,这里的领域可以理解为当下要做的事情,比如产品、方案、系统升级等。说的更具体一点,所谓【技术掌控力】,大致包含两个方面:

1.从技术层面来说,能够对各类技术方案的核心底层逻辑有非常清晰的了解,然后根据实际情况进行架构评估(比如易用性评估、扩展性评估、替代方案评估、风险评估等等),最终做出一个最合适的架构方案。

2.从业务和产品层面来说,能时刻关注业务产品发展现状,以及预判未来发展趋势,进而动态的、持续的调整和完善架构方案,通过技术手段,实现业务产品的最大价值。

所以说,技术掌控力,是技术实力的全方位升级,是更加全面的一种能力。工程师假如要往架构师方向发展,应该将技术实力进化为技术掌控力。

至于如何提升技术掌控力,我有下面一些粗浅的看法。

苦练内功


很多工作几年的工程师,在精通CURD之后,往往会陷入技术上的停滞状态,
这时候可能会出现两个极端:

1.由于没有学习目标,所有学习想法只停留在脑袋里,最终出师未捷心先死;

2.由于学习目标太多,频繁在各个技术领域来回划水,最终弱水三千一瓢都没取到;

study.png

老实说,每个人都可能会在某段时间内突然失去目标感(没有目标或者目标太多),包括我自己,每个月也有那么几天是这样:-)

其实这个时候最好的做法就是去苦练内功,就好比你打篮球一样,当周围全是防守人员,挡住了你传球的思路,什么都做不了的时候,那么最好的做法就是:拼命往球框的方向扔就完事儿了,进不进无所谓,至少方向是对的吧...而苦练内功,绝对是最正确的方向。

不知道大家爱不爱看武侠,在武侠中,内功是所有绝学的基础,只会招式而内功缺乏,战力非常有限。比如《射雕英雄传》,主角郭靖武功盖世,人人敬仰,是我们年少时的偶像。那么他的武功是怎么一步步达到顶尖的呢?郭靖在年少时,由江南七怪教他练一些拳脚功夫,以招式为主,内功基本没有,打打小流氓不在话下,假如遇到高手,肯定会输的吐血,会再多的招式也没用。后来,全真派马珏传授了2年全真内功,武力值一下提升了数倍,这才为日后练习降龙十八掌打下坚实基础。假如没有内功基础,我想洪七公肯定是不会贸然将此神功传授于他的。包括后来学会老顽童的空明拳、以及被骗学会九阴真经,都是因为他有强大的全真派内功基础。

其实在技术领域,道理是一样的,技术领域的底层基础,既是内功。对于工作两三年的工程师来说,想入门一个新的编程语言、框架,其实都非常简单,搭建完环境,跑跑demo,看看API,相信一天内能完全搞定。但是,你要开发生产级别的产品,你会发现,以前用A框架要面对的问题,用B框架也仍然需要面对。就以最常见的并发、GC这类问题来说,只要你用Java,采用任何框架都是逃不掉的。而这类问题,就属于内功问题,一旦内功提升,哪怕用最简单的招式,也能解决很多问题。同时,学习其他新技术的时候,也自然可以融会贯通。

在我看来,练习内功(底层基础)其实是蛮简单的一件事,大部分情况下,你不需要依赖其他环境,比如说学习并发编程,直接打开IDE就可以开始做了。再比如GC,只需要配置几个启动参数,学会几个命令,就直接可以开始看了。相对于其他各种大而全的框架技术来说,它对环境的依赖程度非常低,提升效率非常高。

所以,当大家不知道学什么,而又想提升自己的时候,练内功吧,成长速度比自己想象的要快,We can do this all day...

对技术敏感多情


以前在面试的时候,我经常会问候选人几个额外的问题:

1.你会经常逛什么技术社区嘛?哪些社区?
2.最近有哪些想了解的新技术?
3.你关注了哪几个技术类的公众号?
4.最近读的一本技术书籍是什么?(偶尔还会问下对方作者是谁?)
5.最近技术圈儿有什么八卦没?
6.......

sss.png

之所以会问这些问题,主要是想考察候选人是不是经常关注IT圈子,对一些新的技术或技术牛人有没有过了解,我认为,哪怕是天天在社区里面灌水或者搞八卦,也比什么都不闻不问强。可是,很多工程师自诩热爱技术,却连技术社区都不逛,对新技术新名词一无所知,让人如何相信呢?

我认为,工程师一定要对新技术保持敏感,“花心”一点。每种新技术的出现,肯定是为解决当下问题而出现的,虽说解决问题的方式有很多种,但最终肯定有一种最优解法,对新技术理解的越多,在做技术选型时就会越从容,更易做出最优选择。我们经常说,要学习一门技术,得通过项目实践才能真正掌握,这是一句正确的废话。很多时候,你想要学习的技术,并不一定会在实际项目中采用,你能做的,只有自己创造Demo场景,然后编写各种测试代码进行研究。我在工作的前几年,也经常抱怨不能通过实际场景学习新技术,然后心安理得的拖着不去做研究,以至于在遇到真实案例时,只能边学边用,出过很多严重的生产问题,经常吐血。

所以,大家要尽早放弃用生产案例供自己学习新技术的想法,任何机会都是留给有准备的人的。

学会识别风险


虽说我们要对新技术保持敏感,但是在真正选型时需要格外慎重,有句话说的好:大胆尝试、小心求证,我觉得放在这里非常合适。有很多新技术,虽然能解决现有的问题,但是也可能带来新的问题,所以很多时候,工程师都是在不停填坑,然后挖坑,最后继续填坑的反复循环中。作为架构师,需要识别任何新技术带来的风险问题。

这里举一个之前经历过的一个小例子。当时有个老产品,除了做运营活动时会出现一定的性能波动,其他时间一直平稳运行。团队中某工程师发现,之所以会出现性能波动,是因为在订单处理时同时会做一些积分、赠券相关的计算,当量大的时候,计算量水涨船高,占用了极大的资源,也会导致更长的延迟。该工程师提议,可以在订单处理时引入MQ,将订单更新成功的消息发往一个计算服务去执行,这样不仅使订单落库的更快,还解耦了这块的复杂逻辑。老实说,这是个非常好的方案。但是呢,仔细思考,这个做法会带来下面的风险:

1.引入MQ中间件,势必要保障MQ的高可用,假如出问题了怎样?运维是否有能力hold住它;

2.万一发现RabbitMQ存在问题,RocketMQ能不能在尽可能少改动代码的情况下进行快速替换;

3.计算服务独立出来,需要增派人手进行开发(人是否够?),并且也需要纳入运维的日常巡检管理;

4.计算服务既不能少算,也不能重复计算(幂等性),可靠性要非常强;

5........

qswt1.png

当然,这里面还有很多细节问题,不再一一列出。由于这确实是个好的方案,所以最终采纳并完成实施,在解决完这些风险后,顺利上线了。顺便说一下,第1、2个问题,由于考虑到当时团队现状,直接上云保平安了。

所以大家看,即使这么一个看起来非常简单的方案,也需要考虑很多问题才能最终执行。我一直认为,能有效识别风险,是架构师技术掌控力的最佳体现。

关注非功能性需求


应用程序一般包括两类需求:功能性需求和非功能性需求。功能性需求是指应用应该实现的业务功能,这类需求一般由产品经理提出并形成PRD。非功能性需求是指应用的性能、维护性、扩展性、可靠性、以及高可用等运维保障性需求。本质上,我们做架构,大部分时候都是在做非功能性需求,这是架构师最重要的工作之一。

mtsx.png

现实情况是,Boss或产品经理往往只会关注功能性需求,它们最常见的说辞就是:我要加个这么小的功能怎么这么麻烦?老实说,我理解他们,因为站在他们的角度,都是以业务实现来看待研发问题,能把功能性需求的逻辑整自恰了就已经很好了。而作为架构师,此时的价值就需要体现出来,不能完全被动接受纯功能性开发的需求,老实说,即使你用最糟糕的语言、最糟糕的架构,你都能实现Boss给你的任务,但是一旦产品稍微有点起色,就免不了完全推倒从来的风险,最后不仅给自己和团队挖坑,还会对公司造成损失。有的工程师可能会吐槽,产品开发周期有限,功能性需求都可能做不完,非功能性需求更加没空做。确实存在这种问题,我认为,即使由于deadline太紧而无法顾及更多非功能性设计,也应该在整个架构设计文档和开发文档中加以说明,这是作为“技术负债”的一部分,是需要给产品或者Boss详述报告的。除了让他们对当前产品有个合理的预期之外,也给团队以后“还债”预留时间和空间。顺便提一句:假如永远没有还债的机会,可能公司并不需要一名架构师:-)

我们工程师很容易进入一个误区,那就是总觉得只有大一点的产品才需要考虑非功能性需求。实际上,不同阶段的产品有不同阶段的非功能性需求。比如说,很多互联网公司的产品,特别是创业阶段的产品,都遵循MVP(最小可行性产品)策略,即用最短的时间内完成最核心的功能,然后小范围投入市场进行反馈收集,并持续迭代。这种产品开发形式,虽然不考虑高性能、扩展性等问题,但是仍然需要考虑快速迭代、快速发布、稳定性等问题,否则用户会吐槽“你这款产品本身就已经极简了,不仅发新版慢,还各种卡死闪退”,好不容易积累的种子用户也会消失殆尽。随着产品不断发展,非功能性需求会原来越多,工程师需要关注更多更复杂的非功能性需求,比如考虑性能问题、服务或数据拆分等问题。假如一直坚持下去,不仅可以持续为产品发展带来价值,自己也能得到很大的提升。

学会交流与分享


在我入行的时候,经常听求伯君当年单枪匹马一年多,写出了WPS的传奇故事,总是感觉热血沸腾,不能自已。在那时候,我心里的技术大牛,就像武侠中的世外高人,他们独来独往,身怀绝世神功,但不为外界所知,而一旦横空出世,必定威震武林。事实上,在几十年前的IT行业,确实存在着大量顶尖高手,他们以一己之力推动者行业的发展。那个时候的高手们,是孤独的,就像求伯君说的:“有了难题,不知道问谁,解决了难题,也没人分享喜悦。”。

不过,IT&互联网行业发展到现在,已经不是当初的样子了,应用的复杂度急剧上升,靠单打独斗已经搞不定了。过去之所以个人英雄主义更多,其实是因为信息传播能力、交流协作工具等受限,人与人之间基本是信息孤岛,不像现在,有Github,各种社区、甚至微信群,可以很方便的进行交流协作。

事实证明,当信息传播能力越强,交流协作工具越来越高效,IT行业的整体水平都有更快发展,以Github为例,它吸引了全世界最知名的互联网公司,以及最有创造力的工程师群体,最终产出了最顶级的开源软件,为整个IT行业的发展做出巨大贡献,这是集体智慧发挥到极致的典型案例。

作为工程师个体来说,我们不应该故步自封,关起门来搞建设,而应该多和外界交流学习,无论是社区、行业大会,还是高质量的微信交流群,直播群,都可以尽可能的去参加,以吸取大家的集体智慧,这对增强行业见识,拓宽技术视野都是很有帮助的,当然了,假如能持续在Github上 show your code,那肯定是最高级的交流方式了:-)

fx1.png

我一直相信,人的精力非常有限,不可能所有技术都能完全精通,在我们自己冥思苦想仍不得解的时候,可能别人的一句话就点醒了自己,反过来也一样,这些都在我身上时有发生。老实说,以前的自己,也不太喜欢和人交流,内心总有点小傲气,总觉得人家讲的都是XX,有那么一点“技术相轻”的意思,而自己想去和别人分享心得吧,又抹不开面子,生怕自己讲不好,毁了自己的人设。直到后来,因为做了一次讲师,我才改变了这个观念。那是我人生第一次受邀做分享嘉宾,对方是一知名外企。第一次嘛,我亚历山大,也格外认真,在准备内容的过程中,竟然把我有关该主题的一些不起眼的盲点全部扫清了一遍,当时我就两个感觉:

1.这次分享我收获最大,这么爽的事儿以后不要钱都干啊;
2.分享的讲师之所以有底气站在台上,肯定是掌握了听众不知道的东西;

所以可以看到,无论是当分享者还是当听众,都是会有很大收获的。这里特别提一下,假如大家在公司内外都能做几场成功的分享,你自身的影响力也会逐渐提高,然后对很多事情的掌控能力也会越来越强,这对自己未来的职业发展是有很大帮助的,至少,你可以来申请阿里云MVP,对吧:-)

关注产品与业务


我和很多工程师一样,早年间只迷恋技术,对业务开发非常排斥,对业务的理解仅限于最基本的逻辑,对业务功能所能带来的价值更是不了解,让我理解用户?对不起,我可能连用户是啥群体都还没摸清楚。所以在头几年里,总感觉自己一身武艺,却没有发挥的地方,实际上是自己“作妖”导致的。后来在积累了更多开发经验后,就发现,假如对业务的理解有偏差,做出来的技术架构,开发出来的产品,基本上都是“不良品”,正是印证了那句话:虽然懂得很多技术,但仍然做不好架构,原因就在于此:-)

依我看来,IT行业对架构师的业务理解与分析能力的要求是越来越高的。以往有很多人,把架构师分为技术架构师和业务架构师。技术架构师,通常负责做好技术选型、搭建技术框架、攻克技术难点等工作。而业务架构师,通常负责平台架构、产品规划、领域模型等工作。但实际上,技术类架构师越来越需要拥有业务架构的能力,因为技术肯定是为业务服务的,他需要对实现业务价值做出自己的贡献,而脱离业务场景谈技术架构纯属耍流氓。

微服务定义&拆分策略.png

举个最常见的例子,大家现在都在讨论微服务架构(如图所示,这是我参考《微服务架构设计模式》并结合自己的经验给出的一个通用步骤),我们都知道微服务化是有诸多好处的,比如提高可扩展性、可维护性、资源利用率等等,这是会对产品带来长期价值的非功能性需求,是每个架构师都想做好的一件事。其实做微服务,最难的点已经不是技术栈了,毕竟SpringCloud、Dubbo这类框架已经非常易用了。最难的实际上是领域模型、服务拆分等问题。什么叫领域模型呢?这是DDD(领域驱动设计)中的常见词汇,它是指通过业务需求建立的具有统一术语的业务实体模型,它指导着程序的开发实现,同时,DDD中的另外一个概念叫限界上下文,对它的识别可以有效解决微服务拆分的问题。而这些概念,都与业务息息相关。所以说,假如对业务分析不足,是不可能做好微服务架构的。

平日里我也经常和众多研发团队负责人进行交流,大家有个共识就是:假如某个小团队里存在一位只追求用新技术或所谓“底层”技术而对业务完全不care的架构师,是非常容易出问题的。而且说句可能会被喷的话,对于大部分中小互联网公司来说,业务发展的规模可能还远远不到拼技术(我是指硬核的那种)的时候,这些公司架构师产出的,其实是业务产品。更何况,由于云计算的普及,有很多以前看起来“高高在上”的技术,已经完全达到开箱即用,便利性犹如水电煤一样。当然,这倒不是说技术无用,然后大家转型去做业务专家算了。技术实力仍然是架构师最重要的能力,但是,我们不要忽略业务领域知识的重要性。时常关注业务与产品,不仅对当前架构的合理性进行有效评估,还能够让自己对产品未来发展有个更好的预判,以便提前做出合理的架构规划,笔者认为,业务与产品的深入理解,其实也是【技术掌控力】的一部分。

最后,送给大家一句话:技术能力将决定你能走多快,而产品(业务)能力将决定你能走多远!共勉!

版权声明:本文中所有内容均属于阿里云开发者社区所有,任何媒体、网站或个人未经阿里云开发者社区协议授权不得转载、链接、转贴或以其他方式复制发布/发表。申请授权请邮件developerteam@list.alibaba-inc.com,已获得阿里云开发者社区协议授权的媒体、网站,在转载使用时必须注明"稿件来源:阿里云开发者社区,原文作者姓名",违者本社区将依法追究责任。 如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件至:developer2020@service.aliyun.com 进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
+ 订阅

阿里云最有价值专家,是专注于帮助他人充分了解和使用阿里云技术的意见领袖。

官方博客
官网链接
精彩专题