一個優秀的架構師，抽象思維能力是必不可少的，架構師要善于“店丁解牛”，將實物概念化并歸類，比如一個大型網站，你能夠迅速根據業務功能的不同，將業務垂直化；

而扎實的技術功底又是架構師能力版圖中所占比例最大的一塊，因為抽象思維能力是虛的，技術能力是實的，只有做到虛實結合 ，才能夠達到“手中無劍，心中有劍”的境界：技術前瞻性是需要架構師憑借自身經驗和覺預估當前架構的缺陷會為將來埋下哪些隱患、哪些技術問題是需要在網站發展到一定階段就必須重構的、哪些技術在未來是趨勢，需要提前進行了解和學習的領域知識既要求了架構師的知識廣度，又要求了架構師的知識深度，因為架構師的技術能力不能夠僅局限在自己所擅長的那一畝三分地；

溝通交流能力其實非常重要，因為大多數情況下，我們都是在與人而非計算機打交道，比如，我們構建的系統先是給人使用的，其次才是讓計算機理解。

除此之外，業務的溝通探討、技術方案的探討等諸多事項都是人與人面對面的直接溝通交流，如果你不善于溝通，那么如何能夠讓別人明確你的用意 又如何順利開展工作呢？

架構師的能力版圖

本書主要有五部分組成：

只需要轉發關注小編，私信小編“學習”就可以獲得！

分布式系統的架構演變過程

在移動互聯網的浪潮中，你我正生逢其時地 受著當下，如果你愿意做 只站在風口上 待起飛的豬，那么請認真地問問自己，是否已經準備好了？互聯網究是什么？簡而言之，互聯網詮釋的是 種精神，融入了高度開放、分 ，以及自由的精神。如果你想融入這個圈子，那么請務必先舍棄掉與互聯網精神背道而馳的陳舊觀念和思維，否則你自始至終都只會被孤立在局外。

互聯網悄然改變了世界，改變了人們對事務的認知，縮短了人與人之間的距離無論你是否愿意承認，互聯網已經完全影響并融入我們的生活中。我們的長輩們，也從早期對新鮮事物的排斥，變成現在的欣然接受，這就是互聯網與生俱來的魅力和魔力。

筆者的母親從來就不是 個喜歡追趕潮流的人，但是她早已智能設備從不離身，每天早上起床的第一 件事情就是拿起智能手機，刷刷朋友圈、 看看時事政治、做回“吃瓜群眾”，八卦下娛樂新聞，甚至衣食住行也幾乎是通過互聯網這個載體鍵搞定的，如圖所示。既然互聯網能使我們的生活質量更好，那就請張開雙臂緊緊擁抱它。

擁有互聯網的生活

大流量限流／消峰案例

天貓、淘寶這種級別的大型互聯網電商網站，主要的技術挑戰來自于龐大的用戶規模所帶來的大流量和高并發，在“雙 11 ”、“雙 12 ”等大促場景下尤為明顯。

如果不對流量進行合理管制，肆意放任大流量沖擊系統，那么將導致 系列的問題出現，比如一些可用的連接資源被耗盡、分布式緩存的容量被撐爆、數據庫吞吐量降低，最終必然會導致系統產生雪崩效應。當然，應對大流量和高并發也沒有大家想象得那么復雜和神秘。

一般來說，大型互聯網站通常采用的做法是通過擴容、動靜分離、緩存、服務降級及限流五種常規手段來保護系統的穩定運行。

不同的企業可能會采用不同的解決方案來應對大流量和高并發，因為不同業務之間存在的差異性決定了不會誕生通用的解決方案，所謂條條大路通羅馬，只要能夠換取同質性的結果，過程如何就顯得不是特別重要，這就好比如果能夠提前知道羅馬的具體位置，那么處處都是路，怎么走都行。

本章的重點是流量管制，只要我們能夠采用合理且有效的方式管制住用戶流量 讓其有秩序地對系統進行訪問，那么無論是在平時還是在大促的時候，系統都能夠穩定運行。需要明確的是，流量管制的目的是保護系統，讓系統的負載處于 個比較均衡的水位，而不是刻意為了限流而限流，否則將會嚴重影響用戶體驗，得不償失。

分布式配置管理服務案例

相信大家對配置信息都不會感到陌生，在實際的開發過程中，無論是訪問數據庫、分布式緩存系統、消息隊列，還是通過 Dubbo 框架實現 RPC 調用，都需要提前配置好目標 URL 、賬號／密碼等信息，因此這類信息也被稱為配置信息。在大部分情況下，我們都會選擇將相關配置信息配置在配置文件中，當系統啟動時，會從指定的目錄下進行加載，通過獲取配置文件中的配置信息項來完成環境的初始化工作。

除此之外，我們在使用電腦進行辦公、娛樂時，也會高頻率地與配置信息打交道，比如，通過操作系統的控制面板來設置顯示器的分辨率、鼠標的雙擊速度 ，以及區域和語言設置等，這些都屬于配置信息，所以如果你告訴我你從未接觸過配置信息，那么我一定會搖搖頭對你說這不可能。

大促場景下熱點數據的讀／寫優化案例

在秒殺、限時搶購這種大促場景下，由于峰值流量較大，大量的并發讀／寫操作一定會導致后端的存儲系統產生性能瓶頸。

前面已經講解過，提升單機處理能力最有效的辦法就是采用集群技術對服務器進行擴容，只要系統能夠具備良好的伸縮性，那么從理論上來說，其容量便可以是無限的。

在此需要注意 ，大促場景下因熱點數據導致的單點瓶頸已經不再是簡單地通過橫向擴容就能夠順利解決的，盡管對于讀操作我們可以將熱點數據緩存在分布式緩存中以達到提升系統 QPS 的目的，但是緩存系統的單點容量還是存在上限的 ，因此應對大促場景下的峰值流量仍顯得杯水車薪。

除此之外，由于熱點數據的寫操作無法直接在緩存中完成，那么這必然會引起大量的線程相互競爭 nnoDB 的行鎖。并發越大時，等待的線程就越多，這會嚴重影響數據庫的 TPS ，導致 RT 線性上升，最終可能引發系統出現雪崩。

數據庫分庫分表案例

大型網站幾乎時時刻刻都在接受著高并發和海量數據的洗禮，隨著用戶規模的線性上升，單庫的性能瓶頸會逐漸暴露出來，由于數據庫的檢索效率越來越慢，導致生產環境中產生較多的慢速 SQL。

對于非結構化的數據，可以將其存儲在 NoSQL數據庫中來提升性能，但是重要的業務數據，仍然要落盤在關系型數據庫（如 MySQL數據庫）中。

那么如何提升關系型數據庫的并行處理能力和檢索效率就成為了架構師需要思考和解決的棘手問題，并且單庫如果巖機，業務系統也就隨之癱瘓了。

因此，在互聯網場景下，架構師務必要確保后端存儲系統具備高可用性和高性能，為了解決這些問題，目前互聯網場景下常見的做法便是對數據庫實施分庫分表，即Sharding 改造。