IBM架構師分享：極簡主義軟體架構 - Neal Hu

什麼是依賴？
答案似乎很簡單。如果你的系統依賴某些東西來執行，那就是一個依賴。然而，這只是冰山一角。依賴需要：

• 存在：無論你的系統走到哪裡，它都會發生。
• 合規性：它符合您的系統要求的相同要求。
• “UX”：它讓您的使用者滿意。
• 維護：您需要花費額外的資源來維護它。

故事
在IBM Watson，與許多其他全球業務一樣，我們的系統部署在世界各地。在設計內部SaaS時，我們的團隊希望使用由另一個IBM團隊託管的資料庫即服務。我們在開發環境中使用它做了一個原型，甚至在我們的美國生產中進行了alpha擴充套件。一切看起來都很棒。

然而，當我們被要求在截止日期前將我們的系統部署到歐洲和澳大利亞等非美國地區時，我們意識到資料庫團隊有自己的全球推廣計劃。我們可以等待它們或在我們的程式碼中建立一個標誌，以根據資料庫的存在禁用某些功能。

我們最終選擇了後者。但它為我們的部署引入了碎片，這導致我們的CI / CD管道出現更多問題。它還在我們的程式碼庫中造成了不必要的複雜性。當我們新增新功能時，我們需要考慮兩種情況（使用該資料庫或不使用它）。如果您有N個依賴項，則可能最終得到2 ^ N個依賴項存在情況的組合。不用說，這將是一場噩夢。

合規性
今天，計算系統的規則和合規性比以往任何時候都多。如果您的公司為歐盟公民服務，您可以受GDPR的約束。如果您希望在美國為醫療保健業務提供服務，您必須與HIPAA會面。所有這些法規都對您的系統和依賴關係提出了要求。就像您需要確儲存在一樣，您需要保證您的依賴關係符合相同的要求。否則，在他們違反合規性的那一刻，你的系統也是如此。

“UX”：Kafka Streams vs Flink
當您設計框架並向其他人提供使用程式碼而不是託管SaaS時，使用者體驗更為重要。請記住，當使用者邀請您的框架進入他們的房子時，他們也必須歡迎這些依賴項。
以Kafka Streams和Apache Flink為例。在構建基於Kafka的流處理管道時，我研究了它們。這裡是一些快速上下文背景介紹：Kafka是一個開源的分散式佇列系統，Kafka Streams是一個基於Kafka的框架，可以幫助處理Kafka中的資料。Flink可以完成類似的任務。

Kafka Streams和Flink有很多優點和缺點，但對我來說，中間代理是他們的依賴。Kafka Streams只需要依賴Kafka。另一方面，Flink需要依賴Zookeeper叢集來實現HA（高可用性）。我們沒有足夠的資源來自己託管這樣一個叢集; 因此，我們選擇了在Faf上Kafka Streams。

維護
新增新依賴項還會隱藏維護成本，例如其他度量標準，監視和警報，故障方案和自動化。依賴關係可能變慢或者只是失敗，您的系統需要具有檢測和處理它們的邏輯。部署系統時，持續交付系統應設定所有內容，包括依賴項，因此新的依賴關係通常意味著自動化中的新邏輯。為額外的工作做好準備！