Quản lý API
- 5 phút
Vậy vấn đề tôi đang gặp phải là gì khiến tôi muốn tìm kiếm một giải pháp quản lý API? Rất có thể bạn sẽ gặp phải những thách thức sau:
- , API hoặc API của bạn được nhiều máy khách ở các khu vực khác nhau trên thế giới sử dụng và bạn cần phải đảm bảo rằng API hoặc API đó khả dụng và phản hồi.
- bảo mật, bạn cần phải đảm bảo rằng API của mình an toàn và chỉ những khách hàng được ủy quyền mới có thể truy cập api.
- quản lý lỗi, bạn cần đảm bảo rằng API của mình có thể xử lý lỗi một cách dễ dàng.
- giámgiám sát , bạn cần giám sát API của mình để đảm bảo API hoạt động như mong đợi.
- Khả năng phục hồi, bạn cần phải đảm bảo rằng API của bạn đàn hồi và có thể xử lý các lỗi một cách dễ dàng.
Đối với mỗi thách thức trong số này, bạn có thể lựa chọn một giải pháp điểm, nhưng điều đó có thể khó quản lý. Ngoài ra, hãy cân nhắc rằng các API của bạn có thể được xây dựng trong các ngăn xếp công nghệ khác nhau, điều này có nghĩa là các giải pháp cho những thách thức trên có thể có nghĩa là bạn cần các giải pháp khác nhau cho từng API. Nếu bạn đang gặp phải tất cả những thách thức này, thì bạn nên xem xét một giải pháp quản lý API tập trung như Azure API Management.
Hãy tìm hiểu sâu hơn về một số thách thức và xem giải pháp quản lý API tập trung như Azure API Management có thể giúp bạn giải quyết chúng như thế nào.
Cơ sở hạ tầng như mã, IaC
Việc tạo tài nguyên Azure bằng cách sử dụng cổng thông tin Azure là hoàn toàn hoàn hảo, nhưng khi cơ sở hạ tầng của bạn phát triển, bạn sẽ khó quản lý hơn. Một trong những vấn đề bạn phải đối mặt là bạn không thể dễ dàng sao chép cơ sở hạ tầng của bạn trong một môi trường khác.
Cũng khó theo dõi tất cả các thay đổi được thực hiện cho cơ sở hạ tầng của bạn. Tình huống này là nơi cơ sở hạ tầng như mã (IaC) đi vào. IaC là thực hành quản lý cơ sở hạ tầng của bạn bằng cách sử dụng mã. Để áp dụng IaC trên Azure, bạn có một số tùy chọn, một trong số đó là Bicep. Bicep là một Ngôn ngữ Cụ thể cho Miền (DSL) để triển khai các tài nguyên Azure một cách khai báo. Đây là một cách tuyệt vời để quản lý các tài nguyên đám mây của bạn. Đây là một ví dụ đơn giản về giao diện của Bicep:
param location string = 'eastus'
resource storageAccount 'Microsoft.Storage/storageAccounts@2021-06-01' = {
name: 'mystorageaccount'
location: location
kind: 'StorageV2'
sku: {
name: 'Standard_LRS'
}
}
Trong ví dụ trước, chúng tôi đã xác định một tài khoản lưu trữ bằng cách sử dụng Bicep. Chúng tôi đã xác định vị trí của tài khoản lưu trữ, loại tài khoản lưu trữ và SKU (đơn vị giữ cổ phiếu). Vị trí là một tham số mà chúng ta có thể đi vào khi chúng ta triển khai tệp Bicep. Để triển khai tệp được trình bày, chúng tôi sẽ sử dụng Azure CLI như sau:
az deployment group create --resource-group myResourceGroup --template-file main.bicep
Lệnh trước triển khai tài khoản lưu trữ cho nhóm tài myResourceGroup và sử dụng tệp Bicep main.bicep để tạo tài nguyên trong tệp.
Xử lý tải thông qua trình cân bằng tải
Thêm cấu trúc cân bằng tải là câu trả lời khi vấn đề là API của bạn bị quá tải bởi các yêu cầu. Trình cân bằng tải có thể giúp bạn phân phối tải trên nhiều phiên bản API của mình.
Trong dịch vụ Quản lý API Azure, cân bằng tải được thực hiện bằng cách bạn xác định một khái niệm được gọi là phụ trợ. Ý tưởng là bạn thiết lập nhiều phụ trợ tương ứng với các điểm cuối API của bạn và sau đó bạn tạo ra một trình cân bằng tải phân phối tải trên các phụ trợ này. Dưới đây là diện mạo của kiến trúc:
Những gì đang xảy ra trong kiến trúc trước đó là:
- Máy khách gửi yêu cầu đến phiên bản Quản lý API.
- Yêu cầu được xác thực và ủy quyền.
- Sau đó, yêu cầu sẽ được gửi đến trình cân bằng tải.
- Trình cân bằng tải phân phối yêu cầu tới một trong các phụ trợ (API Azure OpenAI được chọn được biểu thị bằng chữ đậm).
Phụ trợ xử lý yêu cầu và gửi phản hồi lại cho khách hàng.
Xác định trình cân bằng tải
Để thiết lập trình cân bằng tải trong Azure API Management, bạn cần thực hiện các phần sau:
- phụ, bao nhiêu phụ trợ tùy thích để phân phối tải.
- cân bằng tải, trình cân bằng tải có chứa các phụ trợ mà bạn muốn phân phối tải qua.
- Một chính chuyển hướng các cuộc gọi đến đến trình cân bằng tải.
Tạo phụ trợ
Để tạo phụ trợ trong Azure API Management, bạn cần xác định thực thể phụ trợ. Đây là cách bạn có thể xác định một phụ trợ trong Bicep:
resource backend2 'Microsoft.ApiManagement/service/backends@2023-09-01-preview' = {
parent: apimService
name: 'backend2'
properties: {
url: '${openai2Endpoint}openai'
protocol: 'http'
circuitBreaker: {
rules: [
{
failureCondition: {
count: 3
errorReasons: [
'Server errors'
]
interval: 'P1D'
statusCodeRanges: [
{
min: 500
max: 599
}
]
}
name: 'myBreakerRule'
tripDuration: 'PT1H'
}
]
}
}
Trong mã Bicep trước, phần phụ trợ được xác định tương ứng với URL điểm cuối API, thông báo cả tên của backend2 tên này là điều chúng ta có thể sử dụng sau này. Đối với mỗi phụ trợ bạn có, bạn nên mã hóa nó giống như mã bicep trước đó.
Ghi
Hãy nhớ rằng bạn có thể có nhiều phụ trợ để bạn có thể xác định bao nhiêu phụ trợ tùy thích.
Tạo vùng phụ trợ
Tiếp theo, chúng tôi muốn tạo một vùng phụ trợ thiết lập những phụ trợ mà chúng tôi muốn phân phối tải giữa. Chúng tôi có thể mã hóa vùng phụ trợ này như một thực thể phụ trợ như vậy:
resource loadBalancing 'Microsoft.ApiManagement/service/backends@2023-09-01-preview' = {
parent: apimService
name: 'LoadBalancer'
properties: {
description: 'Load balancer for multiple backends'
type: 'Pool'
pool: {
services: [
{
id: '/subscriptions/${subscriptionId}/resourceGroups/${resourceGroupName}/providers/Microsoft.ApiManagement/service/${apimService.name}/backends/${backend1.id}'
}
{
id: '/subscriptions/${subscriptionId}/resourceGroups/${resourceGroupName}/providers/Microsoft.ApiManagement/service/${apimService.name}/backends/${backend2.id}'
}
]
}
}
}
Phần phụ trợ mà chúng ta đã tạo trước đó, backend2, được tham chiếu cùng với một backend1phụ trợ khác , phần sau mà chúng ta đã bỏ qua cho sự dễ dàng.
Chúng tôi cũng có thể bao gồm một thuộc tính priority và weight, cho mỗi mục trong danh sách services để xác định cách thức trình cân bằng tải phân phối tải. Dưới đây là cách bạn có thể đặt mức ưu tiên và trọng lượng cho từng phụ trợ:
services: [
{
id: '/subscriptions/<subscriptionID>/resourceGroups/<resourceGroupName>/providers/Microsoft.ApiManagement/service/<APIManagementName>/backends/backend-1'
priority: 1
weight: 3
}
{
id: '/subscriptions/<subscriptionID>/resourceGroups/<resourceGroupName>/providers/Microsoft.ApiManagement/service/<APIManagementName>/backends/backend-2'
priority: 1
weight: 1
}
]
Trong ví dụ trên đây, trình cân bằng tải phân bố tải backend-1 nhiều hơn ba lần so với backend-2.
Cuộc gọi đến trực tiếp
Cuối cùng, chúng ta cần chuyển hướng bất kỳ cuộc gọi đến nào đến phụ trợ cân bằng tải này. Hướng dẫn được tạo thực thể API sau:
resource api1 'Microsoft.ApiManagement/service/apis@2020-06-01-preview' = {
parent: apimService
name: apiName
properties: {
displayName: apiName
apiType: 'http'
path: apiSuffix
format: 'openapi+json-link'
value: 'https://raw.githubusercontent.com/Azure/azure-rest-api-specs/main/specification/cognitiveservices/data-plane/AzureOpenAI/inference/preview/2024-03-01-preview/inference.json'
subscriptionKeyParameterNames: {
header: 'api-key'
}
}
Cấu hình chính sách
Bây giờ, cuối cùng chúng ta có thể đặt chính sách về API được mô tả trước đó và chuyển các cuộc gọi đến đến trình cân bằng tải:
// policy.xml
<policies>
<inbound>
<base />
<set-backend-service id="apim-generated-policy" backend-id="{0}" />
</inbound>
<backend>
<base />
</backend>
<outbound>
<base />
</outbound>
<on-error>
<base />
</on-error>
</policies>
var headerPolicyXml = format(loadTextContent('./policy.xml'), loadBalancing.name, 5000)
// Create a policy for the API, using the headerPolicyXml variable
resource apiPolicy 'Microsoft.ApiManagement/service/apis/policies@2020-06-01-preview' = {
parent: api1
name: 'policy'
properties: {
format: 'rawxml'
value: headerPolicyXml
}
}
Những gì chúng tôi đã làm là tạo ra một chính sách hướng các cuộc gọi đến đến trình cân bằng tải. Chính set-backend-service được sử dụng để chỉ dẫn các cuộc gọi đến để cân bằng tải. Thuộc backend-id được đặt thành tên của trình cân bằng tải mà chúng tôi đã tạo trước đó.
Với tất cả các phần di chuyển này tại chỗ, phiên bản Quản lý API của bạn hiện đã cân bằng tải. Giờ đây, bạn có thể mở rộng API của mình bằng cách thêm nhiều phụ trợ hơn vào trình cân bằng tải.
Bộ ngắt mạch
Một bộ ngắt mạch là một cái gì đó bạn sử dụng khi bạn muốn bảo vệ API của bạn khỏi bị choáng ngợp bởi các yêu cầu. Làm thế nào nó hoạt động là bạn xác định một tập hợp các quy tắc mà khi đáp ứng, bộ ngắt mạch kích hoạt và ngừng gửi yêu cầu đến phụ trợ. Trong Azure API Management, bạn có thể xác định một bộ ngắt mạch bằng cách thiết lập một phụ trợ và xác định quy tắc ngắt mạch. Dưới đây là cách bạn có thể thực hiện:
resource backend2 'Microsoft.ApiManagement/service/backends@2023-09-01-preview' = {
parent: apimService
name: 'backend2'
properties: {
url: '${openai2Endpoint}openai'
protocol: 'http'
circuitBreaker: {
rules: [
{
failureCondition: {
count: 3
errorReasons: [
'Server errors'
]
interval: 'P1D'
statusCodeRanges: [
{
min: 500
max: 599
}
]
}
name: 'myBreakerRule'
tripDuration: 'PT1H'
}
]
}
}
}
Trong định nghĩa phụ trợ trước đó, có một thuộc tính failureCondition xác định khi nào bộ ngắt mạch nên đi. Trong trường hợp này, các chuyến đi ngắt mạch nếu có ba lỗi máy chủ trong một ngày. Thuộc tripDuration xác định khoảng thời gian mà bộ ngắt mạch sẽ mở trước khi đóng lại. Bạn nên xác định một bộ ngắt mạch cho mỗi phụ trợ mà bạn có trong phiên bản Quản lý API của mình.
Danh tính được quản lý
Một vấn đề khác mà chúng tôi đang tìm cách giải quyết là bảo mật. Bạn muốn đảm bảo rằng API của mình được bảo mật và chỉ những khách hàng được ủy quyền mới có thể truy cập nó. Một cách để bảo mật API của bạn là sử dụng danh tính được quản lý. Danh tính được quản lý là một cách để xác thực API của bạn với các dịch vụ Azure khác. Trong Azure API Management, bạn cần phải áp dụng danh tính được quản lý ở một số nơi cụ thể là:
thể hiện APIM, bạn có thể bật danh tính được quản lý trong phiên bản APIM bằng cách đặt thuộc tính
identitythànhSystemAssignednhư sau:resource apimService 'Microsoft.ApiManagement/service@2023-09-01-preview' = { name: name location: location tags: union(tags, { 'azd-service-name': name }) sku: { name: sku capacity: (sku == 'Consumption') ? 0 : ((sku == 'Developer') ? 1 : skuCount) } properties: { publisherEmail: publisherEmail publisherName: publisherName // Custom properties are not supported for Consumption SKU } identity: { type: 'SystemAssigned' } }Hành động này tạo ra một định danh được quản lý cho phiên bản APIM mà chúng tôi có thể sử dụng sau này phiên bản APIM của chúng tôi, ví dụ: một phiên bản Azure OpenAI.
cấp API, đối với phiên bản API của mình, bạn có thể liên kết api với một chính sách. Trong chính sách nói trên, bạn có thể thêm hướng dẫn cần thiết cho danh tính được quản lý để hoạt động:
<policies> <inbound> <base /> <authentication-managed-identity resource="https://cognitiveservices.azure.com" output-token-variable-name="managed-id-access-token" ignore-error="false" /> <set-header name="Authorization" exists-action="override"> <value>@("Bearer " + (string)context.Variables["managed-id-access-token"])</value> </set-header> </inbound> <backend> <base /> </backend> <outbound> <base /> </outbound> <on-error> <base /> </on-error> </policies>Xem các cuộc gọi trước đó để
authentication-managed-identityvàset-headercác hướng dẫn này đảm bảo rằng danh tính được quản lý được áp dụng cho API.cấp độ phụ, cuối cùng, việc cung cấp các phụ trợ của bạn đang trỏ đến các phiên bản Azure OpenAI. Chúng tôi cần kết nối phiên bản APIM của mình với phiên bản Azure OpenAI. Để thực hiện kết nối này, đây là hướng dẫn Bicep:
resource role 'Microsoft.Authorization/roleAssignments@2022-04-01' = { name: guid(subscription().id, resourceGroup().id, principalId, roleDefinitionId) properties: { principalId: principalId principalType: "ServicePrincipal" roleDefinitionId: resourceId('Microsoft.Authorization/roleDefinitions', roleDefinitionId) } }Ý tưởng với hướng dẫn Bicep ở trên là tạo một gán vai trò giữa phiên bản APIM và phiên bản Azure OpenAI. Trong trường hợp này:
-
principalIdid nhận dạng từ phiên bản APIM, -
roleDefinitionIdlà người dùng cụ thể, trong trường hợp này là người dùng được gọi là "Người dùng Dịch vụ Nhận thức", một người dùng có quyền truy nhập vào phiên bản Azure OpenAI. -
name, thuộc tính này đảm bảo rằng gán vai trò được áp dụng cho phạm vi phù hợp, trong trường hợp này là một đăng ký và nhóm tài nguyên cụ thể. (cần phải là cùng một nhóm tài nguyên với phiên bản Azure OpenAI)
-