Hai Hướng Giao Tiếp, Một Khung
Chào mừng
Các biểu đồ kiến trúc thường hiển thị giao dịch đi một hướng: khách hàng ở trên, máy chủ ở dưới, mũi tên hướng xuống. Thực tế có giao dịch đi cả hai hướng.
Ingress: bên ngoài khách hàng đến với các dịch vụ của bạn thông qua con đường này. Một reverse proxy ở rìa của mạng của bạn kết thúc TLS, định tuyến yêu cầu và áp dụng chính sách truy cập.
Egress: các dịch vụ của bạn đến với các dịch vụ ngoài thông qua con đường này. Gọi một nhà xử lý thanh toán API, tải một webhook mục tiêu, gửi một yêu cầu đến một đối tác. Thường thông qua một forward proxy hoặc NAT gateway với một danh sách cho phép.
Nhiều kiến trúc bắt đầu với một khung xử lý cả hai. Nó hoạt động, cho đến ngày nó không. Biểu hiện của sự thất bại là tinh tế, chỉ xuất hiện sau khi có đủ các dịch vụ nội bộ và dạy một bài học quan trọng về sự khác biệt về quan tâm.
Sau khi hoàn thành bài học này, bạn sẽ hiểu:
- Tại sao ingress & egress đại diện cho các mô hình giao dịch cơ bản khác nhau với các trục độ tăng khác nhau và các biểu hiện thất bại khác nhau
- Hairpin NAT & tại sao một proxy nỗ lực kết nối với chính nó thất bại
- Cành kiến trúc: một khung trở thành hai, và mỗi cái sau đó sở hữu độc quyền
- Các lợi ích cách ly an ninh: mỗi bên có thể khóa lại với các đối tác thực sự của nó
- Cách nhận biết khi thiết kế đơn khung của bạn đã vượt qua ngưỡng mà sự chia tách là cần thiết
Tại Sao Hai Hướng Giao Tiếp Yêu Cầu Các Công Cụ Khác Biệt
Hai Công Việc Khác Biệt tại Một Giới Hạn Mạng
Giao Tiếp Ingress đặc điểm:
- Bắt đầu bởi các bên ngoài (cả internet)
- Số lượng tăng với cơ sở người dùng của bạn
- Kết thúc TLS, định tuyến yêu cầu, giới hạn tốc độ theo nguồn
- Các mối quan tâm về an ninh trong-depth: DDoS, lạm dụng, trích xuất
- IP công cộng cần chấp nhận các kết nối từ bất kỳ ai
Giao Tiếp Egress đặc điểm:
- Bắt đầu bởi các dịch vụ của bạn (một bộ khách biết, hạn chế)
- Số lượng tăng với các mẫu gọi API service-to-service & external-
- Duyệt IP nguồn tại các điểm cuối (bạn có một IP ra ngoài cố định mà đối tác tin tưởng)
- Nhu cầu về an ninh nhiều lớp: tràn dữ liệu, các dịch vụ nội bộ bị đánh cắp gọi ra
- Nên từ chối kết nối từ bất kỳ ai khác ngoài các dịch vụ của chính mình
Tính không đối xứng chính yếu: ingress chấp nhận giao thông từ thế giới; egress chấp nhận giao thông chỉ từ các dịch vụ của mình. Khi đặt chúng trên cùng một máy, máy đó phải đồng thời có thể truy cập từ thế giới (cho ingress) & chỉ có thể truy cập từ các dịch vụ của mình (cho egress). Các quy tắc firewall đáp ứng một trong số chúng lại làm trái với nhau.
Con đường phát triển: một dự án nhỏ có thể giấu cả hai phía sau một IP và một công cụ, vì lượng truy cập nhỏ và danh sách IP đối tác cho phép ngắn. Khi dự án phát triển, sự giãn nở giữa hai vai trò tăng lên và một ngày nào đó một lỗi cụ thể (hairpin NAT) khiến sự tách biệt.
The Bug That Forces the Split
Một Câu Chuyện Dừng Lại Tạm Thời
Hãy hình dung một sự tách biệt kiến trúc xảy ra trong các đội sản xuất. Tên dưới đây đã được làm sạch; hình dạng giống hệt với những gì đội gặp phải trong tự nhiên.
Một tổ chức chạy một máy proxy đơn tại 203.0.113.5. Nó xử lý ingress (cổng 443 cho người dùng) & egress (cổng 1080 SOCKS5 cho các dịch vụ nội bộ gọi ra ngoài). Các dịch vụ nội bộ sống trong các subnet riêng tư & điều hướng tất cả giao thông ra ngoài qua proxy SOCKS5 trên 203.0.113.5:1080.
Một trong các dịch vụ hosted phía sau cùng 203.0.113.5 là api.example.com. DNS công khai giải quyết api.example.com thành 203.0.113.5.
Bây giờ một dịch vụ nội bộ khác cần gọi api.example.com. Con đường ra ngoài của nó:
1. Dịch vụ nội bộ giải quyết api.example.com → 203.0.113.5
2. Dịch vụ nội bộ gửi yêu cầu qua proxy egress SOCKS5 tại 203.0.113.5:1080
3. Proxy nỗ lực mở một kết nối từ chính nó đến 203.0.113.5:443
4. Từ chối kết nối. Packet phải thoát và tái nhập cùng NAT, mà hầu hết các stack mạng từ chối. Proxy không thể kết nối với chính nó qua IP công khai của mình.
NAT tóc đinh: một gói tin xuất khỏi NAT và cần phải tái nhập cùng NAT để đến được đích. Không có hỗ trợ tóc đinh đặc biệt trong lớp định tuyến, gói tin sẽ bị mất.
Tại sao Nó Hiện Ra Muộn
Vào đầu đời của dự án, mọi dịch vụ nội bộ đều giao tiếp với các dịch vụ nội bộ khác thông qua hostname riêng (internal-api.local) hoặc không gọi lại vào các dịch vụ công khai của tổ chức của mình. Con đường tóc đinh đơn giản không tồn tại.
Sau đó, một tính năng mới yêu cầu dịch vụ A gọi api.example.com (một hostname công khai). Con đường tóc đinh được kích hoạt. Liên kết từ chối. Tạm dừng hoạt động.
Giải pháp khắc phục đã vá triệu chứng (đẩy resolver cung cấp IP riêng cho api.example.com thay vì công khai). Nguyên nhân gốc rễ: một chiếc hộp đơn lẻ đang làm quá nhiều việc.
Cái nĩa Kiến trúc
Một Chiếc Box Được Chia Ra Hai
Giải pháp sạch sẽ: tách proxy thành hai máy.
Server truy cập (IP công khai 203.0.113.5):
- Caddy / reverse proxy trên cổng 80, 443
- Đặt DNS công khai hướng về đây
- Chủ trì api.example.com, app.example.com, v.v.
Server truy xuất (một IP công khai khác 203.0.113.99):
- SOCKS5 / forward proxy trên cổng 1080
- Cửa hàng lửa hạn chế các kết nối đến từ subnet IP nội bộ chỉ
- Các dịch vụ nội bộ định tuyến tất cả các kết nối ra ngoài qua địa chỉ này
Điều này mua lại:
1. Tóc đinh được giải quyết. Một dịch vụ nội bộ gọi api.example.com routing ra ngoài qua 203.0.113.99 (truy xuất), sau đó kết nối bình thường đến 203.0.113.5 (truy cập, một IP khác). Lặp lại NAT biến mất vì hai IP sống trên các máy khác nhau.
2. Tách biệt an ninh. Máy chủ truy xuất firewall có thể khóa lại một bộ nhỏ các IP nội bộ. Máy chủ truy cập firewall vẫn mở cho thế giới. Hai bộ quy tắc riêng, mỗi bộ biểu hiện một vai trò sạch sẽ.
3. Tích hợp độc lập. Bandwidth truy cập tăng với người dùng; bandwidth truy xuất tăng với hoạt động của dịch vụ nội bộ. Cập nhật một không ảnh hưởng đến cái khác.
4. Tách biệt lỗi. Một máy chủ truy xuất sai không còn gây ra sự cố cho trang web công khai. Một DDoS chống lại trang web công khai không còn làm kiệt đi bandwidth truy xuất.
5. Mô hình tâm lý rõ ràng hơn. Mỗi máy có một công việc. Kỹ sư suy nghĩ về các vấn đề truy cập mà không cần xem xét về truy xuất, & ngược lại.
Hai trục, hai quyết định về kích cỡ
Tăng trưởng độc lập
Trước khi chia tách, sự tăng trưởng trong bất kỳ hướng nào cũng gây áp lực cho cùng một máy. Sau khi chia tách, mỗi hướng đều có quy định riêng.
Kích cỡ ingress: tăng theo số lượng người dùng. Quyết định về dung lượng sống ở tầng công khai (có nhiều bản sao reverse proxy, các máy VM lớn hơn, CDN ở phía trước). Ngân sách dung lượng được tính toán dựa trên lưu lượng người dùng ở đỉnh điểm.
Kích cỡ egress: tăng theo lượng gọi API từ dịch vụ nội bộ đến API bên ngoài. Thường bị chi phối bởi việc gửi webhook, gọi các nhà cung cấp dịch vụ thanh toán hoặc truy xuất dữ liệu bên thứ ba. Ngân sách dung lượng được tính toán dựa trên các mẫu gọi API nội bộ.
Tách biệt sự cố: một DDoS chống lại ingress công khai không ăn dung lượng egress (các cuộc gọi payment processor vẫn tiếp tục). Một proxy egress bị tắt không còn làm tắc nghẽn trang web công khai (người dùng vẫn tiếp cận được trang web; chỉ có các cuộc gọi ngoại tuyến nội bộ bị ảnh hưởng).
Các SLO khác nhau: khả năng truy cập ingress quan trọng đối với người dùng (xuất hiện sự cố trang web); khả năng truy cập egress quan trọng đối với các quản trị viên (sự cố nền tảng có thể mất thời gian để phát hiện). Mỗi bên có thể giữ SLO của mình.
Các máy chủ egress nhiều
Khi vai trò egress là một máy riêng, bước tiếp theo rõ ràng là chạy nhiều máy egress sau một load balancer để đảm bảo HA. Mỗi dịch vụ nội bộ mới chỉ điểm đến hostname egress (được giải quyết thành bể load cân bằng) thay vì một IP duy nhất.
Lần học giống như phần còn lại của hệ thống phân tán: khi một tầng trở nên stateless & có vai trò riêng, nó nhân lên dễ dàng.
Một nhà tích hợp mới
Công ty của bạn áp dụng sự chia tách ingress / egress như thiết kế. Máy chủ egress có một IP công khai cố định (203.0.113.99) mà bạn đã allowlisted với ba API đối tác hiện có (một nhà cung cấp thanh toán, một gateway SMS, một nhà cung cấp email).
Một đội sản phẩm muốn thêm một tích hợp thứ tư: một hệ thống gửi webhook gọi lại vào điểm cuối khách hàng trên toàn thế giới. Dự báo lượng truy cập: 10.000 cuộc gọi mỗi phút, với đợt tăng lên đến 30.000.
Thiết kế ranh giới mạng cho một Dịch vụ Nhiều hơn
Tích hợp
Bạn đã học lý do ingress và egress đòi hỏi các công cụ khác nhau, sự thất bại của hairpin NAT là nguyên nhân bắt buộc phải tách ra trong các đội thực sự, và cách tích lũy các yếu tố độc lập tăng tốc, cô lập an ninh và cô lập sự cố một lần tách ra.
Áp dụng tất cả bốn.
Một công ty SaaS trung bình sử dụng ba subdomain sản phẩm (app, api, admin) cho người dùng của họ, cùng với bốn tích hợp outbound (Stripe, Twilio, SendGrid, một hệ thống webhook cho khách hàng). Hôm nay mọi thứ đều sống sau một máy proxy đơn tại một IP công khai. Họ đã bắt đầu nhận được báo cáo về các sự cố hairpin tạm thời khi các dịch vụ nội bộ cố gắng gọi api.example.com. Họ muốn thiết kế một giải pháp vĩnh viễn.
Hướng Tiến Sĩ Tiếp Theo
Hướng Tiến Sĩ Tiếp Theo
Bạn đã xem một trong những refactor tách bạch nhất về sự quan tâm trong hệ thống phân tán: một hộp trở thành hai, mỗi cái với một vai trò rõ ràng, và hệ thống thu được các lợi ích tăng tốc, an ninh và cô lập sự cố theo cách.
Bài học tiếp theo (cs_distsys_failure_modes_and_blast_radius) mở rộng lý luận về cô lập sự cố. Bạn sẽ đọc một bản tóm tắt DNS-SERVFAIL postmortem, xác định mô hình nhiễu động của sự cố và viết các mục hành động vô tội vạ targeting systems thay vì người.
Bài học kèm: geometry_of_ingress_egress_separation chuyển đổi sự tách biệt thành một đồ thị hai phần & khám phá các đỉnh cắt, các phân vùng mạng, & những điều lý thuyết đồ thị告诉 bạn về ranh giới của một mạng.
Chúc mừng. Tiến lên.