摘要:本文主要介绍软件架构的定义,以及要成为一个软件架构师所需具有的一些技能,让你对软件架构师这一职位有一个更深的了解。
本文分享自华为云社区《想要成为架构师?先看看这些条件满不知足!》,原文做者:元闰子 。前端
前言
当你点开一个招聘APP,筛选条件选择互联网技术,在列出来的一大堆职位上,每每有那么几个带有“架构师”三个字眼的高薪职位。当你被它的高薪所吸引而点击查看职位详情时,又会被它的高要求所劝退。它们每每要求工做年限在5年以上,须要求职者有过3年以上的系统设计经验,精通各类架构模式和系统框架,反观本身却一个条件都不知足。segmentfault
软件架构师就是这么一个让人向往,但又让人望洋兴叹的一个职位。就像建筑设计师总有成为总设计师的梦想,航天工做者总有成为总工程师的壮志,相信每个软件工程师都有过成为软件架构师的想法。引用维基百科里的定义,软件架构师的职责就是在软件系统研发中,负责依据需求来肯定主要的技术选择、设计系统的主体框架结构,并负责搭建实施。然而,架构师所需的技能远远不止于技术选择和系统设计。本文主要介绍软件架构的定义,以及要成为一个软件架构师所需具有的一些技能,让你对软件架构师这一职位有一个更深的了解。前端框架
文中大部分的观点来自于《Fundamentals of Software Architecture》一书,想了解更多详情推荐阅读原书。架构
对于软件架构(Software Architecture),咱们一般将它当作是软件系统的蓝图(blueprint),可是若是要给出一个精确的定义,每每很难。维基百科里对软件架构的定义为,有关软件总体结构与组件的抽象描述,用于指导大型软件系统各个方面的设计。可是,这种定义也是片面的,软件架构并不只仅是系统的总体结构和组件,光有这些还不足以指导设计出好的软件系统。框架
Mark Richards和Neal Ford在书中,从四个维度上对软件架构进行了描述,分别是Structure、Architecture characteristics、Architecture decisions和Design principles。dom
Structure描述的是软件系统所使用的架构风格,好比最多见的分层架构(layered architecture)、事件驱动架构(event-driven architecture)、微核架构(microkernel architecture)、微服务架构(microservices architecture)等等。当你去问架构师一个软件系统使用什么架构时,若是他告诉你,“系统使用的是微服务架构”,那么也他仅仅阐明了系统的架构风格而已。若想了解整个系统的软件架构,对architecture characteristics、architecture decisions和design principles都要有深刻的认识。异步
Architecture characteristics也就是咱们常说的非功能需求,好比有可用性(Availability)、可扩展性(Scalability)、可靠性(Reliability)等。Architecture characteristics每每容易被软件新手所忽略,可是它对于软件系统而言倒是很是的重要。若是说功能需求决定了一个软件系统的下限,那么非功能需求则决定了它的上限。ide
Architecture decisions描述了开发软件系统时所必须遵循的规则,好比图中例子,对于一个分层架构风格的系统而言,开发工程师须要遵循如下规则:只有业务层才能直接访问服务层,表现层不能直接访问服务层。Architecture decisions更多的只是一种约束,违反了这种约束可能并不会对系统的功能形成影响,可是倒是系统架构腐化的源头。微服务
Design principles指的是系统设计的原则,用于引导开发团队选择更符合系统特色的技术方案。Design principles只会给出一个方向,而不是具体的实现方案。好比图中例子给出的系统设计原则就是:微服务之间应该尽量经过异步通讯来提高系统的性能。至于开发团队经过REST或者RPC的方式进行异步通讯实现,设计原则并未进行限制。性能
就像软件架构不只仅是系统的总体结构和组件同样,要成为一个软件架构师,只会技术选型是远远不够的。一个合格的软件架构师应该具有如下的几种技能:
An architect is expected to define the architecture decisions and design principles used to guide technology decisions within the team, the department, or across the enterprise.
这是一个架构师所需具有的最基本的技能,须要为开发团队给出系统设计的原则和系统开发的约束。架构师在这里的角色更多的是一个引导者,而不是具体技术方案的制定者。好比,开发团队要进行前端框架的选型,做为架构师应该给出的建议是选择Reactive风格的前端框架(引导团队在React.js、Angular、Vue.js或者其余Reactive风格的前端框架之间进行选择),而不是直接建议选择React.js框架。前者属于架构决策,然后者则是技术决策。
An architect is expected to continually analyze the architecture and current technology environment and then recommend solutions for improvement.
就像一个软件系统的生命周期并不止于开发阶段的结束,软件架构也不是一锤子买卖。这就要求架构师可以持续对系统架构进行分析,并提出改进的建议,使得系统在面对业务和技术的双重变化时,仍然可以保持架构良好。
An architect is expected to keep current with the latest technology and industry trends
做为一个架构师必须时刻保持对技术和业界发展趋势的敏感。在敏捷开发的潮流下,软件的特性会频繁的发生变化,可是软件的基础架构每每是不多改变的。架构师若是不能把握当前技术和业界发展的趋势,从而致使设计出来的软件架构不可以应付将来几年的业务和技术变化,这对于一个软件系统而言将会是灾难性的。
An architect is expected to ensure compliance with architecture decisions and design principles.
架构师不只仅须要制定设计原则和开发约束,还须要确保团队可以一直按照这些规则进行软件开发。这就要求架构师对开发人员提交的核心代码进行Code Review,不然系统的架构很容易就腐化掉了。
An architect is expected to have exposure to multiple and diverse technologies, frameworks, platforms, and environments.
对于一个架构师而言,他并不须要精通每一种框架、平台和语言,但至少要尽量多的了解它们,这样才能更好的支撑架构决策。这就要求架构师可以持续的学习新的知识,不断地跳出本身的温馨区。最好的状况就是精通2~3种语言和框架,而且熟悉业界各类经常使用的语言和框架,这样的知识深度和广度的结合才能设计出更好的软件架构。
An architect is expected to have a certain level of business domain expertise.
全部的技术都是服务于既有的业务,剥离了业务的软件技术毫无价值。架构师无需像领域专家同样精通系统的各类业务,但至少也要有必定的业务积累。软件是用来解决问题的,不懂业务的架构师来作软件架构设计,就至关于还没读懂题目就开始解题,结果每每拔苗助长。好比一个须要低时延的业务,交给一个不懂业务的架构师来进行系统设计,可能得出来的是一个高吞吐量的架构。
An architect is expected to possess exceptional interpersonal skills, including teamwork, facilitation, and leadership.
对于大部分的开发工程师和架构师而言,这多是最难的一条了要求了。他们很擅长,也很乐意去解决技术上的问题,可是对于与人相关的问题则至关的抵触。但这对于一个合格架构师来讲所必须克服的一点,由于架构师不只仅须要制定技术规则,更重要的是领导团队按照既定规则进行开发,这不可避免地就涉及到领导力和人际交往的能力。
当一个开发工程师决定在一次需求开发中采用单例模式,可能团队里的其余人并不会有太多的关注。可是当一个架构师决定采用微服务架构来设计系统时,可能就会受到团队内各种人员的挑战,好比版本经理可能以为微服务架构太复杂,会不会影响交付的节奏;开发人员可能以为分层架构更好实现。这种状况下就要求架构师可以有很好的人际交往能力,说服各种人员,这样项目才能更好的进行下去。
软件架构是一个很抽象的东西,目前对它的定义大部分都是一些很宽泛的描述。《Fundamentals of Software Architecture》从四个维度上对软件架构进行了描述,让软件架构有了一个更加清晰的视图。在此基础上,书中也提出了一个合格的软件架构师所须要具有的几种技能。总的来讲,就是想要设计出一个好的软件架构很难,要成为一个好的软件架构师更难。
另外,书中还提出了软件架构的两个准则,颇有道理,就是有点抽象。不过不要紧,不要试图理解它,要去感觉它。
一、Everything in software architecture is a trade-off.
二、Why is more important than how.