摘要:本文主要介紹軟件架構的定義,以及要成爲一個軟件架構師所需具有的一些技能,讓你對軟件架構師這一職位有一個更深的瞭解。
本文分享自華爲雲社區《想要成爲架構師?先看看這些條件滿不知足!》,原文做者:元閏子 。前端
前言
當你點開一個招聘APP,篩選條件選擇互聯網技術,在列出來的一大堆職位上,每每有那麼幾個帶有「架構師」三個字眼的高薪職位。當你被它的高薪所吸引而點擊查看職位詳情時,又會被它的高要求所勸退。它們每每要求工做年限在5年以上,須要求職者有過3年以上的系統設計經驗,精通各類架構模式和系統框架,反觀本身卻一個條件都不知足。segmentfault
軟件架構師就是這麼一個讓人嚮往,但又讓人望洋興嘆的一個職位。就像建築設計師總有成爲總設計師的夢想,航天工做者總有成爲總工程師的壯志,相信每個軟件工程師都有過成爲軟件架構師的想法。引用維基百科裏的定義,軟件架構師的職責就是在軟件系統研發中,負責依據需求來肯定主要的技術選擇、設計系統的主體框架結構,並負責搭建實施。然而,架構師所需的技能遠遠不止於技術選擇和系統設計。本文主要介紹軟件架構的定義,以及要成爲一個軟件架構師所需具有的一些技能,讓你對軟件架構師這一職位有一個更深的瞭解。前端框架
文中大部分的觀點來自於《Fundamentals of Software Architecture》一書,想了解更多詳情推薦閱讀原書。架構
對於軟件架構(Software Architecture),咱們一般將它當作是軟件系統的藍圖(blueprint),可是若是要給出一個精確的定義,每每很難。維基百科裏對軟件架構的定義爲,有關軟件總體結構與組件的抽象描述,用於指導大型軟件系統各個方面的設計。可是,這種定義也是片面的,軟件架構並不只僅是系統的總體結構和組件,光有這些還不足以指導設計出好的軟件系統。框架
Mark Richards和Neal Ford在書中,從四個維度上對軟件架構進行了描述,分別是Structure、Architecture characteristics、Architecture decisions和Design principles。
dom
Structure描述的是軟件系統所使用的架構風格,好比最多見的分層架構(layered architecture)、事件驅動架構(event-driven architecture)、微核架構(microkernel architecture)、微服務架構(microservices architecture)等等。當你去問架構師一個軟件系統使用什麼架構時,若是他告訴你,「系統使用的是微服務架構」,那麼也他僅僅闡明瞭系統的架構風格而已。若想了解整個系統的軟件架構,對architecture characteristics、architecture decisions和design principles都要有深刻的認識。
異步
Architecture characteristics也就是咱們常說的非功能需求,好比有可用性(Availability)、可擴展性(Scalability)、可靠性(Reliability)等。Architecture characteristics每每容易被軟件新手所忽略,可是它對於軟件系統而言倒是很是的重要。若是說功能需求決定了一個軟件系統的下限,那麼非功能需求則決定了它的上限。
ide
Architecture decisions描述了開發軟件系統時所必須遵循的規則,好比圖中例子,對於一個分層架構風格的系統而言,開發工程師須要遵循如下規則:只有業務層才能直接訪問服務層,表現層不能直接訪問服務層。Architecture decisions更多的只是一種約束,違反了這種約束可能並不會對系統的功能形成影響,可是倒是系統架構腐化的源頭。
微服務
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》從四個維度上對軟件架構進行了描述,讓軟件架構有了一個更加清晰的視圖。在此基礎上,書中也提出了一個合格的軟件架構師所須要具有的幾種技能。總的來講,就是想要設計出一個好的軟件架構很難,要成爲一個好的軟件架構師更難。
另外,書中還提出了軟件架構的兩個準則,頗有道理,就是有點抽象。不過不要緊,不要試圖理解它,要去感覺它。
一、Everything in software architecture is a trade-off.
二、Why is more important than how.