对于软件架构(Software Architecture),我们通常将它看成是软件系统的蓝图(blueprint),但是如果要给出一个精确的定义,往往很难。维基百科里对软件架构的定义为,有关软件整体结构与组件的抽象描述,用于指导大型软件系统各个方面的设计。但是,这种定义也是片面的,软件架构并不仅仅是系统的整体结构和组件,光有这些还不足以指导设计出好的软件系统。
Mark Richards和Neal Ford在书中,从四个维度上对软件架构进行了描述,分别是Structure、Architecture characteristics、Architecture decisions和Design principles。
Structure
Structure描述的是软件系统所使用的架构风格,比如最常见的分层架构(layered architecture)、事件驱动架构(event-driven architecture)、微核架构(microkernel architecture)、微服务架构(microservices architecture)等等。当你去问架构师一个软件系统使用什么架构时,如果他告诉你,“系统使用的是微服务架构”,那么也他仅仅阐明了系统的架构风格而已。若想了解整个系统的软件架构,对architecture characteristics、architecture decisions和design principles都要有深入的认识。
Architecture characteristics
Architecture characteristics也就是我们常说的非功能需求,比如有可用性(Availability)、可扩展性(Scalability)、可靠性(Reliability)等。Architecture characteristics往往容易被软件新手所忽略,但是它对于软件系统而言却是非常的重要。如果说功能需求决定了一个软件系统的下限,那么非功能需求则决定了它的上限。
Architecture decisions
Architecture decisions描述了开发软件系统时所必须遵循的规则,比如图中例子,对于一个分层架构风格的系统而言,开发工程师需要遵循以下规则:只有业务层才能直接访问服务层,表现层不能直接访问服务层。Architecture decisions更多的只是一种约束,违反了这种约束可能并不会对系统的功能造成影响,但是却是系统架构腐化的源头。
Design principles
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.
本文系作者在时代Java发表,未经许可,不得转载。
如有侵权,请联系nowjava@qq.com删除。