欢迎您光临本小站。希望您在这里可以找到自己想要的信息。。。

架构师是一个高大上的头衔

架构&设计模式 water 3130℃ 0评论

架构师是一个高大上的头衔,在百度百科中对架构师的定义是“一个既需要掌控整体又需要洞悉局部瓶颈并依据具体的业务场景给出解决方案的团队领导型人物。”ArchSummit是一个知名的架构师技术交流论坛,高达6800元人民币的门票(当然人多的话有打折)也没能阻挡前来参会的架构师们的热情,也直接反映了架构师们一般都不差钱。我是一名工程师,做过搜索、也做过推荐、搭过数据平台、也挖过用户画像,从零开始建设过若干平台和系统,不敢妄称自己为架构师,但有一些经验体会可以分享。

系统架构的选择往往没有对与错,工程师们常常面对的是各种取与舍的矛盾。在众多的矛盾中,首当其冲的当属业务和技术的矛盾,业务快速发展,产品对需求的时间点要求感人,“帅哥,这个需求今天能完成吗?”,“这是老板的需求,赶快实现一下”。应对扑面而来的需求,工程师们往往疲于奔命,使用各种短平快的方法来满足业务的需求,长此以往,整个系统变得错综复杂,臃肿不堪,难以维护。一个好的架构需要在应对业务需求的同时,持续提炼通用化的模块,通用层基础且稳定。在通用模块的基础之上构建出适配层,由适配层处理复杂多变的业务需求,适配层灵活且多变。在技术上不断沉淀基础的通用模块,这不仅不会成为工程师们额外的开发负担,反而可以提升业务需求的实现效率,提高系统的健壮性和可持续发展。解决业务和技术这一对矛盾,需要工程师站在业务和技术中间,不偏不倚。

优秀的系统架构面对的第二个矛盾是技术和运营的矛盾。 工程师们往往热爱新和奇的技术,重视新功能的开发,从0分做到60分的过程总是令人愉悦的,一切按照预期的演进是那么的美好。随着系统投入使用,数据规模越来越大、用户量和访问量逐步增大,算法效果需要不断提高,原有的架构暴露出来的问题也逐步增多。架构的演进进入了深水区,是抛弃原有架构进行重构,还是在现有系统中进行持续的演进,工程师们往往会遇到选择的难题。一个好的系统是要靠持续深入的运营来构建的,这里的运营是一个泛指的概念,指代构建系统中各种监控、调试信息、数据统计分析、数据对比等。一个系统不论是重构,还是持续演进,都需要开发全方位的运营系统来了解当前架构中的每一个环节。系统架构从60分演进到100分是一个艰苦的过程,没有一个系统是在一开发出来就解决了所有的问题的,提高运营能力是架构演进的基础,这本身不是一个技术问题,而是意识问题,需要工程师们做大量细致深入的调研和思考。

最后要说的是全局最优和局部最优的矛盾。我们在开发中常常遇到,当针对某个问题进行优化后,系统中又出了其他问题,也是俗话里说的头疼医头、脚疼医教、治标不治本。当你是从0开始搭建一个系统,对系统的各个环节和历史演进非常清楚,也就比较容易的从全局角度思考和解决问题。但对于复杂系统,大部分工程师往往只关注到系统的某一部分,解决问题的思路是受限于眼界,容易陷入至局部最优,而且往往局部的解决办法相对全局而言更复杂更间接。工程师需要有开阔的眼界,从更高层面理解系统架构,从而了解问题产生的本质,从全局角度出发予以解决。

我大学毕业当了IT民工,一年之后,拿到了助理工程师职称证书,顿觉自己成了有用之身,大有用武之地,传说中的高工就在不远处等着我,那时候还不知道什么是架构师。而今的技术圈里,架构师似乎才是高大上的代名词,毕竟不是每个公司都有研究员、领域专家、科学家的。

架构师与工程师相比,有多大不同呢?在我看来,架构师没有什么特殊的,只是工程师在技术路径的进一步延伸。架构师,是随着系统规模越来越大,越来越复杂而衍生出的角色。许多公司里并没有固定的架构师职位,但具备了相应能力,获得了团队认可,在项目中承担了架构职责,你就是架构师。 架构师的能力大,责任更大,我对架构师的职责定义如下:

  1. 以工程思维全面理解业务需求;

  2. 基于模型和基础模式抽象简化;

  3. 提出恰当可行的整体解决方案;

  4. 在限定资源范围完成明确目标;

  5. 满足业务需求且保证系统质量;

  6. 在可预见的周期内具备扩展性;

  7. 并在系统生命周期内持续演进。

所以架构师要靠项目实践积累经验,并结合系统化的学习,提升自身能力。知易行难,架构师是很难培训出来的,多数都是身经百战,方百炼成钢,即便如此,也很难在具体项目中知行合一。工作中架构师是技术方面负责人,遇到问题多数靠自己解决,没人能传帮带,所以架构师必须具备强悍的自学能力和毫不松懈的自我驱动力,很多时候,凭的就是心中那一口气。

架构师的责任心也很重要,因为架构方面工作往往处于重要但不紧急的尴尬境地,如果架构师在这方面自己不重视,那还怎么能做好呢?当然,要是只关注技术架构,不关注业务目标,就更不合格了,项目组的每一个成员都需要理解业务目标,并为之努力。

温伯格曾说:“一个系统,就是对世界的一种看法。”世界是什么样的?多元、有机、不断变化、并不完美。架构师设计、搭建、维护系统,这个过程,创造了一个小世界。而这个小小的世界,融合了架构师对大千世界的体悟和取舍,是每个架构师的智慧与汗水的结晶。

架构师,是一种修炼,更是一种修行,是一种别样的人生。

架构师是一个充满挑战的职业,知识面的积累往往决定着一个架构师的架构能力。一个优秀的软件架构师,首先一定是一个出色的程序员。但,不是每一个程序员都能够成为一个架构师——这是开发界广为流传的一个论调。随着一切都趋向全堆栈、多种语言化、网络即平台等方向发展,架构师这个角色在企业中的地位越来越重要。

有人的地方就有江湖,有江湖的地方就会有纷争。如同语言之争,每当我看到有人为某些架构、框架的优劣争论不休时,我都会想起遥远的C/S与B/S之争,甚至Vim 和Emacs之争。我们也看到有很多项目、很牛的架构师、很好的团队最终失败的案例。《软件设计精要与模式》作者张逸在接受InfoQ采访时曾说,评价一个架构的优劣的方法之一是,把每一个功能、非功能性的因素扩大化,再看这个架构会不会出问题。诚哉斯言。

张逸的观点是说,架构的设计要面向业务未来,而未来是不断发展变化的。根据Gartner的报告数据,云化是未来所有业务的趋势,云服务的基础设施和系统架构跟传统IT、CT有着太多不同。今天还是微服务、分布式架构,明天可能是无服务、或者其他什么架构。这时,落在架构师肩上的担子更重了,不但要承载业务的增长,还要兼顾技术发展的趋势。在接下来的日子里,希望《架构师》能继续陪你走下去。

转载请注明:学时网 » 架构师是一个高大上的头衔

喜欢 (0)or分享 (0)

您必须 登录 才能发表评论!