架構設計-複雜度是不滅的

作者簡介：姚鋼強，具有豐富的技術架構和業務架構經驗；2013 - 2019 在知乎工作，完整經曆了知乎從内部注冊到上千萬 DAU 的過程；2019 年加入猿輔導，擔任斑馬事業部首席架構師的職務，主要負責工程實踐的改善與架構的優化；參與重要業務與技術架構方案的評審；目前微服務架構趨向合理，數量大幅削減，依賴逐漸清晰；也逐漸建立了以 Metrics 驅動的 DevOps 文化。

@陶文 的 《複雜度是不滅的，隻會轉移，難道一切都是徒勞的嗎？》[1] 提到了 《Complexity Has to Live Somewhere》[2] 這篇文章，這篇文章超級棒，闡述了架構設計的核心。為了透徹了解文中的觀點，是以逐字翻譯了一下。翻譯水準有限，肯定存在疏漏，多多包涵。

與複雜度的鬥争是軟體開發的一個永恒的主題，我一次又一次地看到它反複出現，并且不斷在各個層面上看到有關的争論：到底應該在函數和方法中進行多少注釋？理想的抽象是怎樣的？一個架構何時開始擁有了「過多的魔法」？什麼時候組織中有太多語言？

我們試圖擺脫複雜度，控制它，尋求簡單性。我認為以這種思考方式來尋求問題的解決方案是錯誤的。因為複雜度必須存在于某個地方，是不滅的。

Resilience Engineering 教給我一個來自控制論的 "必要多樣性 "概念：「隻有複雜度才能處理複雜度。」

在處理建構工具時，一些事情變得顯而易見：

• 如果你讓建構工具變得簡單，它就不能處理所有存在的奇怪的邊緣情況。
• 如果你想處理奇怪的邊緣情況，就需要偏離你想建立的任何規範。
• 如果你想讓通用預設值易于使用，那麼通用預設值的規則必須在工具和使用者之間共享，而使用者則要改造自己的系統來适應工具。
• 如果你允許自主配置或編寫腳本，你就給了使用者一種方法來指定必須共享的規則，以便工具适合他們的系統。
• 如果你想保持工具的簡單性，你就必須強迫你的使用者隻在适合這種簡單性的參數範圍内玩耍。
• 如果使用者的用例不能很好地與你的工具簡單性相比對，他們就會在你的工具周圍建立墊片（周圍的小工具）來實作他們的目标。

這是無法避免的。複雜度必須存在于某個地方。無論您是否意識到，它始終是人們解決問題時需要注意到的。

不幸的是，如果我們做到了清單的最後一點（我們總是以某種方式這樣做），墊片就會成為整體工具的一部分。複雜度并不會消失。這部分複雜度是每個人必須要學習的，使用者會需要适應它。

他們嘗試繞過複雜度時，看到了兩個沖突的概念（譯者注：類似 ORM 中的 O 和 R 的概念）之間的不比對。這種必要的複雜度可能會轉移 -- 回到工具（或新工具）-- 或者通過重新建構事物來消除。每一個這樣的變化都需要付出更多的努力和調整，讓人們看到複雜度，了解它，并解決它。但是在某些情況下，這種變化不會使事情簡化，而是會在人們的各種假設之間産生新的不比對，進而使事情複雜化，這就需要新的墊片。必然複雜度時間久了之後，就變成了偶然複雜度。它無法避免，而且它一直在變化。複雜度必須存在于某個地方。

在 《The Design of Everyday Things》 中，Don Norman 提到了“頭腦中的知識”和“世界中的知識”的概念（類似的概念更學術話的出現在了 Roesler & Woods 的《Designing for Expertise》）。頭腦中的知識是你知道的、你學到的、你記憶中的東西。世界上的知識是其他的一切：寫下來的資訊，設計中的線索（你通過看它的符号知道電源按鈕，你知道它可以被按下，因為它看起來像一個按鈕）。一件棘手的事情是，對世界上的知識的解釋既有文化上的，也有上下文上的，并且依賴于頭腦中的知識（你知道電源按鈕可以被按下，因為你知道按鈕首先是什麼）。

在某些方面，專業知識是在你頭腦中可以使你能更好地了解世界的知識。

将精力放在發現閱讀和解釋一段特定的代碼有多 "簡單"是我們在軟體設計中的一個常見的陷阱。專注于簡單性是充滿危險的，因為複雜度無法消除：它隻能被轉移。如果你把它從你的代碼中移出來，它去了哪裡呢？

當我們設計 Rebar3 時，我們覺得這個工具可以很簡單。其簡單的條件是，你對 Erlang/OTP 項目的預期結構有一個基本的了解。隻要你遵循這些規則，項目就會運轉的很好。我們把一些複雜的東西外化到更廣泛的生态系統中。這些規則總是需要學習的（我們是這麼認為的），但現在的工具取決于對它們的了解。在為了解規則的人簡化工具的使用時，我們使那些仍在學習規則的人更難使用。在其他生态系統中用于其他目的的工具都在做類似的權衡。

這個陷阱在軟體架構中是隐蔽的。當我們采用微服務之類的東西時，我們會盡量使每個服務都變得簡單。但是除非你能夠使你的真實應用可以強制進入簡單的狀态，否則複雜度仍然必須去某個地方。如果它不在各個微服務中，那麼它在哪裡（譯者注：使用微服務的人仍然要知道規則是什麼，如何使之簡單）？

複雜度必須存在于某個地方。如果你幸運的話，複雜度在定義明确的地方。在你認為有點複雜的代碼中，在支援代碼的文檔中，在工程師的教育訓練課程中。你給了複雜度一個地方，而不是試圖隐藏它。你創造方法來管理它。你知道當你需要它的時候，該去哪裡找它。如果不走運，你隻是試圖假裝複雜度可以完全消除，那麼它在這個世界上就沒有地方可去。但它仍然會一直存在于這個世界。

由于無處可去，複雜度不得不在你的系統中到處遊蕩，包括在你的代碼中和人們的頭腦中。随着人的轉移和離開，我們對它的了解逐漸減弱。

複雜度必須存在于某個地方，它是不會消失的。如果你接受它，給它應有的位置，在設計你的系統群組織時知道它的存在，并專注于适應它，它可能就會成為幫助軟體架構設計的一種力量。

原文位址：

文中連結：

[1] https://zhuanlan.zhihu.com/p/138145081

[2] https://ferd.ca/complexity-has-to-live-somewhere.html

參考閱讀：

• 愛奇藝本地實時Cache方案
• 周末思考：淺談如何成為技術一号位？
• go語言最全優化技巧總結，值得收藏！
• 如何支援億級使用者分流實驗？AB實驗平台在愛奇藝的實踐
• 從源碼角度分析 Mybatis 工作原理
• 使用 Apache APISIX 進行集中式身份認證及進階玩法

技術原創及架構實踐文章，歡迎通過公衆号菜單「聯系我們」進行投稿。

高可用架構

改變網際網路的建構方式