Gì đứng trước hầu hết mỗi dịch vụ web
Chào mừng
Nếu bạn nhập example.com vào trình duyệt, bạn hầu như không đến được máy tính thực sự chạy ứng dụng. Bạn đến một máy tính mà chuyển tiếp yêu cầu đến một cái khác thực sự. Máy chuyển tiếp này mang một tên: một trung gian ngược lại.
Bài học này sẽ dạy bạn trung gian ngược lại làm gì, tại sao hầu hết mỗi dịch vụ web công khai đều che giấu sau một cái gì đó và ba công việc mà lớp cạnh xử lý cùng một lúc.
Sau khi học xong bạn sẽ hiểu:
- Khác nhau giữa một khách hàng, một trung gian và một nguồn gốc
- Tại sao một trung gian đứng trước nguồn gốc giúp bảo vệ, mở rộng và cho phép bạn thay thế các phần mà không ai nhận biết
- Ba công việc mà trung gian ngược lại xử lý cùng một lúc: che giấu nguồn gốc, kết thúc TLS và phân phối tải trên các bản sao
- Cách một yêu cầu di chuyển từ trình duyệt đến proxy đến upstream và trở lại, bước một bước
Sau khi học xong bạn sẽ lý giải tự tin về vị trí đặt proxy, sự phân tách trách nhiệm ở cạnh và tại sao một lớp proxy không trạng thái nhân lên nhiều lần trong khi một nguồn gốc đơn lẻ không.
Trung gian tiến và trung gian ngược lại
Hướng của hai loại proxy
Hai loại proxy này đều đứng giữa hai bên và truyền thông tin. Chúng khác nhau về bên họ đại diện.
Trung gian tiến: đứng trước một nhóm khách hàng. Các khách hàng biết về một proxy; một máy chủ bên ngoài thấy địa chỉ proxy, không thấy địa chỉ khách hàng. Các proxy ra ngoài, lọc nội dung và SOCKS proxy phù hợp với mô hình này.
Trung gian ngược lại: đứng trước một nhóm máy chủ. Thế giới bên ngoài (khách hàng) giao tiếp với một địa chỉ proxy; khách hàng không biết một máy chủ thực tế đang ẩn sau nó. Hầu hết mỗi dịch vụ web công khai sử dụng loại này.
Nhớ: một trung gian tiến che giấu khách hàng khỏi máy chủ. Một trung gian ngược lại che giấu máy chủ khỏi khách hàng.
Tại sao quan tâm về hướng? Công việc, lỗi và ranh giới an ninh khác nhau. Một khách hàng gửi thông tin qua cả hai loại cùng một lúc: client -> forward_proxy -> internet -> reverse_proxy -> origin.
A client sending traffic through both kinds at once travels: client -> forward_proxy -> internet -> reverse_proxy -> origin.
Tại Sao Nhiều Dòng Tại Bờ
Lớp Bờ Lấy Lại Lợi Ích
Một proxy đảo ngược làm ba công việc cùng một lúc. Mỗi công việc riêng cũng hợp lý hóa lớp; nhưng khi tất cả ba công việc cùng ở một địa chỉ giải thích tại sao gần như mọi kiến trúc web sản xuất đều có hình dạng giống nhau ở phía trước.
Công Việc 1: Giấu nguồn gốc. Proxy trả lời trên một IP công khai. Backends nằm trên IP riêng không thể truy cập từ internet. Một kẻ tấn công muốn đánh vào nguồn gốc phải đầu tiên đánh sập proxy.
Công Việc 2: Kết thúc TLS. Proxy giữ chứng chỉ cho example.com và giải mã các yêu cầu HTTPS đến. Backends sử dụng HTTP đơn giản (hoặc TLS nội bộ dễ dàng) với proxy trên một đoạn mạng đáng tin cậy. Chính sách đổi chứng chỉ, gia hạn và mã vigenère đều nằm trong một chỗ.
Công Việc 3: Phân phối tải. Proxy chọn backend xử lý mỗi yêu cầu. Backends nằm sau một proxy tạo thành một bể; proxy chọn một backend mỗi yêu cầu sử dụng một chiến lược (vòng lặp, ít kết nối, hash trên một tiêu đề). Thêm dung lượng chỉ cần thêm một backend vào bể, không cần thông báo cho mỗi client một địa chỉ mới.
Mỗi công việc là một chương trình nhỏ. Nhóm họ giải thích tại sao một tầng đơn giản như 'Caddy trước một ứng dụng Python' mang nhiều trọng lượng thiết kế hơn chính ứng dụng Python.
Thiết Kế Cho Tất Cả Ba
Đội của bạn chạy một API nhỏ trên một quá trình Python lắng nghe trên cổng 8000 trên một VM duy nhất. Traffic đã lớn đến mức một VM không thể tiếp tục và một đánh giá an ninh đã chỉ ra rằng VM có một IP công khai và giữ chứng chỉ TLS của chính mình.
Bạn quyết định đặt một proxy đảo ngược trước. Vẽ bố cục: địa chỉ DNS đi về đâu, chứng chỉ ở đâu, load đến backends như thế nào và cái gốc VM thay đổi gì?
Thay Đổi Một Nguyên Tố mà Không Ai Nhận Biết
Giống như Một Lớp Bất Ngờ
Một câu nói cổ điển trong ngành khoa học máy tính: mỗi vấn đề đều có thể giải quyết bằng cách thêm một lớp indirection (trừ vấn đề có quá nhiều lớp indirection). Reverse proxy là một trong những indirection hữu ích nhất trong các hệ thống phân tán.
Bạn được gì:
- Backend thay thế được. Chuyển ứng dụng từ Python sang Go? Di chuyển từ một trung tâm dữ liệu khác? Ra mắt một phiên bản với downtime không? Mỗi một điều xảy ra phía sau một địa chỉ công khai ổn định. Không có gì thay đổi cho người dùng.
- Tăng trưởng độc lập. Tầng proxy tăng trưởng dựa trên băng thông và CPU ở lớp TLS. Tầng backend tăng trưởng dựa trên công việc ứng dụng. Mỗi bên phát triển trên trục khác nhau vì chúng sống trên các máy khác nhau.
- Tồn chứa lỗi. Một bản triển khai xấu trên backend không làm tắt địa chỉ công khai. Proxy vẫn hoạt động; bạn đưa ra sửa chữa hoặc lùi lại; thế giới kết nối lại khi backend hồi phục.
- Các vấn đề xuyên suốt trong một nơi. Giới hạn tốc độ, chặn địa lý, ghi nhật ký yêu cầu, viết lại tiêu đề, caching, nén phản hồi: tất cả sống trên proxy. Mã backend tập trung vào ứng dụng.
Không có proxy mỗi một trong những vấn đề này phải sống bên trong quá trình ứng dụng. Với proxy chúng sống ở một lớp mà một đội ngũ sở hữu.
Chi phí: một lớp khác để vận hành. Các đội ngũ trưởng thành chấp nhận chi phí vì tầng proxy itself chạy stateless và tăng trưởng dọc theo chiều ngang; thay thế một proxy với hai không cần sự hợp tác.
Một Crossover Blue/Green qua Proxy
Đội của bạn chạy phiên bản 1 của API trên ba VM backend (bể blue) phía sau một reverse proxy. Bạn muốn triển khai phiên bản 2 với khả năng lùi lại trong dưới ba mươi giây nếu có điều gì sai sót.
Bạn khởi động ba VM backend mới (bể green) chạy phiên bản 2, song song với bể blue, nhưng bạn chưa định tuyến bất kỳ lưu lượng nào đến chúng.
Từ Browser đến Backend & Lại Qua
Theo Một Yêu Cầu HTTPS Từ Đầu Đến Cuối
Ghi lại một yêu cầu HTTPS GET đơn giản https://api.example.com/users/42 qua một reverse proxy trước một nhóm backend.
Hop 1: Giải quyết DNS. Browser hỏi một giải pháp DNS cho api.example.com. Giải pháp DNS trả lại địa chỉ IP công khai của proxy (ví dụ 203.0.113.10). Browser mở một kết nối TCP đến 203.0.113.10:443.
Hop 2: Tiến hành TLS. Proxy trình bày chứng chỉ của nó cho api.example.com. Browser xác minh chứng chỉ, hai bên đồng ý về một chìa khóa phiên và kênh mã hóa mở.
Hop 3: Yêu cầu HTTP trong TLS. Browser gửi GET /users/42 HTTP/1.1\nHost: api.example.com\n.... Proxy giải mã các byte yêu cầu.
Hop 4: Lựa chọn backend. Proxy tham khảo nhóm upstream của nó cho api.example.com và chọn một backend (ví dụ 10.0.0.21:8000) sử dụng chiến lược cân bằng tải của nó.
Hop 5: Yêu cầu upstream. Proxy mở (hoặc tái sử dụng) một kết nối HTTP đơn giản đến 10.0.0.21:8000 và chuyển yêu cầu. Proxy có thể viết lại các tiêu đề dọc theo đường: thêm X-Forwarded-For: <client-ip>, đặt Host: đúng, xóa tiêu đề nhảy như Connection.
Hop 6: Xử lý backend. Ứng dụng backend đọc yêu cầu, truy vấn cơ sở dữ liệu, tạo một phản hồi JSON.
Hop 7: Phản hồi upstream. Backend gửi phản hồi trở lại proxy dưới dạng HTTP đơn giản.
Hop 8: Phản hồi cạnh. Proxy có thể viết lại hoặc nén phản hồi, mã hóa lại thông qua phiên TLS và gửi nó trở lại cho browser.
Hop 9: Cuộc sống của kết nối. Kênh TLS thường giữ mở cho yêu cầu tiếp theo (HTTP/2 đa luồng nhiều yêu cầu trên một kết nối). Kết nối proxy-to-backend thường pooling để tái sử dụng.
Mỗi dịch vụ web công khai tuân theo một biến thể của hình dạng này. Biết các bước giúp bạn lý luận về nơi latency tích lũy, nơi logging thuộc về và nơi một lỗi có thể ẩn.
Đâu Là Thời Gian?
Một người dùng phàn nàn API cảm thấy chậm. Bạn đo và tìm ra yêu cầu mất 850 ms từ đầu đến cuối. Server logs trên backend cho thấy ứng dụng đã xử lý yêu cầu trong 40 ms. Proxy logs cho thấy proxy đã tốn 50 ms cho công việc của mình (TLS handshake + routing + response writing).
Thiết kế Minimal Edge cho một Dịch vụ Mới
Tổng hợp
Bạn đã học được sự khác biệt giữa một forward & reverse proxy, ba công việc mà một reverse proxy xử lý cùng lúc, lý do vì sao che giấu nguồn gốc mang lại lợi ích mỗi khi bạn cần thay đổi điều gì đó, & cách một yêu cầu lưu chuyển qua các nút hop trong Edge.
Bây giờ áp dụng.
Một đội ngũ nhỏ lên kế hoạch tung ra một dịch vụ mới gọi là notes.example.com. Người dùng sẽ đọc & viết các ghi chú cá nhân. Đội ngũ này sẽ chạy hai máy chủ backend từ lúc ra mắt & dự kiến sẽ mở rộng lên mười trong một năm. Họ muốn HTTPS cho người dùng, triển khai từng bước cho các phiên bản mới & không tiết lộ công khai địa chỉ IPs backend.
Đường này Dịch Vụ Tiếp Theo
Đường này Dịch Vụ Tiếp Theo
Bài học này đã thiết lập được hình dạng của lớp Edge. Ba bài học tiếp theo trong khóa học này dựa trên nó:
- Tích lũy Hướng dọc Không Stateful: lý do vì sao một tier proxy (& các backend phía sau nó) nhân lên rẻ tiền, & công thức tính kích cỡ các bản sao trong thời gian bùng nổ.
- Tách biệt Ingress / Egress: lý do vì sao một hộp proxy đơn lẻ xử lý cả lưu lượng truy cập vào & ra cuối cùng sẽ gặp vấn đề bất ngờ, & cách chia tách các lớp.
- Các chế độ lỗi & Tầm ảnh hưởng nổ: cách một thay đổi cấu hình lan truyền thành sự cố, & cách viết các mục hành động không đổ lỗi giúp ngăn ngừa tái diễn.
- Đo lường & Tính năng: gì cần đo lường ở cạnh để bạn biết điều gì bị hỏng trước khi người dùng nhận biết.
Mỗi bài học đều độc lập. Khi kết hợp chúng, bạn sẽ có một mô hình tư duy về một đội ngũ web quy mô lớn.
Bài học kèm theo: geometry_of_proxies_and_origins tái hiện tất cả các bài học trong bài này dưới dạng đồ thị hướng và khám phá những điều đồ thị hướng告诉你 về một con đường yêu cầu.
Chúc mừng. Tiếp tục.