Blog này là một phần của loạt bài mà chúng tôi thảo luận về 101 khái niệm từ Ground Zero dành cho khán giả có kiến ​​thức ban đầu hạn chế. Bài viết này nằm trong Loạt bài Cấp độ Trung cấp vì nó liên quan đến việc hiểu về Mẫu đại sứ - được sử dụng chủ yếu như một dịch vụ proxy độc lập chạy cùng vị trí với ứng dụng doanh nghiệp / ứng dụng khách.

Một số blog trước đó trong Series 101 như sau:

Giao tiếp không đồng bộ API 101 Cơ sở dữ liệu 101 Thiết kế cơ sở dữ liệu 101 Chiến lược triển khai 101

Ambassador Pattern là gì?

Ambassador là một trường hợp đặc biệt của mẫu xe hơi s Ide-car làm giảm tải các chức năng kết nối ứng dụng khách thông thường như giám sát, ghi nhật ký, định tuyến, bảo mật, khả năng phục hồi bằng cách sử dụng dịch vụ / vùng chứa đồng định vị chung (trong trường hợp triển khai dựa trên Kubernetes / Docker). Dịch vụ Ambassador hoạt động như một giải pháp proxy có thể sử dụng lại cho các dịch vụ kế thừa được viết bằng nhiều ngôn ngữ và khuôn khổ bằng cách cung cấp các tính năng L7 như thử lại HTTP, mẫu ngắt mạch, yêu cầu sửa đổi tiêu đề, v.v. Các bản phát hành và cơ sở hạ tầng của Ambassador có thể được phát hành và mở rộng quy mô độc lập với doanh nghiệp ứng dụng / vùng chứa, làm cho nó trở thành một lựa chọn phù hợp để đáp ứng các nhu cầu phi chức năng của Lĩnh vực kinh doanh.

Đại sứ với tư cách là một SideCar

Dòng trình tự

1. Vùng chứa ứng dụng gửi yêu cầu đến Dịch vụ B / Dịch vụ C từ xa thông qua Ambassador Proxy
2. Proxy SideCar thêm thông tin theo dõi vào các tiêu đề yêu cầu. Đồng thời mã hóa yêu cầu bằng cách thêm chứng chỉ cho TLS lẫn nhau . Ngoài ra, bắt đầu đo độ trễ yêu cầu.
3. Dịch vụ Từ xa B / Dịch vụ C nhận yêu cầu và xác thực các tiêu đề yêu cầu trước khi gửi lại thông báo phản hồi.
4. Xe phía Ambassador nhận lại phản hồi và ghi lại thời gian chờ yêu cầu.
5. Vùng chứa ứng dụng nhận lại phản hồi cuối cùng.

1. Khi các dịch vụ kế thừa được xây dựng bằng nhiều ngôn ngữ và thời gian phát triển cũng như chi phí để thêm các tính năng mạng / định tuyến cho mỗi máy khách cao đáng kể so với việc thêm vào một giải pháp dựa trên proxy thông thường.
2. Khi các mẫu kiến ​​trúc phi chức năng phổ biến như ngắt mạch c, thiết bị đo lường ứng dụng, giới hạn tốc độ có các chính sách độc lập với ứng dụng khách.
3. Ứng dụng có cơ sở dữ liệu / lớp nhắn tin phân đoạn và nhiều phiên bản / nút cơ sở hạ tầng đang chạy, do đó cần phải trừu tượng hóa cấu hình bằng cách sử dụng một thành phần chung.

Hạn chế

1. Các yêu cầu ứng dụng có yêu cầu về độ trễ quan trọng và chuyến đi khứ hồi cuối 2 chiều có thể bị ảnh hưởng bởi việc bổ sung proxy bên xe
2. Các ứng dụng có nhu cầu kết nối được tích hợp sâu với mã máy khách / ngôn ngữ và sự cô lập các yêu cầu thông qua proxy không thể mở rộng.

Chúng ta đã thảo luận những điều cơ bản về mẫu Ambassador, mẫu thiết kế phổ biến giúp hiện đại hóa các nhu cầu ứng dụng kế thừa mà không cần xây dựng giải pháp dựa trên lưới dịch vụ end-2-end tích hợp. Trong thế giới Kubernetes, proxy đại sứ có thể được triển khai bằng cách sử dụng dưới dạng tệp kê khai dịch vụ và được mở rộng cùng với các nhóm ứng dụng

Để có phản hồi, vui lòng gửi tin nhắn tới amit [dot] 894 [at] gmail [dot] com hoặc liên hệ với bất kỳ liên kết nào tại https://about.me/amit_raj .