從程序員到架構師 - 架構師篇

圖片

對工作多年的程序員而言，日後的職業發展無非是專精技術，轉型管理，晉升架構師三種選擇。成爲一名優秀的架構師，是大多數技術人的追求。想要做架構，空有一身技術是遠遠不夠的，知識的深度和廣度，往往會決定一個架構師的架構能力。而這些知識，從你踏入 IT 行業那一刻起，甚至更早就應該開始儲備了。那麼到底什麼是架構師？如果有一天把你丟到架構師的位置上你會怎麼做？做什麼呢？以下來具體闡述下一些看法和建議！

先看看 IT 市場對於架構師的職位要求：

架構師要求

綜述：

系統性，知其然知其所以然。是某一個領域的專家，在專業領域具備一定的預見性，可獨立領導跨部門的項目。

項目管理：

具備較高複雜度的 (項目如鏈路較長 / 模塊複雜度較高 / 風險較大 / 發佈週期較緊 / 技術驅動等任意兩項及以上) 的 PM 經驗和能力。

開發語言技能及架構能力：

1、可以寫出比較優秀的代碼，能夠基於設計原則及模式掌握代碼演變的方向和節奏；具備技術攻堅的能力；

2、具備高複雜度的平臺 / 框架 / 業務系統技術與架構設計能力，掌握常見的架構設計方法和模式，理解大型網站所需要用到的架構和技術；

3、熟悉業務的價值、特點及對系統的要求，掌握領域建模的方法，可以對業務進行必要的抽象，並推進技術實現；

4、能夠負責複雜度高，平臺級產品或跨團隊的產品架構，系統設計和實現。

業務理解：

1、行業開發：開發熟悉自己直接負責的及上下游相關的業務，關注業務發展相關的數據並能有效的分析解讀；

2、平臺開發：熟悉所在業務域，並且負責核心業務目標的分解 & 落地；能夠把縱向行業需求落地爲橫向產品化形態；

3、在業務及產品規劃方面有自己獨立的思考，能夠影響業務及產品的發展方向。

影響：

1、在所處的業務線具有廣泛的影響力，對相應涉及的技術和業務都能有足夠的公信力；2、具備輔導他人的能力和技能，有良好的分享習慣，對團隊有正向影響和幫助。

一

架構師職責

架構師是一個既需要掌控整體又要洞悉局部瓶頸，並依據具體的業務場景給出解決方案的團隊領導型人物，他需要參與項目開發的全部過程，包括需求分析、架構設計、系統實現、集成、測試和部署各個階段，負責在整個項目中對技術活動和技術說明進行指導和協調。

架構師主要職責有 4 條：

在項目開發過程中，架構師是在需求規格說明書完成後介入的，需求規格說明書必須得到架構師的認可。架構師需要和分析人員反覆交流，以保證自己完整並準確地理解用戶需求。

系統分解

依據用戶需求，架構師將系統整體分解爲更小的子系統和組件，從而形成不同的邏輯層或服務。隨後，架構師會確定各層的接口，層與層相互之間的關係。架構師不僅要對整個系統分層，進行 “縱向” 分解，還要對同一邏輯層分塊，進行 “橫向” 分解。

      架構師的功力基本體現於此，這是一項相對複雜的工作。

技術選型

架構師通過對系統的一系列的分解，最終形成了軟件的整體架構。技術選擇主要取決於軟件架構。Web Server 運行在 Windows 上還是 Linux 上？數據庫採用 MSSql、Oracle 還是 Mysql？需要不需要採用 MVC 或者 Spring 等輕量級的框架？前端採用富客戶端還是瘦客戶端方式？類似的工作，都需要在這個階段提出，並進行評估。

架構師對產品和技術的選型僅僅限於評估，沒有決定權，最終的決定權歸項目經理。架構師提出的技術方案爲項目經理提供了重要的參考信息，項目經理會從項目預算、人力資源、時間進度等實際情況進行權衡，最終進行確認。

制定技術規格說明

架構師在項目開發過程中，是技術權威。他需要協調所有的開發人員，與開發人員一直保持溝通，始終保證開發者依照它的架構意圖去實現各項功能。

架構師與開發者溝通的最重要的形式是技術規格說明書，它可以是 UML 視圖、Word 文檔，Visio 文件等各種表現形式。通過架構師提供的技術規格說明書，保證開發者可以從不同角度去觀察、理解各自承擔的子系統或者模塊。

架構師不僅要保持與開發者的溝通，也需要與項目經理、需求分析員，甚至與最終用戶保持溝通。所以，對於架構師來講，不僅有技術方面的要求，還有人際交流方面的要求。

架構師綜合能力

作爲架構師，必須成爲所在開發團隊的技術路線引導者，具有很強的系統思維的能力；需要從大量互相沖突的系統方法和工具中區分出哪些是有效的，哪些是無效的。架構師應當是一個成熟的、豐富的、有經驗的、學習快捷、善溝通和決策能力強的人。他必須廣泛瞭解各種技術並精通一種特定技術，至少了解計算機通用技術以便確定哪種技術最優，或組織團隊開展技術評估。優秀的架構師能考慮並評估所有可用來解決問題的總體技術方案。需要良好的書面和口頭溝通技巧，一般通過可視化模型和小組討論來溝通指導團隊確保開發人員按照架構建造系統。

所以作爲架構師需要如下的綜合能力：

溝通能力

爲了提高效率，架構師必須贏得團隊成員、項目經理、客戶或用戶認同，這就需要架構師具有較強的溝通能力。溝通能力是人類最普遍性的素質要求，技術人員好像容易忽略，想成爲架構師就不能忽略。千萬不要抱着這樣的觀念：懷纔跟懷孕似的，時間久了總會被人發現的。還是天橋上賣大力丸的哥們說得對：光說不練假把式，光練不說傻把式。看看你周圍的頭頭腦腦們，哪一個不是此中高手，我們千萬不要鄙視，認爲這是阿諛奉承、投機鑽營，凡事都要看到積極的一面，“溝通” 的確是一種能力。我認爲自己是一個略內向的人，因爲我是農村出來的孩子，普通話都說不好，以前或多或少帶有點自卑感，幻想着是金子總會發光，所以在職業生涯中吃了不少虧。現在，我深深懂得了溝通的重要性，我會很主動地跟同事們，跟老大們不定時地溝通，感覺工作起來順暢多了。

這一條我認爲最爲重要，所以排在首位。我甚至認爲下面幾條都可以忽略，唯一這一條得牢記，而且要常常提醒自己

技術能力

架構師最好精通 1-2 個技術，具備這種技術能力可以更加深入的理解有關架構的工作原理，也可以拉近和開發人員的距離，並形成團隊中的影響力。

架構師的技術知識廣度也很重要，需要了解儘可能多的技術，所謂見多識廣，只有這樣，纔可能綜合各種技術，選擇更加適合項目的解決方案。有的人說，架構師技術廣度的要求高於技術深度的要求，這是很有道理的。總而言之，一句話：架構師是項目團隊中的技術權威。

架構能力

架構是架構師洞察內在結構、原則、規律與邏輯的過程，架構師要做到清晰理解系統、簡潔描述，除此之外，一個架構師還必須具備極強的分析能力，要做到根據產品宗旨和目標，分析清楚產品定位、產品業務，再整合利用現有的技術領域，找出最佳方案，實現產品概念。

抽象分析

架構師必須具備抽象思維和分析的能力，這是你進行系統分析和系統分解的基本素質。只有具備這樣的能力，架構師才能看清系統的整體，掌控全局，這也是架構師大局觀的形成基礎。你如何具備這種能力呢？一是來自於經驗，二是來自於學習。架構師不僅要具備在問題領域上的經驗，也需要具備在軟件工程領域內的經驗。也就是說，架構師必須能夠準確得理解需求，然後用軟件工程的思想，把需求轉化和分解成可用計算機語言實現的程度。經驗的積累是需要一個時間過程的，這個過程誰也幫不了你，是需要你去經歷的。但是，如果你有意識地去培養，不斷吸取前人的經驗的話，還是可以縮短這個週期的。

決策能力

決策能力是一個架構師最重要的職責。

1. 技術方案決策原則

通常一個問題都會有多種可解決的技術方案，怎麼來決策就至關重要了，而決策通常又和全面相關，大的來說通常決策的原則就是性價比和可持續發展。性價比簡單來說是方案的實現成本，這個成本要包括非常多的方面，例如有些場景可能會是用硬件解決看起來是花錢，但最終折算成本是最划算的，很多系統設計在決策性價比時都過於隨意，例如一個另外常見的場景就是建設一套新系統替代舊系統，這個時候可能完全沒考慮舊系統的遷移代價甚至超過了改造舊系統的代價；

可持續發展簡單來說就是所選擇的技術方案在公司是否可持續，例如簡單的案例是公司主體的研發人員都是 php，卻搞一個其他語言，且只有極少人懂的（當然，這還是要看性價比，如果搞一個其他語言帶來的效益超過了語言 / 人才體系的更換成本），又例如引入一個開源產品，有無專業團隊維護這都是要考慮的關鍵因素。

2. 優先級和節奏控制

經常我會問做系統設計的同學一個問題：對於這個業務場景而言，在系統設計上最需要把握的一個點是什麼；這是一個關鍵問題，全面意味着考慮到了很多地方的問題，但通常業務需求實現都是有很強的時間要求的，因此在這個時候必須考慮清楚不同點的優先級，同時也包括技術方案在決策時也要做出取捨，有可能選了一個不是那麼好的技術方案，但通過留下一些可改造的空間，爲以後的重構做好鋪墊，那就是很不錯的，尤其技術同學有些時候比較容易陷入解決技術問題的場景去，但那個問題其實有可能不是現階段最重要的。

優先級和節奏控制是我認爲一個優秀的架構師的最佳體現，優先級意味着把握住了重點，可以確保在所設計的架構指導下業務實現不會出現大問題，節奏控制則意味着全面，知道隨着業務發展該在什麼時間點做什麼事，爲將來做好鋪墊。

架構師技能

技能樹

圖片

架構優化思路

架構優化一方面是優化系統交易鏈上的每個環節進行分析並優化，另一方面是對單一架構進行瓶頸點分析和調優。但是優化的目標大致相同，最終目的是提高系統的響應速度、吞吐量、降低各個模塊之間的耦合。

優化原則

1. 在應用系統的設計、開發過程用中，應始終把性能放在考慮的範圍內。

2. 確定清晰明確的性能目標是關鍵。

3. 性能調優是伴隨整個項目週期的，最好進行分階段設定目標開展，在達到預期性能目標之後即可對本階段工作進行總結和知識轉移進入下一階段調優工作。

4. 必須保證調優後的程序運行正確。

5. 性能更大程度是取決於良好的設計，調優技巧只是一個輔助手段。

6. 調優過程是疊代漸進的過程，每次調優的結果要反饋到後續的代碼開發中去。

7. 性能調優不能以犧牲代碼的可讀性和維護性爲代價。

後端優化手段

1. 硬件升級

   硬件問題對性能的影響不容忽視。

   舉一個例子：一個 DB 集羣經常有慢 SQL 報警，業務排查下來發現 SQL 都很簡單，該做的索引優化也都做了。後來 DBA 同學幫忙定位到問題是硬件過舊導致，將機械硬盤升級成固態硬盤之後報警立馬消失了，效果立竿見影！

2. 緩存化

   緩存可以稱的上是性能優化的利器，使用緩存時需要考慮緩存命中率、緩存更新、數據一致性、緩存穿透及雪崩、Value 過大等問題，可以通過 mutiGet 將多次請求合併一次、異步訪問等方式來提升緩存讀取的性能。

3. 產品邏輯優化

   業務邏輯優化經常會容易被忽略，但效果卻往往比數據庫調優、JVM 調優之類的來的更明顯。

   舉一個例子，12306 春運搶火車票的場景，由於訪問的人多，用戶點擊 “查票” 之後系統會非常卡，進度條非常慢，作爲用戶，我們會習慣性的再去點“查票”，可能會連續點個好幾次。假設平均一個用戶點 5 次，則後端系統負載就增加了 5 倍！而其中 80% 的請求是重複請求。這個時候我們可以通過產品邏輯的方式來優化，比如，在用戶點擊查詢之後將“按鈕置灰”，或者通過 JS 控制 xx 秒只能只能提交一次請求等，有效的攔截了 80% 的無效流量。

4. 服務化

   做服務化最基礎的是按業務做服務拆分，避免跨業務間的互相影響，數據和服務同時拆分。同一個業務內部我們還按計算密集型 / IO 密集型的服務拆分、C 端 / B 端服務拆分、核心 / 非核心服務拆分、高頻服務單獨部署等原則做拆分。

5. 異步化

   異步化可以利用線程池、消息隊列等方式實現。

   使用線程池的時候一定要注意核心參數的設置，可以通過監控工具去觀測實際創建、活躍、空閒的線程數，結合 CPU、內存的使用率情況來做線程池調優。

   另一種是通過 NIO 實現異步化，一切網絡 IO 皆可異步：RPC 框架、Servlet 3.0 提供的異步技術、Apache HttpAsyncClient、緩存異步接口等等。

6. 搜索引擎

   複雜查詢以及一些聚合計算不適合在數據庫中做，可以利用搜索引擎來實現，另外搜索引擎還可以幫我們很好的解決跨庫、跨數據源檢索的場景。

數據庫優化

數據庫優化原則

• 優先考慮緩存降低對數據庫的讀操作。

• 再考慮讀寫分離，降低數據庫寫操作。

• 最後開始數據拆分, 切分模式：首先垂直（縱向）拆分、再次水平拆分。

• 首先考慮按照業務垂直拆分。

• 再考慮水平拆分：先分庫 (設置數據路由規則，把數據分配到不同的庫中)

• 最後再考慮分表，單表拆分到數據 1000 萬以內。

數據庫垂直、水平拆分

數據拆分前其實是要首先做準備工作的，然後纔是開始數據拆分，我先講拆分前需要做的事情：

第一步：採用分佈式緩存 redis、memcached 等降低對數據庫的讀操作。

第二步：如果緩存使用過後，數據庫訪問量還是非常大，可以考慮數據庫讀、寫分離原則。

第三步：當我們使用讀寫分離、緩存後，數據庫的壓力還是很大的時候，這就需要使用到數據庫拆分了。

數據庫拆分原則：就是指通過某種特定的條件，按照某個維度，將我們存放在同一個數據庫中的數據分散存放到多個數據庫（主機）上面以達到分散單庫（主機）負載的效果。

垂直拆分

一個數據庫由很多表的構成，每個表對應着不同的業務，垂直切分是指按照業務將表進行分類，分佈到不同的數據庫上面，這樣也就將數據或者說壓力分擔到不同的庫上面 。

比如淘寶中期開始的數據庫端按照業務垂直拆分：按照業務交易數據庫、用戶數據庫、商品數據庫、店鋪數據庫等進行拆分。

    優缺點

優點：

1. 拆分後業務清晰，拆分規則明確。

2. 系統之間整合或擴展容易。

3. 數據維護簡單。

缺點：

1. 部分業務表無法 join，只能通過接口方式解決，提高了系統複雜度。

2. 受每種業務不同的限制存在單庫性能瓶頸，不易數據擴展跟性能提高。

3. 事務處理複雜。

水平拆分

垂直拆分後遇到單機瓶頸，可以使用水平拆分。相對於垂直拆分的區別是：垂直拆分是把不同的表拆到不同的數據庫中，而水平拆分是把同一個表拆到不同的數據庫中。

相對於垂直拆分，水平拆分不是將表的數據做分類，而是按照某個字段的某種規則來分散到多個庫之中，每個表中包含一部分數據。簡單來說，我們可以將數據的水平切分理解爲是按照數據行的切分，就是將表中 的某些行切分到一個數據庫，而另外的某些行又切分到其他的數據庫中。

分庫分表需要涉及到對應的 SQL 路由規則主庫備庫等，例如：淘寶設計了一套 TDDL 來解決這些問題，應用端只需配置對應的規則即可，對應用端的沒有任何侵入的設計。

水平拆分，總之，一般先分庫，如果分庫後查詢仍然慢，於是按照分庫的思想開始做分表的工作數據庫採用分佈式數據庫（所有節點的數據加起來纔算是整體數據），文件系統採用分佈式文件系統任何強大的單一服務器都滿足不了大型系統持續增長的業務需求，數據庫讀寫分離隨着業務的發展最終也將無法滿足需求，需要使用分佈式數據庫及分佈式文件系統來支撐。

總結

架構師是一個充滿挑戰的職業，知識面的寬窄往往決定着一個架構師的架構能力，所以在這一點上我比較贊成，就是要閱讀大量的技術書籍，但我希望你不要僅限於軟件相關的書籍，經常泡技術論壇，一方面可以結交朋友，一方面可以增加自己的知識面。

總之，想要成爲架構師，需要有耐心，不斷學習，拓寬自己的視野，不僅僅侷限於自己眼前的項目，關注開源技術，關注熱門技術社區的新動向。

公衆號回覆：技術羣， 可以加入技術瑣話粉絲羣。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/iYXlaHcbWSV8Gpey5FcbMw