前言

當(dāng)你點(diǎn)開(kāi)一個(gè)招聘APP，篩選條件選擇互聯(lián)網(wǎng)技術(shù)，在列出來(lái)的一大堆職位上，往往有那么幾個(gè)帶有“ 架構(gòu)師 ”三個(gè)字眼的高薪職位。當(dāng)你被它的高薪所吸引而點(diǎn)擊查看職位詳情時(shí)，又會(huì)被它的高要求所勸退。它們往往要求工作年限在5年以上，需要求職者有過(guò)3年以上的系統(tǒng)設(shè)計(jì)經(jīng)驗(yàn)，精通各種架構(gòu)模式和系統(tǒng)框架，反觀自己卻一個(gè)條件都不滿足。

軟件架構(gòu)師就是這么一個(gè)讓人向往，但又讓人望洋興嘆的一個(gè)職位。就像建筑設(shè)計(jì)師總有成為總設(shè)計(jì)師的夢(mèng)想，航天工作者總有成為總工程師的壯志，相信每一個(gè)軟件工程師都有過(guò)成為軟件架構(gòu)師的想法。引用維基百科里的定義， 軟件架構(gòu)師的職責(zé)就是在軟件系統(tǒng)研發(fā)中，負(fù)責(zé)依據(jù)需求來(lái)確定主要的技術(shù)選擇、設(shè)計(jì)系統(tǒng)的主體框架結(jié)構(gòu)，并負(fù)責(zé)搭建實(shí)施 。然而，架構(gòu)師所需的技能遠(yuǎn)遠(yuǎn)不止于技術(shù)選擇和系統(tǒng)設(shè)計(jì)。本文主要介紹軟件架構(gòu)的定義，以及要成為一個(gè)軟件架構(gòu)師所需具備的一些技能，讓你對(duì)軟件架構(gòu)師這一職位有一個(gè)更深的了解。

文中大部分的觀點(diǎn)來(lái)自于《Fundamentals of Software Architecture》一書(shū)，想了解更多詳情推薦閱讀原書(shū)。

軟件架構(gòu)的定義

對(duì)于 軟件架構(gòu) （Software Architecture），我們通常將它看成是軟件系統(tǒng)的藍(lán)圖（blueprint），但是如果要給出一個(gè)精確的定義，往往很難。維基百科里對(duì)軟件架構(gòu)的定義為， 有關(guān)軟件整體結(jié)構(gòu)與組件的抽象描述，用于指導(dǎo)大型軟件系統(tǒng)各個(gè)方面的設(shè)計(jì) 。但是，這種定義也是片面的，軟件架構(gòu)并不僅僅是系統(tǒng)的整體結(jié)構(gòu)和組件，光有這些還不足以指導(dǎo)設(shè)計(jì)出好的軟件系統(tǒng)。

Mark Richards和Neal Ford在書(shū)中，從四個(gè)維度上對(duì)軟件架構(gòu)進(jìn)行了描述，分別是 Structure 、 Architecture characteristics 、Architecture decisions和 Design principles 。

軟件架構(gòu)的描述

Structure

Structure描述的是軟件系統(tǒng)所使用的架構(gòu)風(fēng)格 ，比如最常見(jiàn)的分層架構(gòu)（layered architecture）、事件驅(qū)動(dòng)架構(gòu)（event-driven architecture）、微核架構(gòu)（microkernel architecture）、微服務(wù)架構(gòu)（microservices architecture）等等。當(dāng)你去問(wèn)架構(gòu)師一個(gè)軟件系統(tǒng)使用什么架構(gòu)時(shí)，如果他告訴你，“系統(tǒng)使用的是微服務(wù)架構(gòu)”，那么也他僅僅闡明了系統(tǒng)的架構(gòu)風(fēng)格而已。若想了解整個(gè)系統(tǒng)的軟件架構(gòu)，對(duì)architecture characteristics、architecture decisions和design principles都要有深入的認(rèn)識(shí)。

Structure

Architecture characteristics

Architecture characteristics也就是我們常說(shuō)的非功能需求 ，比如有可用性（Availability）、可擴(kuò)展性（Scalability）、可靠性（Reliability）等。Architecture characteristics往往容易被軟件新手所忽略，但是它對(duì)于軟件系統(tǒng)而言卻是非常的重要。如果說(shuō)功能需求決定了一個(gè)軟件系統(tǒng)的下限，那么非功能需求則決定了它的上限。

Architecture characteristics

Architecture decisions

Architecture decisions描述了開(kāi)發(fā)軟件系統(tǒng)時(shí)所必須遵循的規(guī)則 ，比如圖中例子，對(duì)于一個(gè)分層架構(gòu)風(fēng)格的系統(tǒng)而言，開(kāi)發(fā)工程師需要遵循以下規(guī)則：只有業(yè)務(wù)層才能直接訪問(wèn)服務(wù)層，表現(xiàn)層不能直接訪問(wèn)服務(wù)層。Architecture decisions更多的只是一種約束，違反了這種約束可能并不會(huì)對(duì)系統(tǒng)的功能造成影響，但是卻是系統(tǒng)架構(gòu)腐化的源頭。

Architecture decisions

Design principles

Design principles指的是系統(tǒng)設(shè)計(jì)的原則 ，用于引導(dǎo)開(kāi)發(fā)團(tuán)隊(duì)選擇更符合系統(tǒng)特點(diǎn)的技術(shù)方案。Design principles只會(huì)給出一個(gè)方向，而不是具體的實(shí)現(xiàn)方案。比如圖中例子給出的系統(tǒng)設(shè)計(jì)原則就是：微服務(wù)之間應(yīng)該盡可能通過(guò)異步通信來(lái)提升系統(tǒng)的性能。至于開(kāi)發(fā)團(tuán)隊(duì)通過(guò)REST或者RPC的方式進(jìn)行異步通信實(shí)現(xiàn)，設(shè)計(jì)原則并未進(jìn)行限制。

Design principles

成為架構(gòu)師所需的技能

就像軟件架構(gòu)不僅僅是系統(tǒng)的整體結(jié)構(gòu)和組件一樣，要成為一個(gè)軟件架構(gòu)師，只會(huì)技術(shù)選型是遠(yuǎn)遠(yuǎn)不夠的。一個(gè)合格的軟件架構(gòu)師應(yīng)該具備以下的幾種技能：

進(jìn)行架構(gòu)決策

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.

這是一個(gè)架構(gòu)師所需具備的最基本的技能，需要為開(kāi)發(fā)團(tuán)隊(duì)給出系統(tǒng)設(shè)計(jì)的原則和系統(tǒng)開(kāi)發(fā)的約束。 架構(gòu)師在這里的角色更多的是一個(gè)引導(dǎo)者，而不是具體技術(shù)方案的制定者 。比如，開(kāi)發(fā)團(tuán)隊(duì)要進(jìn)行前端框架的選型，作為架構(gòu)師應(yīng)該給出的建議是選擇Reactive風(fēng)格的前端框架（引導(dǎo)團(tuán)隊(duì)在React.js、Angular、Vue.js或者其他Reactive風(fēng)格的前端框架之間進(jìn)行選擇），而不是直接建議選擇React.js框架。前者屬于架構(gòu)決策，而后者則是技術(shù)決策。

持續(xù)對(duì)系統(tǒng)架構(gòu)進(jìn)行分析

An architect is expected to continually analyze the architecture and current technology environment and then recommend solutions for improvement.

就像一個(gè)軟件系統(tǒng)的生命周期并不止于開(kāi)發(fā)階段的結(jié)束，軟件架構(gòu)也不是一錘子買賣。這就要求架構(gòu)師能夠持續(xù)對(duì)系統(tǒng)架構(gòu)進(jìn)行分析，并提出改進(jìn)的建議，使得系統(tǒng)在面對(duì)業(yè)務(wù)和技術(shù)的雙重變化時(shí)，仍然能夠保持架構(gòu)良好。

保持對(duì)技術(shù)和業(yè)界的發(fā)展趨勢(shì)的敏感

An architect is expected to keep current with the latest technology and industry trends

作為一個(gè)架構(gòu)師必須時(shí)刻保持對(duì)技術(shù)和業(yè)界發(fā)展趨勢(shì)的敏感。在敏捷開(kāi)發(fā)的潮流下，軟件的特性會(huì)頻繁的發(fā)生變化，但是軟件的基礎(chǔ)架構(gòu)往往是很少改變的。架構(gòu)師如果不能把握當(dāng)前技術(shù)和業(yè)界發(fā)展的趨勢(shì)，從而導(dǎo)致設(shè)計(jì)出來(lái)的軟件架構(gòu)不能夠應(yīng)付未來(lái)幾年的業(yè)務(wù)和技術(shù)變化，這對(duì)于一個(gè)軟件系統(tǒng)而言將會(huì)是災(zāi)難性的。

確保團(tuán)隊(duì)按照既定的規(guī)則進(jìn)行開(kāi)發(fā)

An architect is expected to ensure compliance with architecture decisions and design principles.

架構(gòu)師不僅僅需要制定設(shè)計(jì)原則和開(kāi)發(fā)約束，還需要確保團(tuán)隊(duì)能夠一直按照這些規(guī)則進(jìn)行軟件開(kāi)發(fā)。這就要求架構(gòu)師對(duì)開(kāi)發(fā)人員提交的核心代碼進(jìn)行Code Review，否則系統(tǒng)的架構(gòu)很容易就腐化掉了。

擴(kuò)展知識(shí)的廣度

An architect is expected to have exposure to multiple and diverse technologies, frameworks, platforms, and environments.

對(duì)于一個(gè)架構(gòu)師而言，他并不需要精通每一種框架、平臺(tái)和語(yǔ)言，但至少要盡可能多的了解它們，這樣才能更好的支撐架構(gòu)決策。這就要求架構(gòu)師能夠持續(xù)的學(xué)習(xí)新的知識(shí)，不斷地跳出自己的舒適區(qū)。最好的情況就是精通2～3種語(yǔ)言和框架，并且熟悉業(yè)界各種常用的語(yǔ)言和框架，這樣的知識(shí)深度和廣度的結(jié)合才能設(shè)計(jì)出更好的軟件架構(gòu)。

擁有一定的領(lǐng)域知識(shí)

An architect is expected to have a certain level of business domain expertise.

所有的技術(shù)都是服務(wù)于既有的業(yè)務(wù)，剝離了業(yè)務(wù)的軟件技術(shù)毫無(wú)價(jià)值 。架構(gòu)師無(wú)需像領(lǐng)域?qū)＜乙粯泳ㄏ到y(tǒng)的各種業(yè)務(wù)，但至少也要有一定的業(yè)務(wù)積累。軟件是用來(lái)解決問(wèn)題的，不懂業(yè)務(wù)的架構(gòu)師來(lái)做軟件架構(gòu)設(shè)計(jì)，就相當(dāng)于還沒(méi)讀懂題目就開(kāi)始解題，結(jié)果往往適得其反。比如一個(gè)需要低時(shí)延的業(yè)務(wù)，交給一個(gè)不懂業(yè)務(wù)的架構(gòu)師來(lái)進(jìn)行系統(tǒng)設(shè)計(jì)，可能得出來(lái)的是一個(gè)高吞吐量的架構(gòu)。

人際交往的能力

An architect is expected to possess exceptional interpersonal skills, including teamwork, facilitation, and leadership.

對(duì)于大部分的開(kāi)發(fā)工程師和架構(gòu)師而言，這可能是最難的一條了要求了。他們很擅長(zhǎng)，也很樂(lè)意去解決技術(shù)上的問(wèn)題，但是對(duì)于與人相關(guān)的問(wèn)題則相當(dāng)?shù)牡钟|。但這對(duì)于一個(gè)合格架構(gòu)師來(lái)說(shuō)所必須克服的一點(diǎn)，因?yàn)榧軜?gòu)師不僅僅需要制定技術(shù)規(guī)則，更重要的是領(lǐng)導(dǎo)團(tuán)隊(duì)按照既定規(guī)則進(jìn)行開(kāi)發(fā)，這不可避免地就涉及到領(lǐng)導(dǎo)力和人際交往的能力。

當(dāng)一個(gè)開(kāi)發(fā)工程師決定在一次需求開(kāi)發(fā)中采用單例模式，可能團(tuán)隊(duì)里的其他人并不會(huì)有太多的關(guān)注。但是當(dāng)一個(gè)架構(gòu)師決定采用微服務(wù)架構(gòu)來(lái)設(shè)計(jì)系統(tǒng)時(shí)，可能就會(huì)受到團(tuán)隊(duì)內(nèi)各類人員的挑戰(zhàn)，比如版本經(jīng)理可能覺(jué)得微服務(wù)架構(gòu)太復(fù)雜，會(huì)不會(huì)影響交付的節(jié)奏；開(kāi)發(fā)人員可能覺(jué)得分層架構(gòu)更好實(shí)現(xiàn)。這種情況下就要求架構(gòu)師能夠有很好的人際交往能力，說(shuō)服各類人員，這樣項(xiàng)目才能更好的進(jìn)行下去。

總結(jié)

軟件架構(gòu)是一個(gè)很抽象的東西，目前對(duì)它的定義大部分都是一些很寬泛的描述?！禙undamentals of Software Architecture》從四個(gè)維度上對(duì)軟件架構(gòu)進(jìn)行了描述，讓軟件架構(gòu)有了一個(gè)更加清晰的視圖。在此基礎(chǔ)上，書(shū)中也提出了一個(gè)合格的軟件架構(gòu)師所需要具備的幾種技能。總的來(lái)說(shuō)，就是 想要設(shè)計(jì)出一個(gè)好的軟件架構(gòu)很難，要成為一個(gè)好的軟件架構(gòu)師更難 。

另外，書(shū)中還提出了軟件架構(gòu)的兩個(gè)準(zhǔn)則，很有道理，就是有點(diǎn)抽象。不過(guò)沒(méi)關(guān)系， 不要試圖理解它，要去感受它 。

1、Everything in software architecture is a trade-off.

2、Why is more important than how.