架構硬實力

這個章節，基本大家都沒有什麼爭議性，必須是硬實力，拿得出手，能解決技術當前面臨的挑戰，能解決別人解決不了的問題。

從目前大家遇到的挑戰來看，從架構設計要求，我稍微做個總結。

1

分層的應用設計思想：SOA，事件驅動等。

SOA這塊的內容，我推薦大家去看支付寶首席架構師程立的文章。這塊支付寶和淘寶算是一起實踐走過來的。但是，程立算是比較早而且很詳盡的把支付寶的SOA之路說得非常詳細。

2

分散式原理：CAP，最終一致性，冪等操作等

這方面是的知識，網上比較多而且很全，也可買一本分散式系統相關的書籍瞭解。

3

大型網路應用結構

訊息中介軟體，分散式快取，負載均衡，叢集技術，資料同步等。

上一篇也談到了中介軟體，基本上現在大的網際網路公司，中介軟體基本可以與架構組劃上等好了。他們基本提供了分散式場景下的應用擴充套件的大部分基礎設施。淘寶在這塊的實力比較強，基本都已經開源出來了。常見的分散式快取Tair,分散式小檔案儲存TFS,等等。我之前一篇淘寶最具挑戰的的架構演變，也談到。

3

高可用，可容災分散式系統設計能力。

例如，阿里雲SLB產品使用開源軟體LVS＋keeplived實現4層的負載均衡。

採用淘寶的Tengine實現7層的負載均衡。所有負載均衡均採用叢集部署，叢集之間實時會話同步，以消除伺服器單點，提升冗餘，保證服務穩定。在各個地域採用多物理機房部署，實現同城容災。

SLB在整體設計上讓其可用性高達99.99%。且能夠根據應用負載進行彈性擴容，在任意一臺SLB故障或流量波動等情況下都能做到不中斷對外服務。

大容量資料儲存和檢索系統設計能力：資料庫分割槽，NoSQL，搜尋引擎等。

當然，還有自動化部署、回滾機制等，以及監控系統等等。

架構師前瞻性

所謂前瞻性表面聽起來還是比較空洞，什麼叫前瞻性？這裡我談談我看到或者觀察到的例子，這樣來觀察，也許更好感受到什麼叫前瞻性。

比如，這是當時支付寶程立在談到支付寶SOA之路的場景。

“瞻前”、“顧後” ――這是我現在體會到的最大挑戰。

先談談“瞻前”。當業務個性不明顯、業務規模也不大時，架構師還是有很多容易模仿的定式與先例的。但當業務的個性與規模到達一定階段時，一定會有一些別人從未遇到過的非常困難的問題需要你去解決。作為站在企業技術金字塔塔尖上的一群人，當過去的經驗用不上，搜尋引擎也不能向你提供任何有用的答案，只有獨立去思考，去做出重大決定時，如果沒有充分的準備，對企業對個人都是巨大的風險。這需要架構師建立未雨綢繆的意識，不斷推演未來可能的變化並思索應對之策，持續而有方向地積累知識、發展能力，建立廣泛的技術交流圈子，並且“顧後”。

再談談“顧後”。架構師的另一個重要的職責是發掘團隊中的好苗子，幫助他們，使他們趕上並超越自己。無論這一點是否寫入你的KPI，這樣做都是必須的。站在架構師的立場看，架構必須有一個好的技術梯隊一層層傳遞下去，才能夠有效、持續地貫徹執行，如果只是架構師們衝在前面，背後空了一大片，架構永遠只能停留在藍圖上。站在企業的立場看，企業真正的技術實力，不在於已經有怎樣的系統或者平臺，而在於是否有一個強大而有生命力的技術團隊，通過快速複製架構師的技術與經驗，可以幫助發展並壯大這樣的團隊，而企業整體技術實力的提升也促進了架構師提升。

業務產品架構

技術架構的目的是為了服務好業務，技術離開了業務，啥都不是。所以，對於好的架構師來講，對業務的掌握以及理解，需要一個團隊從早期就意識起來。

我用一個例子來舉例：語言翻譯能力。

將業務語言翻譯為產品語言、開發語言的能力很重要。業務需求來自客戶或業務部門，收集到的資訊是基於業務語言描述。 業務架構師需要學會基於自己的經驗知識進行分析，把業務語言轉換成產品語言、開發語言。這樣在跟產品、研發團隊的溝通中，才能完成資訊的有效、高保真傳遞。我早幾年前接觸過很多大公司的BD，基本就是幹著活。能把一個使用者的需求，從需求、產品、市場、功能、流程分析出一份詳細的需求報告書出來，在與使用者確認後，才能需求分析書轉到技術部開始架構設計等後續的工作。

一般來講，公司的很多需求業務模型，都是他們在整理。比如，公司的核心業務介紹等手冊。

當然，這裡還有好幾個方面。比如，對行業的理解、交流溝通能力等等。