Cân bằng tải trên các máy chủ phụ trợ

Bạn đang xem tài liệu về Apigee Edge.
Hãy xem tài liệu về Apigee X.

Apigee Edge tăng cường khả năng sử dụng API bằng cách cung cấp khả năng hỗ trợ tích hợp để cân bằng tải và chuyển đổi dự phòng qua nhiều thực thể máy chủ phụ trợ.

Cấu hình TargetServer phân tách các URL điểm cuối cụ thể khỏi cấu hình TargetEndpoint. Mỗi TargetServer được tham chiếu theo tên trong HTTPEndpoint HTTPConnection. Thay vì xác định một URL cụ thể trong cấu hình, bạn có thể định cấu hình một hoặc nhiều Máy chủ đích có tên như được mô tả trong phần TargetEndpoint.

Định nghĩa TargetServer bao gồm tên, máy chủ và cổng cùng với một phần tử bổ sung để cho biết liệu TargetServer được bật hay tắt.

Video

Xem các video sau để tìm hiểu thêm về cách định tuyến API và cân bằng tải bằng máy chủ mục tiêu

Video	Mô tả
Cân bằng tải bằng máy chủ đích	Tải API cân bằng tải trên các máy chủ mục tiêu.
Định tuyến API dựa trên môi trường sử dụng máy chủ đích	Định tuyến API đến một máy chủ đích khác dựa trên môi trường.
Định tuyến API và cân bằng tải bằng máy chủ đích (Classic Edge)	Định tuyến API đến một máy chủ đích khác dựa trên môi trường và cân bằng tải API của bạn trên các máy chủ mục tiêu trong giao diện người dùng Classic Edge.

Cấu hình máy chủ đích mẫu

Mã sau đây xác định máy chủ đích:

<TargetServer  name="target1">
  <Host>1.mybackendservice.com</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer >

Phần tử cấu hình máy chủ đích

Bảng sau đây mô tả các phần tử dùng để tạo và định cấu hình TargetServer:

Tên	Mô tả	Mặc định	Bắt buộc?
name	Tên của cấu hình TargetServer phải là duy nhất trong môi trường. Tên TargetServer chỉ có thể chứa các ký tự chữ và số.	Không áp dụng	Có
Host	URL máy chủ của dịch vụ phụ trợ (không có giao thức).	Không áp dụng	Có
Port	Cổng mà dịch vụ phụ trợ đang lắng nghe	Không áp dụng	Có
IsEnabled	Giá trị boolean cho biết cấu hình TargetServer được bật hay tắt. Điều này cho phép bạn loại bỏ TargetServers mà không cần sửa đổi cấu hình proxy API. Trường hợp sử dụng phổ biến là viết một ứng dụng hoặc tập lệnh để tự động bật hoặc tắt TargetServers dựa trên các yêu cầu về dung lượng dự kiến, lịch bảo trì, v.v.	true	Có

Quản lý máy chủ mục tiêu bằng cách sử dụng giao diện người dùng

Quản lý máy chủ đích, như được mô tả bên dưới.

Quản lý máy chủ đích bằng API

Bạn có thể sử dụng Edge API để tạo, xóa, cập nhật, nhận và liệt kê các máy chủ mục tiêu. Để biết thêm thông tin, hãy xem phần TargetServers.

Sử dụng lệnh gọi API sau đây để tạo một máy chủ mục tiêu:

$ curl -H "Content-Type:text/xml" -X POST -d \
'<TargetServer name="target1">
   <Host>1.mybackendservice.com</Host>
   <Port>80</Port>
   <IsEnabled>true</IsEnabled>
 </TargetServer>' \
-u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers

Phản hồi mẫu:

{
  "host" : "1.mybackendservice.com",
  "isEnabled" : true,
  "name" : "target1",
  "port" : 80
}

Sau khi bạn tạo TargetServer đầu tiên, hãy sử dụng lệnh gọi API sau đây để tạo một TargetServer thứ hai. Bằng cách xác định hai Máy chủ đích, bạn cung cấp hai URL mà TargetEndpoint có thể sử dụng để cân bằng tải:

$ curl -H "Content-type:text/xml" -X POST -d \
'<TargetServer  name="target2">
  <Host>2.mybackendservice.com</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer >' \
-u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers

Phản hồi mẫu:

{
  "host" : "2.mybackendservice.com",
  "isEnabled" : true,
  "name" : "target2",
  "port" : 80
}

Sử dụng lệnh gọi API sau đây để truy xuất danh sách Máy chủ đích trong môi trường:

$ curl -u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers

Câu trả lời mẫu:

[ "target2", "target1" ]

Hiện tại, bạn có thể sử dụng hai Máy chủ đích để sử dụng proxy API được triển khai trong môi trường thử nghiệm. Để tải lưu lượng truy cập cân bằng trên các Máy chủ đích này, bạn hãy định cấu hình kết nối HTTP trong điểm cuối mục tiêu của proxy API để sử dụng Máy chủ mục tiêu.

Mỗi môi trường có giới hạn là 500 máy chủ mục tiêu, như nêu trong chủ đề Giới hạn.

Định cấu hình TargetEndpoint để tải số dư trên các Máy chủ đích được đặt tên

Bây giờ, khi đã có hai Máy chủ mục tiêu, bạn có thể sửa đổi chế độ cài đặt kết nối HTTP TargetEndpoint để tham chiếu đến hai Máy chủ đích đó theo tên:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
    <LoadBalancer>
      <Server name="target1" />
      <Server name="target2" />
    </LoadBalancer>
    <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

Cấu hình ở trên là cấu hình cân bằng tải cơ bản nhất có thể. Trình cân bằng tải hỗ trợ ba thuật toán cân bằng tải là Round Robin, Weight và Least Connection. Round Robin là thuật toán mặc định. Vì không có thuật toán nào được chỉ định trong cấu hình ở trên, nên các yêu cầu đi từ proxy API đến các máy chủ phụ trợ sẽ lần lượt thay thế, giữa các mục tiêu 1 và 2.

Phần tử <Path> tạo thành đường dẫn cơ sở của URI TargetEndpoint cho tất cả máy chủ đích. Giá trị này chỉ được dùng khi sử dụng <LoadBalancer>. Nếu không, hàm này sẽ bị bỏ qua. Trong ví dụ trên, yêu cầu đạt đến "target1" sẽ là http://target1/test và tương tự như vậy đối với các máy chủ mục tiêu khác.

Đặt tùy chọn trình cân bằng tải

Bạn có thể điều chỉnh tình trạng sẵn có bằng cách sử dụng các tuỳ chọn cân bằng tải và chuyển đổi dự phòng ở cấp độ trình cân bằng tải và cấp TargetServer. Phần này mô tả các tùy chọn này.

Thuật toán

Đặt thuật toán mà <LoadBalancer> sử dụng. Các thuật toán hiện có là RoundRobin, Weighted và LeastConnections được liệt kê dưới đây.

Thi đấu vòng tròn

Thuật toán mặc định, vòng tròn, chuyển tiếp một yêu cầu đến từng TargetServer theo thứ tự liệt kê các máy chủ trong kết nối HTTP của điểm cuối mục tiêu. Ví dụ:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

Trọng số

Thuật toán cân bằng tải có trọng số cho phép bạn định cấu hình tải lưu lượng truy cập tương ứng cho các Máy chủ mục tiêu của bạn. Loadbalancer có trọng số phân phối yêu cầu đến TargetServers theo tỷ lệ trực tiếp với trọng số của mỗi TargetServer. Do đó, thuật toán trọng số yêu cầu bạn phải đặt một thuộc tính weight cho mỗi TargetServer. Ví dụ:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
    <LoadBalancer>
      <Algorithm>Weighted</Algorithm>
      <Server name="target1">
        <Weight>1</Weight>
      </Server>
      <Server name="target2">
        <Weight>2</Weight>
      </Server>
    </LoadBalancer>
    <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

Trong ví dụ này, hai yêu cầu sẽ được chuyển đến target2 cho mỗi yêu cầu được chuyển đến target1.

Ít kết nối nhất

Loadbalancers được định cấu hình để sử dụng thuật toán kết nối ít nhất định tuyến các yêu cầu gửi đi tới TargetServer có ít kết nối HTTP mở nhất. Ví dụ:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>LeastConnections</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
      </LoadBalancer>
  </HTTPTargetConnection>
  <Path>/test</Path>
</TargetEndpoint>

Số lỗi tối đa

Số lượng tối đa các yêu cầu không thành công từ proxy API đến TargetServer dẫn đến yêu cầu được chuyển hướng đến một máy chủ đích khác.

Lỗi phản hồi có nghĩa là Apigee không nhận được bất kỳ phản hồi nào từ máy chủ đích. Khi điều này xảy ra, bộ đếm lỗi sẽ tăng thêm một.

Tuy nhiên, khi Apigee nhận được phản hồi từ một mục tiêu, ngay cả khi phản hồi đó là lỗi HTTP (chẳng hạn như 500), phản hồi đó sẽ được tính là một phản hồi từ máy chủ mục tiêu và bộ đếm lỗi được đặt lại. Để đảm bảo rằng các phản hồi HTTP không hợp lệ (chẳng hạn như 500) cũng làm tăng bộ đếm lỗi để đưa máy chủ hoạt động không ổn định ra khỏi tính năng cân bằng tải ngay khi có thể, bạn có thể thêm phần tử <ServerUnhealthyResponse> có các phần tử con <ResponseCode> vào cấu hình trình cân bằng tải. Edge cũng sẽ đếm phản hồi có các mã đó là không thành công.

Trong ví dụ sau, target1 sẽ bị xoá khỏi xoay vòng sau năm yêu cầu không thành công, bao gồm một số phản hồi 5XX từ máy chủ đích.

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <MaxFailures>5</MaxFailures>
        <ServerUnhealthyResponse>
            <ResponseCode>500</ResponseCode>
            <ResponseCode>502</ResponseCode>
            <ResponseCode>503</ResponseCode>
        </ServerUnhealthyResponse>
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

Giá trị mặc định của MaxFailures là 0. Điều này có nghĩa là Edge luôn cố gắng kết nối với mục tiêu cho từng yêu cầu và không bao giờ xoá máy chủ đích khỏi chế độ xoay.

Tốt nhất là bạn nên sử dụng MaxFailures > 0 với HealthMonitor. Nếu bạn định cấu hình MaxFailures > 0, TargetServer sẽ bị xoá khỏi chế độ xoay khi mục tiêu không đạt được số lần bạn chỉ định. Khi đã có HealthMonitor, Apigee sẽ tự động đặt TargetServer quay lại sau khi mục tiêu được thiết lập và chạy lại, theo cấu hình của HealthMonitor đó. Hãy xem phần Theo dõi sức khỏe để biết thêm thông tin.

Ngoài ra, nếu bạn định cấu hình MaxFailures > 0 và không định cấu hình HealthMonitor, thì Apigee sẽ không tự động bao gồm lại TargetServer vào chế độ xoay vòng sau khi Apigee phát hiện lỗi. Trong trường hợp này, bạn phải triển khai lại proxy API trước khi Apigee đặt TargetServer quay lại. Xem phần Triển khai proxy API.

Thử lại

Nếu bạn bật lại tính năng thử lại, một yêu cầu sẽ được thử lại mỗi khi xảy ra lỗi phản hồi (lỗi I/O hoặc thời gian chờ HTTP) hoặc phản hồi nhận được khớp với giá trị do <ServerUnhealthyResponse> đặt. Hãy xem phần Số lỗi tối đa ở trên để biết thêm thông tin về cách đặt <ServerUnhealthyResponse>.

Theo mặc định, <RetryEnabled> được đặt thành true. Hãy đặt thành false để tắt tính năng thử lại. Ví dụ:

<RetryEnabled>false</RetryEnabled>

Dự phòng

Một (và chỉ một) TargetServer có thể được đặt làm máy chủ 'dự phòng'. TargetServer dự phòng không được đưa vào quy trình cân bằng tải cho đến khi trình cân bằng tải xác định rằng tất cả các Server khác đều không dùng được. Khi trình cân bằng tải xác định rằng không có máy chủ đích, thì tất cả lưu lượng truy cập đều được định tuyến đến máy chủ dự phòng. Ví dụ:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <Server name="target3">
          <IsFallback>true</IsFallback>
        </Server>
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

Cấu hình ở trên dẫn đến việc cân bằng tải vòng tròn giữa mục tiêu 1 và 2 cho đến khi cả hai mục tiêu 1 và 2 không có sẵn. Khi mục tiêu 1 và 2 không có sẵn, tất cả lưu lượng truy cập đều được định tuyến đến mục tiêu 3.

Đường dẫn

Đường dẫn xác định một phân đoạn URI sẽ được thêm vào tất cả yêu cầu do TargetServer đưa ra cho máy chủ phụ trợ.

Phần tử này chấp nhận một đường dẫn chuỗi bằng chữ hoặc mẫu thông báo. Mẫu thông báo cho phép bạn thay thế chuỗi biến trong thời gian chạy. Ví dụ: trong định nghĩa điểm cuối mục tiêu sau, giá trị của {mypath} được dùng cho đường dẫn:

<HTTPTargetConnection>
    <SSLInfo>
      <Enabled>true</Enabled>
    </SSLInfo>
    <LoadBalancer>
      <Server name="testserver"/>
    </LoadBalancer>
    <Path>{mypath}</Path>
</HTTPTargetConnection>

Định cấu hình máy chủ đích cho TLS/SSL

Nếu bạn đang sử dụng TargetServer để xác định dịch vụ phụ trợ và dịch vụ phụ trợ cần có kết nối để sử dụng giao thức HTTPS, thì bạn phải bật TLS/SSL trong định nghĩa TargetServer. Điều này là cần thiết vì thẻ <Host> không cho phép bạn chỉ định giao thức kết nối. Bên dưới là định nghĩa TargetServer cho TLS/SSL một chiều trong đó Edge thực hiện các yêu cầu HTTPS đối với dịch vụ phụ trợ:

<TargetServer name="target1">
  <Host>mocktarget.apigee.net</Host>
  <Port>443</Port>
  <IsEnabled>true</IsEnabled>
  <SSLInfo>
      <Enabled>true</Enabled>
  </SSLInfo> 
</TargetServer>

Nếu dịch vụ phụ trợ yêu cầu TLS/SSL hai chiều hoặc tương hỗ, thì bạn phải định cấu hình Máy chủ đích bằng cách sử dụng cùng chế độ cài đặt cấu hình TLS/SSL như TargetEndpoints:

<TargetServer  name="TargetServer 1">
    <IsEnabled>true</IsEnabled>
    <Host>www.example.com</Host>
    <Port>443</Port>
    <SSLInfo>
        <Ciphers/>
        <ClientAuthEnabled>true</ClientAuthEnabled>
        <Enabled>true</Enabled>
        <IgnoreValidationErrors>false</IgnoreValidationErrors>
        <KeyAlias>keystore-alias</KeyAlias>
        <KeyStore>keystore-name</KeyStore>
        <Protocols/>
        <TrustStore>truststore-name</TrustStore>
    </SSLInfo>
</TargetServer >

Để biết thông tin về các thuộc tính <SSLInfo>, chẳng hạn như <Ciphers> và <ClientAuthEnabled>, hãy xem thông tin về cách đặt các thuộc tính đó cho Máy chủ ảo trong phần Định cấu hình quyền truy cập của TLS vào API cho Đám mây riêng.

Để biết hướng dẫn đầy đủ về cách định cấu hình TLS/SSL đi, hãy xem Định cấu hình TLS từ Edge cho phần phụ trợ (Cloud và Private Cloud).

Giản đồ TargetServer

Xem giản đồ cho TargetServer và các thực thể khác trên GitHub.

Theo dõi sức khỏe

Tính năng theo dõi tình trạng cho phép bạn cải thiện cấu hình cân bằng tải bằng cách chủ động thăm dò các URL dịch vụ phụ trợ được xác định trong cấu hình TargetServer. Khi bạn bật tính năng giám sát tình trạng hoạt động, một TargetServer bị lỗi sẽ tự động được khôi phục khi HealthMonitor xác định rằng TargetServer đang hoạt động.

Tính năng giám sát sức khỏe hoạt động với <MaxFailures>. Nếu bạn không bật tính năng giám sát tình trạng, <MaxFailures> sẽ chỉ định số lượng yêu cầu không thành công từ proxy API tới TargetServer dẫn đến yêu cầu được chuyển hướng đến một Máy chủ mục tiêu khác. Sau đó, TargetServer bị lỗi sẽ được đưa ra khỏi quá trình xoay cho đến khi bạn triển khai lại proxy.

Khi bật tính năng giám sát tình trạng, TargetServer bị lỗi sẽ tự động được khôi phục và không cần triển khai lại proxy.

HealthMonitor hoạt động như một ứng dụng khách đơn giản gọi một dịch vụ phụ trợ qua TCP hoặc HTTP:

• Ứng dụng khách TCP chỉ đảm bảo rằng có thể mở ổ cắm.
• Bạn định cấu hình ứng dụng HTTP để gửi yêu cầu HTTP hợp lệ đến dịch vụ phụ trợ. Bạn có thể xác định các thao tác HTTP GET, PUT, POST hoặc DELETE. Phản hồi của lệnh gọi màn hình HTTP phải khớp với chế độ cài đặt đã định cấu hình trong khối <SuccessResponse>.

Thành công và thất bại

Khi bạn bật tính năng theo dõi tình trạng sức khỏe, Edge sẽ bắt đầu gửi tính năng kiểm tra tình trạng đến máy chủ đích của bạn. Kiểm tra tình trạng là một yêu cầu được gửi đến máy chủ đích để xác định xem máy chủ đích có hoạt động hay không.

Kiểm tra tình trạng có thể có một trong hai kết quả sau:

• Success (Thành công): Máy chủ đích được coi là hoạt động tốt khi kiểm tra tình trạng thành công. Nguyên nhân thường là do một hoặc nhiều nguyên nhân sau đây:
  • Máy chủ đích chấp nhận kết nối mới với cổng được chỉ định, phản hồi yêu cầu trên cổng đó rồi đóng cổng trong khung thời gian đã chỉ định. Phản hồi từ máy chủ đích có thông báo “Connection: close” (Kết nối: đóng)
  • Máy chủ đích phản hồi yêu cầu kiểm tra tình trạng bằng mã trạng thái HTTP 200 (OK) hoặc mã trạng thái HTTP khác mà bạn xác định là có thể chấp nhận được.
  • Máy chủ đích phản hồi một yêu cầu kiểm tra tình trạng có phần nội dung thư khớp với nội dung thư mong đợi.

  Khi xác định rằng một máy chủ hoạt động tốt, Edge sẽ tiếp tục hoặc tiếp tục gửi yêu cầu đến máy chủ đó.

• Không đạt: Máy chủ mục tiêu có thể không vượt qua được quy trình kiểm tra tình trạng theo nhiều cách, tuỳ thuộc vào loại kiểm tra. Hệ thống có thể ghi lại lỗi khi máy chủ đích:
  • Từ chối kết nối từ Edge tới cổng kiểm tra tình trạng.
  • Không trả lời yêu cầu kiểm tra tình trạng trong một khoảng thời gian nhất định.
  • Trả về mã trạng thái HTTP không mong muốn.
  • Trả lời bằng nội dung tin nhắn không khớp với nội dung tin nhắn mong muốn.

  Khi máy chủ đích không kiểm tra được tình trạng, Edge sẽ gia tăng số lỗi của máy chủ đó. Nếu số lượng lỗi của máy chủ đó đạt hoặc vượt quá ngưỡng xác định trước (<MaxFailures>), thì Edge sẽ ngừng gửi yêu cầu đến máy chủ đó.

Bật HealthMonitor

Để tạo HealthMonitor, bạn thêm phần tử <HealthMonitor> vào cấu hình HTTPConnection của TargetEndpoint. Bạn không thể thực hiện việc này trong giao diện người dùng. Thay vào đó, bạn sẽ tạo một cấu hình proxy và tải tệp này lên Edge làm tệp ZIP. Cấu hình proxy là nội dung mô tả có cấu trúc về tất cả các khía cạnh của proxy API. Cấu hình proxy bao gồm các tệp XML trong cấu trúc thư mục được xác định trước. Để biết thêm thông tin, hãy xem phần Tài liệu tham khảo về cấu hình proxy API.

HealthMonitor đơn giản xác định IntervalInSec kết hợp với TCPMonitor hoặc HTTPMonitor. Phần tử <MaxFailures> chỉ định số lượng tối đa các yêu cầu không thành công từ proxy API đến TargetServer dẫn đến yêu cầu được chuyển hướng đến một máy chủ đích khác. Theo mặc định, <MaxFailures> là 0, có nghĩa là Edge sẽ không thực hiện hành động khắc phục nào. Khi định cấu hình trình theo dõi tình trạng, hãy đảm bảo rằng bạn thiết lập <MaxFailures> trong thẻ <HTTPTargetConnection> của thẻ <TargetEndpoint> thành giá trị khác 0.

TCPMonitor

Cấu hình bên dưới xác định HealthMonitor sẽ thăm dò ý kiến mỗi TargetServer bằng cách mở kết nối trên cổng 80 mỗi năm giây. (Cổng là tùy chọn. Nếu không được chỉ định, cổng TCPMonitor là cổng TargetServer.)

• Nếu kết nối không thành công hoặc mất hơn 10 giây để kết nối, thì số lỗi sẽ tăng 1 cho TargetServer.
• Nếu kết nối thành công thì số lần lỗi cho TargetServer được đặt lại về 0.

Bạn có thể thêm HealthMonitor dưới dạng phần tử con của phần tử HTTPTargetConnetion của TargetEndpoint, như được hiển thị bên dưới:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <MaxFailures>5</MaxFailures>
      </LoadBalancer>
      <Path>/test</Path>
      <HealthMonitor>
        <IsEnabled>true</IsEnabled>
        <IntervalInSec>5</IntervalInSec>
        <TCPMonitor>
            <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
            <Port>80</Port>
        </TCPMonitor>
      </HealthMonitor>
  </HTTPTargetConnection>
. . .

HealthMonitor với các phần tử cấu hình TCPMonitor

Bảng sau đây mô tả các phần tử cấu hình TCPMonitor:

Tên	Mô tả	Mặc định	Bắt buộc?
IsEnabled	Giá trị boolean bật hoặc tắt HealthMonitor.	sai	Không
IntervalInSec	Khoảng thời gian, tính bằng giây, giữa mỗi yêu cầu TCP thăm dò ý kiến.	0	Có
ConnectTimeoutInSec	Thời gian cần thiết lập kết nối với cổng TCP để được coi là thành công. Không kết nối được trong khoảng thời gian được chỉ định là lỗi, làm tăng số lượng sự cố của trình cân bằng tải cho TargetServer.	0	Có
Port	Không bắt buộc. Cổng nơi kết nối TCP sẽ được thiết lập. Nếu không được chỉ định, cổng TCPMonitor sẽ là cổng TargetServer.	0	Không

Giám sát HTTP

Một HealthMonitor mẫu sử dụng HTTPMonitor sẽ gửi yêu cầu GET tới dịch vụ phụ trợ 5 giây một lần. Mẫu dưới đây sẽ thêm tiêu đề Uỷ quyền cơ bản HTTP vào thông báo yêu cầu. Cấu hình phản hồi xác định các chế độ cài đặt sẽ được so sánh với phản hồi thực tế từ dịch vụ phụ trợ. Trong ví dụ bên dưới, phản hồi dự kiến là một mã phản hồi HTTP 200 và một tiêu đề HTTP tùy chỉnh ImOK có giá trị là YourOK. Nếu phản hồi không khớp, thì cấu hình trình cân bằng tải sẽ coi yêu cầu là lỗi.

HTTPMonitor hỗ trợ các dịch vụ phụ trợ được định cấu hình để sử dụng giao thức HTTP và HTTPS một chiều. Tuy nhiên, tính năng này không hỗ trợ:

• HTTPS hai chiều (còn được gọi là TLS/SSL hai chiều)
• Chứng chỉ tự ký.

Lưu ý rằng mọi chế độ cài đặt Request and Response (Yêu cầu và phản hồi) trong màn hình HTTP sẽ dành riêng cho dịch vụ phụ trợ mà sẽ được gọi.

    <HealthMonitor>
      <IsEnabled>true</IsEnabled>
      <IntervalInSec>5</IntervalInSec>
      <HTTPMonitor>
        <Request>
          <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
          <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
          <Port>80</Port>
          <Verb>GET</Verb>
          <Path>/healthcheck</Path>
          <Header name="Authorization">Basic 12e98yfw87etf</Header>
          <IncludeHealthCheckIdHeader>true</IncludeHealthCheckIdHeader>
        </Request>
        <SuccessResponse>
          <ResponseCode>200</ResponseCode>
          <Header name="ImOK">YourOK</Header>
        </SuccessResponse>
      </HTTPMonitor>
    </HealthMonitor>
    

HealthMonitor với các phần tử cấu hình HTTPMonitor

Bảng sau đây mô tả các phần tử cấu hình HTTPMonitor:

Tên	Mô tả	Mặc định	Bắt buộc?
IsEnabled	Giá trị boolean bật hoặc tắt HealthMonitor.	sai	Không
IntervalInSec	Khoảng thời gian, tính bằng giây, giữa mỗi yêu cầu thăm dò ý kiến.	0	Có
Request	Các tuỳ chọn cấu hình cho thông báo yêu cầu gửi đi do HealthMonitor gửi tới TargetServers trong chế độ xoay. Đường dẫn không hỗ trợ biến.	Không áp dụng	Có
ConnectTimeoutInSec	Thời gian tính bằng giây, trong đó sự kết nối kết nối TCP với dịch vụ HTTP phải hoàn tất để được coi là thành công. Việc không kết nối được trong khoảng thời gian đã chỉ định được tính là lỗi, làm tăng số lượng sự cố của Loadbalancer cho TargetServer.	0	Không
SocketReadTimeoutInSec	Thời gian, tính bằng giây, trong đó dữ liệu phải được đọc từ dịch vụ HTTP để được coi là thành công. Việc không đọc trong khoảng thời gian được chỉ định được tính là không thành công, làm tăng số lượng lỗi của Loadbalancer cho TargetServer.	0	Không
Port	Cổng nơi kết nối HTTP với dịch vụ phụ trợ sẽ được thiết lập.	Không áp dụng	Không
Verb	Động từ HTTP được sử dụng cho mỗi yêu cầu HTTP thăm dò ý kiến về dịch vụ phụ trợ .	Không áp dụng	Không
Path	Đường dẫn được nối vào URL được xác định trong TargetServer. Sử dụng phần tử đường dẫn để định cấu hình một "điểm cuối thăm dò ý kiến" trên dịch vụ HTTP.	Không áp dụng	Không
IncludeHealthCheckIdHeader	Cho phép bạn theo dõi các yêu cầu kiểm tra tình trạng trên hệ thống tải lên. IncludeHealthCheckIdHeader nhận giá trị Boolean và mặc định là false. Nếu bạn đặt giá trị này là true, thì Header có tên là X-Apigee-Healthcheck-Id sẽ được đưa vào yêu cầu kiểm tra tình trạng. Giá trị của tiêu đề được chỉ định động và có dạng ORG/ENV/SERVER_UUID/N, trong đó ORG là tên tổ chức, ENV là tên môi trường, SERVER_UUID là mã nhận dạng duy nhất xác định MP và N là số mili giây đã trôi qua kể từ ngày 1 tháng 1 năm 1970. Ví dụ về tiêu đề yêu cầu kết quả: X-Apigee-Healthcheck-Id: orgname/envname/E8C4D2EE-3A69-428A-8616-030ABDE864E0/1586802968123	sai	Không
Payload	Phần nội dung HTTP được tạo cho mỗi yêu cầu HTTP bỏ phiếu. Xin lưu ý rằng phần tử này không bắt buộc đối với các yêu cầu GET.	Không áp dụng	Không
SuccessResponse	Các tuỳ chọn so khớp cho thông báo phản hồi HTTP đến do dịch vụ phụ trợ được thăm dò ý kiến tạo ra. Số phản hồi không khớp sẽ làm tăng số lỗi 1.	Không áp dụng	Không
ResponseCode	Mã phản hồi HTTP dự kiến sẽ nhận được từ TargetServer được thăm dò ý kiến. Một mã khác với mã chỉ định sẽ dẫn đến lỗi và số lượng sẽ tăng lên đối với dịch vụ phụ trợ được thăm dò ý kiến. Bạn có thể xác định nhiều phần tử mã phản hồi.	Không áp dụng	Không
Headers	Danh sách một hoặc nhiều tiêu đề HTTP và giá trị dự kiến sẽ nhận được từ dịch vụ phụ trợ được thăm dò ý kiến. Mọi tiêu đề HTTP hoặc giá trị trên phản hồi khác với các tiêu đề hoặc giá trị được chỉ định sẽ dẫn đến lỗi và số lượng của TargetServer được thăm dò ý kiến sẽ tăng thêm 1. Bạn có thể xác định nhiều phần tử Tiêu đề.	Không áp dụng	Không