架構師如何做決策

碁峰資訊出版

軟體開發人員在網上搜尋當前問題的解決方案方面建立了出色的技能。例如，如果他們需要弄清楚如何在他們的環境中配置一個特定工具，專業地使用Google就會找到答案。

但對架構師來說，情況並非如此。

對於架構師來說，許多問題都帶來了獨特的挑戰，因為它們混淆了你組織的確切環境和情況──有人遇到了這種情況並將它發布在博客或貼在Stack Overflow上的機會有多少？

架構師可能想知道，與框架、API等技術主題相比，為什麼關於架構的書籍這麼少。架構師很少會經歷常見的問題，但卻在新情況下為了做決定而不斷地掙扎。對於架構師來說，每一個問題都是一片雪花。在許多情況下，問題不僅僅是出現在特定的組織內，而對整個世界都是新的。對於這些問題，沒有任何的書籍或是會議討論它！

架構師不應該一直為他們的問題尋找靈丹妙藥。因為幾乎每一個問題都會帶來新的挑戰，架構師的真正工作在於他們能夠客觀地決定和評估一個最終決定任何一方的權衡，以盡可能好地解決它。作者沒有談論「最佳解決方案」（在本書或現實世界中），因為「最佳」意味著架構師已經設法將設計中所有可能的競爭因素最大化。相反地，我們提出以下半開玩笑的建議：

不要試圖在軟體架構中找到最好的設計；相反地，要爭取最不差的權衡組合。

通常情況下，架構師可以建立的最好設計是最不差的權衡集合──沒有一個單一架構特徵能超過它單獨的那樣，但所有競爭架構特徵的平衡能促進專案成功。

這就引出了一個問題，「架構師如何才能找到最不差的權衡組合（並有效地記錄它們）？」

為什麼是「困難部分」？

為什麼我們把這本書叫做《軟體架構：困難部分》？實際上，書名中的「hard」一字有雙重含義。首先，hard意味著困難，而架構師們不斷面臨著字面上（及象徵性地）以前沒有人所面臨過的困難問題，涉及許多具有長期影響的技術決策，這些決策必須發生在人際和政治環境之上。

第二，hard意味著硬──就如同在分離的硬體和軟體中，硬的部分應該改變得比較少，因為它為軟的部分提供了基礎。同樣地，架構師也討論了架構和設計之間的區別，前者是結構性的，而後者更容易改變。

軟體架構的定義本身已經為它的參與人員提供了許多時間的非生產性對話。一個最受歡迎半開玩笑的定義是「軟體架構是那些以後很難改變的東西。」

提供關於軟體架構的永恆建議

軟體開發的生態系統不斷地、混亂地轉變和成長。幾年前風靡一時的話題要麼被生態系統所包含並消失，要麼被不同/更好的東西所取代。例如，10年前，大型企業的主流架構樣式是協作驅動、服務導向的架構。現在，幾乎沒有人再採用這種架構的樣式了；目前許多分散式系統所青睞的樣式是微服務，這種轉變是如何以及為什麼發生的？

當架構師注視一個特定的樣式（尤其是歷史性的），他們必須考慮導致這架構成為主流的約束因素。當時，許多公司合併成為企業，伴隨著這種過渡隨之而來的是整合問題。此外，對於大公司來說，開源並不是一個可行的選項（通常是出於政治而非技術原因）。因此，架構師強調共用資源以及集中協作作為一種解決方案。

然而，在這幾年中，開源和Linux成為可行的替代方案，使作業系統在商業上免費。然而，真正的轉捩點發生在Linux隨著像是Puppet和Chef等工具的出現而在操作上變得免費，這些工具允許開發團隊以編程方式啟動他們的環境，作為自動建構的一部分。一旦有了這種能力，它就透過微服務和迅速出現的容器基礎架構，以及像是Kubernetes等協作工具而促進了一場架構革命。

這說明了軟體開發的生態系統以完全無法預期的方式擴展和演進。一種新的能力導致了另一種能力，這又不預期地創造了新的能力。隨著時間的推移，這個生態系統一次一個地完全取代了自己。

資料在架構中的重要性

對於架構界許多人來說，資料就是一切。每個建立任何系統的企業都必須處理資料，因為它的壽命往往比系統或架構還長得多，需要勤奮的思考和設計。然而，資料架構師建立緊密耦合系統的許多本能在現代分散式架構中產生了衝突。例如，架構師和DBA必須確保商務資料在整體式系統被拆散後仍能存在，並且無論架構如何波動，商務仍可以從它的資料中獲得價值。

有人說，資料是一個公司最重要的資產。企業希望從他們擁有的資料中提取價值，並在決策中找到新的方法部署資料。現在企業的每一部分都是由資料驅動的，從服務現有客戶到獲得新客戶、增加客戶保留率、改善產品、預測銷售和其他的趨勢。這種對資料的依賴意味著所有的軟體架構都在為資料服務，確保正確的資料可以被企業的各部門使用。

幾十年前，當分散式系統剛開始流行時，作者就建立了許多分散式系統，但是現代微服務的決策似乎更為困難，我們想弄清楚為什麼。我們最終意識到，在分散式架構的早期，我們大多仍然是堅持資料在一個單一的關聯式資料庫中。然而，在微服務中，以及從「Domain-Driven Design」中對有界上下文的哲學堅持，作為限制實作細節耦合範圍的一種方式，資料已經和交易性一起移到了架構關注點上。現代架構的許多困難部分都來自於資料和架構關注點之間的緊張關係。

使用適應度函數

在2017年的《Building Evolutionary Architectures》（O’Reilly）一書中，作者（Neal Ford、Rebecca Parsons和Patrick Kua）定義了架構適應度函數的概念：對某些架構特徵或架構特徵的組合進行客觀完整性評估的機制。

架構師實作適應度函數，以圍繞架構特徵的意外變化建立保護。在敏捷軟體開發領域，開發者實作單元、功能以及使用者驗收測試，以驗證領域設計的不同維度。然而，直到現在，還沒有類似的機制來驗證設計中的架構特徵部分。事實上，適應度函數和單元測試之間的分離為架構師提供了一個很好的範圍指引。適應度函數驗證架構特徵，而不是領域標準；單元測試則正好相反。因此，架構師可以透過詢問以下問題來決定是否需要適應度函數或單元測試：「執行這個測試是否需要任何的領域知識？」如果答案是「是」，那麼單元/功能/使用者驗收測試是合適的；如果答案是「否」，則需要一個適應度函數。

例如，當架構師談論彈性時，指的是應用程式能夠承受使用者突然爆發的能力。請注意，架構師不需要知道有關領域的任何細節──這可以是電子商務網站、線上遊戲、或其他的東西。因此，彈性是一個架構上的問題，並且在適應度函數的範圍內。另一方面，如果架構師想要驗證一個郵寄位址的正確部分，則可以透過傳統測試來涵蓋。當然，這種分離並不是純粹的二分法──有些適應度函數會觸及到領域，反之亦然，但不同的目標提供了一個很好的方法來從精神上將它們分開。（本文摘錄整理自《軟體架構：困難部分》第一章，碁峰資訊提供）