僅在幾年前，當(dāng)我們談?wù)摶A(chǔ)架構(gòu)時，我們指的是物理基礎(chǔ)架構(gòu)：服務(wù)器、內(nèi)存、磁盤、網(wǎng)絡(luò)交換機以及連接它們所需的所有電纜。我曾經(jīng)有一些電子表格，在其中插入一些數(shù)字并獲取構(gòu)建可支持?jǐn)?shù)千甚至數(shù)百萬用戶的Web應(yīng)用程序所需的硬件規(guī)格。

一切都變了。首先是虛擬基礎(chǔ)架構(gòu)，位于這些物理服務(wù)器機架之上。借助一組虛擬機管理程序以及軟件定義的網(wǎng)絡(luò)和存儲，我可以指定應(yīng)用程序的計算要求，并在其他人為我管理的物理硬件之上配置該應(yīng)用程序及其虛擬網(wǎng)絡(luò)。如今，在超大規(guī)模公共云中，我們正在業(yè)務(wù)流程框架之上構(gòu)建分布式應(yīng)用程序，該框架可自動管理向上和向外的擴展。

使用服務(wù)網(wǎng)格來管理分布式應(yīng)用程序基礎(chǔ)結(jié)構(gòu)

這些新的應(yīng)用程序基礎(chǔ)結(jié)構(gòu)需要它們自己的基礎(chǔ)結(jié)構(gòu)層，該層足夠智能以響應(yīng)自動擴展，處理負載平衡和服務(wù)發(fā)現(xiàn)并仍支持策略驅(qū)動的安全性。

坐在微服務(wù)容器外部，您的應(yīng)用程序基礎(chǔ)結(jié)構(gòu)被實現(xiàn)為服務(wù)網(wǎng)格，每個容器都鏈接到作為邊車運行的代理。這些代理管理容器間的通信，使開發(fā)團隊可以專注于他們的服務(wù)和它們托管的API，而應(yīng)用程序運營團隊則管理連接它們的服務(wù)網(wǎng)格。

實施服務(wù)網(wǎng)格的任何人可能面臨的最大問題是：它們太多了：谷歌流行的Istio、開源Linkerd、HashiCorp的Consul或更多的實驗工具，例如F5的Aspen Mesh。在整個組織中，很難選擇一個，而且仍然很難在一個上實現(xiàn)標(biāo)準(zhǔn)化。

當(dāng)前，如果要將服務(wù)網(wǎng)格與Azure Kubernetes Service一起使用，建議使用Istio，Linkerd或Consul，并將其說明作為AKS文檔的一部分。這不是最簡單的方法，因為您需要單獨的虛擬機來管理服務(wù)網(wǎng)格以及AKS上正在運行的Kubernetes集群。但是，正在開發(fā)的另一種方法是Service Mesh Interface（SMI），它提供了一套標(biāo)準(zhǔn)的接口，用于將Kubernetes與Service Mesh鏈接。由于Kubernetes團隊一直在領(lǐng)導(dǎo)開發(fā)，Azure一直為SMI提供支持。

SMI：一組通用的服務(wù)網(wǎng)格API

SMI是像Kubernetes一樣的Cloud Native Computing Foundation項目，盡管目前只是一個沙盒項目。處于沙箱中意味著它尚未被認為是穩(wěn)定的，因為它經(jīng)歷了CNCF開發(fā)計劃的各個階段，因此可能會發(fā)生重大變化。當(dāng)然，在云和Kubernetes供應(yīng)商以及服務(wù)網(wǎng)格項目的支持下，有很多支持。SMI旨在為Kubernetes提供一組基本API，以連接到符合SMI的服務(wù)網(wǎng)格，因此您的腳本和操作員可以與任何服務(wù)網(wǎng)格一起使用。無需鎖定單個提供商。

作為一組自定義資源定義和擴展API服務(wù)器構(gòu)建的SMI可以安裝在任何經(jīng)過認證的Kubernetes發(fā)行版上，例如AKS。安裝到位后，您可以使用熟悉的工具和技術(shù)定義應(yīng)用程序和服務(wù)網(wǎng)格之間的連接。SMI應(yīng)該使應(yīng)用程序具有可移植性。例如，您可以使用Istio使用SMI在本地Kubernetes實例上進行開發(fā)，并將任何應(yīng)用程序帶到具有SMI兼容服務(wù)網(wǎng)格的托管Kubernetes中，而不必擔(dān)心兼容性。

重要的是要記住，SMI本身并不是服務(wù)網(wǎng)格。這是服務(wù)網(wǎng)格需要實現(xiàn)以具有通用基本功能集的規(guī)范。沒有什么可以阻止服務(wù)網(wǎng)格進一步發(fā)展并添加自己的擴展和接口的，但是它們必須具有吸引力才能被應(yīng)用程序和應(yīng)用程序運營團隊使用。SMI項目背后的人們還注意到，隨著服務(wù)網(wǎng)格定義的發(fā)展和預(yù)期功能列表的改變，他們并不反對將新功能移植到SMI規(guī)范中。

引入開放式服務(wù)網(wǎng)格，Microsoft的SMI實現(xiàn)

微軟最近宣布在其在SMI社區(qū)中的工作的基礎(chǔ)上，推出了首個Kubernetes服務(wù)網(wǎng)格。開放服務(wù)網(wǎng)格是一種符合SMI的輕量級服務(wù)網(wǎng)格，可作為托管在GitHub上的開源項目運行。Microsoft希望OSM成為社區(qū)主導(dǎo)的項目，并打算盡快將其捐贈給CNCF。您可以將OSM視為SMI的參考實現(xiàn)，它是基于現(xiàn)有服務(wù)網(wǎng)格組件和概念構(gòu)建的。

盡管Microsoft并未這么明確地說，但在其公告和文檔中有其在Azure上使用服務(wù)網(wǎng)格的經(jīng)驗，并且著重于操作員方面。在最初的博客文章中，Michelle Noorali將OSM描述為“讓Kubernetes操作員毫不費力地安裝，維護和運行”。這是一個明智的決定。OSM與供應(yīng)商無關(guān)，但是它很可能成為AKS的眾多服務(wù)網(wǎng)格選項之一，因此使其易于安裝和管理將成為推動接受度的重要組成部分。

OSM建立在其他服務(wù)網(wǎng)格項目中完成的工作之上。盡管它具有自己的控制平面，但數(shù)據(jù)平面是在Envoy上構(gòu)建的。同樣，這是一種務(wù)實且明智的方法。SMI與您如何控制和管理服務(wù)網(wǎng)格實例有關(guān)，因此使用熟悉的Envoy處理策略可以使OSM建立在現(xiàn)有技能集的基礎(chǔ)上，減少學(xué)習(xí)曲線，并允許應(yīng)用程序操作員從有限的SMI功能集過渡到更復(fù)雜的Envoy功能在必要時。

當(dāng)前，OSM實現(xiàn)了一組通用服務(wù)網(wǎng)格功能。其中包括對流量轉(zhuǎn)移的支持，保護服務(wù)到服務(wù)的鏈接，應(yīng)用訪問控制策略以及在服務(wù)中處理可觀察性。OSM通過自動部署Envoy Sidecar代理自動將新的應(yīng)用程序和服務(wù)添加到網(wǎng)格中。

部署和使用OSM

要從OSM alpha版本開始，請從項目的GitHub版本頁面下載其命令行界面osm 。運行時osm install，它將使用默認名稱空間和網(wǎng)格名稱將OSM控制平面添加到Kubernetes集群。您可以在安裝時更改它們。安裝并運行OSM后，您可以使用策略定義添加服務(wù)到網(wǎng)格中，以添加Kubernetes命名空間，并自動將sidecar代理添加到托管命名空間中的所有pod。

這些將實現(xiàn)您選擇的策略，因此在開始部署之前設(shè)計一套SMI策略是一個好主意。OSM GitHub存儲庫中的示例策略將幫助您入門。OSM有用地包括Prometheus監(jiān)視工具包和Grafana可視化工具，因此您可以快速查看服務(wù)網(wǎng)格和Kubernetes應(yīng)用程序的運行方式。

Kubernetes是現(xiàn)代的云原生應(yīng)用程序中的重要基礎(chǔ)架構(gòu)元素，因此開始將其視之為重要。這要求您將其與運行在其上的應(yīng)用程序分開進行管理。AKS、OSM、Git和Azure Arc的組合應(yīng)該為您提供托管Kubernetes應(yīng)用程序環(huán)境的基礎(chǔ)。應(yīng)用程序基礎(chǔ)架構(gòu)團隊管理AKS和OSM，設(shè)置應(yīng)用程序和服務(wù)的策略，同時Git和Arc控制應(yīng)用程序的開發(fā)和部署，并通過OSM的可觀察性工具提供實時的應(yīng)用程序指標(biāo)。

所有這些元素完全融合還需要一段時間，但是很明顯，微軟正在對分布式應(yīng)用程序管理以及必要的工具做出重大承諾。有了AKS，該套件的基本要素以及OSM和Arc均已添加，因此無需等待。您現(xiàn)在可以使用Envoy作為服務(wù)網(wǎng)格在Azure上構(gòu)建和部署Kubernetes，同時在實驗室中對OSM和Arc進行原型制作，以使其適合生產(chǎn)。等待不應(yīng)該那么久。