前言

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

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

文中大部分的觀點來自于《Fundamentals of Software Architecture》一書，想了解更多詳情推薦閱讀原書。

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

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

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

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

Structure

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

Structure

Architecture characteristics

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

Architecture characteristics

Architecture decisions

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

Architecture decisions

Design principles

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

Design principles

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

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

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

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

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

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

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

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

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

確保團隊按照既定的規(guī)則進行開發(fā)

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

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

擴展知識的廣度

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

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

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

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

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

人際交往的能力

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

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

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

總結(jié)

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

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

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

2、Why is more important than how.