在最近一段時間一直有幾個問題纏繞著我铣缠，架構(gòu)師該做什么？如何成為一個名副其實的架構(gòu)師鹦付？帶著這個問題我查閱了很多資料尚粘，請教了很多人，但依然沒有找到我需要的答案敲长。
請教猛哥郎嫁，他告訴我，就把你對質(zhì)量的知識遷移到質(zhì)量運營就好了潘明，當時不得其解行剂。后來一次和周老師討論這個問題，他說你就別管架構(gòu)師這高深的名詞钳降，就從你擅長的角度思考這個問題厚宰，作為一個質(zhì)量負責人，你需要關(guān)注產(chǎn)品的那些方面遂填？我很快的告訴了他以下六個詞铲觉。
可用、可靠吓坚、易用撵幽、效率、可配置（可維護）礁击、兼容（可移植）
然后他很認真的對我說盐杂，架構(gòu)本身就是為軟件質(zhì)量服務的，你就從你剛才理解的這六個詞重新思考下什么是架構(gòu)哆窿，然后你就明白該如何做了链烈。
回到工位把那六個詞寫下來，并認真思考挚躯，在某個瞬間恍然大悟强衡，這六個詞不就是ISO9126中關(guān)于質(zhì)量模型的六大特性么？有了這個啟發(fā)码荔，我重新從質(zhì)量的視角思考架構(gòu)師的工作漩勤。
1.架構(gòu)師分類
從質(zhì)量模型的上圖從左往右前三個是對用戶來說可以感知的屬感挥，后三個主要是質(zhì)量內(nèi)建相關(guān)的屬性，系統(tǒng)運維運營需要關(guān)注的點越败。這樣來看触幼，功能性、可靠性和易用性眉尸，其實不就是應用架構(gòu)師的職責么域蜗；效率、維護性和可移植性不就是系統(tǒng)架構(gòu)師職責么噪猾？
應用架構(gòu)師：負責構(gòu)建一個以解決特定業(yè)務問題為目標的軟件應用，一般以滿足各種功能性需求以及維護性需求為設計考慮目標筑累；從應用程序的維度袱蜡，偏業(yè)務系統(tǒng)，從用戶的角度關(guān)注業(yè)務理解慢宗，負責某個應用的技術(shù)架構(gòu)坪蚁，梳理模型，設計模式镜沽，接口敏晤，數(shù)據(jù)交互等方面。
系統(tǒng)架構(gòu)師：以企業(yè)的持續(xù)經(jīng)營目標為考慮要素來構(gòu)建企業(yè)所需要的內(nèi)在結(jié)構(gòu)設計缅茉；提供運營支撐軟件應用的信息系統(tǒng)的結(jié)構(gòu)設計嘴脾。從系統(tǒng)的維度，負責整體系統(tǒng)的架構(gòu)設計蔬墩，主要是基礎服務和各系統(tǒng)間協(xié)調(diào)上译打，著眼全局不太注重某個應用本身架構(gòu)，比如關(guān)注服務器負載拇颅，可靠性奏司，伸縮，擴展樟插，數(shù)據(jù)庫切分韵洋，緩存應用等方面的基礎架構(gòu)設計。
當然黄锤，現(xiàn)實中的架構(gòu)師往往會身兼數(shù)職搪缨，而不僅僅是構(gòu)思架構(gòu)本身。比如猜扮，大部分軟件架構(gòu)師也會組織軟件團隊勉吻、進行一些相關(guān)研究，甚至擔負一些行政管理的工作旅赢，在此不再延伸贅述齿桃。
2.架構(gòu)師應該關(guān)注點重點
1. 從功能的角度需要思考：
用戶真正想要什么惑惶？這些是用戶想要的么？是否準確的實現(xiàn)和解決了用戶的需求和痛點短纵？系統(tǒng)的邊界在哪里带污？確定系統(tǒng)干什么不干什么？流程是否合理香到？系統(tǒng)產(chǎn)品之間數(shù)據(jù)流轉(zhuǎn)過程合理鱼冀？系統(tǒng)安全可靠，允許經(jīng)過授權(quán)的用戶和系統(tǒng)能夠正常的訪問相應的數(shù)據(jù)和信息悠就，禁止未授權(quán)的用戶訪問.......
2.從可靠性的角度需要思考：
系統(tǒng)是否成熟可靠千绪，設計時是否考慮系統(tǒng)內(nèi)部錯誤，導致軟件失效的各種異常流程和錯誤的兼容性處理梗脾；軟件出現(xiàn)故障荸型，是否能夠快速修復，甚至自我修復炸茧；失效情況下的如何恢復并正常運行瑞妇？
3.從易用性的角度需要思考：
設計的產(chǎn)品是否符合心理學和行為學，是否能夠很方便快速的被操作者使用和理解梭冠，就像iPhone手機Home鍵設計辕狰，一兩歲的孩子只要探索一兩遍，便能夠很容易操作并使用控漠，作為架構(gòu)師也需要從業(yè)務領域相關(guān)的背景知識中抽取和提練業(yè)務流程蔓倍，并結(jié)合用戶的特點給產(chǎn)品設計提出指導性原則和積極的建議。
4.從效率性的角度需要思考：
需要關(guān)注用戶操作端到端的系統(tǒng)響應時間润脸，實現(xiàn)這個目標柬脸，架構(gòu)師從縱向分解和橫向分解，縱向分解是將整個系統(tǒng)分層毙驯，從而將整體系統(tǒng)分解成下一級的子系統(tǒng)與組件倒堕；橫向分解是在系統(tǒng)分解成不同的邏輯層或服務后，對邏輯層進行分塊爆价，確定層與層之間的關(guān)系垦巴，從中選擇最優(yōu)的一種方案。
并且關(guān)注系統(tǒng)前端到后臺铭段、系統(tǒng)之間業(yè)務數(shù)據(jù)交互的時間及效率骤宣，如業(yè)務響應時間，吞吐率序愚、TPS（每秒事務數(shù)）等業(yè)務指標憔披；以及系統(tǒng)資源的利用率，CPU 內(nèi)存 磁盤 IO 網(wǎng)絡帶寬、隊列芬膝、共享內(nèi)存望门。
5.從軟件維護性的角度需要思考：
主要從運營的角度思考軟件架構(gòu)如何設計，如何能夠快速分析定位問題锰霜；軟件產(chǎn)品出現(xiàn)的失效可以通過外部修改修復筹误，同時又能防止意外修改導致程序失效，確保已修改軟件能被正確的運行的能力癣缅。
6.從軟件可移植性的角度需要思考：
軟件的可移植性就是需要考慮厨剪，軟件從一種環(huán)境遷移到另一種環(huán)境的能力，是否可以在不同的硬件服務器友存、操作系統(tǒng)或者中間件產(chǎn)品上不需要修改就能夠被部署和搭建祷膳；并且能夠很方便快速的被安裝的能力。
3.架構(gòu)師能力要求
架構(gòu)師到底有哪些能力要求呢爬立？網(wǎng)上有張關(guān)于架構(gòu)師能力要求調(diào)研報告钾唬，其中37%的人認為架構(gòu)師的設計能力最重要，技術(shù)實力重要度排在第二占了24%侠驯，溝通能力則排在第三占比14%，此次奕巍，我們詳細分析排在前三的能力吟策。
1.設計能力－擅長整合分析
架構(gòu)是過程，并非結(jié)果的止。架構(gòu)是架構(gòu)師洞察內(nèi)在結(jié)構(gòu)檩坚、原則、規(guī)律與邏輯的過程诅福，架構(gòu)師要做到清晰理解系統(tǒng)匾委，以及簡潔描述，這是分析整合的能力氓润。
一個架構(gòu)師必須具備極強的分析能力赂乐，要做到根據(jù)產(chǎn)品宗旨和目標，分析清楚產(chǎn)品定位以及產(chǎn)品業(yè)務咖气，再整合利用現(xiàn)有的技術(shù)領域挨措，找出最佳方案，實現(xiàn)產(chǎn)品概念崩溪。
2.技術(shù)實力－實現(xiàn)產(chǎn)品規(guī)劃
能夠在業(yè)務需求清楚的前提下浅役，能夠?qū)⒁粋€完整的業(yè)務系統(tǒng)從功能模塊和系統(tǒng)架構(gòu)的角度進行分解，從技術(shù)的角度給予技術(shù)選型提供建議伶唯，前端到底用瘦客戶端還是富客戶端呢觉既？數(shù)據(jù)庫是用MySQL還是MSSQL又或是Oracle呢？等等，架構(gòu)師還應該深入一線解決和攻克技術(shù)難點瞪讼。
3.溝通能力－能夠橫向溝通
架構(gòu)師參與項目開發(fā)全過程钧椰，包括確認需求、系統(tǒng)分解尝艘、架構(gòu)設計演侯、技術(shù)選型、制定技術(shù)規(guī)格說明背亥、系統(tǒng)實現(xiàn)秒际、集成測試和部署各階段，在這一系列過程中狡汉，架構(gòu)師會與各部門溝通交流娄徊。
一個產(chǎn)品會有多部門合作，架構(gòu)師在其中的溝通極為重要盾戴，直接影響產(chǎn)品進度與質(zhì)量寄锐。架構(gòu)師不僅要與開發(fā)人員溝通，也要和項目經(jīng)理尖啡、分析人員甚至用戶溝通橄仆，來實現(xiàn)產(chǎn)品的各種可能性。所以衅斩，對于架構(gòu)師來講盆顾，不僅有技術(shù)方面的要求，還有能夠橫向溝通的要求畏梆。
從以上綜合來看您宪，架構(gòu)師是一個既需要掌控整體又需要洞悉局部瓶頸并依據(jù)具體的業(yè)務場景給出解決方案的團隊領導型人物。架構(gòu)師不是一個人奠涌，他需要建立高效的體系宪巨，帶領團隊去攻城略地，在規(guī)定的時間內(nèi)完成項目溜畅。
以上知識筆者希望從既往工作中捏卓，快速復制和遷移其能力的一些思考，并未經(jīng)過真是檢驗达皿。希望有相關(guān)經(jīng)驗的同學一起思考并給予建議和指導天吓。
特別說明：本文第三部分內(nèi)容，部分內(nèi)容來源于網(wǎng)絡
