天之道，損有餘而補不足，是故虛勝實，不足勝有餘。
對於軟件架構，更多的是一種思想，即內功修爲。在道與術層面，則更偏重道的修煉，道的深度決定架構的境界。相對而言，術是手段，隨不同的環境應運而生，就像太極劍法和獨孤九劍，能做到隨境而變。
架構是一種權衡
沒有一種架構可以應用到所有環境，也沒有一個技術或框架可以解決所有問題，即使是針對同一種場景也往往存在多種解決方案。在架構的時候，更多的是方案和手段的權衡，例如高可用性、高併發性、一致性本身就存在一定的矛盾；而異步還是同步、是否需要事務、如何應用事務、緩存、拆分、容災、發佈等等，每一項都需要從各種技術實現中進行權衡。細化到框架，ActiveMQ、RocketMQ、Kafka、Redis、ZooKeeper等等都可以實現消息隊列模型，具體使用哪個就需要結合場景進行權衡了。
分與合
天下大事，合久必分、分久必合，在解決高併發分佈式的問題時絕大部分都在使用分與合的思想。
當數據量很大、併發量很多的時候就需要考慮拆分（分而治之），例如分層設計、橫向拆分、縱向拆分、分IDC、分庫分表...等等。並且這些拆分本身就是分層的，例如在DNS層可以將流量按照地域或運營商分配到不同的IDC、業務層可以將業務處理邏輯分配到多個子系統、系統層可以根據用戶進行橫向拆分、而存儲層可以根據規則將數據分配到不同的庫不同的表；另外讀寫分離、熱點分離、獨立出緩存層也體現了分佈式系統架構中分的思想。
爲什麼要做這麼多的拆分，拆分就是爲了化多爲少，在單節點處理能力有限的情況下，通過橫向拆分提供無線的擴展能力，當巨大的流量通過拆分後，每個節點要處理的QPS就會下降；拆分是爲了化繁爲簡，簡化單節點的複雜度，現在的微服務（當然微服務引發的服務治理需要另說）、二階段事務提交，就是將複雜的業務通過多維度的拆分降解單節點複雜度的手段。
拆多了就要合，hadoop將複雜的任務分解到一個個的mapreduce job處理和聚合後，處理效率得到了極大的提升，而這種分解必然伴隨着聚合。而在有些業務場景，兩類節點相互調用非常頻繁，通過合併將原本的RPC調用轉換爲本地JVM調用，則可以很大的提升系統性能。
隔離
隔離也是一種思想，其中也包含了分的意思，例如灰度、壓測隔離、動靜隔離、多版本發佈等。
轉換
路由與轉換，可以看做是分思想的衍生物。分的太多，就需要能將請求轉發到正確的位置，此外也需要將各種通信格式與協議進行轉換。
重複與唯一（冪等）
冪等伴隨着請求的靠套投遞而產生，在發送請求時可能會存在如下幾個場景：接收端不一定要接收、接收端只能接收一次、接收端可重複接收。對於配置推送平臺，大多場景要求接收端可重複接收配置信息，但只保存最後一次消息即可；而對於一筆付款請求，如果重複發送，接收端要控制只能處理一次（即要進行冪等控制）。
最終一致
在分佈式系統架構中，面對事務性業務有兩種選擇，一種是分佈式事務、一種是最終一致性處理。分佈式事務控制比較複雜，一般採用二階段提交的方式，其思想是要麼成功要麼失敗，注意要麼失敗是指其中有一步出錯就全部回滾，看似是保證了數據一致性但實際業務卻失敗了。而最終一致性相對於分佈式事務的核心思想是讓業務儘可能成功，即當業務處理過程中可能會存在中間步驟失敗的情況，但通過補償邏輯可以保障失敗的步驟後續繼續執行，此時就應該儘可能的標記業務成功。
並行與串行
將大量的計算分散到多個節點、多個進程、多個線程進行並行處理，是應對大數據計算的常用技巧。而伴隨並行的就是串行（或者說是併發鎖）的處理，在分佈式環境，併發鎖的可以通過數據庫、zookeeper等進行實現。
主動與被動
主動與被動主要是針對客戶端如何獲取服務端內容的場景，典型的就是消息隊列中的推模式（push）和拉模式（pull）。具體底層實現上，無外乎輪詢、長鏈接等等，其中使用輪詢不一定就是拉模型，很多推模型其底層也是通過輪詢實現的。
同步與異步
同步與異步也是經常要面臨抉擇的事情，異步可以減少系統的阻塞，例如Ajax、消息隊列（還可以達到消峯填谷的作用）等等。此外流式計算與離線計算，也可以看做是同步與異步的衍生技術。再深一層次，會衍生批量計算、全量、增量等思想。
點到爲止
限流：當巨大的流量打過來時，通過犧牲部分請求處理可保證整個系統可用；
降級：當面對流量高峯時（例如大促）往往將次要的服務停掉，以便節省資源給主要服務；另外當某個服務不可用時，直接返回默認結果也是降級的一種表現；
熔斷：對於金融系統，當出現bug時可能會造成資損，此時需要旁路系統進行不斷的核對，當發現異常時能夠及時終止處理。
對於以上幾個方面，系統要能做到自動限流、自動降級和自動熔斷。
最後
以上一切問題都是由於量（數據量、請求量等等）產生的，當量很小時不需要架構，通過增加內存、CPU、機器等都能解決；當量增加到一定的程度時，才需要考慮架構，而架構的道與術卻又是“道可道，非常道，名可名，非常名”。