共用方式為

2018 年 9 月

第 33 卷 9

本文章是由機器翻譯。

微服務-成微服務架構設計人員區塊鏈應用程式

藉由Stefano Tempesta |2018 年 9 月

微服務和區塊鏈智能合約有許多通用。兩者都預期它們在隔離 （鏈上） 中執行，並與外部通訊 （鏈結外） 透過以訊息為基礎的通道。它們應該很小的大小，執行自主且獨立地開發和執行得更好的集中式的網路上部署時。

此文章提供的設計原則、 成品和建置區塊鏈應用程式的程式碼範例使用微服務架構樣式，以及將其部署在 Microsoft Azure 區塊鏈平台上。

微服務完全具體表現的精神的 Unix 原理：做一件事，而且這麼好 (tcrn.ch/2vnq5Pb)。微服務是獨立、 可部署的元件，支援透過訊息式通訊的互通性的限定範圍。指定此內部部署，微服務架構，是工程的協助建立高度自動化，利於軟體系統的單一功能的微服務組成的樣式。

區塊鏈應用程式有與微服務，以及哪些設計原則可以套用微服務架構從集中式的世界做什麼？中的資料表**[圖 1**比較微服務與針對特定的設計屬性智能合約。

[圖 1 微服務和區塊鏈設計原則

設計原則 微服務 智慧合約
單一責任 通常會提供單一實體上的 CRUD 介面。 在單一物件，使用螃蟹方法 （稍後在本文中） 上定義角色、 狀態和驗證工作流程的相關邏輯。
繫結的內容 不會相依於其他服務中，擁有自己的資料模型的永續性儲存體。 其他智能合約不具有相依性，並利用鏈上資料模型 （也就是區塊鏈本身） 做為慣用的資料模型。
訊息已啟用 可利用 API 閘道服務間的通訊和適用於服務匯流排內部的服務通訊。 可以利用 「 先知"或"cryptlets 「 鏈結外資料存取，或像是 Azure Blockchain Workbench 公開 REST API 的工具。
自主開發 多種程式設計語言和架構。 有多個可供使用，雖然目前沒有跨平台通訊的區塊鏈平台。
獨立部署 使用適當的設計 （事件來源，CQRS） 可能會降低或完全移除相依性。 類似的設計模式可套用 （這篇文章中所述）。
分散式和非集中式 分散式的架構，而不是集中式 「 單體。 」 內建分散式和非數位分類帳集中式設計。

 

設計成微服務的區塊鏈應用程式，可為您的解決方案帶來下列優點：

  • 允許以平行方式執行的許多軟體工程計劃。
  • 減少軟體開發與測試團隊之間的相依性。
  • 支援多種技術、 語言和架構。
  • 將升級的可處置的程式碼透過創新的輕鬆。

微服務通常會向外界透過應用程式開發介面 (API) 共用通用的語言，例如 JSON 或 SOAP 用戶端--跨不同的技術 （.NET、 Java、 提供通用語言的傳訊功能的系統Node.js 等等） 與平台 （Windows、 Linux）。如您在本文稍後所見，這是也針對區塊鏈 Azure Blockchain Workbench，所公開的 API，則為 true。

從非集中式應用程式的微服務

如果您已熟悉的將您的伺服器不是隻寵物的牛等 DevOps 情感 (bit.ly/2vrdM4p)，您可能會將相同的方法套用至您的原始程式碼。輕鬆可處置的程式碼可以降低技術債務，將升級的工程程序現代化，減少作業成本，藉由最佳化基礎結構 （例如，在容器或完全無伺服器的組態）。

設計微服務架構原則的區塊鏈應用程式，也可以產生商業利益。軟體系統中的改善的效率可縮短基礎結構成本及容量相關的服務中斷的風險。這些層面都屬於特定的值以私用區塊鏈，成本效益及服務持續性是適用於企業的重要需求。

微服務架構主體可以支援使用可取代的元件，同時也可以減少技術債務，可能會導致過時且不可靠的環境。在 solidity，在以太坊，智能合約的程式語言會有一項機制，來指定每個合約執行所在的確切執行階段版本。經過一段時間，智慧合約的版本號碼可用來識別已過時的區塊鏈儲存的程式碼可能會被取代的候選項目。只要記住，在區塊鏈，智慧合約，已經處理 （亦即是 「 生產 」 區塊的一部分） 無法刪除，未來的交易必須發行新版本的合約。

另一個優點是更好的執行階段延展性，可讓軟體系統擴張或縮小的需求。實作微服務啟用更有彈性的方式授與權限將交易的工作負載分散的企業或協會私人環境中的區塊鏈和採礦節點智能合約。

在其最基本的層級，微服務架構會大致拆解成較小部分的系統的應用程式，以及如何受益於分散式安裝。同樣地，在智能合約上的區塊鏈執行受益於對等網路的分散式本質。使用微服務導向架構式設計、 提升的效率、 延展性與管理能力，可以提供智能合約 — 適當實作的企業中的區塊鏈解決方案不可或缺的所有屬性。

 

非集中式的網域導向設計

撰寫非集中式的區塊鏈數位交易記錄資料庫的應用程式，並使用分散式系統，例如儲存體隔離、 非同步傳訊和分散式的交易的一般基礎結構和軟體需求。區塊鏈應用程式也需要驗證的使用者和裝置，以及執行特定動作的智慧合約的授權。我展開常用的 Domain-Driven 設計 (DDD) 方法，是指考慮為 「 非集中式 Domain-Driven 設計 」 或 DDDD 的實體、 處理程序和屬性的區塊鏈系統的作法。

讓我們開始定義網域或內數位分類帳智能合約的執行內容。智能合約代表商務邏輯的區塊鏈應用程式，做為工作流程，與每個階段的訊息傳送者 （使用者或裝置執行的函式的合約） 和狀態 （合約的參數，表示所識別的工作流程為訊息傳送至函式，以及其內部狀態）。其他合作對象 (同樣地，使用者或裝置) 可能會受到執行智慧合約的函式。

在此情況下，我們將應用程式角色中所涉及的所有合作對象。建立合約的第一個應用程式角色稱為起始端。在合約的內部狀態的變更，可能表示這項變更智慧的合約、 其他組件或外部應用程式引發事件。這是典型的模式，比方說，填入鏈結外資料所使用的服務匯流排，處理智慧型的合約與發佈訊息相關的接聽程式所引發的事件。[圖 2識別涉及的工作流程中的智慧合約中的實體。

智慧合約中的工作流程項目
[圖 2 智慧合約中的工作流程項目

以太坊會使用在 Solidity 做為程式設計語言撰寫的智能合約的自我強制執行商務邏輯。在 Solidity 智能合約是類似於物件導向語言中的類別。每個合約包含了角色、 狀態和函式來實作動作項目、 階段和商務程序的動作。

中的程式碼片段**[圖 3**顯示不同類型的變數宣告中在 Solidity 角色、 狀態與可用於智慧合約賭的應用程式的屬性。角色 （gambler 和 bookmaker） 會定義為地址，也就是使用者或以太坊中的合約的唯一識別碼。狀態會是首選的可識別目前狀態，透過智慧合約放置標籤的列舉。您稍後所見，函式，定義狀態的變更。選擇量會以不帶正負號的數字 （目前在 Solidity 不支援十進位值）。

角色、 狀態和屬性賭智慧合約中的 [圖 3 宣告

pragma solidity ^0.4.20;
contract Betting
{
  // Roles
  address public Gambler;
  address public Bookmaker;
  // State
  enum BetType { Placed, Won, Lost }
  BetType public State;
  // Properties
  uint public BetAmount;

請注意版本針對此智慧合約的在 Solidity 的指示。它是個不錯的做法，表示這個 pragma 指示，以避免使用在 Solidity 程式設計語言和編譯器的未來版本不相容。這也有助於找出智慧的合約，可能需要換成新的版本，以支援更新的程式碼中的舊程式碼。從區塊鏈中移除現有的智慧合約的程序稱為 「 自動銷毀。 」

智慧合約應該具有單一責任，並包含以最少的商務邏輯，以最佳方式只驗證所需的邏輯才能認定合約有效與否。在我賭的應用程式，智慧合約可能會公開用於將一放 gambler，以和認可 win 或遺失 bookmaker 函式。可能的首選工作流程的兩個角色之間交換的貨幣。需要進行驗證的合約承諾交易的常見模式會看到量傳輸發生在兩個階段，如所示**[圖 4**。Gambler （啟動者的合約） 會一一段，然後儲存在智慧的合約。如果動作成功的選擇，則會將成交的數量，由 bookmaker，轉移到 gambler。否則，bookmaker cashes 首選數量。

身上賭一把工作流程
[圖 4 身上賭一把工作流程

中所示**[圖 5**，在 Solidity 這個智慧合約的實作需要幾個函式定義的工作流程，每個動作，如下所示：

  • 建構函式會將訊息傳送者儲存為 gambler;這是起始智慧合約的角色。
  • Bet 函式接受做為輸入的金額時，會執行一些驗證 （只能由 gambler 可以呼叫此函式和數量應大於零），然後將 bet 量傳送至合約。若要允許在鏈結貨幣傳輸，就必須為應付帳款函式的旗標。
  • 成交函式，驗證啟動程式不 gambler 之後, 會成交的數量轉送至 gambler，並關閉 bet"贏了。 」
  • 遺失函式，一次可以只叫用 bookmaker、 傳輸量一開始採用，現在要 bookmaker 遺失 gambler，並關閉 [選擇為 「 遺失 」。
  • 關閉的首選，移除 gambler （其位址設為 0x0） 和數量設為零，供另一個辦法。

[圖 5 賭智慧合約中的函式

constructor() public {
  Gambler = msg.sender;
}
function Bet(uint amount) public payable {
  require(msg.sender == Gambler, "Only a gambler can place a bet.");
  require(amount > 0, "Amount should be greater than zero.");
  BetAmount = amount;
  address(this).transfer(amount);
  State = BetType.Placed;
}
function Won(uint amount) public payable {
  require(msg.sender != Gambler, "Only the bookmaker can mark a bet as won.");
  require(amount > 0, "Amount should be greater than zero.");
  Gambler.transfer(amount);
  Close(BetType.Won);
}
function Lost() public payable {
  require(msg.sender != Gambler, "Only the bookmaker can mark a bet as won.");
  Bookmaker = msg.sender;
  Bookmaker.transfer(BetAmount);
  Close(BetType.Lost);
}
function Close(BetType state) internal {
  Gambler = 0x0;
  BetAmount = 0;
  State = state;
}

簡單的實作中，但這種情況下會識別管理金額支出，區塊鏈應用程式的典型模式。其他案例可能需要納入 attestable 的檔案，例如文件、 試算表、 憑證及圖片。原因很多的主要是有關儲存體限制，並不恰當的區塊鏈上放置檔案。常見的方法是執行對檔案的密碼編譯雜湊 (比方說，SHA-256) 和共用分散式總帳上的該雜湊。外部系統會改為將檔案保存到儲存機制，例如 Azure 儲存體或 IPF (ipfs.io)。

在任何未來的時間執行一次使用相同的雜湊演算法的雜湊會傳回相同的結果，除非修改保存的檔案，即使只有一個像素修改映像中。此程序會授與資訊物件，例如電子郵件、 檔案、 文件、 通話或影片的時間存在某一點的存在的證明。它也會授與的真實性證明 — 您知道的數位資產尚未變更，因為數位分類帳儲存不可變且獨立的可驗證的所有交易的記錄。如需詳細資訊的企業內容管理的區塊鏈的值，讀取我在發表的文章bit.ly/2OC2Ycp。

事件溯源和 CQRS

上一節所述，我建議使用有一項功能負責建置智能合約。功能導向的設計是隔離的智能合約的關鍵技巧，雖然它不足以確保獨立的可部署性。智能合約可能會對系統中，儘管隔離，在執行中的網域內的常見資料模型。例如，應用程式中可能有管理盤賭注，另一個用於管理體育活動要採用的智慧型合約。身上賭一把智慧合約可能會參考體育賽事，建立兩個 （身上賭一把不會發生，如果事件不存在） 的智慧合約之間的相依性。有辦法模型資料有助於避免智能合約之間共用的資料嗎？

任何格式和儲存體 (SQL、 NoSQL JSON) 我們使用，我們通常模型根據物件及建立、 讀取、 更新、 刪除 (CRUD) 作業的資料庫。而不是儲存結構，該模型的狀態的網域中，我們可以儲存通往我們的世界的目前狀態的事件。此模型化方法會呼叫事件來源 (bit.ly/2O68nrt)。

事件來源是儲存事實。事實是在事件發生的表示值。如同生活中，我們就無法回到過去並將變更過去，我們可以只進行 present，以補償先前動作中。資料是不變;因此我們一律發出新的命令或補償，而不是更新的實體狀態的事件。這種方法運作的螃蟹縮略字，建立、 擷取、 附加及 Burn (bit.ly/2MbpUOb)，這正是允許執行的區塊鏈： 任何資料更新或刪除，它僅會附加至鏈結。從區塊鏈刪除的項目衝突，其不變性，但您可以停止資產傳輸，只要 「 燒錄 」 的收件者地址。

這種方法立即顧慮是效能。如果狀態的任何值的函式的事件，您可能會假設每個值的存取需要重新計算，從來源事件的目前狀態。很明顯地，這會是很慢。在事件來源，您可以避免這類耗費資源的作業，使用所謂的輪流快照集： 在指定的時間點的實體狀態的投影的時間。比方說，銀行預先計算您的銀行帳戶餘額的最後一天的每個月，因此您不必加總所有的借方，並從天起的信用額度作業開啟您的銀行帳戶，以取得您目前的餘額。

[圖 6顯示賭的應用程式的結構化資料模型。這有時候稱為雪花式模型，因為每個實體 （資料庫資料表） 的任何其他不同。

結構化資料模型
[圖 6 結構化資料模型

事件來源的方法將儲存個別事實時，結構化資料模型會儲存系統的目前狀態。狀態，請在事件來源時，會發生的所有相關事實的函式。不只這並未提供完整的稽核，但它也可讓我們來建置狀態投影到任何過去的時間。

若要推送這方面的責任隔離更進一步，命令查詢責任隔離 (CQRS) 會補充事件來源為資料存放區的設計模式。CQRS 可促進有效的單一責任和部署微服務，並延伸智能合約的能力。它指出，您可以 — 而且也應該 — 分開成不同的模型的資料查詢功能的資料更新。

在使用 CQRS 時，就可以排除需要跨多個內容中存取資料。智慧合約可以擁有和封裝的模型狀態的任何更新和引發事件，在此狀態的變更。藉由訂閱這些事件的通知，不同的智慧合約可以建立完全獨立且查詢最佳化的模型不需要與任何其他合約或外部服務共用。您可以深入了解 CQRS 從 Martin Fowler 文章，網址bit.ly/2Awoz33。

[圖 7描述我賭使用事件來源的應用程式而設計的資料模型。這個簡單的模型會採用類似的結構，不論處理事件。您不需要知道要讀取的事件順序 bet 的目前狀態。事件的資料結構，取決於事件本身。雖然做的工作流程中定義，就會存在狀態的順序，是以資料模型觀點無關。考慮較大：在供應鏈案例中，多個工作流程和事件存在，使用不同的實體和屬性。您的結構化資料模型可能會變得複雜，而事件為基礎的模型，幾個不同的屬性，為每個事件，橫條會維持不變。

事件來源的資料模型
[圖 7 事件來源的資料模型

分散式的交易

共用的資料模型不是唯一的使用案例會導致智能合約之間的緊密結合。另一個重要的威脅是工作流程。許多實際的處理序不可以有單一、 不可部分完成的作業。使用這類工作流程中，結果才有意義也可執行所有步驟。如果序列中的任何步驟失敗，產生相關的系統的狀態會變為無效。在 RDBMS 的世界中，這種程序稱為 「 交易 」。 資料庫交易是一般為本機，包含在單一資料庫的範圍內，並依賴之前更新的資料表上的鎖定。如果步驟失敗，您可以回復之前最終認可已嘗試的步驟。

分散式工作流程和無狀態微服務，與資料鎖定和不可部分完成性、 一致性、 隔離、 持久性 (ACID) 合規性的傳統的交易實作 (en.wikipedia.org/wiki/ACID) 是並不實用。Sagas (bit.ly/2AzdKNR) 是長時間執行的分散式的交易，允許在鬆散偶合的環境中，執行工作流程，而不需進行的每個元件的複雜的系統可靠性提出任何假設。

Sagas，在工作流程中的每個步驟執行其部分的工作、 註冊補償交易的呼叫中稱為 「 傳閱名單 」 的訊息，並傳遞更新的訊息活動鏈結中向下。如果下游任何步驟失敗，該步驟就會查看傳閱名單，並叫用最新步驟的補償交易，並傳回傳閱名單。上一個步驟執行相同的動作，直到所有已執行的交易，來補償，依此類推呼叫其前身的補償交易。此模式會導致分散式交易中的資料最終一致性 (bit.ly/2v8T360)。由於它的高容錯的分散式本質，sagas 是非常適合微服務架構，以及有關區塊鏈智能合約。

您可以在 Solidity 中實作一種透過後援函式的傳閱名單。後援的函式是未命名函式定義為任何輸入引數和傳回值。如果其他函式都不符合指定的函式識別項或合約收到 Ether （如果是以太坊） 時，它會在合約呼叫進行執行。此外，若要接收 Ether，後援的函式必須標記應付帳款。如果沒有這類函式存在，合約無法接收 Ether 透過規則 （地址地址） 交易。

值得一提的是，而不需要應付帳款後援函式的合約可以接收 Ether 為 coinbase 交易，例如 miner 區塊 reward 的收件者。合約這類 Ether 傳輸無法回應，以及因此，也不能拒絕它們。這是設計各種以太坊，而且在 Solidity 無法解決之道。合約可以有一個未命名的函式，如下所示：

// Fallback function
function() public payable {
  emit AmountTransfered(msg.sender);
}
event AmountTransfered(address sender);

在以太坊，後援函式的智慧合約以允許帳戶對帳戶直接傳輸。這是因為傳輸的帳戶可能需要將這兩個外部擁有的帳戶 (EOAs) 以及其他智能合約進行傳輸。EOAs 僅能接受直接傳輸，來將值傳輸到另一個帳戶的帳戶的唯一方式就是實作後援的函式正在執行的合約。這表示，想要接受這類傳輸必須直接傳輸妥當，具有後援的函式的任何合約。該函式，則傳輸將會失敗，而無法接受 Ether 從其他合約的合約。

最佳的作法是在後援的函式中沒有任何邏輯。您可將程式碼放在此函式主體中，但建議您最好避免非常簡短的簡單記錄以外的項目。原因是重要且唯一智能合約：您不希望此函式失敗，因為它用盡 ga。根據經驗法則，您必須剛好足夠的天然氣來引發事件，但不足以將資料寫入至儲存體。

非同步傳訊

非同步傳訊扮演著舉足輕重保持鬆散耦合微服務架構中的項目。比方說，我們可以使用訊息代理程式來傳送事件通知以非同步方式，防止在每個端點的可用性和訊息格式建立的相依性的點對點連線。由相同的權杖，智能合約能夠受益於通訊的整合為輸入 (從外部或內部的區塊鏈) 和輸出 （從到外部應用程式區塊鏈） 通訊。

除了提供 REST API，Azure Blockchain Workbench 會提供傳訊為基礎的整合，以交易記錄資料庫為中心的事件為基礎。事件都會發佈至 Azure Event Grid，並取用者可以擷取資料，或根據這些事件採取動作。對於需要可靠傳訊的用戶端，Azure Blockchain Workbench 會將訊息傳遞至 Azure 服務匯流排端點，以及。您可以引發事件，例如，通知使用者和系統的交易或變更的智慧合約中的狀態。事件通知可以直接在程式碼中使用或搭配邏輯應用程式之類的工具 (bit.ly/2n4EgoP) 的資料至下游系統的觸發程序流程。

智能合約通常代表商務工作流程整合與外部系統和裝置。如此一來，交易必須要能夠在分散式的交易記錄資料庫，其中包含來自外部系統或裝置上起始。您也可以有外部系統回應來自智能合約上的分散式總帳的事件。REST API 和訊息整合提供能夠同時從外部系統將交易傳送到智能合約包含 Azure Blockchain Workbench 應用程式，並將事件通知傳送到外部系統，根據所進行的變更在應用程式。現在讓我們來探索所識別的每一種類型的端對端解決方案中整合的模式：

  • 從智慧合約單向事件傳遞至事件取用者。
  • 單向事件傳遞的訊息從外部系統以智慧的合約。

要為事件取用者的智慧合約

在第一個案例中，就會發生事件內的智慧合約;例如，狀態變更或執行特定類型的交易。此事件廣播透過 Event Grid 給下游取用者和這些取用者，然後採取適當的動作。此案例的範例是，交易時，取用者會收到警示，並可能採取動作，例如記錄資料庫中的資訊。這是 Azure Blockchain Workbench 來填入它鏈結外的 SQL 資料庫會遵循相同的模式。另一個是為特定的狀態; 如果轉換智慧合約比方說，當合約會進入 「 共合規性 」 狀態。此狀態變更發生時，它可能會觸發警示，以傳送給系統管理員。發生這種情況使用所述的程序**[圖 8**，其中：

  1. 智慧合約轉換成新的狀態，並將事件傳送到交易記錄資料庫。
  2. 分類帳接收，並將事件傳遞至 Azure Blockchain Workbench。
  3. Azure Blockchain Workbench 分類帳從中訂閱事件，並接收事件。
  4. Azure Blockchain Workbench 會將事件發佈到 Event Grid 訂閱者。
  5. Event Grid 訂閱外部系統、 使用訊息並採取適當的動作。

外部系統智慧合約中所引發之事件的傳播
[圖 8 傳用至外部系統的智慧合約中所引發之事件的

外部系統，以智慧的合約

另外還有從相反的方向流動的案例。在此情況下，感應器產生事件，或外部系統，並從該事件的資料應傳送至智慧的合約。資料可從金融市場，例如價格商品、 股票或債，傳遞至智慧型合約是一個常見的例子。發生這種情況使用所述的程序**[圖 9**，其中：

  1. 觸發 Azure Blockchain Workbench 的建立訊息的外部系統中發生的事件。
  2. 外部系統具有已知的格式建立這個訊息撰寫的程式碼，以及這將直接傳送至服務匯流排。
  3. Azure Blockchain Workbench 從服務匯流排訂閱事件，並擷取訊息。
  4. Azure Blockchain Workbench 會起始交易記錄資料庫，呼叫從外部系統傳送資料，特定合約。
  5. 收到訊息的詳細資訊，合約會轉換成可能的新狀態。

外部系統以智慧的合約所引發之事件的傳播
[圖 9 智慧合約的外部系統所引發的事件中傳播

其中一個整合案例的端對端解決方案的實作已超出本文的範圍。整合兩個方向的絕佳範例，請參閱bit.ly/2M8yflL。

在 [摘要] 類似的整合模式可在微服務架構和區塊鏈智能合約。這兩種架構的分散式的本質鼓勵非同步傳訊模式與訊息代理程式，事件格線 」 或 「 服務匯流排，以用於傳達資訊以及執行服務和智能合約。設計模式，例如事件來源，最後，比對不可變的本質，數位分類帳以及鏈外通訊的事件驅動方法。

探索 Azure Blockchain Workbench API

Azure Blockchain Workbench (aka.ms/abcworkbench) 是一項服務，以分鐘為單位建立區塊鏈數位交易記錄資料庫 （目前，以太坊）。它也提供適用於快速開發智能合約，同時執行以太坊或類似的區塊鏈平台所需的基礎結構的顧慮降至最低，在 Azure 中裝載的資源。

如果您還不熟悉 Azure Blockchain Workbench，請參閱我介紹它在 6 月號的MSDN Magazine (msdn.com/magazine/mt846726)。Azure Blockchain Workbench 提供作為整合桌面、 Web 及行動應用程式區塊鏈應用程式閘道 REST API 開發人員。比方說，開發人員也可以使用 API，以便將資料傳送至智慧合約的 IoT 裝置。或者，此 API 可供建立區塊鏈資料的視覺效果的 Power BI。API 會公開大量 Azure Blockchain workbench，組織作業群組中，如下所示的功能**[圖 A**，而且可用來自動執行下列：

  • 建立和管理區塊鏈協會內的工作流程。
  • 與建立關聯的使用者和組織協會、 區塊鏈應用程式或應用程式工作流程。
  • 執行區塊鏈上的交易。
  • 擷取的交易式和區塊鏈的資料合約。

 

作業群組 描述
應用程式 Blockchain Workbench 區塊鏈應用程式管理。
功能 使用者可以執行 Blockchain Workbench 內的功能清單。
檢查程式 開發人員工具，用來驗證 Workbench 組態和區塊鏈智能合約。
連線 區塊鏈網路連接。
合約 智慧合約執行個體，包括能夠採取動作，智能合約。
圖形 Proxy Azure Active Directory Graph api 的使用者表示 proxy 的方法。
健全狀況 Blockchain Workbench API 的健全狀況狀態。
總帳 支援的區塊鏈網路。
使用者 Blockchain Workbench 中的使用者管理。

[圖 A Azure Blockchain Workbench REST API 作業群組

REST api 的 HTTP 要求會受到保護，與 Azure Active Directory (Azure AD)。若要讓 REST API 已驗證的要求，用戶端必須可以呼叫 API 之前，使用有效的認證進行驗證。驗證是由 Azure AD 的各種動作項目之間協調，並提供存取權杖中的用戶端，做為驗證的證明。語彙基元，然後在每個 REST API 要求的 HTTP 授權標頭中傳送。如何驗證 Azure Blockchain Workbench REST API，在用戶端應用程式的 GitHub 上查看這些範例**bit.ly/2vxzlAC**。

該 GitHub 存放庫包含其他範例，示範如何叫用不同的服務，以列出應用程式、 工作流程和區塊鏈上的合約。雖然 Azure Blockchain Workbench 目前實作中的支援只以太坊，未來的版本會延伸到其他數位總帳的支援。在結束時，API 會提供一般存取使用單一應用程式設計介面，無論何種技術和程式設計語言中使用任何支援的區塊鏈平台。

Stefano TempestaMicrosoft 區域經理以及 AI 和商務應用程式，以及分會領導人的雙精度浮點 MVP 為覅痹 Microsoft Dynamics 365 社群。講師的課程有關 Dynamics 365、 區塊鏈和機器學習服務，而在國際 IT 研討會發表演說，包括 Microsoft Ignite 和 Tech Summit 發言 Tempesta。他成立 Blogchain 空間 (blogchain.space)，區塊鏈技術的相關部落格 MSDN Magazine 和 MS Dynamics 世界中，將寫入，並將發佈機器學習服務實驗，在 Azure AI 資源庫 (gallery.azure.ai)。

感謝下列技術專家：Jonathan Waldman

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