• 發行項

2017 年 8 月

第 32 卷，第 8 期

本文章是由機器翻譯。

Azure - 使用無伺服器架構進行批次處理

由約瑟夫 Fultz |2017 年 8 月

Azure 企業版的客戶，管理其雲端使用量的主要挑戰是控制它們的支出，以及收取這些成本分配到取用者的能力。幸運的是，有許多廠商提供工具，例如 Cloud Cruiser、 Cloudyn 和 Cloudability，以協助收集使用量資料，並產生一組豐富的報表。此外，您可以在這裡找到如何以程式設計的方式，例如，從先前 Ed Mondek，他可以在其中示範如何資料提取到 Excel，並檢視我的同事 post 提取資料的多個很好的例子 (bit.ly/2rzDOPI)。不過，如果您想要定期提取該資料，並且讓歷程記錄、 存在趨勢和預測的檢視，您需要儲存更多的資料。用於大型企業與數千個每個訂閱的資源，該數量的資料會令人怯和當然不是您會想要擷取並將保留在本機電腦上。

幸運的是，還有另一個方法。本文章中我們即將逐步引導您完成無伺服器擷取-轉換-載入 (ETL) 處理程序來擷取這類資料、 提供一些擴充並儲存資料的位置，其中進一步設定的工作 (分析，將 map-reduce 等等) 即可。我將觸控整體設計、 索引鍵的決策點，以及在採用無伺服器的方法，要考慮的重要事項。

判斷耗用量

第一個決策 Enterprise 合約 (EA) 計費 API 和 Azure 計費 API，其中心周圍特定訂用帳戶其要求之間做選擇。我原型 EA 中的多個註冊與企業客戶為目標。我正在使用的案例中，訂用帳戶會在使用一部分管理界限這兩個特定產品群組，並分隔實際執行的非生產資源。這可能導致相當大量的訂閱，因為工作建立為新的群組與新的產品線開始在 Azure 中的變動性的概念證明 (PoC) 類型的變動。因此，我選擇使用 EA API，因為它降低工作的範圍，不需要重新建立訂閱的探索機制。這會保留我沒有訂用帳戶建立於企業的註冊項目之外的任何資料的標註挑戰。雖然這是一個重要的區域，以便處理時，它會隨附一些組織解決需要其他處理程序和管理挑戰的我想要完成之工作的範圍外。

需求和邏輯流程

在任何架構中，它是系統需要設計中大部分的監督與測試之間的交集。無伺服器的架構不會變更需要考慮通過 supersystem，且必須納入考量的離散子系統特定的條件約束的資料磁碟區。這類 supersystem 架構而實際的主要變更時更深度或範圍中定義的系統，例如調整佇列的輸送量，但無法調整硬體大小裝載它。您仍然必須考慮延遲、 連線、 磁碟區、 可用性、 成本和任何數目的其他因素而定，但是調整大小，以及定義服務端點的軟體，一旦您定義了容量以及符合識別的需求所需要功能的成本。沒有定義主機環境和所有必要的成品，因為您可能在過去執行的任何其他工作。

取得設計的資訊儲存至系統的整體流程看起來像之前，我們請注意幾項事實來源系統的相關和結束狀態系統的一些需求：

  • 所有 EA 下每個訂用帳戶資料將位於指定之月的每一天傳回的所有資源。這會導致大量的資料，與在月份進行線性成長。
  • 所有的記錄可能會更新整個月。指定的結算計時是 72 小時。為安全的點，將指定的月份，後續的月份開頭過去 72 小時才考慮變動中的所有記錄。
  • 使用量資料不被傳回註冊識別碼，所以我必須先將它加入。
  • 決定成本是不同的活動，而且需要擷取速率卡和進一步處理。
  • 將不接收訂用帳戶不在指定的 EA 中的任何資訊。

此外，有幾個原型必須包含的技術的商務需求：

  • 建立唯讀能力和地理位置分散的資料集必須包含。
  • 處理效能應該是可調整的成本與效能。
  • 應設計能夠安全在訂用帳戶層級的存取。

本身的整體流程就相當簡單，也就是說，我只要擷取資料、 新增少量資訊並將它保存在目標儲存體。

如中所示圖 1，取得資料到其目標的路徑是相當簡單，因為沒有與 EA 計費 API 以外的任何外部系統沒有整合。我知道我工作時的資料，我稍後必須先執行一些初始處理和豐富性 （例如，新增的註冊識別碼），以及我必須處理來自前一天提取的現有記錄的持續性一邊。我可能會想要查看分隔的兩個處理序。


圖 1 邏輯流程

因此，您會看到三個主要區塊代表擷取、 擴充和持續性，以分隔藉由某種佇列機制。在我進行一些技術來挑選並開始了解與這些元件實作，並進行平行執行的處理管線的詳細資料之後，就會開始的複雜性。

技術對應

此時在過程中，整體系統的需求超過兩個因素可能會遇到： 企業標準和個人的喜好設定。如果這些衝突，此結果會幾乎無限的爭論。幸運的是，這個執行個體中，我不需要擔心這。我沒有自己的條件約束，以及從最初的需求所述的混合。在此情況下，我想要確定叫用這些標記：

  • 最簡單的計算佈建和編輯/更新快速的測試週期
  • 簡單的自動調整
  • 輕鬆佈建地理分佈的資料
  • 簡單的機制來排程及觸發工作

在這裡，我想要的工作，而不是在系統安裝程式的焦點。我將會讓一切功能已開啟的工作原型之後, 要各種實作及遵循之前的公司標準成本分析。未考慮某些替代作法，例如 Azure SQL Database 與 Azure Cosmos DB，但我把重點放在我選擇及這些選擇的每個主要的因素。

  • 運算：Azure 的函式將會處理我見面。它符合我需要的小數位數和簡單性同時也提供簡單的設定排程和觸發作業和輕鬆整合的繫結。
  • 佇列：保持簡單的事情，我要使用 Azure 儲存體 Blob，並由容器的檔案。每個初始輸入檔案的未知但 gold 大型大小儲存體佇列了非選項供初始擷取，並可能將他們帶出處理個別訂用帳戶資料分割的執行。此外，我想要保留統一的機制，實際上不需要任何進階的功能，例如優先權的訊息、 路由、 特定的訊息安全性和有害的訊息處理。
  • 儲存：Azure Cosmos DB 的確是我的朋友。做為資料分割索引鍵使用訂用帳戶 ID，可讓我的訂閱，以限制存取如有必要。此外，輕鬆新增和移除讀取和讀寫地理位置分散的複本與原生支援在 Power BI 可讓這可想而知我的系統。最後，我不得不承認有點個人偏差：我想要支援已放棄使用太多年的 SQL 語法正確的文件儲存機制。

圖 2代表技術的應用程式的邏輯架構，以及加入一些處理流程。


圖 2 技術對應和資料流程

我已經採取 liberty 我所使用的名稱，其中包括在此圖中，但您沒有在此階段設計的名稱。使用的圖形表示以播放; 中的技術在列上的數字序列的處理程序執行所在，而且箭號表示哪些元件會起始傳出呼叫。請注意，我已經識別四個 Azure 函式、 四個 Azure 儲存體 Blob 容器和三個 Azure Cosmos DB 集合我為我的實作中的工作項目會採用。

將資料分成三個集合的說明，但是 grander 的用途。我將不會針對每個類型的文件需要相同的安全性和隔離很容易，了解並管理。更重要的是，我的效能特性，並以定義集合的分隔可讓我，來更輕鬆地最佳化，專為 DetailedUsageData 具有大型的高輸送量集合，但與其他兩個仍保持最小。

擷取資料

我想要執行類似做些什麼 Cron 作業從資料歷程的前兩個邊開始。雖然 WebJobs SDK 本身會支援這種類型的實作，它會使大量設定 eAzure 函式之上 WebJobs SDK 和自然支援計時器觸發程序的執行階段的工作，很容易的選擇。我無法使用 Azure Data Factory，因為它是特別針對四處移動資料所做的工具，它還支援擷取 Web 資料與使用 Blob。不過，這就表示我需要找出特定事件的參考資料和更新 Azure Cosmos DB 中重複的記錄，當沒有資料列識別碼。熟悉開發和偵錯使用 Azure 函式和我可以獲得與 Application Insights 的 Azure 功能整合的資訊讓 Azure 函式我首選中的這個執行個體。

計時器觸發程序的明顯函式，但為了讓 DailyEABatchControl 知道要處理的項目，它會擷取組態資訊從註冊項目集合，其具有下列結構描述：

{
  "enrollmentNumber": "<enrollment number>",
  "description": "",
  "accessKey": "<access key>",
  "detailedEnabled": "true",
  "summaryEnabled": "false",
}

現在，讓註冊號碼、 存取金鑰和處理 (「 detailedEnabled 」) 開啟的旗標已足夠讓我要執行的作業。不過，我應該開始將功能加入且需要其他的回合的組態資訊，Azure Cosmos DB 可讓我輕鬆地將項目加入文件結構描述而不需要進行修改和資料移轉的一大堆。一旦觸發 DailyEABatchControl 時，則會重複使用所有的文件，並呼叫 RetrieveUsage 具有"detailedEnabled 「 每個註冊設為 true，區隔邏輯，以擷取來源資料的邏輯開始工作。我使用 JobLog 集合，以便判斷作業是否已執行一天，如下所示圖 3。

圖 3 的工作控制邏輯

// Get list of enrollments for daily processing
List<Enrollment> enrollments = 
  inputDocument.CreateDocumentQuery<Enrollment>(
  UriFactory.CreateDocumentCollectionUri(dbName, enrollmentCollection), 
  new SqlQuerySpec("SELECT * FROM c WHERE c.detailedEnabled = 'true'"),
  queryOptions).ToList<Enrollment>();

// Get yesterday's date to make sure there are logs for today
int comparisonEpoch = 
  (int)(DateTime.UtcNow.AddDays(-1) - new DateTime(1970, 1, 1)).TotalSeconds;

string logQuery = 
  "SELECT * FROM c WHERE c.epoch > '" + comparisonEpoch.ToString() + "'";

List<JobLog> logs = inputDocument.CreateDocumentQuery<JobLog>(
  UriFactory.CreateDocumentCollectionUri(dbName, jobLogCollection), 
  new SqlQuerySpec(logQuery), queryOptions).ToList<JobLog>();

// Get list of enrollments for which there is no match
var jobList = enrollments.Where(x =>
  !logs.Any (l => l.enrollmentNumber == x.enrollmentNumber));

最後一個 lambda 會導致篩選的資料尚未被擷取其一天有問題的註冊項目清單。接下來，我稱 RetrieveUsage (步驟 3 中圖 2) 從了解的註冊，它會擷取資料和月份，它會擷取它，如中所示呼叫它具有為它的 post 本文中的足夠資料 HTTPClient DailyEABatchControl 內圖 4。

圖 4 擷取使用量資料

foreach(var doc in jobList)
{
  HttpClient httpClient = new HttpClient();

  string retrieveUsageUri = @"https://" + 
    System.Environment.GetEnvironmentVariable("retrieveUsageUri");

  string postBody = "{\"enrollment\":\"" + doc.enrollmentNumber + "\"," +
    "\"month\":\"" + DateTime.Now.ToString("yyyy-MM") + "\"}";

  httpClient.DefaultRequestHeaders.Accept.Add(
    new MediaTypeWithQualityHeaderValue("application/json"));

  var content = new StringContent(postBody, Encoding.UTF8, "application/json");
  var response = await httpClient.PostAsync(theUri, content);    

  response.EnsureSuccessStatusCode();
 
  string fetchResult = await response.Content.ReadAsStringAsync();
}

它是值得這不是要開啟的系統。我不想執行 RetrieveUsage 函式的任何呼叫端，建立已關閉的處理迴圈。因此，我已經受到它需要不會顯示在程式碼圖 4，但從 GetEnvironmentVariable("retrieveUsageUri") URI 的一部分傳回。在企業中實作、 服務主體和 Azure Active Directory 整合會比較實際的選擇，以達到較高的安全性。

我的資料歷程的第一個階段的最後一個步驟是它已保存到 Azure Blob 儲存體的 newdailyusage 容器 RetrieveUsage 函式內。不過，為了取得該資料我必須先建構呼叫，並將 accessKey 納入作為標頭中的承載權杖：

HttpClient httpClient = new HttpClient();

string retrieveUsageUri = usageQB.FullEAReportUrl();

httpClient.DefaultRequestHeaders.Add("authorization", bearerTokenHeader);
httpClient.DefaultRequestHeaders.Add("api-version", "1.0");

var response = await httpClient.GetAsync(retrieveUsageUri);    

response.EnsureSuccessStatusCode();

string responseText = await response.Content.ReadAsStringAsync();

為了簡短起見，我已剪下超出這個程式碼區塊的某些日期操作，並沒有包含產生 bearerTokenHeader 或 UsageReportQueryBuilder 的 helper 類別。不過，這應該足以說明其正在使用和已排序的方式。AccessKey 會傳入 FromJwt，將傳回 BearerToken 型別的從中我只抓取標頭，並將它加入至建立從 usageQB.FullEAReportUrl 的呼叫所建構之 URL 要求的靜態方法。最後，更新輸出繫結至的路徑和檔名，我想 Blob 目標：

path = "newdailyusage/" + workingDate.ToString("yyyyMMdd") 
  + "-" +  data.enrollment + "-usage.json";
var attributes = new Attribute[]
{
  new BlobAttribute(path),
  new StorageAccountAttribute("eabillingstorage_STORAGE")
};

using (var writer = await binder.BindAsync<TextWriter>(attributes))
{
  writer.Write(responseText);
}

這會導致看起來像這樣的 Azure 儲存體中的結構：

newdailyusage/
        20170508-1234-usage.json
        20170508-456-usage.json
        20170507-123-usage.json

這可讓我儲存資料，多個註冊項目和每個註冊的多個檔案以防處理也不會發生基於某些原因。此外，因為資料可以隨著月份進展過去幾天的變更，所以一定要有進行研究和重新調整可用的檔案，以防異常顯示在 [報表資料。

將資料分割平行處理

很多，所以資料與傳入以某種方式處理每一天的指定月份更新記錄的工作，請務必處理此資料，以平行方式。通常，至少 screen 鍵，這是當我細分的平行程式庫的 C#、 撰寫幾行程式碼，並鼓勵自己的平行處理在天才背面時。不過，在本例中，我真的想只依賴嗎，並允許我的平台功能，將焦點放在每個離散的工作。

序列中下一個 Azure 函式已使用的 blob 觸發程序，它會挑選登陸輸入的處理儲存體容器中的檔案。在這個步驟中工作是將傳入的檔案分割成檔案每天每個註冊。總而言之，這是非常簡單的步驟，但它需要還原序列化成 RAM 的 JSON 檔案。務必注意，因為我選擇要用於原型方法只會呼叫還原序列化方法：

JsonConvert.DeserializeObject<List<EAUsageDetail>>(myBlob);

我知道這項資訊足以讓我的需求，但 Azure 函式主控件存在 RAM 的配置 1.5 GB。有可能，針對大型註冊與佈建的大量資源]，檔案會成為在某個時間點太大當月載入所在案例進行剖析和分割檔案的替代方法將會擁有要使用的 RAM。此外，如果您建立使用超過五分鐘執行 Azure 函式，它將需要修改，因為目前的預設值是 5 分鐘，不過這可以調整，以便透過主機設定 JSON 的 10 分鐘的最大值。如早所述，知道的資料量會在每個點，以及的整合的索引鍵整體系統中。一旦已還原序列化資料，我要抓取不使用的最大日期，並設定從一開始選取每個這些發行日，資料中所示的最大日期值到迴圈圖 5。

圖 5 中選取每一天的資料

// Loop through collection filtering by day
for(int dayToProcess = 1; dayToProcess <= maxDayOfMonth; dayToProcess++)    
{
  // Get documents for current processing day
  var docsForCurrentDay = results.Where (d => d.Day==dayToProcess);

  // Serialize to string
  string jsonForCurrentDay = 
    JsonConvert.SerializeObject(docsForCurrentDay);
  log.Info($"***** Docs for day {dayToProcess} *****");

  // Get date for one of the records for today
  string processDateString = (from docs in results where docs.Day == 
    dayToProcess select docs.Date).First();

  path = "newdailysplit/" + DateTime.Parse(processDateString).ToString("yyyyMMdd") 
    + "-" +  enrollment + "-dailysplit.json";

  // Write out each day's data to file in container "\newdailysplit"
  var attributes = new Attribute[]
  {
    new BlobAttribute(path),
    new StorageAccountAttribute("eabillingstorage_STORAGE")
  };

  using (var writer = await binder.BindAsync<TextWriter>(attributes))
  {
    writer.Write(jsonForCurrentDay);
  }
}

一旦已分割成個別的檔案並寫出所有天數 (請參閱中的步驟 7圖 2)，只需將檔案移至 processedusage 容器。若要讓圖表圖 2簡單剖析，我已省略某些容器 — 尤其是，錯誤的檔案容器中遺漏圖表。這是容器，其中含有會在處理期間，發生例外狀況的任何檔案，該檔案是否為所有使用檔案或其中一個每日的分割。我不花時間或努力修正遺失或錯誤天的資料，因為為給定的月份、 註冊或每日的單一分割，以更正問題，一旦發現問題，可以觸發程序。也清楚地遺失與原型警示和補償的機制，當發生錯誤，但這是我想要透過將與 Operations Management Suite 的 Application Insights 整合反昇。

將資料保存到 Azure Cosmos DB

檔案分割和已備妥可挑選 ProcessDailyUsage 函式，就可以考慮一些問題需要處理，也就是目標，以及如何處理更新的輸送量。通常工作時透過在企業中的某些解決方案架構，您會遇到能力，或其中即時載入和高輸送量狀況需要管理較舊的系統。在這種架構，我雲端原生安裝程式自然沒有任何硬碟的輸送量條件約束，但我可以為自己建立問題，如果我不需要仔細的磁碟區和速度我送入我正在耗用的雲端服務的資料的時間。

我的資料集，每個每日分割大約 2.4 mb，並且包含關於 1200 個別文件。請記住，每份文件表示一個的計量器讀取一個在 Azure 中佈建的資源。因此，針對每個 EA 文件中的每日的分割數目可能有所不同大幅資源使用狀況整個企業。ProcessDailyUsage 函式會設定為觸發程序根據接收的新 blob newdailysplit 容器中。這表示必須為 31 操作資料的並行函式執行。為了協助我估計我需要佈建 Azure Cosmos db，我會在 documentdb.com/capacityplanner 使用計算機。某些測試經驗我必須進行一些猜測初始的佈建。我知道會有 31 同時執行，但卻有點難關閉多少的並行要求，而不會進行重複執行以建立每秒鎖定重點。此原型的最終結果是為了通知的最終的架構和需求佈建，但我在轉寄處理這個時間軸，因為我們即將使用下列規則當做預估它在拍攝平安定面：

  • 1200 記錄
  • （適用於單一的 EA) 31 並行執行
  • 每個要求 （來自測量一些個別要求的經驗法則） 0.124 秒

我將會捨入到 0.1 秒時較為保守的評估，因此高估負載。此通道 310 EA，依次出來成為在根據中可以看到 [小算盤] 結果中，約 7,800 要求單位 (Ru) 每秒要求圖 6。


圖 6 Azure Cosmos DB 定價計算機

因為最大可以佈建，而不需要呼叫支援 RUs 10000，這看起來似乎有點高。不過，我執行 unthrottled 的平行處理的磁碟機及總輸送量顯著，其中接著也會提高成本。設計結構，因為它是適合我執行某些測試，但真實世界的解決方案需要節流機制會降低處理，讓我可以佈建較少的俄文並節省自行極小的成本時，這是主要的考量。我不需要以盡量擷取的資料，別人無法夠合理的時間內只檢閱，並取用每日。好消息是 Azure 函式團隊可以並行存取控制機制，在待辦項目最後會解決的問題 (bit.ly/2tcpAbI)，也會提供一次實作的控制的好方法。某些其他選項還有引進人為任意的延遲 （我們所有同意這是不正確） 或重做處理及處理在 C# 程式碼中明確平行執行。此外，如技術專家 Fabio Cavalcante 交談，另一個很好的選項會新增 Azure 儲存體佇列，並使用功能，例如可見性逾時和排程的傳遞做為節流機制稍微修改架構。將會新增一些移動到系統的組件，而且我會算出的互動，同時在儲存區中的資料啟用使用佇列或佇列的 64 KB 區塊中的資料配量。一旦節流可以使用 Azure 功能中，我可以將它放在我正在使用此簡單表單。主要的重點是，使用無伺服器的架構時您必須先熟悉所在您正在建置，以及每個決策的成本的平台的條件約束。

佈建時超過 2,500 RUs，系統會要求，指定資料分割索引鍵。這適用於我，因為我想要在任何情況下將該資料分割以在未來協助規模和安全性。

您可以看到在圖 7我指定 8000 RUs，這是比如有需要，計算，我已經指定訂用帳戶 Id 為資料分割索引鍵。


圖 7 佈建一個新的集合

此外，設定 ProcessDailyUsage newdailysplit 容器的 blob 觸發程序與輸入和輸出繫結 Azure Cosmos DB。若要尋找有特定一天和註冊的記錄，來處理重複的項目，則會使用輸入的繫結。我可以確保我 FeedOptions 設定跨資料分割查詢旗標，如中所示圖 8。

圖 8 使用 FeedOptions 設定跨資料分割查詢旗標

string docsToDeleteQuery = String.Format(@"SELECT * FROM c where c.Enrollment = 
  ""{0}"" AND c.Date = ""{1}""", enrollment, incomingDataDate); 

FeedOptions queryOptions = new FeedOptions { MaxItemCount = -1, 
  EnableCrossPartitionQuery = true };

IQueryable<Document> deleteQuery = docDBClient.CreateDocumentQuery<Document>(
  UriFactory.CreateDocumentCollectionUri(dbName, collectionName), 
  new SqlQuerySpec(docsToDeleteQuery), queryOptions);

log.Info("Delete documents");
int deletedDocumentCount = 0;
foreach (Document doc in deleteQuery)
{ 
  await docDBClient.DeleteDocumentAsync(((dynamic)doc)._self,  
    new RequestOptions { PartitionKey = 
    new PartitionKey(((dynamic)doc).SubscriptionId) });
  deletedDocumentCount++;
}

我建立的查詢上抓取註冊的所有記錄的日期，然後迴圈，並加以刪除。這是一個執行個體，其中 SQL Azure 可能已經項目可以更方便進行發出刪除查詢或藉由使用已知的主索引鍵中的 upsert。不過，在 Azure Cosmos DB 中，若要執行 upsert 我需要資料列識別碼，這表示我必須進行往返並進行比較，我知道要唯一識別文件，然後使用該資料列識別碼或 selflink 欄位上。針對此範例中，我只需刪除所有記錄，並將新 — 和潛在更新 — 備份中的文件。若要這樣做，我需要在資料分割索引鍵中傳遞至 DeleteDocumentAsync 方法。最佳化是撤回文件和進行本機的比較，請更新任何已變更的文件並新增網路的新文件。這是極小的消耗，因為所有每份文件中的項目必須進行比較。因為沒有定義計費的文件沒有主索引鍵，可能可以尋找使用訂用帳戶 Id、 MeterId、 InstanceId 和日期比對文件，並比較項目從該處的其餘部分。這會卸載部分從 Azure Cosmos DB 工作，並減少整體的流量。

清除為文件將重新加入至集合的方式，我只需執行迴圈文件，呼叫上 documentCollector AddAsync 我定義為 Azure 函式的輸出繫結：

// Update the enrollment field in the incomming collection
incomingDailyUsage.ForEach (usage => usage.Enrollment = enrollment); 

int processedRecordCount=0;
foreach (EnrollmentUsageDetail usageDoc in incomingDailyUsage)
{

  await documentCollector.AddAsync(usageDoc);
  processedRecordCount++;
}

雖然大部分的變更，我也已完成一些擴充方法是加入集合中每份文件中的註冊編號。執行其中一個每日分割檔案都會產生中顯示的記錄資訊圖 9。

圖 9 每日的記錄資訊的檔案分割。

2017-06-10T01:16:55.291 Function started (Id=bfb220aa-97ab-4d36-9c1e-602763b93ff0)
2017-06-10T01:16:56.041 First 15 chars: [{"AccountOwner
2017-06-10T01:16:56.181 get date
2017-06-10T01:16:56.181 getting enrollment
2017-06-10T01:16:56.181 Incoming date: 11/01/2016 for Enrollment: 4944727
2017-06-10T01:16:56.181 Collection: partitionedusage
2017-06-10T01:16:56.181 query:  SELECT * FROM c where c.Enrollment = "4944727" AND c.Date = "11/01/2016"
2017-06-10T01:16:56.181 Create delete query
2017-06-10T01:16:56.197 Delete documents
2017-06-10T01:17:23.189 2142 docs deleted while processing 20161101-4944727-dailysplit.json
2017-06-10T01:17:23.189 Import documents
2017-06-10T01:17:44.628 2142 records imported from file 20161101-4944727-dailysplit.json
2017-06-10T01:17:44.628 Moving file 20161101-4944727-dailysplit.json to /processedusage container
2017-06-10T01:17:44.674 Deleting 20161101-4944727-dailysplit.json
2017-06-10T01:17:44.690 Completed!
2017-06-10T01:17:44.690 Function completed (Success, Id=bfb220aa-97ab-4d36-9c1e-602763b93ff0, Duration=49397ms)

最後一個注意事項

只事剩下做為使用不同的輸入執行更佳多反覆項目，然後測量 [讓我可以適當的大小我正在使用的服務。這包括測試的地理複寫功能及一些進一步的原型，我想要訂用帳戶資料的存取; 周圍實作的安全性這些是兩個選擇 Azure Cosmos DB 的主要原因。Net 課程，能證明是一些似乎保留了解的世界中的項目 IT:

  1. 沒有識別常數項目符號，甚至不能與無伺服器的架構。
  2. 不會取代徹底測試。
  3. 大小相依的服務，並將此項嚴重一樣時調整硬體大小在過去。
  4. 請密切注意成本，特別是在高輸送量的情況下。

使用無伺服器和 Azure 函式一樣運算的優點是您只針對功能一經付費。進行這類規則但次數不頻繁處理，可以節省成本的一大優點。最後，設定功能就是更好的體驗，可讓產品更快的時間比設定主機伺服器。

約瑟夫 Fultz是在 Microsoft 雲端方案架構設計人員。他會搭配 Microsoft 客戶開發解決商務問題運用 Microsoft Azure 的架構。先前，Fultz 所負責的開發和 GM 的汽車共用程式 (mavendrive.com) 架構。在 Twitter 上連絡他： @JosephRFultz或透過電子郵件在jofultz@microsoft.com。

非常感謝下列 Microsoft 技術專家檢閱這篇文章：Fabio Calvacante

MSDN Magazine 論壇中的這篇文章的討論