關(guān)于分布式系統架構

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

　　架構是一種權衡

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

　　分與合

　　天下大事，合久必分、分久必合，在解決高并發(fā)分布式的問(wèn)題時(shí)絕大部分都在使用分與合的思想。

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

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

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

　　隔離

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

　　轉換

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

　　重復與唯一(冪等)

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

　　最終一致

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

　　并行與串行

　　將大量的計算分散到多個(gè)節點(diǎn)、多個(gè)進(jìn)程、多個(gè)線(xiàn)程進(jìn)行并行處理，是應對大數據計算的常用技巧。而伴隨并行的就是串行(或者說(shuō)是并發(fā)鎖)的處理，在分布式環(huán)境，并發(fā)鎖的可以通過(guò)數據庫、zookeeper等進(jìn)行實(shí)現。

　　主動(dòng)與被動(dòng)

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

　　同步與異步

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

　　點(diǎn)到為止

　　限流：當巨大的流量打過(guò)來(lái)時(shí)，通過(guò)犧牲部分請求處理可保證整個(gè)系統可用;

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

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

　　對于以上幾個(gè)方面，系統要能做到自動(dòng)限流、自動(dòng)降級和自動(dòng)熔斷。

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

【分布式系統架構】相關(guān)文章：

如何搭建系統CSS架構12-31

系統架構設計模式大全08-22

系統架構師是做什么的12-30

如何成為優(yōu)秀的系統架構師06-03

圖書(shū)檢索系統體系架構研究12-05

基于云架構的系統安全設計08-08

系統架構師的就業(yè)前景分析01-11

系統架構設計師要素01-11

系統架構師必須具備哪些能力05-07

MES系統安全架構設計09-19