前言

　　分布式云應(yīng)用(也叫微服務(wù))在大行其道的同時，也給應(yīng)用本身的設(shè)計和運維帶來巨大的復(fù)雜性。以前單體服務(wù)時代，尚可將這種復(fù)雜性隱藏于自身內(nèi)部，而到了微服務(wù)時代，這種復(fù)雜性幾乎擴(kuò)散到了成百上千個“松耦合”的服務(wù)上面。盡管每個微服務(wù)都可以使用不同的語言構(gòu)建，也可以快速地橫向擴(kuò)展，但他們作為一個整體，相比于單體服務(wù)，分布式的特性常常會帶來規(guī)劃、部署和安全上的難題。

　　這些問題也給云原生應(yīng)用的管理和發(fā)展帶來挑戰(zhàn)。我們不禁要思考，怎樣才能確保云原生應(yīng)用的持續(xù)健康，如何才能取其精華，去其糟粕，既保持面向服務(wù)設(shè)計的優(yōu)勢，同時不增加開發(fā)維護(hù)等成本?

　　還好在微服務(wù)之前就遇到過類似的問題，對于如何治理錯綜復(fù)雜的組件關(guān)系網(wǎng)，經(jīng)過幾十年的積累，開發(fā)者們已經(jīng)提煉出了一套通用的解決方案：依賴管理(Dependency Management)。

　　其實我們每天都在使用依賴管理器提供的公共或者私有的軟件包，在這些包的基礎(chǔ)之上增加自己的功能，最后再精心地打包為標(biāo)準(zhǔn)格式以供后續(xù)使用。筆者認(rèn)為依賴管理正是釋放分布式應(yīng)用強(qiáng)大能力的關(guān)鍵，現(xiàn)在是時候引入依賴管理機(jī)制來推動云原生技術(shù)的發(fā)展了，具體來說，有以下5點原因。

　　1.開發(fā)者之間的相互協(xié)作

　　NPM, Pip, Maven等依賴管理器最重要的作用之一，就是促進(jìn)了開發(fā)者之間的相互協(xié)作。通過提供一套統(tǒng)一的打包管理機(jī)制，依賴管理器可以讓你的代碼被其他團(tuán)隊使用或者增強(qiáng)。此外，不僅在企業(yè)內(nèi)部團(tuán)隊之間，我們也看到了依賴管理大范圍地用于促進(jìn)開源社區(qū)上的協(xié)作。工具的一致性和使用的廣泛性也使我們能夠創(chuàng)建強(qiáng)大易得的軟件庫，從而供所有人使用并在其上進(jìn)行構(gòu)建。

　　這種級別的協(xié)作已經(jīng)在各個語言社區(qū)中實現(xiàn)，比如JavaScript的NPM，Python的Pip等，但在云原生社區(qū)里還沒有成型的落地方案。雖然有Docker定義了云服務(wù)打包的規(guī)范，但各種容器方案還缺乏足夠的信息去解析和拓展服務(wù)間的依賴關(guān)系。如果我們希望微服務(wù)也能實現(xiàn)這種協(xié)作效果，就像各個語言對軟件庫做的那樣，就非常有必要增加合適的依賴管理機(jī)制，使其能檢索并處理各個終端服務(wù)之間的關(guān)系。

　　2.環(huán)境的自服務(wù)

　　依賴管理器的協(xié)作效果并不能憑空產(chǎn)生，而是得益于統(tǒng)一的依賴解析。統(tǒng)一的依賴解析之所以強(qiáng)大，主要是因為世界各地的開發(fā)者都能夠使用相同的命令和程序來重現(xiàn)他們的效果?？芍貜?fù)性(Reproducibility)是依賴管理器的一個關(guān)鍵要素，缺少了這個要素，如果沒有定制復(fù)雜的啟動邏輯，開發(fā)者們就不能方便地下載和操作其他人創(chuàng)建的庫和包，而這些將增加開發(fā)成本，成為大規(guī)模采用和分發(fā)的巨大障礙。

　　在這方面，微服務(wù)與各種語言庫之間沒有太大的差別。我們擴(kuò)展他人工作的成果，取決于我們可以運行或調(diào)用期望的服務(wù)和應(yīng)用程序的能力。目前，我們已經(jīng)可以通過沙盒環(huán)境，集中QA的形式來完成任務(wù)，但還無法真正做到環(huán)境的完全重現(xiàn)，從而會產(chǎn)生一系列的問題。由于依賴他人的服務(wù)無法輕松交付，開發(fā)者并沒有完全操控自己的開發(fā)環(huán)境的能力，需要被迫編寫自己的腳本來本地或者遠(yuǎn)程地運行他人的應(yīng)用程序，同時每個團(tuán)隊都需要開發(fā)生產(chǎn)級別的工具，自行保證網(wǎng)絡(luò)問題和安全問題。

　　如果擁有統(tǒng)一的依賴關(guān)系管理解決方案，每個團(tuán)隊只需要聲明其服務(wù)的網(wǎng)絡(luò)依賴關(guān)系，即可為組織中的每個人提供相同的方式來運行其技術(shù)棧中的服務(wù)，并同時準(zhǔn)備好服務(wù)的依賴，可以使每個開發(fā)者真正地?fù)碛胁倏丨h(huán)境的能力。

　　3.自動化

　　自助服務(wù)優(yōu)勢不僅僅意味著開發(fā)者可以操控自己的環(huán)境，也意味著開發(fā)環(huán)境可以通過程序自動化來提供并且細(xì)化。只需使用一個命令或程序，就能實現(xiàn)依賴關(guān)系的解析、網(wǎng)絡(luò)的豐富、安全性的自動保證，這是能否集成到CI/CD管道的關(guān)鍵。

　　如果每個服務(wù)都可以使用統(tǒng)一的機(jī)制運行(例如，使用容器平臺)并且知道自己的依賴關(guān)系，那么每次Git合并請求就能提供一套新的環(huán)境，并且無縫地發(fā)布到預(yù)生產(chǎn)和生產(chǎn)環(huán)境。這意味著每個團(tuán)隊都可以為每個成員和每個添加到應(yīng)用里的新服務(wù)提供非常靈活的基于Git的自動運維部署，即GitOps。

　　4.安全性

　　微服務(wù)架構(gòu)其中的一個安全風(fēng)險，是每個服務(wù)都需要暴露API接口以提供功能的調(diào)用。由于這些服務(wù)作為單獨的進(jìn)程存在，因此通過網(wǎng)絡(luò)進(jìn)行通信幾乎是服務(wù)間相互連接、接收處理請求的唯一方式。這意味著每個新服務(wù)都會公開一些其他人可以訪問的接口，如果開發(fā)者不小心，可能會錯誤地暴露接口給到本不允許訪問的服務(wù)。

　　防止網(wǎng)絡(luò)接口的意外暴露是依賴管理可以大展身手的另一個領(lǐng)域。通過帶有網(wǎng)絡(luò)依賴的結(jié)構(gòu)化索引，我們不僅可以自動解析服務(wù)間的依賴，還可以豐富環(huán)境配置，生成對應(yīng)的網(wǎng)絡(luò)策略來保障接口的合法訪問，也就是說只有相互依賴的服務(wù)才能相互訪問。這種結(jié)構(gòu)化的方式將極大減少開發(fā)者了解網(wǎng)絡(luò)安全工具的需求，并讓他們可以更自由地創(chuàng)建新服務(wù)。

　　5.靈活性

　　微服務(wù)或者說分布式應(yīng)用的依賴管理的另一個好處是靈活性。一旦開發(fā)者確定好依賴項并關(guān)聯(lián)到自己的服務(wù)上，解析器自己就可以在每個部署的環(huán)境中唯一地構(gòu)建好關(guān)系網(wǎng)絡(luò)。想嘗試不同的API網(wǎng)關(guān)(API Gateway)或服務(wù)網(wǎng)格(Service Mesh)?想通過每個服務(wù)的入口和出口流量來進(jìn)行鏈接追蹤?通過依賴解析器的自動化分析，開發(fā)者可以自由地試驗新工具和配置，而無需分散精力對現(xiàn)有的任何代碼進(jìn)行更改。

　　那為什么分布式應(yīng)用的依賴管理還沒出現(xiàn)?

　　依賴解析將是一個非常強(qiáng)大的解決方案，使得開發(fā)者能夠相互協(xié)作并對云原生應(yīng)用做出貢獻(xiàn)，那么我們能使用現(xiàn)有的包管理器來幫助實現(xiàn)嗎?盡管使用現(xiàn)有的工具也許可行，但解決網(wǎng)絡(luò)應(yīng)用的依賴關(guān)系和解決二進(jìn)制庫文件之間還是有著明顯的差異。

　　依賴的二進(jìn)制庫文件是在主庫文件編譯構(gòu)建時才下載的，但是微服務(wù)不會捆綁到單個二進(jìn)制文件中，它們需要作為獨立服務(wù)運行，然后通過網(wǎng)絡(luò)連接交互形成一個完整的應(yīng)用。這意味著解析有著額外的步驟，并且發(fā)生在與二進(jìn)制庫完全不同的生命周期階段。事實證明，可以正確解析分布式應(yīng)用依賴關(guān)系的最早時間是在部署階段。正是在部署時，我們既知道技術(shù)棧中所有服務(wù)間的關(guān)系，也了解正確配置和連接服務(wù)所需的工具與目標(biāo)環(huán)境細(xì)節(jié)。

　　結(jié)語

　　總而言之，目前還很難創(chuàng)建一個大規(guī)模的解析器用于解決網(wǎng)絡(luò)依賴，但這樣做會給工程團(tuán)隊和整個云社區(qū)帶來巨大的好處。如果我們要正確引導(dǎo)云原生工具的發(fā)展方向，我們就需要從過去的依賴管理實踐中總結(jié)學(xué)習(xí)。

　　原文標(biāo)題：Why Distributed Apps Need Dependency Management，作者：David Thor