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

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

使用服務網(wǎng)格來管理分布式應用程序基礎結構

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

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

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

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

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

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

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

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

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

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

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

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

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

部署和使用OSM

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

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

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

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