Bạn đang xem tài liệu về Apigee Edge.
Truy cập vào
tài liệu Apigee X. thông tin
Cấu hình TargetEndpoint xác định cách Apigee Edge kết nối với một dịch vụ phụ trợ hoặc API. Nó gửi yêu cầu và nhận phản hồi đến/từ dịch vụ phụ trợ. Dịch vụ phụ trợ có thể là máy chủ HTTP/HTTPS, NodeJS hoặc Mục tiêu được lưu trữ.
Bạn có thể gọi dịch vụ phụ trợ trong TargetEndpoint theo một trong những cách sau:
- URL trực tiếp đến một máy chủ HTTP hoặc HTTPS
- ScriptTarget cho tập lệnh Node.js được lưu trữ trên Edge
- HostedTarget đến NodeJS được triển khai trên Môi trường đích được lưu trữ
- Cấu hình TargetServer
Tương tự, bạn có thể sử dụng chính sách Chú thích dịch vụ để gọi đến bất kỳ dịch vụ bên ngoài nào từ quy trình API Proxy. Chính sách này hỗ trợ việc xác định URL đích HTTP/HTTPS ngay trong chính sách hoặc bằng cách sử dụng cấu hình TargetServer.
Cấu hình TargetServer
Cấu hình TargetServer tách các URL điểm cuối cụ thể khỏi cấu hình TargetEndpoint hoặc trong chính sách Lệnh gọi dịch vụ. TargetServer được tham chiếu theo tên thay vì URL trong TargetEndpoint. Cấu hình TargetServer sẽ có tên máy chủ của dịch vụ phụ trợ, số cổng và các thông tin chi tiết khác.
Sau đây là một cấu hình TargetServer mẫu:
<TargetServer name="target1"> <Host>www.mybackendservice.com</Host> <Port>80</Port> <IsEnabled>true</IsEnabled> </TargetServer>
TargetServer cho phép bạn có các cấu hình khác nhau cho từng môi trường. Bạn có thể định cấu hình chính sách TargetEndpoint/Service Callout bằng một hoặc nhiều TargetServer được đặt tên bằng LoadBalancer. Tính năng hỗ trợ cân bằng tải được tích hợp sẵn giúp tăng cường khả năng cung cấp của các API và khả năng chuyển đổi dự phòng giữa các phiên bản máy chủ phụ trợ đã định cấu hình.
Sau đây là một cấu hình TargetEndpoint mẫu sử dụng TargetServers:
<TargetEndpoint name="default">
<HTTPTargetConnection>>
<LoadBalancer>
<Server name="target1"/>
<Server name="target2"/>
</LoadBalancer>
</HTTPTargetConnection>
</TargetEndpoint>MaxFailures
Cấu hình MaxFailures chỉ định số lượng tối đa các yêu cầu không thành công đến máy chủ đích. Sau đó, máy chủ đích sẽ được đánh dấu là không hoạt động và bị xoá khỏi quy trình luân phiên cho tất cả các yêu cầu tiếp theo.
Ví dụ về cấu hình có chỉ định MaxFailures:
<TargetEndpoint name="default">
<HTTPTargetConnection>
<LoadBalancer>
<Server name="target1"/>
<Server name="target2"/>
<MaxFailures>5</MaxFailures>
</LoadBalancer>
</HTTPTargetConnection>
</TargetEndpoint>Trong ví dụ trên, nếu 5 yêu cầu liên tiếp không thành công cho "target1" thì "target1" sẽ bị xoá khỏi vòng xoay và tất cả các yêu cầu tiếp theo sẽ chỉ được gửi đến target2.
Antipattern
Bạn không nên có một TargetServer trong cấu hình LoadBalancer của chính sách TargetEndpoint hoặc Service Callout với MaxFailures được đặt thành một giá trị khác 0 vì điều này có thể gây ra những tác động tiêu cực.
Hãy xem xét cấu hình mẫu sau đây có một TargetServer duy nhất có tên là "target1" với MaxFailures được đặt thành 5 (giá trị khác 0):
<TargetEndpoint name="default">
<HTTPTargetConnection>
<LoadBalancer>
<Algorithm>RoundRobin</Algorithm>
<Server name="target1" />
<MaxFailures>5</MaxFailures>
</LoadBalancer>
</HTTPTargetConnection>Nếu yêu cầu đến TargetServer "target1" không thành công 5 lần (số được chỉ định trong MaxFailures), TargetServer sẽ bị loại bỏ khỏi vòng luân phiên. Vì không có TargetServer nào khác để chuyển đổi dự phòng, nên tất cả các yêu cầu tiếp theo đối với API Proxy có cấu hình này sẽ không thành công với lỗi 503 Service Unavailable.
Ngay cả khi TargetServer "target1" trở lại trạng thái bình thường và có khả năng gửi phản hồi thành công, các yêu cầu đến API Proxy sẽ tiếp tục trả về lỗi 503. Điều này là do Edge không tự động đưa TargetServer trở lại vòng luân chuyển ngay cả sau khi đích đến hoạt động trở lại. Để giải quyết vấn đề này, bạn phải triển khai lại API Proxy cho Edge để đưa TargetServer trở lại vòng quay.
Nếu cùng một cấu hình được dùng trong chính sách Chú thích dịch vụ, thì các yêu cầu API sẽ gặp Lỗi 500 sau khi các yêu cầu đến TargetServer "target1" không thành công 5 lần.
Tác động
Việc sử dụng một TargetServer trong cấu hình LoadBalancer của chính sách TargetEndpoint hoặc Service Callout có MaxFailures được đặt thành một giá trị khác 0 sẽ gây ra:
- Các yêu cầu API liên tục không thành công với Lỗi 503/500 (sau khi các yêu cầu không thành công trong số lần MaxFailures) cho đến khi API Proxy được triển khai lại.
- Thời gian ngừng hoạt động lâu hơn vì vấn đề này khá phức tạp và có thể mất nhiều thời gian hơn để chẩn đoán nguyên nhân (nếu không có kiến thức trước về mẫu chống này).
Phương pháp hay nhất
- Có nhiều TargetServer trong cấu hình
LoadBalancerđể tăng khả năng đáp ứng. Luôn xác định Trình giám sát trạng thái khi
MaxFailuresđược đặt thành một giá trị khác 0. Một máy chủ đích sẽ bị loại khỏi nhóm khi số lần thất bại đạt đến số lượng được chỉ định trongMaxFailures. HealthMonitor đảm bảo rằng TargetServer được đưa trở lại vòng luân phiên ngay khi máy chủ mục tiêu hoạt động trở lại, tức là bạn không cần triển khai lại proxy.Để đảm bảo rằng quy trình kiểm tra tình trạng hoạt động được thực hiện trên cùng một số cổng mà Edge dùng để kết nối với các máy chủ đích, Apigee đề xuất bạn bỏ qua phần tử con
<Port>trong<TCPMonitor>, trừ phi phần tử này khác với cổng TargetServer. Theo mặc định,<Port>giống với cổng TargetServer.Cấu hình mẫu với HealthMonitor:
<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> </TCPMonitor> </HealthMonitor> </HTTPTargetConnection> </TargetEndpoint>Nếu có một số ràng buộc khiến chỉ có một TargetServer và nếu HealthMonitor không được dùng, thì đừng chỉ định
MaxFailurestrong cấu hìnhLoadBalancer.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ủ mục tiêu khỏi vòng luân phiên.