摘要：软件架构师就是这么一个让人向往，但又让人望洋兴叹的一个职位。
前言
当你点开一个招聘 APP，筛选条件抉择互联网技术，在列出来的一大堆职位上，往往有那么几个带有“架构师”三个字眼的高薪职位。当你被它的高薪所吸引而点击查看职位详情时，又会被它的高要求所劝退。它们往往要求工作年限在 5 年以上，须要求职者有过 3 年以上的零碎设计教训，精通各种架构模式和零碎框架，反观本人却一个条件都不满足。
软件架构师就是这么一个让人向往，但又让人望洋兴叹的一个职位。就像修建设计师总有成为总设计师的幻想，航天工作者总有成为总工程师的壮志，置信每一个软件工程师都有过成为软件架构师的想法。援用维基百科里的定义，软件架构师的职责就是在软件系统研发中，负责根据需要来确定次要的技术抉择、设计零碎的主体框架结构，并负责搭建施行。然而，架构师所需的技能远远不止于技术抉择和零碎设计。本文次要介绍软件架构的定义，以及要成为一个软件架构师所需具备的一些技能，让你对软件架构师这一职位有一个更深的理解。
文中大部分的观点来自于《Fundamentals of Software Architecture》一书，想理解更多详情举荐浏览原书。
软件架构的定义
对于 软件架构 （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.
所有的技术都是服务于既有的业务，剥离了业务的软件技术毫无价值。架构师无需像领域专家一样精通零碎的各种业务，但至多也要有肯定的业务积攒。软件是用来解决问题的，不懂业务的架构师来做软件架构设计，就相当于还没读懂题目就开始解题，后果往往事与愿违。比方一个须要低时延的业务，交给一个不懂业务的架构师来进行零碎设计，可能得进去的是一个高吞吐量的架构。
人际交往的能力
An architect is expected to possess exceptional interpersonal skills, including teamwork, facilitation, and leadership.
对于大部分的开发工程师和架构师而言，这可能是最难的一条了要求了。他们很善于，也很乐意去解决技术上的问题，然而对于与人相干的问题则相当的冲突。但这对于一个合格架构师来说所必须克服的一点，因为架构师不仅仅须要制订技术规定，更重要的是领导团队依照既定规定进行开发，这不可避免地就波及到领导力和人际交往的能力。
当一个开发工程师决定在一次需要开发中采纳单例模式，可能团队里的其他人并不会有太多的关注。然而当一个架构师决定采纳微服务架构来设计零碎时，可能就会受到团队内各类人员的挑战，比方版本经理可能感觉微服务架构太简单，会不会影响交付的节奏；开发人员可能感觉分层架构更好实现。这种状况下就要求架构师可能有很好的人际交往能力，压服各类人员，这样我的项目能力更好的进行上来。
总结
软件架构是一个很形象的货色，目前对它的定义大部分都是一些很宽泛的形容。
《Fundamentals of Software Architecture》从四个维度上对软件架构进行了形容，让软件架构有了一个更加清晰的视图。在此基础上，书中也提出了一个合格的软件架构师所须要具备的几种技能。总的来说，就是 想要设计出一个好的软件架构很难，要成为一个好的软件架构师更难。
另外，书中还提出了软件架构的两个准则，很有情理，就是有点形象。不过没关系，不要试图了解它，要去感触它。
1、Everything in software architecture is a trade-off.
2、Why is more important than how
看完三件事❤️
如果你感觉这篇内容对你还蛮有帮忙，我想邀请你帮我三个小忙：
- 点赞，转发，有你们的『点赞和评论』，才是我发明的能源。
- 关注公众号『Java 斗帝』，不定期分享原创常识。
- 同时能够期待后续文章 ing????