文章插圖

文章插圖
分布式云應用程序(又名微服務)已將大量復雜性引入到云軟件的設計和運營中 。曾經的單體應用將復雜性隱藏在單個進程或運行時中 , 現在卻分散在數十或數百個松耦合的服務中 。盡管所有這些服務都可以使用不同的編程語言 , 并且可以彼此獨立地進行擴展 , 但是分布式特性通常會使應用程序整體難以駕馭、難以部署并且很難保證安全 。
這種新的復雜性使得管理和開發云原生應用程序變得越來越困難 , 并且引發了有關如何維護健康云軟件的問題 。我們如何才能利用面向服務設計的好處 , 而又不會在其他地方引入沖突和成本呢?
幸運的是 , 我們之前已經遇到過這個問題 。微服務并不是第一種迫使開發人員弄清楚如何協作 , 并為無數互連組件操勞的模式 。在過去的幾十年中 , 這類問題的解決方案一直是相同的:依賴管理 。
我們每天都使用依賴管理來重復使用公有和私有軟件包 , 并在他人工作的基礎上 , 將我們自己的應用優雅的封裝為可用格式提供給其他人 。依賴管理是釋放分布式軟件能力的關鍵 , 背后的原因有很多;現在是時候向過去學習 , 為云原生開發的未來提供動力了 。
1. 開發者協作
依賴管理工具(如 NPM , Pip , Maven 等)最重要的功能之一是促進開發者之間的協作 。通過提供一致的打包機制以無縫擴展代碼 , 依賴管理工具使原本不相關的團隊可以互相使用彼此的成果 。我們可以在企業內部使用這些工具 , 以使團隊能夠在工作中協作并發布自己的成果;我們還看到 , 依賴管理工具得到了更廣泛的應用 , 以在開源社區中促成協作 。依賴管理工具的一致性以及較高的采用率使得社區能夠創建功能非常強大且可自由訪問的軟件庫 , 以供所有人使用并在此基礎上繼續發展 。
雖然這種協作水平已經在社區中針對單個編程語言實現了(針對 Javascript 的 NPM , 針對 Python 的 Pip 等) , 但尚未在云原生社區中完全實現 。幸運的是 , 我們使用 Docker 打包云服務可以保證一致性 , 但是容器沒有足夠的有關服務之間關系的信息來解析和擴展依賴關系 。如果我們想為微服務實現類似于其他單獨編程語言中的依賴管理功能 , 則非常重要的環節是添加適當的依賴管理工具 , 以索引并解析與其他應用和服務的關系 。
2. 自服務環境
依賴管理工具產生的協作作用并不是憑空產生的 。一致的依賴解析器如此強大的主要原因是 , 世界各地的開發人員都可以使用相同的命令和流程來重現其效果 ??芍貜托允且蕾嚬芾砉ぞ叩年P鍵要素 。沒有它 , 開發人員需要使用復雜的傳統方式來自行下載和使用其他人創建的庫 , 從而極大阻礙軟件庫的采用和分發 。
【分布式應用是什么意思 分布式軟件開發是什么】在這方面 , 面向服務的應用程序與基于特定語言的應用并沒有什么不同 。我們擴展他人工作的能力取決于我們運行或訪問我們希望調用的服務或應用 。團隊能夠通過集中式的質量保證或沙箱環境來做出貢獻 , 但無法復現這些環境會帶來一系列新問題 。工程師無法運營自己的開發環境 , 依賴其他應用的服務無法輕松交付 , 開發人員被迫編寫自己的腳本以在本地和遠程運行他們的應用 , 每個團隊都需要關心生產級工具、網絡的信息 , 以及網絡安全性 。通過一致的依賴管理工具 , 團隊只需聲明其服務的依賴 , 即可為組織中的每個人提供一致的方式來部署其服務棧及其依賴 , 從而使每個人都可以運營自己的環境 。
3. 自動化
一致的依賴管理工具所具有的自服務優勢不僅僅意味著開發人員可以運營自己的環境 。這也意味著可以通過自動化的方式來產生和拆除環境 。單個命令或過程(用于解決依賴關系、豐富網絡和自動化安全性)的一致性是集成到 CI/CD 流水線的完美秘訣!
如果每個服務都可以一致地運行(例如在容器平臺上運行)并且知道其自身的依賴 , 則可以為每個合并請求提供新的環境 , 并且在合并到相關分支后可以將更改無縫地升級到預發布和生產環境中 。這意味著每個團隊都可以為每個開發人員和添加到應用程序的每個新服務實現可擴展的 GitOps。
4. 安全性
微服務架構引入的風險之一是每個服務都需要公開對其功能進行訪問的 API 。由于這些服務作為單獨的進程存在 , 因此通過網絡進行通信是它們彼此連接并接收處理請求的唯一方式 。這意味著每個新服務都會公開一個可供其他人訪問的接口 , 如果開發人員不注意 , 他們可能會不小心將其公開給錯誤的參與者 。
5. 靈活性
靈活性是微服務和分布式應用依賴管理工具的另一個好處 。開發人員可以捕獲依賴項的詳細信息并將它們關聯到自己的服務 , 這樣解析器本身可以自由地以特定方式在部署環境中檢測這些依賴關系 。想要嘗試不同的 API 網關或服務網格?想要追蹤每一個服務的入站和出站的流量來實現分布式追蹤?借助依賴管理工具的自動化功能 , 運營人員可以自由嘗試新工具和配置 , 而不必改動現有服務的代碼或干擾開發人員 。
為什么它還不存在
依賴關系解析將是一個強大的工具 , 使開發人員能夠進行協作并為云原生應用程序做出貢獻 , 但是我們不能使用已經存在的大量軟件包管理器來進行依賴管理嗎?雖然使用現有工具會很好 , 但是解決網絡應用程序的依賴關系與解決庫與二進制文件之間的關系并不是同樣的工作 。
對于普通庫 , 滿足依賴要求的依賴下載全部在構建時進行 , 以創建一個主二進制文件 / 庫 。但是 , 微服務不是捆綁到單個二進制文件中 , 而是需要作為獨立服務運行 , 然后通過網絡進行連接 。這意味著依賴解析策略還有額外的步驟 , 并且該步驟發生在與常規庫完全不同的生命周期階段 。事實證明 , 在應用程序生命周期中 , 我們可以正確解決分布式應用程序依賴關系的最早時間是在部署時 。此時 , 我們既了解堆棧中所有服務之間的關系 , 也了解目標環境的工具和詳細信息 , 而這一目標環境需要正確配置并用以提供服務連接 。
綜上所述 , 很難為網絡依賴關系創建大規模的解析器 , 但是這樣做將為工程團隊和整個云社區帶來巨大好處 。如果我們要正確地駕馭云原生工具的不斷發展的局面 , 則需要從過去的依賴管理實踐中學習經驗 。
- 標簽檢測報告是什么內容 標簽檢測報告檢測哪些
- 線性光耦工作原理 線性光耦典型應用
- 手機窗口切換快捷鍵是什么 多個窗口進行切換的快捷鍵
- PIN二極管工作原理 pin二極管的應用詳解
- 女朋友總是太過于粘人 粘人的女孩是什么心理
- 宇宙少女311事件是什么意思 苞娜不和吳宣儀互動
- 外鏈的作用是什么 外鏈的什么很重要
- 阿里旗下應用接入微信支付 阿里多個App已接入微信支付
- 搓澡時搓出來的“泥”到底是什么
- 分布式數據處理技術 大數據分布式處理怎么理解
