Azure - Kiến trúc hướng sự kiện trong cloud với lưới sự kiện Azure(Phần I)
Bài đăng này đã không được cập nhật trong 6 năm
Đó là một thời gian thú vị để trở thành một kiến trúc sư về đám mây. Tốc độ đổi mới đã dẫn đến một loạt các thách thức mới và công nghệ đang định hình lại cách thức các giải pháp được thiết kế. Lợi ích từ sự tăng trưởng này là các nhà phát triển và kiến trúc sư có thể lựa chọn từ một sự phong phú của các dịch vụ và các tùy chọn.
Khi các nhà phát triển trải qua việc thực hiện việc phân hủy kiến trúc của mình để tận dụng các dịch vụ mới như Azure Functions, Logic Apps và các ứng dụng khác, những trở ngại quen thuộc trên bề mặt. Trong nhiều trường hợp, chúng ta thấy mình lại một lần nữa những mảnh ghép cùng nhau như một chất keo mà kết dính cho phép tất cả được nên một với nhau như một concert . Sự ra mắt gần đây của Azure Event Grid nhằm giải quyết thách thức này bằng cách cung cấp dịch vụ định tuyến sự kiện hạng nhất trong đám mây được quản lý đầy đủ, khả năng mở rộng và cực kỳ linh hoạt.
Trong bài này, tôi sẽ khám phá tính linh hoạt của Azure Event Grid và chỉ ra cách sử dụng nó để giải quyết những thách thức quen thuộc trong các ứng dụng doanh nghiệp. Tôi cũng khuyến khích bạn kiểm tra thông báo về sự sẵn có của Sự kiện Sự kiện của Sự kiện trên tại aka.ms/egblog.
Sự đảo ngược của Dependencies
Khái niệm sử dụng sự kiện trong một giải pháp hoặc ứng dụng không phải là mới. Trên thực tế, chương trình hướng sự kiện đã sử dụng thành công khái niệm này trong một thời gian. Pub / Sub queues và GUI chỉ là một vài trong số những ví dụ sử dụng ý tưởng phản ứng với các sự kiện xảy ra trong một tổ chức, ứng dụng hoặc hệ thống. Một trong những cốt lõi của một kiến trúc hướng sự kiện là đảo ngược dependencies mà các dịch vụ hiện có có thể có với nhau. Hình 1 cho thấy một ví dụ về một tập các quy trình dựa vào nhau để giao tiếp và hỗ trợ bộ phận Nhân sự (HR).
Hình 1 Dịch vụ chứa Logic về Các dịch vụ Khác
Đối với thiết kế này để làm việc, mỗi dịch vụ phải có một số logic cơ bản về những người khác để giao tiếp. Những dependencies này tạo ra những thách thức, không chỉ về quy mô, mà còn do thực tế rằng logic này nằm rải rác khắp kiến trúc. Theo thời gian, khi các loại giải pháp này mở rộng, chúng trở nên khó khăn để duy trì và ngày càng trở nên giòn vì có nhiều thay đổi hơn và dependencies được giới thiệu.
Thay vào đó, khái niệm thiết kế theo sự kiện sẽ loại bỏ những mối quan hệ phụ thuộc này bằng cách quảng bá ý tưởng về một sự kiện như là một công dân hạng nhất trong kiến trúc. Sự cân nhắc quan trọng này cho phép nhiều hệ thống khác có khả năng tận dụng dịch vụ tập trung mà không có gánh nặng phụ thuộc và logic phân tán trong suốt quá trình áp dụng. Hình 2 nêu bật sự đảo ngược của sự phụ thuộc đối với giải pháp HR department bằng cách đưa ra khái niệm cơ bản này.
Hình 2 Một dịch vụ tập trung phục hồi Dependencies giữa các dịch vụ khác
Dịch vụ chính này là phần còn lại của bài viết. Tôi sẽ khám phá Azure Event Grid và cách nó có thể được sử dụng để hỗ trợ thế hệ tiếp theo của các giải pháp.
Giới thiệu lưới sự kiện Azure
Azure Event Grid là một dịch vụ được quản lý đầy đủ mới hỗ trợ việc định tuyến các sự kiện bằng cách sử dụng mô hình publisher-subscriber. Core Grid là dịch vụ định tuyến sự kiện quản lý định tuyến và phân phối các sự kiện từ nhiều nguồn và người đăng ký. Hình 3, được lấy từ tài liệu tổng quan về lưới sự kiện (bit.ly/2qhaj9q), minh hoạ cho một số publishers và handlers có thể được sử dụng với Event Grid ngày hôm nay.
Hình 3 Tổng quan về Azure Event
Sự kiện được tạo bởi publisher chẳng hạn như tài khoản Blob Storage, Event Hubs hoặc thậm chí Azure subscription. Khi sự kiện xảy ra, chúng được xuất bản tới điểm kết thúc được gọi là chủ đề Event Grid service manages quản lý. Danh sách các dịch vụ trên Azure tích hợp với Event Grid đang phát triển.
Event publishers không giới hạn đối với các dịch vụ trên Azure. Trong thực tế, trường hợp sử dụng rất phổ biến bao gồm các sự kiện bắt nguồn từ các ứng dụng hoặc hệ thống tùy chỉnh có thể chạy từ bất cứ đâu. Điều này bao gồm các ứng dụng được lưu trữ tại chỗ, trong một trung tâm dữ liệu, hoặc thậm chí trên các clouds. Những loại publishers này được gọi là Custom Topics. Nếu họ có thể gửi yêu cầu HTTP đến dịch vụ Event Grid, thì họ là ứng cử viên để gửi sự kiện.
Trình xử lý sự kiện bao gồm một số dịch vụ trên Azure. Chúng giới thiệu một số công nghệ không có server mới trên Azure, chẳng hạn như Chức năng và Ứng dụng Logic. Ngoài Azure Automation, một loại xử lý sự kiện khác có thể là bất kỳ gọi lại HTTP nào, còn được gọi là WebHook. Handlers được đăng ký với Event Grid bằng cách tạo một đăng ký sự kiện. Nếu điểm cuối trình xử lý sự kiện được truy cập công khai và mã hóa bởi Transport Layer Security, sau đó các tin nhắn có thể được đẩy đến nó từ Event Grid.
Không giống nhiều dịch vụ Azure khác, không có không gian tên Lưới sự kiện nào cần được cung cấp hoặc quản lý. Chủ đề đối với tài nguyên Azure bản địa được xây dựng và minh bạch hoàn toàn với người dùng trong khi các chủ đề tùy chỉnh được cung cấp theo yêu cầu và tồn tại trong một nhóm tài nguyên. Đăng ký sự kiện chỉ đơn giản là liên kết với một chủ đề. Mô hình này đơn giản hóa việc quản lý các chủ đề dưới dạng đăng ký và khiến cho Event Grid trở thành đa người thuê, cho phép mở rộng quy mô lớn.
Azure Event Grid là agnostic cho bất kỳ ngôn ngữ hoặc nền tảng. Mặc dù nó tích hợp hoàn toàn với các dịch vụ Azure, nó cũng dễ dàng được tận dụng bởi bất cứ thứ gì hỗ trợ giao thức HTTP, nó làm cho nó trở thành một dịch vụ rất thông minh và sáng tạo.
Events hoặc Commands
Trước khi đi sâu vào một số mã và xây dựng giải pháp làm nổi bật một số tính năng này, hãy phân biệt sự kiện và lệnh. Sự phân biệt đôi khi có thể tinh tế, nhưng điều quan trọng cần phải hiểu khi thiết kế các hệ thống dựa vào các thông điệp.
Khi một thông báo được gửi một hành động cụ thể hoặc response, nó rất có thể là command. Ví dụ: nếu nhân viên được thăng trong một tổ chức và thông báo được gửi để hướng người quản lý mới của bạn điền vào biểu mẫu, thì nó sẽ mang theo một mục đích hoặc ý định cụ thể. Bởi vì người gửi tin nhắn có một kỳ vọng, và trong một số trường hợp, thậm chí có thể mong đợi một phản ứng, chúng ta có thể phân loại điều này như một lệnh.
Nếu một thông báo được xuất bản mà không có mong đợi về cách nó sẽ được xử lý, sau đó nó được coi là một sự kiện. Hãy nói rằng trong một tổ chức, cùng một nhân viên đã yêu cầu thay đổi địa chỉ gửi thư của họ. Dó là thông báo không xác định mục đích. Trong trường hợp này, publisher chỉ đơn giản thông báo cho bất kỳ bên quan tâm rằng một sự kiện đã xảy ra. Đây là một sự kiện và rõ ràng sự xuất hiện của một cái gì đó là một lựa chọn khả thi cho một dịch vụ như Event Grid.
Tôi có thể dành nhiều thời gian hơn để thảo luận về những khác biệt này và ngoài việc chọn dịch vụ nhắn tin thích hợp trên Azure, tuy nhiên, điều đó nằm ngoài phạm vi của bài viết này. Tôi khuyến khích bạn đọc bài viết sâu sắc này từ Clemens Vasters về chủ đề: bit.ly/2CH3sbQ.
Kịch bản cho Human Resources
Cách tốt nhất để hiểu sâu hơn về Event Grid là viết mã để thúc đẩy khả năng của nó. Trong bài này, tôi sẽ xem xét một vài sự kiện bắt nguồn từ một ứng dụng nhân sự giả tưởng. Tôi sẽ xuất bản sự kiện cho một chủ đề tùy chỉnh và sau đó đăng ký vào các sự kiện bằng cách sử dụng một số trình xử lý khác nhau.
Để giữ mọi thứ đơn giản, tôi sẽ triển khai hai loại sự kiện từ hệ thống nhân sự-khi một nhân viên được thêm vào một tổ chức và khi một nhân viên bị xóa. Những sự kiện này gần đủ trong tự nhiên rằng nó sẽ cung cấp các tùy chọn giới thiệu cách lọc và xử lý sự kiện theo những cách khác nhau. Hình đại diện của giải pháp được minh họa trong Hình 4.
26/5000
Hình 4 Một giải pháp mẫu
Ở cấp độ cao, giải pháp bao gồm một số thành phần chính mà tôi sẽ xây dựng trong bài báo này. Hãy khám phá chúng ở đây. Employee Events sẽ là một Event Grid Topic mà ứng dụng nhân sự có thể gửi tin nhắn. Điều này sẽ bao gồm các sự kiện cho nhân viên mới và nhân viên đã bị xóa trong tổ chức. Mỗi tin nhắn sẽ chứa thông tin về nhân viên, phòng ban và loại sự kiện. New Employee Welcome sẽ là một Ứng dụng Logic đăng ký nhận tin nhắn cho nhân viên mới trong tổ chức. Cuối cùng nó sẽ gửi một email chào mừng đến nhân viên mới. New Employee Equipment Order là một Chức năng Azure sẽ đăng ký các sự kiện cho nhân viên mới trong Phòng Kỹ thuật. Sau đó, nó sẽ tạo ra một thông điệp trong một hàng đợi để xử lý bổ sung. Employee Records là một trang web tùy chỉnh được xây dựng trên ASP.NET Core sẽ để lộ một Web API để nhận các tin nhắn khi nhân viên rời khỏi tổ chức.
Tạo chủ đề tùy chỉnh
Để bắt đầu, tôi sẽ cần phải tạo ra một vài tài nguyên cơ bản trong Azure. Bạn có thể khởi chạy Azure Cloud Shell từ cổng hoặc sử dụng giao diện dòng lệnh (CLI) tại địa phương. Chi tiết về cách sử dụng Cloud Shell có thể tìm thấy tại bit.ly/2CsFtQB. Nếu bạn chưa sử dụng Cloud Shell trước, tôi khuyên bạn nên sử dụng nó.
Điều đầu tiên tôi sẽ làm là tạo ra một nhóm tài nguyên để quản lý và đóng gói các tài nguyên Azure:
az group create --name <resource-group-name> --location <location>
Sau khi nhóm được tạo, Event Grid Topic được cung cấp. Điều này sẽ cung cấp một điểm cuối để xuất bản các sự kiện tùy chỉnh từ ứng dụng nhân sự. Tên của chủ đề phải là duy nhất cho khu vực, vì nó sẽ là một dịch vụ truy cập công cộng trên Azure. Vị trí cũng phải ở trong vùng có dịch vụ Event Grid service. Tôi thường đi với vị trí westus2 hoặc tham khảo danh sách các dịch vụ được cung cấp trong mỗi vùng Azure (xem bit.ly/2DU15ln).
az eventgrid topic create --name <topic-name> \
--location <location> \
--resource-group <resource group name>
163/5000 Sau khi thực hiện lệnh tạo chủ đề, chi tiết về tài nguyên sẽ được trả về. Đầu ra sẽ trông giống như, nhưng không chính xác, mã ở đây:
{
"endpoint": "https://<topic name>.westus2-1.eventgrid.azure.net/api/events",
"id": "/subscriptions/xxxx-xxx-xx-xxx-xx/resourceGroups/eventgridsolution-rg/providers/Microsoft.EventGrid/topics/<topic name>",
"location": "westus2",
"name": "<topic name>",
"provisioningState": "Succeeded",
"resourceGroup": "eventgridsolution-rg",
"tags": null,
"type": "Microsoft.EventGrid/topics"
}
Lưu ý giá trị điểm cuối - nó sẽ được sử dụng sau khi xuất bản các sự kiện. Bạn cũng cần một trong hai keys truy cập đã được tạo để ủy quyền. Để lấy lại các keys, bạn có thể liệt kê những cái được liên kết với chủ đề. Bạn có thể và nên chu kỳ và tạo lại các phím này như là một biện pháp an ninh-giống như bạn sẽ có với các dịch vụ khác trên Azure.
az eventgrid topic key list --name <topic-name> --resource-group <resource-group-name>
Nếu sở thích của bạn là làm việc trong Azure Portal, bạn cũng có thể tạo và xem tất cả các tùy chọn và cài đặt này ở đó.
Xuất bản một Event
Trước khi gửi sự kiện đầu tiên, bạn cần phải hiểu giản đồ sự kiện mà chủ đề mong đợi. Mỗi sự kiện, bất kể publisher là resource Azure hoặc ứng dụng tùy chỉnh, sẽ tuân thủ cấu trúc được nêu trong đoạn mã sau (một tham khảo hữu ích cho giản đồ sự kiện, cũng như một số ví dụ, có thể được tìm thấy tại bit.ly/2CG8oxI ):
[
{
"topic": string,
"subject": string,
"id": string,
"eventType": string,
"eventTime": string,
"data":{
object-unique-to-each-publisher
}
}
]
Điều đầu tiên chỉ ra là các sự kiện được gửi đi trong một mảng. Điều này được thực hiện một cách có chủ ý để cung cấp khả năng gửi nhiều sự kiện trong yêu cầu. Các sự kiện có thể được gửi theo lô, làm giảm mạng chattiness trong khi hỗ trợ các kịch bản mà kết nối không phải là luôn luôn có sẵn.
Sự kiện đầu tiên tôi muốn xuất bản là khi một nhân viên mới tham gia vào một tổ chức. Tải trọng cho sự kiện này có thể giống với nội dung của Hình 5.
[{
"id": "30934",
"eventType": "employeeAdded",
"subject": "department/engineering",
"eventTime": "2017-12-14T10:10:20+00:00",
"data":{
"employeeId": "14",
"employeeName": "Nigel Tufnel",
"employeeEmail": "nigel@contoso.com",
"manager": "itmanager@contoso.com",
"managerId": "4"
}
}]
Sau đó trong bài viết tôi sẽ sử dụng cùng một cấu trúc, với một số khác biệt trong các giá trị, như khi một nhân viên rời khỏi tổ chức. Các thuộc tính chính trong sự kiện này như sau:
eventType là một giá trị được sử dụng để xác định duy nhất loại sự kiện được xuất bản. Property này có thể được sử dụng bởi người xử lý muốn đăng ký chỉ với các loại sự kiện cụ thể, chứ không phải là tất cả các loại.
subject là một giá trị, giống như eventType, có sẵn để cung cấp ngữ cảnh bổ sung về sự kiện, với tùy chọn cung cấp thêm bộ lọc bổ sung cho người đăng ký. Tôi sẽ tận dụng cả eventType và chủ đề ngay khi tôi tạo các đăng ký. Subject và eventType cung cấp bối cảnh cho sự kiện.
dữ liệu là một thùng do nhà xuất bản định nghĩa đơn giản là một đối tượng có thể chứa một hoặc nhiều thuộc tính. Nhà xuất bản chỉ định thông tin liên quan về sự kiện đó bên trong thuộc tính này. Ví dụ: sự kiện lưu trữ Azure Blob bao gồm các chi tiết về các liên kết được tạo hoặc xóa blob như URL và loại nội dung.
Để xuất bản sự kiện, tôi sử dụng Postman (hoặc một công cụ tương tự) để mô phỏng thông điệp đến từ ứng dụng nhân sự đến địa chỉ đích đã đề cập trước đó. Để được ủy quyền, tôi thêm một mục vào tiêu đề được gọi là aeg-sas-key-giá trị của nó là một trong các phím truy cập được tạo ra khi chủ đề được tạo ra. Phần thân yêu cầu sẽ chứa tải trọng được đề cập trong Hình 5.
Bởi vì không có bất kỳ thuê bao nào, không có gì để quan sát được. Bước tiếp theo sẽ là xem hành động này bằng cách tạo ra một vài trình xử lý sự kiện cho Event Grid để đẩy các sự kiện vào.
All rights reserved
