例如，根據(jù) Cloud Native Computing Foundation （CNCF）的客戶調(diào)查，73%的受訪客戶在生成環(huán)境中運行容器應(yīng)用程序，其余27%的客戶計劃在未來使用容器。
除了調(diào)查數(shù)據(jù)，以及媒體相關(guān)報道的激增（盡管有些人認為Kubernetes有炒作的成分），但毫無疑問容器是基礎(chǔ)設(shè)施虛擬化的下一波浪潮。這是因為容器化有很多顯而易見的好處：應(yīng)用程序的可移植性、已于部署配置、更好的可伸縮性、基礎(chǔ)設(shè)施靈活性、更高的生產(chǎn)力、持續(xù)集成以及更高效的資源利用。
與此同時，應(yīng)用程序的系統(tǒng)架構(gòu)也發(fā)生演變，從數(shù)十年前的面向服務(wù)架構(gòu)（SOA）發(fā)展到微服務(wù)體系架構(gòu)。運用微服務(wù)架構(gòu)，應(yīng)用程序被構(gòu)建為使用定義良好的接口，來進行通信的服務(wù)組件。每個微服務(wù)組件都是可獨立部署和可伸縮的�；谖⒎⻊�(wù)應(yīng)用程序的設(shè)計，考慮了分布式協(xié)調(diào)、分布式事務(wù)控制、基礎(chǔ)設(shè)施自動化、故障移除和彈性伸縮。
微服務(wù)架構(gòu)與容器緊密關(guān)聯(lián)也不是巧合，因為容器化在不同的微服務(wù)組件之間提供了明顯自然的邊界。并且，使用容器技術(shù)并不要求應(yīng)用程序必須是微服務(wù)架構(gòu)，巨石型應(yīng)用也可以被容器化，然后一個容器會代表一個整體，或者單實例的可運行應(yīng)用。
單一容器化應(yīng)用的一個缺點是，由于應(yīng)用程序的組件完全耦合在一起，所以即便是做很小部分的改動，也需要對整個容器進行重新構(gòu)建和部署。隨著時間的推移，通常很難在單體模型中維持良好的模塊化結(jié)構(gòu)，如果應(yīng)用程序中的某個部分需要擴容，那么整個應(yīng)用必須一起擴容，在運維角度看這是低效的。
話句話說，這是眾所周知的：許多企業(yè)和開發(fā)人員已經(jīng)發(fā)現(xiàn)，如果不同時采用微服務(wù)架構(gòu)，就不可能完全享受到遷移到容器的好處。采用基于容器的微服務(wù)應(yīng)用體系，帶來的相互增強的好處是非常顯著的，缺一不可。理想情況下，任何支持這種現(xiàn)代化工作的工具都將會趨于類似和全面。
一、存儲和數(shù)據(jù)管理
靜態(tài)應(yīng)用程序是容器初始應(yīng)用的主要驅(qū)動，通常由微服務(wù)組件組成，充當著未使用容器動態(tài)后端應(yīng)用的前端。要實現(xiàn)基于容器的基礎(chǔ)設(shè)施，需將靜態(tài)和動態(tài)的應(yīng)用程序都遷移至容器。要實現(xiàn)這一點，則需要考慮容器環(huán)境中存儲和數(shù)據(jù)管理方面的挑戰(zhàn)，以便于更有效的實現(xiàn)容器化。
現(xiàn)在，我們正處于容器化生產(chǎn)部署中動態(tài)應(yīng)用如何進行存儲和管理的建設(shè)階段。許多人依賴于外部，筒倉式存儲設(shè)備不是云/容器環(huán)境的組成部分，但也已經(jīng)發(fā)展成熟，而且提供了豐富的數(shù)據(jù)管理功能，如故障恢復、數(shù)據(jù)還原、格式化（與鏡像相反）和存儲分層。
要充分體會到容器化的好處，存儲基礎(chǔ)設(shè)施必須與相同環(huán)境中的容器化應(yīng)用程序運行在相同的環(huán)境中。這將大大的簡化管理、降低成本，提高資源利用率。達到這一點需要一種新的方法。
二、重構(gòu)存儲架構(gòu)
存儲體系一直想要實現(xiàn)分離數(shù)據(jù)面板和控制面板，以允許數(shù)據(jù)（數(shù)據(jù)面板）和元數(shù)據(jù)（控制平臺）流的獨立伸縮。此外，分離平面允許有控制面板驅(qū)動數(shù)據(jù)管理操作，如分層、數(shù)據(jù)遷移或快照，而不會干擾數(shù)據(jù)路徑活動。
到為目前為止，存儲還未實現(xiàn)有效的分離控制面板和數(shù)據(jù)面板，標準繁瑣、附加的增量特性和非最優(yōu)數(shù)據(jù)流是需要克服的障礙。然而，容器和微服務(wù)的出現(xiàn)為存儲領(lǐng)域提供了一個機會，可以把它們拋諸腦后，重新開始。
三、探索微服務(wù)
微服務(wù)架構(gòu)原則能夠很自然地應(yīng)用到容器本機存儲系統(tǒng)設(shè)計中。例如，控制和數(shù)據(jù)路徑分離就很好的符合“高內(nèi)聚、低耦合”微服務(wù)設(shè)計原則。
基于微服務(wù)的設(shè)計可能是什么樣子的？它將帶來什么好處？
通過分離控制平臺和數(shù)據(jù)平臺，基于微服務(wù)的容器本地存儲解決方案將具有不同的控制實體（元數(shù)據(jù)）和數(shù)據(jù)服務(wù)，它們以高度可擴展、分布式的方法，獨立聯(lián)合地提供服務(wù)（IO和數(shù)據(jù)管理），類似于基于微服務(wù)的應(yīng)用程序一樣�？梢哉f使用微服務(wù)實現(xiàn)存儲系統(tǒng)不僅可以實現(xiàn)，而且可以強制分離控制平臺和數(shù)據(jù)面板。
- 容量規(guī)劃與性能擴展：基于微服務(wù)的容器本地存儲系統(tǒng)能夠有效地分離數(shù)據(jù)和控制路徑，它將提供多個維度的伸縮性，容量、帶寬、IOPS，以允許容量和性能根據(jù)需要進行彈性伸縮。不應(yīng)該低估縮減資源的影響，因為這樣靈活性可以資源在應(yīng)用之間高效共享。
- 彈性：由于微服務(wù)可以自動失敗后進行重新啟動，因此這種類型的設(shè)計提升了應(yīng)用的彈性變化。
- 數(shù)據(jù)管理：許多數(shù)據(jù)管理操作可以僅有元數(shù)據(jù)微服務(wù)執(zhí)行，而不影響數(shù)據(jù)面板。在其他需要操作數(shù)據(jù)的情況下，可以以最小化性能問題對元數(shù)據(jù)和數(shù)據(jù)的操作進行解耦，提高效率。
- 存儲設(shè)備支持：由于微服務(wù)是獨立的，并且運用定義明確的協(xié)議進行通信，因此該系統(tǒng)能夠?qū)崿F(xiàn)多種風格的數(shù)據(jù)面板微服務(wù)，驅(qū)動多種設(shè)備類型。
- 分層：通過控制這些設(shè)備類型之間的分層操作，元數(shù)據(jù)微服務(wù)可以提供進一步的作用，從而更好的實現(xiàn)成本結(jié)構(gòu)和最佳數(shù)據(jù)結(jié)構(gòu)。
- 數(shù)據(jù)遷移：一旦數(shù)據(jù)和元數(shù)據(jù)存儲被離散的微服務(wù)單獨維護，多個元數(shù)據(jù)條目可能引用一個公共數(shù)據(jù)塊，那么文件或邏輯卷等對象可以被虛擬化為輕量級的、元數(shù)據(jù)專用的對象，這些對象引用的公共數(shù)據(jù)池，可能跨越不用的設(shè)備類型甚至地理位置。這位混合云或者多云的快速部署帶來了有益的數(shù)據(jù)遷移能力。
- 存儲協(xié)議和應(yīng)用支持：將應(yīng)用程序前端做為微服務(wù)，它也可以以多種方式實現(xiàn)，支持不同的存儲訪問協(xié)議，甚至于特定于應(yīng)用程序的訪問，從而提供更大的靈活性。
雖然基于微服務(wù)的容器本地存儲系統(tǒng)可以提供應(yīng)用程序和容器所需的靈活性、可伸縮性和可移植性，但是還需要考慮其他問題。例如，對于需要高并發(fā)的分布式系統(tǒng)來說，維護強一致性是極其困難的，而對于許多應(yīng)用程序來說，最終一致性并不是一個選項。雖然這是一個巨大的挑戰(zhàn)，但也不是不可能解決，而且這不應(yīng)該妨礙對基于微服務(wù)架構(gòu)的追求。
四、結(jié)論
微服務(wù)和容器已經(jīng)為當前的業(yè)務(wù)貢獻了重要的價值，隨著越來越多的應(yīng)用程序?qū)崿F(xiàn)云原生開發(fā)，支持這些應(yīng)用程序的基礎(chǔ)設(shè)施也將得到發(fā)展�；谖⒎⻊�(wù)的容器本地存儲方法的靈活性和可擴展性，可以幫助制定滿足現(xiàn)代應(yīng)用程序需求的解決方案，同時消除基礎(chǔ)設(shè)施的限制。要真正實現(xiàn)容器帶來的應(yīng)用程序現(xiàn)代化的潛力，我們需要采用微服務(wù)方法，消除存儲解決方案的限制。
原文鏈接：https://thenewstack.io/why-cloud-native-storage-requires-tightly-coupled-containers-and-microservices/
原文鏈接：https://thenewstack.io/why-cloud-native-storage-requires-tightly-coupled-containers-and-microservices/
