一篇文章了解架构设计的本质
“
大型網站的架構設計，涉及到的面非常多，并不像大家想象的那樣，就是一個網站這么簡單，今天拋磚引玉，希望大家正確看待架構設計。
什么是架構設計的本質？
任何系統，自然情況下，都是從有序到無序，這是有科學依據的， 按照熱力學第二定律，自然界的一切自發過程都有方向性，一個孤立系統會由有序變為無序，即它的熵會不斷增加，最終寂滅。但生物可以通過和外界交互，主動進行新陳代謝，制造“負熵”來保證自身有序，繼續生存。
同樣，一個軟件系統隨著功能越來越多，調用量急劇增長，整個系統逐漸碎片化，越來越無序，最終無法維護和擴展，所以系統在一段時間的野蠻生長后，也需要及時干預，避免越來越無序。
架構的本質就是對系統進行有序化重構，不斷減少系統的“熵”，使系統不斷進化。
那架構是如何實現無序到有序的呢？ 基本的手段就是分和合，先把系統打散，然后重新組合。
分的過程是把系統拆分為各個子系統/模塊/組件，拆的時候，首先要解決每個組件的定位問題，然后才能劃分彼此的邊界，實現合理的拆分。合就是根據最終要求，把各個分離的組件有機整合在一起，相對來說，第一步的拆分更難。
拆分的結果使開發人員能夠做到業務聚焦、技能聚焦，實現開發敏捷，合的結果是系統變得柔性，可以因需而變，實現業務敏捷。
架構設計的能力
我們要想做好一個架構的話需要哪些能力？我覺得最重要的是架構師一個最重要的能力就是你要有分解能力。
第一，你必須要有抽象的能力，抽象的能力最基本就是去重，去重在整個架構中體現在方方面面，從定義一個函數，到定義一個類，到提供的一個服務，以及模板，背后都是要去重提高可復用率。
第二， 分類能力。做軟件需要做對象的解耦，要定義對象的屬性和方法，做分布式系統的時候要做服務的拆分和模塊化，要定義服務的接口和規范。
第三， 算法（性能），它的價值體現在提升系統的性能，所有性能的提升，最終都會落到CPU，內存，IO和網絡這4大塊上。
架構設計的演變過程
架構設計的演變，其實就要清楚整個大型網站技術架構的演變歷程，知道每個階段的瓶頸在哪里，以及對應的解決方案。
很多公司都是小做到大，特別是創業公司，如果一步步發展起來，網站架構演變都會經歷這些步驟，請重點注意順序。
架構演變第一步：物理分離webserver和數據庫
架構演變第二步：增加頁面緩存
架構演變第三步：增加頁面片段緩存
架構演變第四步：數據緩存
架構演變第五步： 增加webserver（集群）
架構演變第六步：分庫（首先考慮）
架構演變第七步：分表、DAL和分布式緩存
架構演變第八步：增加更多的webserver
架構演變第九步：數據讀寫分離和廉價存儲方案
架構演變第十步：進入大型分布式應用時代和廉價服務器群夢想時代
架構知識體系
隨著互聯網技術迅速發展和演變，不斷改變的商業化應用系統越來越復雜，由單一的應用架構到垂直的應用架構，但還是面臨的擴容的問題。
流量分散在各個系統中，雖然體積可控，但對開發人員和維護人員帶來極麻煩。此時，將核心的業務單獨提煉出來作為單獨的系統對外提供服務。達成業務之間復用，系統也將演變成分布式系統架構。
大型網站最終都會走向大型分布式業務場景
分層：橫向分層：應用層，服務層，數據層
分割：縱向分割：拆分功能和服務
分布式
分布式應用和服務
分布式靜態資源
分布式數據和存儲
集群：提高并發和可用性
緩存：優化系統性能
cdn
方向代理訪問資源
本地緩存
分布式緩存
異步：降低系統的耦合性
冗余：冷備和熱備，保證系統的可用性
自動化：發布，測試，部署，監控，報警，失效轉移，故障恢復
安全等。
分布式緩存
高并發環境下，大量的讀寫請求涌向數據庫，磁盤的處理速度與內存顯然不在一個量級，從減輕數據庫的壓力和提高系統響應速度兩個角度來考慮，一般都會在數據庫之前加一層緩存。由于單臺機器的內存資源以及承載能力有限，并且，如果大量使用本地緩存，也會使相同的數據被不同的節點存儲多份，對內存資源造成較大的浪費，因此，才催生出了分布式緩存。
分布式緩存系統
memcached ,redis，動態、靜態數據的緩存，這里會涉及到：一致性hash算法、分布式session、數據復制多份、單臺緩存失效、集群間能夠自動復制和備份等知識點。
CDN
全稱:Content Delivery Network或Content Ddistribute Network，即內容分發網絡基本。通過在網絡各處放置節點服務器所構成的在現有的互聯網基礎之上的一層智能虛擬網絡，CDN系統能夠實時地根據網絡流量和各節點的連接、負載狀況以及到用戶的距離和響應時間等綜合信息將用戶的請求重新導向離用戶最近的服務節點上。
現在大型互聯網公司都建立由屬于自己的CDN基站，也有第三方專注于CDN的基站等。
主要特點：
1、本地Cache加速，提高了企業站點（尤其含有大量圖片和靜態頁面站點）的訪問速度，并大大提高以上性質站點的穩定性
2、鏡像服務消除了不同運營商之間互聯的瓶頸造成的影響，實現了跨運營商的網絡加速，保證不同網絡中的用戶都能得到良好的訪問質量。
3、遠程加速 遠程訪問用戶根據DNS負載均衡技術 智能自動選擇Cache服務器，選擇最快的Cache服務器，加快遠程訪問的速度
4、帶寬優化 自動生成服務器的遠程Mirror（鏡像）cache服務器，遠程用戶訪問時從cache服務器上讀取數據，減少遠程訪問的帶寬、分擔網絡流量、減輕原站點WEB服務器負載等功能。
5、集群抗攻擊 廣泛分布的CDN節點加上節點之間的智能冗余機制，可以有效地預防黑客入侵以及降低各種D.D.o.S攻擊對網站的影響，同時保證較好的服務質量 。
說了這么多，你也可以理解為自動分發的緩存系統，把圖片等消耗資源的都從CDN進行訪問。
持久化儲存
Hbase、MySQL、Redis傳統的IOE方案： IBM小型機Oracle數據庫 EMC持久儲存成本很高。
以后會涉及到廉價存儲方案（小型機太貴了），這塊以后我會講到。
數據庫拆分
一般先分庫，如果分庫后查詢仍然慢，于是按照分庫的思想開始做分表的工作數據庫采用分布式數據庫（所有節點的數據加起來才算是整體數據），文件系統采用分布式文件系統任何強大的單一服務器都滿足不了大型系統持續增長的業務需求，數據庫讀寫分離隨著業務的發展最終也將無法滿足需求，需要使用分布式數據庫及分布式文件系統來支撐。
分布式數據庫是系統數據庫拆分的最后方法，只有在單表數據規模非常龐大的時候才使用，更常用的數據庫拆分手段是業務分庫，將不同的業務數據庫部署在不同的物理服務器上。
比如淘寶中期開始的數據庫端按照業務垂直拆分：按照業務交易數據庫、用戶數據庫、商品數據庫、店鋪數據庫等進行拆分。
還有就是水平擴展，分庫分表，再結合讀寫分離一起。當然，分庫分表需要涉及到對應的SQL路由規則主庫備庫等，淘寶設計了一套TDDL來解決這些問題，應用端只需配置對應的規則即可，對應用端的沒有任何侵入的設計。
消息系統
消息隊列中間件是分布式系統中重要的組件，主要解決應用耦合，異步消息，流量削鋒等問題。實現高性能，高可用，可伸縮和最終一致性架構。是大型分布式系統不可缺少的中間件。
目前使用較多的消息隊列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ。
消息系統使用場景
典型的 異步處理，應用解耦，流量削鋒和消息通訊四個場景。
除了以上還要設計運維（掌握分布式并行計算、報表、監控技術以及規則策略），安全、運營、服務、存儲、業務拆分、機房容災等等，要做好一個大型的網站真的很不容易。
你可能也喜歡:
總結
以上是生活随笔為你收集整理的一篇文章了解架构设计的本质的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 论文浅尝 - WSDM2020 | QA
- 下一篇： 研讨会 | CCF TF 第 17 期：