分佈式雲應用程序（又名微服務）已將大量複雜性引入到雲軟件的設計和運營中。曾經的單體應用將複雜性隱藏在單個進程或運行時中，現在卻分散在數十或數百個松耦合的服務中。儘管所有這些服務都可以使用不同的編程語言，並且可以彼此獨立地進行擴展，但是分佈式特性通常會使應用程序整體難以駕馭、難以部署並且很難保證安全。
這種新的複雜性使得管理和開發雲原生應用程序變得越來越困難，並且引發了有關如何維護健康雲軟件的問題。我們如何才能利用面向服務設計的好處，而又不會在其他地方引入衝突和成本呢？
幸運的是，我們之前已經遇到過這個問題。微服務並不是第一種迫使開發人員弄清楚如何協作，併爲無數互連組件操勞的模式。在過去的幾十年中，這類問題的解決方案一直是相同的：依賴管理。
我們每天都使用依賴管理來重複使用公有和私有軟件包，並在他人工作的基礎上，將我們自己的應用優雅的封裝爲可用格式提供給其他人。依賴管理是釋放分佈式軟件能力的關鍵，背後的原因有很多；現在是時候向過去學習，爲雲原生開發的未來提供動力了。
1. 開發者協作
依賴管理工具（如NPM，Pip，Maven等）最重要的功能之一是促進開發者之間的協作。通過提供一致的打包機制以無縫擴展代碼，依賴管理工具使原本不相關的團隊可以互相使用彼此的成果。我們可以在企業內部使用這些工具，以使團隊能夠在工作中協作併發布自己的成果；我們還看到，依賴管理工具得到了更廣泛的應用，以在開源社區中促成協作。依賴管理工具的一致性以及較高的採用率使得社區能夠創建功能非常強大且可自由訪問的軟件庫，以供所有人使用並在此基礎上繼續發展。
雖然這種協作水平已經在社區中針對單個編程語言實現了（針對Javascript的NPM，針對Python的Pip等），但尚未在雲原生社區中完全實現。幸運的是，我們使用Docker打包雲服務可以保證一致性，但是容器沒有足夠的有關服務之間關係的信息來解析和擴展依賴關係。如果我們想爲微服務實現類似於其他單獨編程語言中的依賴管理功能，則非常重要的環節是添加適當的依賴管理工具，以索引並解析與其他應用和服務的關係。
2. 自服務環境
依賴管理工具產生的協作作用並不是憑空產生的。一致的依賴解析器如此強大的主要原因是，世界各地的開發人員都可以使用相同的命令和流程來重現其效果。可重複性是依賴管理工具的關鍵要素。沒有它，開發人員需要使用複雜的傳統方式來自行下載和使用其他人創建的庫，從而極大阻礙軟件庫的採用和分發。
在這方面，面向服務的應用程序與基於特定語言的應用並沒有什麼不同。我們擴展他人工作的能力取決於我們運行或訪問我們希望調用的服務或應用。團隊能夠通過集中式的質量保證或沙箱環境來做出貢獻，但無法復現這些環境會帶來一系列新問題。工程師無法運營自己的開發環境，依賴其他應用的服務無法輕鬆交付，開發人員被迫編寫自己的腳本以在本地和遠程運行他們的應用，每個團隊都需要關心生產級工具、網絡的信息，以及網絡安全性。通過一致的依賴管理工具，團隊只需聲明其服務的依賴，即可爲組織中的每個人提供一致的方式來部署其服務棧及其依賴，從而使每個人都可以運營自己的環境。
3. 自動化
一致的依賴管理工具所具有的自服務優勢不僅僅意味着開發人員可以運營自己的環境。這也意味着可以通過自動化的方式來產生和拆除環境。單個命令或過程（用於解決依賴關係、豐富網絡和自動化安全性）的一致性是集成到CI/CD流水線的完美祕訣！
如果每個服務都可以一致地運行（例如在容器平臺上運行）並且知道其自身的依賴，則可以爲每個合併請求提供新的環境，並且在合併到相關分支後可以將更改無縫地升級到預發佈和生產環境中。這意味着每個團隊都可以爲每個開發人員和添加到應用程序的每個新服務實現可擴展的GitOps。
4. 安全性
微服務架構引入的風險之一是每個服務都需要公開對其功能進行訪問的API。 由於這些服務作爲單獨的進程存在，因此通過網絡進行通信是它們彼此連接並接收處理請求的唯一方式。這意味着每個新服務都會公開一個可供其他人訪問的接口，如果開發人員不注意，他們可能會不小心將其公開給錯誤的參與者。
防止網絡接口意外暴露是另一個依賴管理工具可以提供支持的領域。通過開發人員提供其服務的依賴關係的結構化索引，我們不僅可以自動解決這些依賴，而且還可以豐富相應的網絡策略來鎖定服務調用關係——只有相互依賴的服務才能訪問彼此。這種結構化方法極大地減少了開發人員理解網絡安全工具的需求，並使他們可以自由的創建更多服務。
5. 靈活性
靈活性是微服務和分佈式應用依賴管理工具的另一個好處。開發人員可以捕獲依賴項的詳細信息並將它們關聯到自己的服務，這樣解析器本身可以自由地以特定方式在部署環境中檢測這些依賴關係。想要嘗試不同的API網關或服務網格？想要追蹤每一個服務的入站和出站的流量來實現分佈式追蹤？藉助依賴管理工具的自動化功能，運營人員可以自由嘗試新工具和配置，而不必改動現有服務的代碼或干擾開發人員。
爲什麼它還不存在
依賴關係解析將是一個強大的工具，使開發人員能夠進行協作併爲雲原生應用程序做出貢獻，但是我們不能使用已經存在的大量軟件包管理器來進行依賴管理嗎？雖然使用現有工具會很好，但是解決網絡應用程序的依賴關係與解決庫與二進制文件之間的關係並不是同樣的工作。
對於普通庫，滿足依賴要求的依賴下載全部在構建時進行，以創建一個主二進制文件/庫。但是，微服務不是捆綁到單個二進制文件中，而是需要作爲獨立服務運行，然後通過網絡進行連接。這意味着依賴解析策略還有額外的步驟，並且該步驟發生在與常規庫完全不同的生命週期階段。事實證明，在應用程序生命週期中，我們可以正確解決分佈式應用程序依賴關係的最早時間是在部署時。此時，我們既瞭解堆棧中所有服務之間的關係，也瞭解目標環境的工具和詳細信息，而這一目標環境需要正確配置並用以提供服務連接。
綜上所述，很難爲網絡依賴關係創建大規模的解析器，但是這樣做將爲工程團隊和整個雲社區帶來巨大好處。如果我們要正確地駕馭雲原生工具的不斷髮展的局面，則需要從過去的依賴管理實踐中學習經驗。
原文鏈接：
https://www.architect.io/blog/why-distributed-apps-need-dependency-management