2017 年 2 月

第 32 卷,第 2 期

本文章是由機器翻譯。

Azure - 無伺服器結構與 Azure Functions

Joseph Fultz | 2017 年 2 月

從電腦到電腦的工具,我們的方法來自動化重複性的工作並標準化我們處理,以便我們可以專注於高價值特殊貢獻完成工作,並解決問題的內容。以平行方式,很明顯,隨著 IT 產業發展,我們已經 strived 達成每個從伺服器陣列中,想要從系統取得最高的效率輸出至 CPU 的系統層級較高的密度。無伺服器的架構是在這兩個串流趨於一致的點。它是的點的個人的努力最更精細地專注於特定的工作,且系統中的浪費最少。

在無伺服器的世界中,開發人員建立解決方案,而不是基礎結構和監視執行和不環境的健全狀況。財務支付時間配量,大部分是閒置的虛擬機器 (VM) 陣列。在 Microsoft Azure 中,有許多可鏈結在一起以表單整個方案的取用服務。索引鍵的新元件,這是 Azure 函式,提供完整的解決方案生態系統中的無伺服器的計算功能。在本文中,我們將探討這表示有無伺服器的架構,並瀏覽 Azure 函式工具。

無伺服器的架構,具有 Azure 函式

有許多定義,無伺服器的架構。雖然命名法,無伺服器的架構不是執行而不需要伺服器的程式碼。事實上,伺服器仍十分必要的。您只是不需要考慮它們。您可能會認為它的下一個反覆項目平台即服務 (PaaS),且時關閉,這不是,可以是。因此,完全,這是什麼? 基本上,無伺服器的架構是 PaaS,而抽象化離開 Vm、 應用程式架構,以及透過繫結的外部相依性,讓開發人員可以專注於實作商務邏輯的程式碼的只是為基礎的雲端服務的演進。

最好將討論 Azure 函式和無伺服器架構的一般屬性。Azure 函數提供無伺服器架構的無伺服器的運算元件。中所示**[圖 1**、 Azure 函式建構在 Azure App Service 和 WebJobs SDK,新增一些額外的魔法裝載並執行 Azure 函式的程式碼,並提供一些可,例如執行階段繫結。

Azure 的函式架構
[圖 1 Azure 函式架構

因此,您使用 Azure 應用程式服務取得的所有優點有,可以設定中找到之服務的正下方。此外,這也表示,WebJobs SDK 可在本機建立的本機執行階段環境。不架構的優勢,而 Azure 函式是多語言支援各種不同的語言,包括 Node.js、 C#、 PhP、 Python 和甚至是 Windows PowerShell 平台。執行階段和相依性是由平台處理。這是一項優點的混合式環境中運作,它可讓小組使用不同的喜好設定以及技術運用相同的平台建置及傳遞功能。使用 Azure 函式做為無伺服器架構的無伺服器的運算元件提供數個主要優點︰

  • 縮減產品上市時間︰ 因為基礎結構管理平台,開發人員可以自由專注於實作商務邏輯的應用程式程式碼。Azure 函數可能會被視為 nanoservices 的微服務的進一步分解。這兩個架構提供用於開發程序是一大福音開發、 測試和部署活動失去焦點放在一小段的其他相關,但不連續的服務分開管理的功能。
  • 較低的擁有權總成本︰ 因為基礎結構或維護的作業系統,開發人員可以專注於提供商業價值。此外,開發和維護所需的投資大幅簡化並減少。
  • 支付每次執行︰ 只需要支付已使用的循環中搭配使用的計算資源的功能密度的增加通常找到索引鍵的成本節約。

至於方法建置使用 Azure 函式時,實現的完整值的索引鍵是工作的邏輯的撰寫只的最小單位執行的單一範圍,並保留到最少的相依性。當使用 Azure 函式,最好是保持這些作法︰

  • Azure 函式應在本質上的單一用途。把它們視為簡短、 簡潔的陳述式,而不是複合的句子。
  • 作業是等冪的本質。也就是說,如果呼叫後續有重複使用相同的參數呼叫 API 端點系統產生狀態將會是不變。
  • 保持簡短的執行時間。目標應該會收到的輸入、 執行所需的作業和下游取用者取得的結果。長時間執行的處理程序,您可能考慮 Azure WebJobs 或甚至是裝載在 Azure Service Fabric 服務。
  • 在嘗試將保留的整體複雜性低和執行的快速方法,最好是內部的相依性降到最低。加入太多的執行階段加權會減慢初始載入時間,且會增加系統的複雜性。
  • 透過輸入和輸出繫結外部的整合。針對高效能的網站提供一些一般指引是撰寫的無狀態服務。這可以協助不複雜或速度變慢的服務,要保留,序列化及還原序列化的執行階段狀態,以及簡化偵錯的工作,因為您不需要探索,並嘗試重現狀態,找出發生什麼事;在無狀態就只需傳遞參數值後。

無伺服器架構的屬性包括下列各項︰

  • 無伺服器的架構中的工作單位的形式為無狀態的函式叫用事件。
  • 縮放比例、 容量和基礎結構管理是以服務形式提供。
  • 執行計費的模型,您只需支付次您的程式碼正在執行。

無伺服器架構的挑戰包括︰

  • 複雜度︰ 無伺服器的架構可讓開發人員簡化許多項目,而平台抽象概念您需要重新思考您要在其中建置應用程式的方式。管理以單一整合型應用程式是較簡單比管理眾多特殊用途的函式和它們之間的相依性。這是其中功能,例如 Azure API 管理所提供的那些派上用場,讓您可以建立一致的向外,面對結合在一起的命名空間的所有分開定義和管理函式。
  • 工具︰ 正在相對而言比較新,是仍在開發工具來撰寫、 偵錯和測試函式。撰寫本文時,它們目前在預覽中,但 Visual Studio 2017 會內建的工具。另外,管理和監視工具仍處於發展,但您可以在其中檢視要求、 成功、 錯誤和要求-回應詳細資料的 Azure 函式的基本介面。有很多時,就是將在平台應用程式監視工具和 Azure 函式小組正著手成長和發展這類支援的工作。
  • 組織的支援︰ 它是為部分移至無伺服器架構的重要的考量。許多組織將移至完全自動化的連續整合 (CI) 的挑戰 / 連續傳遞 (CD) 管線和微服務架構。移至無伺服器的設計可以加入這些問題,因為它通常會影響目前的標準,並且需要教育上可用、 如何將一起繫結以及如何加以管理的資源。
  • 沒有執行階段最佳化︰ 在傳統的設計中,您可能會將最佳化執行環境工作負載,變更的類型及數量的 RAM、 交換、 磁碟和網路連線等。Azure 函式,只有最少可以變更,例如,若要使用的儲存體帳戶。

與傳統架構無伺服器架構

典型的系統設計成品一組包含邏輯的設計、 技術設計和軟體架構。邏輯的設計通常定義系統和其用途、 的功能,而技術的設計通常會定義系統的功能。當您移動至無伺服器的架構,您就成為注重什麼樣的系統執行多個作業的相關比什麼是如此。在許多 IT 工作室您可能會發現更多類似的架構圖表**[圖 2**。

傳統的技術架構
[圖 2 的傳統技術架構

這種類型的成品特別重要的同仁竟然裝載、 網路、 而且 DBA 群組需要知道要佈建及設定。不過,在平台做為服務 (PaaS) 環境中,您的重心是功能的內容,並將佈建到平台需要只有本身定義 PaaS 服務的組態詳細資料。您輸入在組態中的相關詳細資料將保留在範本中,所有交談,您必須將焦點放在功能、 整合和功能,而不是什麼是最佳的量,RAM、 Cpu 和磁碟的相關討論。

結果圖表可能會有點接近通常看邏輯圖所示為**[圖 3**。這類圖表可以開始將重點放在函式組件,以及如何它們結合在一起,而不是所設定的應用程式主機的焦點。這個簡化的訊息和釐清目的不僅協助技術討論有關意圖和實作,但無可避免地有助於傳達更技術性的 office 焦點其實從系統是它的人所執行作業的相關討論系統的值。

無伺服器架構
[圖 3 無伺服器架構

作用中的 azure 函式

Azure IoT 平台提供一組豐富的服務,以支援集合和分析的資料。我們的範例需要現有的 IoT 實作建置以收集車輛遙測,並將它儲存在雲端、 具有基本的分析功能。我們現在要瀏覽至方案中,例如能夠查詢以找出最接近指定位置車輛的即時資料加入新功能。自由浮動的汽車共用程式或甚至在停車場中尋找您的車上,您可能會使用這類的功能。

我們必須請注意在此範例實作幾個警告訊息,因為我們故意為了示範平台與工具取得一些快速鍵。首先,我們正在直接使用 DocumentDB 的單一資料分割。在更質數的實作中,我們必須至少分區化,DocumentDB 會根據預期的磁碟區的資料,但是我們可能也選擇來進行其他動作,例如新增 Azure Redis 快取和 Azure 彈性搜尋最佳化讀取的路徑部分的方法。其次,因為目前的 DocumentDB API 會要求取得的記錄,我們要比較,我們已採取的前 100 筆記錄只會造成快顯的更多用戶端處理。資料分割和搜尋功能會較為典型的路徑,以找出需要大量的記錄。在任何情況下,您仍然會使用函數來尋找潛在的記錄,然後比較圖表與指定的位置並傳回最接近的車輛的集合。

建立函式

在撰寫本文時,Visual Studio 工具無法協助您加速開發程序。為此,我們一開始先建立 Azure 函式,透過入口網站的介面。Azure 入口網站中啟動 Azure 函式建立之後,您將會看到分頁,來設定一些設定值,那麼函式。請注意應用程式服務計劃選取的選項︰ 使用方案和應用程式服務方案。在這兩者之間選擇看起來像是最簡單的選擇,但實際上會被顯示舊樣式的管理資源和無伺服器架構的理想化目標之間做選擇。選擇應用程式服務方案,您必須進行推測需要處理能力。如果您選擇太多,要支付您未使用,但選擇太少的資源,您可能有問題,與您最終會影響您的客戶和您的營收的實作。選擇耗用量計劃慣用的樣式的離開調整擴大或縮小系統與您為消費者,付款盡可能或為您的應用程式取用。

最後一個步驟是實際建立函式本身。您現在要開始使用 C# 的 WebHook 預先製作好函式。這將會預先設定起訴根據接收 HTTP 要求的函式的觸發程序。選取左側功能表中整合的項目,並可選擇數個選項的設定觸發程序、 輸入和輸出。觸發程序選取] 頁面上有一些有用的資訊,包括如何使用 API 金鑰和一些範例程式碼呼叫從 C# 和 Node.js WebHook WebHook 繫結的相關資訊。一旦顯示對話方塊,您將設定的輸入和輸出繫結中所示**[圖 4**。

輸入繫結組態
[圖 4 輸入繫結組態

雖然您可以包含程式庫和介面卡,才能呼叫外部系統,系統是由繫結,並有許多資料來源,例如 EventHubs 和 DocumentDB 的第一級支援。屬於 Azure 函式的繫結基礎結構透過增強的開發經驗。繫結的抽象實際目標軟體基礎結構 (DocumentDB、 EventHubs、 儲存體等等) 可讓開發人員程式碼,以表示目標,同時仍然有彈性,因為目標可以藉由變更組態變更的參數。在這裡,您已設定它跟來源 DocumentDB。設定中您可以直接對 DocumentDB 用戶端在函式中撰寫程式碼,您不必自行進行連線。請注意文件參數名稱︰ inputDocument。這是傳遞至您將使用對 DocumentDB 進行呼叫的函式的變數。

以下的輸出選項可以看到,包含多項儲存體、 佇列和其他外部系統。所有項目,選取並透過 UI 設定可以透過函式應用程式設定 UI 的更新版本,並可設定的範本中或透過程式設計介面。您只透過 HTTP 傳回 JSON 結果給呼叫者。因為 HTTP(res) 已經設定輸出與輸出參數定義,您將會接受它。

開發程式碼

一旦開發選取左側功能表中,您會有線上的編輯器。這適用於快速反覆進行的變更,以及查看您的登入時間,並提供了您介面觸發 WebHook 函式。工具正在進行中的 Visual Studio 和 Visual Studio 程式碼可提供更豐富的體驗。如果您正在使用 Azure 函式現在,您想要使用 IDE,並透過 [伺服器總管] 中的函式應用程式輕鬆地連接 Visual Studio。

有若干事項您必須在編輯檔案。下面的程式碼視窗中,沒有檢視檔案的連結。開啟直接以程式碼視窗右邊的 [檔案總管]。首先,您必須 DocumentDB 用戶端。有數會自動提供使用 #r 指示詞上方所參考的程式庫。這些程式庫,以及其他的開發人員資訊的清單可以位於在線上的開發人員參考bit.ly/2gaWT9x。比方說,您將需要 DocumetDB 用戶端物件的存取權,因為沒有第一級支援 DocumentDB 有。您只需將該組件在檔案頂端新增 #r 指示詞。如果您需要的程式庫不包含在內,假設您維護並發佈至 NuGet,它會加入至 project.json 檔案 (package.json 在 Node.js 中)。

此時,您已準備好編輯 run.csx 檔案,將會用來保留所有程式碼。若要這樣做編輯直接在線上的 IDE 中 Azure 功能中所示**[圖 5**。

編輯函式程式碼
[圖 5 編輯函式程式碼

從範本程式碼,先將您自己自訂的外部程式庫加入函式,因為它包含 haversine 函式的程式碼。如果您有自訂的類別或函式不是太大,而且特定函式,您可以將它們直接加入 run.csx 檔案。不過,如果您有可重複使用片段,您可以到不同的路由和 \bin 資料夾中包含已編譯的版本或參考它們為 NuGet 封裝,透過 project.json 檔案並參考程式庫的 #r。或者,您可以將程式碼放到不同的.csx 檔案,並使用 #load 指示詞。

您需要幾個函數,可協助判斷您正在為其檢查相近的車輛和它們傳遞至函式的點之間的距離。已經過一段時間後 school 天,其實不定期需要 haversine 公式。Wikipedia 提供不錯的參考在bit.ly/2gCWrgb我們借用的 C# 函式和bit.ly/2gD26mK進行一些變更。我們已經建立必要的功能為 haversine 類別的靜態成員︰

namespace SphericalDistanceLib
{
  public class Haversine
  {
    public static double CalculateDistance(
      double currentLong, double currentLat,
      double vehicleLong, double vehicleLat){…}
    public static double ToRadians(double degrees){...}
  }
}

編譯程式碼,並再上傳到函式的根資料夾的相對路徑的 bin 資料夾。在我們的案例中,路徑會是 FindNearVehicle/bin,但是必須建立 bin 資料夾,因為它不是有預設。完成安裝的該位元,您可以開啟您焦點移到您所需要的程式碼。您必須確定您所參考的任何程式庫函式的頂端,您需要。特別是,您需要 DocumentDB 用戶端物件型別、 Newtonsoft 和自訂的程式庫已上傳至 /bin 資料夾。這些加入 using #r 指示詞檔案的頂端︰

#r "Microsoft.Azure.Documents.Client"
#r "Newtonsoft.Json"
#r "SphericalDistanceLib.dll"

如先前所述,您就會把根據 created_at 時間戳記欄位最後 100 筆記錄。DocumentDB 有不錯的 SQL 語法,使該項很簡單︰

IQueryable<Document> telemDocs = inputDocument.CreateDocumentQuery<Document>(
  UriFactory.CreateDocumentCollectionUri(dbName, collectionName),
  new SqlQuerySpec("SELECT TOP 100 c.vehicle.vin, c.vehicle.model,
  c.location FROM c ORDER BY c.created_at DESC"), queryOptions);

使用文件類型,可簡化事情一點,因為您會將它轉換成動態型別,輕鬆地將內容新增至物件。SQL 會傳遞 SqlQuerySpec 的形式,並將您的物件專案只 vin、 模型和位置。此時您必須逐一查看文件的清單、 計算外部文件庫中使用 haversine 函式之距離和決定最接近並將它傳回。不過,它會取得一個難題。

您需要追蹤的所有 vins 您所見,因為您只想針對該 vin 最新的位置記錄。因為您將已排序它以遞減順序排序,則第一個文件是上次收到的文件。您將檢查 vin 為 null,因為您正在查看會被驅動的車輛,而且如果 vin 中有 null 值,您可以假設文件無效。在項目具有非 null 值,只會嘗試將 vin 加入至雜湊集。如果它是唯一清單,加入將會成功,但如果沒有,它將會失敗,而且您知道該工具的最新記錄中已有清單中所示**[圖 6**。

[圖 6 最後一個已知的位置給不同 Vins

HashSet<string> seen = new HashSet<string>();
foreach(dynamic doc in telemDocs){
  if(seen.Add(doc.vin)){
    // Calculate the distance
    if (doc.location != null) {
      doc.distance =
        Haversine.CalculateDistance(double.Parse(currentLong),
        double.Parse(currentLat), double.Parse(
        doc.location.lon.ToString()),
        double.Parse(doc.location.lat.ToString()));
      lastKnownLocations.Add(doc);
    }
    else{
      // Location is null, so we won't take this
      // record as last known location
      seen.Remove(doc.vin);
    }
  }
}

您將整份文件加入 lastKnownLocations] 清單中,方便您來查詢出取決於最小距離值所排序的第一個文件︰

var nearestVehicle = lastKnownLocations.OrderBy(x => ((dynamic)x).distance).First();
return currentLat == null || currentLong == null
  ? req.CreateResponse(HttpStatusCode.BadRequest,
  "Please pass a lat and lon on the query string or in the request body")
  : req.CreateResponse(HttpStatusCode.OK, nearestVehicle);

可以傳回排序清單中的第一個文件,其中也處理 null 的參數檢查,而序列化的文件會為您處理的最後一行所示。

執行範例

若要查看作業是這樣的最後一個步驟。右上角的開發檢視沒有包含附加至該測試標記為 flask 圖示的連結。按一下此選項會開啟測試的 UI 中, 所示**[圖 7**。其中可以變更的 HTTP 方法、 將參數加入、 新增標頭和設定要傳遞至所選的 HTTP 方法的主體。我們通常使用 Postman 當我們要到很多,這項工作,因為我們已經測試的程式庫。不過,對於 HTTP 函式的內建測試設備是絕佳和立即可供快速反覆性的工作。

測試函式
[圖 7 測試函式

我們已抓取的緯度和經度,並格式化成預期的 JSON 格式,在 [執行] 視窗中。一旦按下執行時,出現在 [輸出] 視窗右下角的狀態與輸出記錄檔] 視窗中可以看到任何輸出記錄物件的呼叫及一般記錄檔輸出。記錄檔輸出看起來花費大約 250 毫秒,以取得我們要執行的函式,並記下的時間。這是我們想使用 Azure 函式的執行模型內︰ singlepurpose 和相當短執行時間。提取出 [輸出] 視窗的內容,並將其格式化,我們可以更加清楚看到我們有一種載具、 已記錄的位置時的時間戳記、 位置和距離︰

{
  "vin": "wmwrxxxxxxxx54251",
  "model": "Cooper Hardtop",
  "location": {
    "lat": 30.4xxxxxx,
    "lon": -97.8xxxxxx,
    "accuracy_m": 22.505,
    "ts": 1473116792970
  },
  "distance": 13.552438042837085
}

當我們完成距離計算我們指定地球的圓周以公里為單位,因此傳回的資料中表示的距離約 13.6 公里。

總結

在此範例中,我們使用了不同的線上工具來開發和起訴 Azure 函式,但開發團隊有更實際的方法是在本機開發,並設定連續整合和部署透過 Git 儲存機制。使用 WebJobs.Script 和 WebJobs SDK,您可以設定開發和在本機執行 Azure 函式的能力。好的作法的逐步解說,請參閱bit.ly/2hhUCt2。您也可以找到有幾個不同的來源可設定為部署的來源。

Azure 的函式是在 Azure 平台中區塊上新的孩子。這是計算的無伺服器所需達到的定域機組 PaaS 實作優點的重要組成成分。Azure 函式將焦點移到程式碼,並從管理基礎結構的值。平台工具支援和語言支援繼續發展,但已經支援多種語言,而且可以將繫結至 CI/CD 管線。詳細資訊,請參閱bit.ly/2h7lo4C。如果您未使用 Azure 函式,您應該試試看。您可以開始在bit.ly/2glBJnC

移轉到無伺服器的計算

無伺服器計算代表在我們如何思考雲端運算和建置的雲端應用程式基本架構的轉變。無伺服器運算開發人員提供完全抽象和無限擴充的環境來執行其程式碼,並提供完全著重於執行程式碼的付款模型。

無伺服器運算可以探討發展的平台即服務 (PaaS) 的下一個步驟。它可藉 PaaS 承諾的抽象化的程式碼的應用程式基礎結構,並提供自動調整大小功能。主要的差異無伺服器為每個執行定價模型 (而不是支付裝載程式碼的時間),以及立即無限制的規模。無伺服器計算提供完全受管理的運算經驗 (零個系統管理工作),立即無限小數位數 (零個小數位數設定) 和對事件做出反應(即時處理)。這可讓開發人員開發應用程式,可擴充設計,而且最終會更有彈性的新類別。

建立無伺服器的應用程式的開發人員使用 Azure 函式,類似的無伺服器計算,但也使用數量不斷增加的完全受管理的 Azure 或協力廠商服務撰寫使用端對端無伺服器解決方案。開發人員現在可以輕鬆地設定及執行完整的設計和較少的成本,輕鬆調整的無伺服器架構。開發人員也不會遭受管理及監視基礎結構的負擔,它們可以專注於商務邏輯,並解決業務而不適用於執行其程式碼的基礎結構維護的相關問題。

非伺服器是此處變更我們談到建置應用程式的方式,這裡停留一段很長的時間。加入在交談bit.ly/2hhP41Obit.ly/2gcbPzr。提交功能要求給bit.ly/2hhY3jq以及發現我們的 Twitter: @Azure與 #AzureFunctions 雜湊標記。   — Yochay Kiriaty


Darren Brust是 microsoft 雲端方案架構設計人員,他花大部分時間協助企業客戶,因為它們會轉換至 Microsoft Azure。 在他的空閒時間,您可能找到他在他三個子系體育活動或奧斯丁到當地咖啡店耗用咖啡佈滿大量的其中一個。您可以連線到他dbrust@microsoft.com或 Twitter: @DarrenBrust

Joseph Fultz是 microsoft 雲端方案架構設計人員。 他負責開發適用於解決商業問題運用 Microsoft Azure 架構的 Microsoft 客戶。先前,Fultz 是負責開發和 GM 的汽車共用程式架構 (mavendrive.com)。在 Twitter 上與他聯絡:: @JosephRFultz或透過電子郵件地jofultz@microsoft.com

感謝下列 Microsoft 技術專家人員檢閱這份文件︰ Fabio Calvacante