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

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

一

架構師職責

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

架構師主要職責有4條：

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

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

      架構師的功力基本體現(xiàn)于此，這是一項相對復雜的工作。

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

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

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

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

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

二

架構師綜合能力

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

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

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

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

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

架構師的技術知識廣度也很重要，需要了解盡可能多的技術，所謂見多識廣，只有這樣，才可能綜合各種技術，選擇更加適合項目的解決方案。有的人說，架構師技術廣度的要求高于技術深度的要求，這是很有道理的?？偠灾痪湓挘杭軜嫀熓琼椖繄F隊中的技術權威。

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

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

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

1. 技術方案決策原則

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

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

2. 優(yōu)先級和節(jié)奏控制

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

優(yōu)先級和節(jié)奏控制是我認為一個優(yōu)秀的架構師的最佳體現(xiàn)，優(yōu)先級意味著把握住了重點，可以確保在所設計的架構指導下業(yè)務實現(xiàn)不會出現(xiàn)大問題，節(jié)奏控制則意味著全面，知道隨著業(yè)務發(fā)展該在什么時間點做什么事，為將來做好鋪墊。

三

架構師技能

架構優(yōu)化一方面是優(yōu)化系統(tǒng)交易鏈上的每個環(huán)節(jié)進行分析并優(yōu)化，另一方面是對單一架構進行瓶頸點分析和調(diào)優(yōu)。但是優(yōu)化的目標大致相同，最終目的是提高系統(tǒng)的響應速度、吞吐量、降低各個模塊之間的耦合。

1. 在應用系統(tǒng)的設計、開發(fā)過程用中，應始終把性能放在考慮的范圍內(nèi)。

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

3. 性能調(diào)優(yōu)是伴隨整個項目周期的，最好進行分階段設定目標開展，在達到預期性能目標之后即可對本階段工作進行總結和知識轉(zhuǎn)移進入下一階段調(diào)優(yōu)工作。

4. 必須保證調(diào)優(yōu)后的程序運行正確。

5. 性能更大程度是取決于良好的設計，調(diào)優(yōu)技巧只是一個輔助手段。

6. 調(diào)優(yōu)過程是疊代漸進的過程，每次調(diào)優(yōu)的結果要反饋到后續(xù)的代碼開發(fā)中去。

7. 性能調(diào)優(yōu)不能以犧牲代碼的可讀性和維護性為代價。

1. 硬件升級

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

   舉一個例子：一個DB集群經(jīng)常有慢SQL報警，業(yè)務排查下來發(fā)現(xiàn)SQL都很簡單，該做的索引優(yōu)化也都做了。后來DBA同學幫忙定位到問題是硬件過舊導致，將機械硬盤升級成固態(tài)硬盤之后報警立馬消失了，效果立竿見影！

2. 緩存化

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

3. 產(chǎn)品邏輯優(yōu)化

   業(yè)務邏輯優(yōu)化經(jīng)常會容易被忽略，但效果卻往往比數(shù)據(jù)庫調(diào)優(yōu)、JVM調(diào)優(yōu)之類的來的更明顯。

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

4. 服務化

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

5. 異步化

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

   使用線程池的時候一定要注意核心參數(shù)的設置，可以通過監(jiān)控工具去觀測實際創(chuàng)建、活躍、空閑的線程數(shù)，結合CPU、內(nèi)存的使用率情況來做線程池調(diào)優(yōu)。

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

6. 搜索引擎

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

• 優(yōu)先考慮緩存降低對數(shù)據(jù)庫的讀操作。

• 再考慮讀寫分離，降低數(shù)據(jù)庫寫操作。

• 最后開始數(shù)據(jù)拆分,切分模式：首先垂直（縱向）拆分、再次水平拆分。

• 首先考慮按照業(yè)務垂直拆分。

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

• 最后再考慮分表，單表拆分到數(shù)據(jù)1000萬以內(nèi)。

數(shù)據(jù)拆分前其實是要首先做準備工作的，然后才是開始數(shù)據(jù)拆分，我先講拆分前需要做的事情：

第一步：采用分布式緩存redis、memcached等降低對數(shù)據(jù)庫的讀操作。

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

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

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

垂直拆分

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

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

水平拆分

垂直拆分后遇到單機瓶頸，可以使用水平拆分。相對于垂直拆分的區(qū)別是：垂直拆分是把不同的表拆到不同的數(shù)據(jù)庫中，而水平拆分是把同一個表拆到不同的數(shù)據(jù)庫中。

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

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

水平拆分，總之，一般先分庫，如果分庫后查詢?nèi)匀宦?，于是按照分庫的思想開始做分表的工作數(shù)據(jù)庫采用分布式數(shù)據(jù)庫（所有節(jié)點的數(shù)據(jù)加起來才算是整體數(shù)據(jù)），文件系統(tǒng)采用分布式文件系統(tǒng)任何強大的單一服務器都滿足不了大型系統(tǒng)持續(xù)增長的業(yè)務需求，數(shù)據(jù)庫讀寫分離隨著業(yè)務的發(fā)展最終也將無法滿足需求，需要使用分布式數(shù)據(jù)庫及分布式文件系統(tǒng)來支撐。

總結

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

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