分布式系統架構

時間：2024-09-27 05:12:27 系統架構師我要投稿

相關推薦

關于分布式系統架構

　　對于軟件架構，更多的是一種思想，即內功修為。在道與術層面，則更偏重道的修煉，道的深度決定架構的境界。相對而言，術是手段，隨不同的環境應運而生，就像太極劍法和獨孤九劍，能做到隨境而變。

　　架構是一種權衡

　　沒有一種架構可以應用到所有環境，也沒有一個技術或框架可以解決所有問題，即使是針對同一種場景也往往存在多種解決方案。在架構的時候，更多的是方案和手段的權衡，例如高可用性、高并發性、一致性本身就存在一定的矛盾;而異步還是同步、是否需要事務、如何應用事務、緩存、拆分、容災、發布等等，每一項都需要從各種技術實現中進行權衡。細化到框架，ActiveMQ、RocketMQ、Kafka、Redis、ZooKeeper等等都可以實現消息隊列模型，具體使用哪個就需要結合場景進行權衡了。

　　分與合

　　天下大事，合久必分、分久必合，在解決高并發分布式的問題時絕大部分都在使用分與合的思想。

　　當數據量很大、并發量很多的時候就需要考慮拆分(分而治之)，例如分層設計、橫向拆分、縱向拆分、分IDC、分庫分表...等等。并且這些拆分本身就是分層的，例如在DNS層可以將流量按照地域或運營商分配到不同的IDC、業務層可以將業務處理邏輯分配到多個子系統、系統層可以根據用戶進行橫向拆分、而存儲層可以根據規則將數據分配到不同的庫不同的表;另外讀寫分離、熱點分離、獨立出緩存層也體現了分布式系統架構中分的思想。

　　為什么要做這么多的拆分，拆分就是為了化多為少，在單節點處理能力有限的情況下，通過橫向拆分提供無線的擴展能力，當巨大的流量通過拆分后，每個節點要處理的QPS就會下降;拆分是為了化繁為簡，簡化單節點的復雜度，現在的微服務(當然微服務引發的服務治理需要另說)、二階段事務提交，就是將復雜的業務通過多維度的拆分降解單節點復雜度的手段。

　　拆多了就要合，hadoop將復雜的任務分解到一個個的mapreduce job處理和聚合后，處理效率得到了極大的提升，而這種分解必然伴隨著聚合。而在有些業務場景，兩類節點相互調用非常頻繁，通過合并將原本的RPC調用轉換為本地JVM調用，則可以很大的提升系統性能。

　　隔離

　　隔離也是一種思想，其中也包含了分的意思，例如灰度、壓測隔離、動靜隔離、多版本發布等。

　　轉換

　　路由與轉換，可以看做是分思想的衍生物。分的太多，就需要能將請求轉發到正確的位置，此外也需要將各種通信格式與協議進行轉換。

　　重復與唯一(冪等)

　　冪等伴隨著請求的靠套投遞而產生，在發送請求時可能會存在如下幾個場景：接收端不一定要接收、接收端只能接收一次、接收端可重復接收。對于配置推送平臺，大多場景要求接收端可重復接收配置信息，但只保存最后一次消息即可;而對于一筆付款請求，如果重復發送，接收端要控制只能處理一次(即要進行冪等控制)。

　　最終一致

　　在分布式系統架構中，面對事務性業務有兩種選擇，一種是分布式事務、一種是最終一致性處理。分布式事務控制比較復雜，一般采用二階段提交的方式，其思想是要么成功要么失敗，注意要么失敗是指其中有一步出錯就全部回滾，看似是保證了數據一致性但實際業務卻失敗了。而最終一致性相對于分布式事務的核心思想是讓業務盡可能成功，即當業務處理過程中可能會存在中間步驟失敗的情況，但通過補償邏輯可以保障失敗的步驟后續繼續執行，此時就應該盡可能的標記業務成功。

　　并行與串行

　　將大量的計算分散到多個節點、多個進程、多個線程進行并行處理，是應對大數據計算的常用技巧。而伴隨并行的就是串行(或者說是并發鎖)的處理，在分布式環境，并發鎖的可以通過數據庫、zookeeper等進行實現。

　　主動與被動

　　主動與被動主要是針對客戶端如何獲取服務端內容的場景，典型的就是消息隊列中的推模式(push)和拉模式(pull)。具體底層實現上，無外乎輪詢、長鏈接等等，其中使用輪詢不一定就是拉模型，很多推模型其底層也是通過輪詢實現的。

　　同步與異步

　　同步與異步也是經常要面臨抉擇的事情，異步可以減少系統的阻塞，例如Ajax、消息隊列(還可以達到消峰填谷的作用)等等。此外流式計算與離線計算，也可以看做是同步與異步的衍生技術。再深一層次，會衍生批量計算、全量、增量等思想。

　　點到為止

　　限流：當巨大的流量打過來時，通過犧牲部分請求處理可保證整個系統可用;

　　降級：當面對流量高峰時(例如大促)往往將次要的服務停掉，以便節省資源給主要服務;另外當某個服務不可用時，直接返回默認結果也是降級的一種表現;

　　熔斷：對于金融系統，當出現bug時可能會造成資損，此時需要旁路系統進行不斷的核對，當發現異常時能夠及時終止處理。

　　對于以上幾個方面，系統要能做到自動限流、自動降級和自動熔斷。

　　以上一切問題都是由于量(數據量、請求量等等)產生的，當量很小時不需要架構，通過增加內存、CPU、機器等都能解決;當量增加到一定的程度時，才需要考慮架構，而架構的道與術卻又是“道可道，非常道，名可名，非常名”。

【分布式系統架構】相關文章：