聊一聊架构师的三种境界

Posted by 冷眼樵夫 on 02-21,2021

引子

不管你现在是学习什么前沿的技术,大致一句话应该是没有错的,你所掌握的技术,在你有生之年,是会过时的。这种过时的生命周期是从后端向前端逐渐缩短的。我这里的后端和前端的方向是以靠近真实用户的距离计算的。比如数据库,操作系统这种技术,距离用户最远,用户基本不会感知,他们可能几十年都不会过时,从mysql,linux大致就能看出来。再往前,中间件技术,缓存等技术,大致十几年吧。再往前,后端服务技术,我认为生命周期应该是10年之内。再往前,前端技术,我觉得迭代周期应该是5年之内了。如果有工作超过10年的朋友,应该对我这个时间估计也会有所赞同的。

迭代更新是伴随着技术红利的,这里的技术红利指的是新技术的培训,人员更新,市场需求等。越是更新换代快的,越容易抢占这个技术红利。在这个技术红利中,会有一波人才缺口流出,会有一波技术很强的人出现。但是,残酷的是,这波人才缺口,很多情况下是通过淘汰只掌握过时的技术的人员空出来的。所以越靠近用户侧的技术人员越需要跟紧技术迭代的脚步,否则一不小心就会被淘汰。当然也不是说越往后端越舒服,技术迭代慢同时也代表坑位固定,因为在同技术领域沉淀很久的老人会把及格线带的很高,所以基本需要沉淀比较久才能成为比较合格的人才。而且靠近后端的人才一旦遇到技术迭代,那么可能是毁灭性的,究其原因,恐怕一个是深入后端技术比较慢,一个是新的后端技术坑更少。

是不是所有的技术迭代都是好的呢?我的观点是肯定的。新技术的出现一定是为了解决某种痛点,或者填补某种空缺才会出现的。但是,大家往往忘记了,技术是为了解决问题的,有很多公司由于体量,技术人员储备等条件,根本不存在所谓的痛点,但是也莫名其妙引入了各种时髦新技术。技术都不是银弹,使用新技术,一定要承担新技术带来的成本和新痛点。衡量一个新技术引入公司的决策是否正确的标准,恐怕应该是业务是否得到提升。这里说的业务提升,两个方面,一个成本侧减少,一个收益侧增加。

在我看来的很多公司,对于新的技术往往是为了革新而革新,所带来对公司业务上的伤害,恐怕更多于旧的技术。所以架构师的价值,特别是业务架构师的价值我认为体现在这里,对整个公司或者部门的业务,人员水平有一定判断,选择合适的技术,有时候,甚至于拒绝新技术的引入也是一个成功的决定。

架构师的境界

架构师,在每个程序心里都是一个神圣的职业,那么什么才是真正意义上的架构师呢?我们先来给一个定义:
狭义的定义:在一个软件项目开发过程中,将客户的需求转换为规范的开发计划及文本,并制定这个项目的总体架构,指导整个开发团队完成这个计划。
广义的定义:系统架构师是一个既需要掌控整体又需要洞悉局部瓶颈并依据具体的业务场景给出解决方案的团队领导型人物。

甚至每个人对架构师的理定位都不同,同一个人在不同阶段对架构师的理解也会发生改变,这里主要说下我能看到的架构师的三种境界。

一、软件型架构师

必要条件:

精通至少一种后端语言,精通十种以上设计模式并能熟练运用到模块的设计开发中,精通关系型数据库和非关系数据库至少各一种,熟练使用缓存、消息队列、ELK等技术,可以将开源社区源码引入到自己项目中来。

定位:

独立设计某个软件产品,并且成品软件高可用、高并发、高可扩展。

二、产品型架构师

必要条件:

精通至少一种云平台,最好是容器云,精通某一个行业,精通产品从需求确定、软件开发、测试用例编写、交付物构建、灰度发布、全量发布、线上回滚、质量评测、指标优化等整个生命周期涉及到的环节和用到的技术栈,熟悉容灾、监控、报警、自愈等设计,能够发现当前产品在某个环节中存在的缺陷,并能预测和规划产品后期的发展方向。

产品型架构师关心的是整个产品链,而软件型架构师属于这个链上的一环。

定位:

负责整个产品的迭代和优化,具备一个人完成和发布一个产品的能力。

三、战略型架构师

必要条件:

精通某一领域,并能看到该领域与其它领域的节点关系,能够预言领域的前景并及时对蓝图做调整,根据最终目标部署相应的产品,能把这些产品结合起来。对如何实现不需要事无巨细,只需要将自己的理念灌输给团队。

战略型架构师关心的是整个行业,而产品型架构师只负责其中一条产品线。

定位:

负责整个企业的战略部署,能够瞄准5-10年内的目标做战略规划。

总结:

三种类型的架构师是几何学中点线面的关系,软件型架构师是齿轮,产品型架构师是部件,战略型架构师是掌舵人,他们的关注点不一样。齿轮需要提供高效稳定的输出,部件需要将每个齿轮拼装在一起发挥即战力,而掌舵人一边盯着水面避免触礁一边盯着远方的目的地。

所谓人外有人山外有山,做技术永远不要自满,在更高的维度里我们可能什么都不是。以我的视野目前也只能看到战略型架构师,更高维度会不会有更深层次的架构师存在?我相信一定会有。


0评论