摘要：本文主要介紹軟體架構的定義，以及要成為一個軟體架構師所需具備的一些技能，讓你對軟體架構師這一職位有一個更深的瞭解。
本文分享自華為雲社群《想要成為架構師？先看看這些條件滿不滿足！》，原文作者：元閏子 。
前言
當你點開一個招聘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.