架構師，這個title就和總監之類的title一樣，已經徹底被用爛了。但在乙個軟體產品的生命週期中，架構師是實實在在的乙個極度重要的角色。架構師非常重要的職責是編寫整個系統中核心部分的**。這個部分並不一定是技術挑戰最高的，但對整個系統的質量甚至成敗起到非常關鍵的控制作用。架構師必須是從寫核心**的人中誕生而來。畢玄的這篇文章就是主要講他理解的架構師到底應該具備什麼素質。
業務理解和抽象能力
架構師的第一職責是理解業務，並轉換為可被研發理解的實現方案，因此業務理解能力是架構師的必備技能。通常來說乙個資深的業務架構師，對業務會有非常深的認識和積累。乙個極好的業務架構師應該能大概預判業務未來的發展趨勢，以便在系統的可擴充套件性上留好一定的空間。所以也會很自然的出現有些業務架構師做著做著就乾脆轉為pd型別的角色。
抽象能力是通過對業務的理解轉換為系統實現的模型，這顯然也是重要的能力。抽象很多時候也承擔了分解清楚多個團隊的職責，分工清晰化。
nb的**能力
之所以現在很多的架構師都會被認為是大忽悠，就是有一堆頂著架構師頭銜，又不幹活的人（甚至會出現對技術幾乎不太懂的人），光說不幹，再加上說的不靠譜的話，自然很容易被認為是大忽悠。
我一直認為架構師有個非常重要的職責是編寫整個系統中核心部分的**。這個部分並不一定是技術挑戰最高的，但對整個系統的質量甚至成敗起到非常關鍵的控制作用。
所以架構師必須是從寫核心**的人中誕生而來。在乙個跨多領域的大型系統中，架構師不太可能什麼都擅長，不可能寫各個部分的核心**，這種時候架構師一定要知道怎麼判斷非自己知識領域的部分實現是否ok，以確保各部分組合在一起的時候是符合架構設計預期的，通常這種確保各部分組織在一起work的機制部分的**應該由架構師自己操刀。
最關鍵素質：全面
全面是乙個架構師展現出來的最關鍵素質，全面體現為以下三點：
一、在面對業務問題上，架構師腦海裡是否會浮現出多種技術方案：
這點其實挺重要的。否則可能就會出現明明有乙個簡單成熟的方案，但由於不知道而做了其他複雜不成熟的方案，所以廣闊的技術視野是架構師的必備。
另外架構師不可能全部擅長，在自己不擅長的點上，需要知道找哪個專業的人是靠譜的，這點也非常重要。
二、在做系統設計時是否考慮到了足夠多的方方面面：
例如很多系統設計容易遺漏上線環節的細節，導致在上線時發現漏掉了什麼考慮，臨時解決或只能重來。
記得有一年我做的乙個設計沒有考慮到上線階段的乙個細節，導致上線的時候發現由於網段的問題完全不work，並且沒有臨時解決方案，只好重來。
系統設計不僅僅指導研發同學怎麼寫**，也包括指導其他所有相關技術同學的工作。
又例如我2023年在做服務框架設計的時候，集群和集群之間通過硬體負載均衡裝置來訪問的，連線的方式是單個長連線，這個設計導致了執行過程中如果要發布被呼叫的服務方，很容易出現壓力都集中在前面重啟的機器上，這也是典型的整個鏈路沒有考慮清楚造成的設計問題。
再例如2023年我在做乙個比較大範圍的系統改造的設計時，由於對其中一部分的軟體了解得不夠，判斷錯誤，導致後來這個改造在進行過程中才發現有些需要改造的關鍵軟體設計做得太粗糙，最後上線進度差不多推遲了乙個多月，而且那些後來補的設計都是緊急做的，風險非常高。
回顧自己設計過的軟體，發現在這個點上犯的錯可以講好幾天，看來我應該整理另外一篇文件《我在系統設計上犯過的***個錯誤》，裡面有些其實靠乙份好的系統設計模板也許就能避免掉。乙份好的系統設計模板是可以幫助架構師思考全面些的。
三、在做系統設計時是否考慮到了未來的一些發展？
盡可能不要出現未來的一點變化就導致現在白幹或要花大量力氣來改造的現象。
想當年做服務框架的時候，後來就發現由於當年做設計的時候沒有考慮到將來服務呼叫trace的問題，導致了後來為了彌補這點花了巨大的力氣（不是技術上，而是實施上）。
全面需要架構師有足夠廣的技術領域知識和足夠多的經驗積累，從全面這點就可以看到架構師的工作絕不是畫幾個框，連幾根線那麼簡單。
對架構師「全面」這點的挑戰，會隨著系統的範圍越大（乙個系統的設計，和100個系統組成的大系統的設計挑戰是完全不同的）而變得越難，無論是知識的廣度、考慮的點的覆蓋度、還是未來趨勢，更複雜的情況甚至會出現架構的調整對應著組織結構的調整，這種也要考慮到，例如服務化這種大的架構改造，就意味著專職的專業領域服務團隊的成立。
全域性
全域性觀通常是指在系統設計時是否考慮到了對上下游的系統的影響。
畢竟通常所設計的系統不是乙個孤立的系統，如果沒有足夠好的全域性觀，有可能會導致自己的系統做完上線，其他上下游系統（尤其有些連上下游是誰，怎麼用都不知道的情況下）出現問題。這種案例同樣不少。
權衡
權衡同樣也是架構師極度重要的能力。或者也可以認為是決策能力，技術方案的拍板是乙個架構師最重要的職責。
上面說的「全面」是架構師在思考時「放」的過程，而權衡就是「收」的過程。收的過程結束基本就意味著技術方案的確定，同時也確定了節奏。
權衡在兩點上會體現得特別突出：
一、技術方案決策原則：
通常乙個問題都會有多種可解決的技術方案。怎麼來決策就至關重要了，而決策通常又和全面相關。大的來說通常決策的原則就是價效比和可持續發展。
二、優先順序和節奏控制：
經常我會問做系統設計的同學乙個問題：對於這個業務場景而言，在系統設計上最需要把握的乙個點是什麼。
這是乙個關鍵問題，全面意味著考慮到了很多地方的問題，但通常業務需求實現都是有很強的時間要求的，因此在這個時候必須考慮清楚不同點的優先順序，
同時也包括技術方案在決策時也要做出取捨，有可能選了乙個不是那麼好的技術方案，但通過留下一些可改造的空間，為以後的重構做好鋪墊，那就是很不錯的，尤其技術同學有些時候比較容易陷入解決技術問題的場景去，但那個問題其實有可能不是現階段最重要的。
優先順序和節奏控制是我認為乙個最nb的架構師的最佳體現，優先順序意味著把握住了重點，可以確保在所設計的架構指導下業務實現不會出現大問題，節奏控制則意味著全面，知道隨著業務發展該在什麼時間點做什麼事，為將來做好鋪墊。
專訪 奇虎架構師 技術人才轉管理是浪費
fw 自負 的高階技術人才 但是拋開技術能力，談及高階技術人才性格上的一些特質，李釗深有感觸和無奈，很多人才個性比較強，溝通能力差。我帶人帶了十五六年了。從我的經驗看，一般比較優秀的人性格方面或多或少都有點問題。比如說過度自負，導致他攻擊性強，自我認知膨脹，認為某個問題有沒有其他人都無所謂，但沒有他...
專訪神龍首席架構師行憲 有技術信仰的阿里人
摘要 尤里卡！簡單純粹的技術信仰 乙個有技 術信仰的阿里人行憲 尤里卡！尤里卡！阿基公尺德 archimedes，西元前287年 西元前212年 阿里雲飛天八部有一位有技術信仰的技術專家楊航，花名 行憲 作為彈 性裸金屬服 務器的首席架構師，在 軟硬體一體化的 自研道路上，不斷給雲 帶來技術創新。緣...
阿里P7架構師是如何解決跨域問題的！你有遇到嗎？
現在越來越多的專案就算是乙個管理後端也偏向於使用前後端分離的部署方式去做，為了順應時代的潮流，一前後端分離就產生了跨域問題，所以許多同學把跨域和前後端分離專案聯絡在了一起，其實跨域產生的原因並不是前後端分離導致的，那我們一起來看一下，希望可以靠這一篇文章解答大家所有的跨域問題 以上三個條件缺一不可，...