3.13 Mạng và kết nối

Tổng quan và động lực

Mọi yêu cầu mà ứng dụng của bạn gửi đi đều đi qua một mạng, và mạng không quan tâm đến hạn chót của bạn. Giữa mã của bạn và cơ sở dữ liệu, nhà cung cấp thanh toán, hay trình duyệt là một chồng các bộ phận chuyển động: phân giải tên, định tuyến, kiểm soát tắc nghẽn, bắt tay mã hóa, bộ cân bằng tải, proxy và tường lửa. Hầu hết kỹ sư ứng dụng coi tất cả những thứ này là một đường ống phẳng, đáng tin cậy, và giả định đó là nguồn phong phú nhất của các sự cố trên môi trường thực. Những ngụy biện của điện toán phân tán kinh điển (mạng đáng tin cậy, độ trễ bằng không, băng thông vô hạn, cấu trúc liên kết không bao giờ đổi, chi phí vận chuyển bằng không) gọi tên chính xác những niềm tin biến một trục trặc nhỏ thành một sự cố. Chương này không phải là một khóa học chứng chỉ mạng. Nó là kiến thức làm việc mà một kỹ sư ứng dụng thực sự cần để xây dựng các hệ thống vẫn chạy khi mạng hành xử sai.

Với một tổ chức lớn, kết nối là nơi kiến trúc gặp vật lý và chính trị cùng lúc. Một doanh nghiệp toàn cầu ghép nối trung tâm dữ liệu, vùng đám mây, API đối tác và hệ thống cũ, và mỗi bước nhảy thêm độ trễ, chế độ thất bại và một ranh giới bảo mật mà ai đó phải sở hữu. Chính phủ chồng thêm các quy tắc nghiêm ngặt về cách lưu lượng vào và ra khỏi mạng của họ và nơi dữ liệu công dân có thể di chuyển. Sự khác biệt giữa một đội hiểu mạng và một đội phớt lờ nó hiện ra ở các con số tính sẵn sàng, thời gian tải trang, báo cáo xâm phạm và các phát hiện kiểm toán. Tài liệu này liên hệ với hệ thống phân tán (chương 3.3), khả năng mở rộng và phục hồi (chương 3.5), bảo mật hạ tầng và đám mây (chương 4.3), và mật mã học cùng quản lý khóa (chương 4.8).

Tin tốt là bạn không cần làm chủ các giao thức định tuyến để xây dựng các hệ thống có khả năng phục hồi. Bạn cần biết tầng nào quan trọng với các quyết định của bạn, độ trễ đến từ đâu, tên được phân giải thế nào, kết nối được bảo mật và cân bằng ra sao, và cách thất bại nhẹ nhàng ở ranh giới mạng. Làm đúng những điều đó và phần lớn mạng trở thành một nền tảng đáng tin cậy.

Các nguyên tắc chính

Mạng là một phụ thuộc, không phải điều đã cho. Hãy coi mọi lệnh gọi từ xa là thứ có thể chậm, rớt, hoặc nói dối về việc nó đã xong chưa.
Độ trễ được định bởi khoảng cách và số vòng đi về. Bạn không thể thắng tốc độ ánh sáng, nên hãy cắt giảm vòng đi về và đưa dữ liệu gần người dùng hơn.
Tên hỏng nhiều hơn máy. Phân giải tên và chứng chỉ gây ra một phần đáng ngạc nhiên các sự cố, nên hãy coi chúng là mối quan tâm vận hành hạng nhất.
Bảo mật và kết thúc mã hóa có chủ đích. Biết chính xác nơi lưu lượng được mã hóa, nơi nó được giải mã, và ai giữ khóa.
Mọi ranh giới mạng cần một thời gian chờ và một phương án dự phòng. Chờ không giới hạn và thử lại mù quáng biến một phụ thuộc chậm thành sự cố toàn cục.
Mặc định từ chối ở các rìa. Phân đoạn mạng, kiểm soát cái gì có thể rời đi, và giả định chu vi đã xốp.
Quan sát kết nối, không chỉ mã. Lỗi kết nối, truyền lại, thời gian bắt tay và độ trễ DNS là các tín hiệu mà nhật ký của bạn thường bỏ lỡ.

Khuyến nghị

Hiểu các tầng thực sự ảnh hưởng đến quyết định của bạn

Bạn không cần thuộc lòng mô hình bảy tầng đầy đủ, nhưng bạn cần một bản đồ tinh thần. Ở tầng vận chuyển, Giao thức Điều khiển Truyền (TCP) cho bạn một luồng byte có thứ tự, đáng tin cậy với cái giá là một cú bắt tay và chặn đầu hàng đợi, trong khi Giao thức Datagram Người dùng (UDP) cho bạn các datagram rẻ, không thứ tự mà không có bảo đảm giao nhận. Lưu lượng yêu cầu/phản hồi đáng tin cậy chạy trên TCP; phương tiện thời gian thực, trò chơi và một số đo đạc từ xa chạy trên UDP vì một gói muộn tệ hơn một gói mất.

Sự tiến hóa của Giao thức Truyền Siêu văn bản (HTTP) thay đổi trần hiệu năng của bạn. HTTP/1.1 xử lý một yêu cầu mỗi kết nối tại một thời điểm, nên trình duyệt mở nhiều kết nối và bạn trả các cú bắt tay lặp lại. HTTP/2 ghép nhiều luồng trên một kết nối TCP, loại bỏ chặn đầu hàng đợi ở cấp ứng dụng nhưng không loại ở cấp TCP: một gói mất làm đình trệ mọi luồng trên kết nối đó. HTTP/3 chạy trên QUIC, một giao thức vận chuyển dựa trên UDP cho mỗi luồng giao nhận độc lập, thiết lập kết nối nhanh hơn, và di chuyển kết nối qua các thay đổi mạng. Bạn hiếm khi tự cài đặt những thứ này, nhưng bạn chọn chúng trong bộ cân bằng tải, mạng phân phối nội dung và máy khách, và lựa chọn đó hiện ra ở độ trễ đuôi.

Coi DNS và chứng chỉ là các hệ thống sản xuất

Hệ thống Tên Miền (DNS) dịch tên con người thành địa chỉ, và nó đứng trước gần như mọi yêu cầu. Một số lượng đáng chú ý các sự cố lớn truy về DNS: một thay đổi bản ghi sai, một vùng hết hạn, một bộ phân giải cấu hình sai, một tầng lưu đệm phục vụ câu trả lời cũ, hoặc một máy chủ có thẩm quyền chậm thêm hàng trăm mili giây vào byte đầu tiên. Hãy xử lý thay đổi DNS với cùng sự chặt chẽ như triển khai mã. Dùng giá trị thời gian sống (TTL) hợp lý để bạn có thể chuyển lưu lượng nhanh trong sự cố mà không mời gọi lưu đệm cũ trong vận hành bình thường, và giám sát độ trễ phân giải cùng tỷ lệ thất bại như các chỉ số thực.

Chứng chỉ xứng đáng sự nghiêm túc như vậy. Khi chứng chỉ Bảo mật Tầng Vận chuyển (TLS) hết hạn mà không ai để ý, cả dịch vụ tối đen cùng lúc, và thất bại trông chẳng giống một lỗi mã. Hãy tự động hóa việc cấp và gia hạn, theo dõi ngày hết hạn tập trung, và cảnh báo từ rất sớm trước hạn chót. Hãy quyết định có chủ đích nơi TLS kết thúc: ở bộ cân bằng tải rìa, ở một proxy, hay đến tận dịch vụ. Kết thúc ở rìa đơn giản hóa lưu lượng nội bộ nhưng để bước nhảy nội bộ không mã hóa trừ khi bạn mã hóa lại. Cơ quan chứng thực, xoay vòng khóa và lựa chọn mật mã được bao quát trong chương 4.8; ở đây điểm vận hành là DNS và chứng chỉ hỏng trong im lặng và kéo theo mọi thứ, nên hãy đo đạc và tự động hóa cả hai.

Cân bằng tải ở đúng tầng và cho proxy làm việc

Cân bằng tải phân tán lưu lượng qua nhiều backend, và nơi bạn làm điều đó rất quan trọng. Một bộ cân bằng tải tầng 4 (L4) định tuyến theo địa chỉ IP và cổng mà không đọc tải trọng, nên nó nhanh, bất khả tri giao thức và rẻ. Một bộ cân bằng tải tầng 7 (L7) hiểu HTTP, nên nó có thể định tuyến theo đường dẫn hoặc tiêu đề, kết thúc TLS, thử lại các yêu cầu lũy đẳng, và thực thi giới hạn tốc độ, với cái giá là nhiều việc hơn cho mỗi yêu cầu. Hầu hết lưu lượng ứng dụng muốn một proxy ngược L7 hoặc cổng API ở rìa, cho bạn một nơi để xử lý TLS, xác thực, định tuyến và khả năng quan sát. Hãy dành L4 cho thông lượng thô hoặc các giao thức không phải HTTP.

Kiểm tra sức khỏe là thứ làm cho cân bằng tải an toàn. Hãy cấu hình chúng phản ánh sự sẵn sàng thực, không chỉ “tiến trình đang chạy”, để một backend không với được cơ sở dữ liệu của nó bị rút khỏi vòng quay trước khi nó phục vụ lỗi, và xả kết nối khi triển khai để các yêu cầu đang bay hoàn tất. Một cổng API tập trung các mối quan tâm xuyên suốt (xác thực, giới hạn tốc độ, định hình yêu cầu, đánh phiên bản) nhưng trở thành một phụ thuộc quan trọng và một nút thắt tiềm tàng, nên hãy cho nó cùng ngân sách sẵn sàng và khả năng quan sát như bất kỳ dịch vụ lõi nào.

Đưa dữ liệu gần người dùng hơn bằng CDN và rìa

Độ trễ bị chi phối bởi thời gian đi-về, và thời gian đi-về bị chi phối bởi khoảng cách. Một mạng phân phối nội dung (CDN) lưu đệm nội dung ở các điểm hiện diện gần người dùng để tài sản tĩnh, và ngày càng nhiều các phản hồi động và cá nhân hóa, được phục vụ từ cách vài mili giây thay vì băng qua một đại dương. Với bất kỳ sản phẩm hướng người dùng nào có đối tượng trải rộng địa lý, CDN là một trong những khoản đầu tư hiệu năng lợi tức cao nhất bạn có thể làm, và nó kiêm lá chắn hấp thụ các đợt tăng lưu lượng và tấn công thể tích.

Hãy đẩy công việc ra rìa ở nơi nó có ích. Kết thúc TLS ở rìa cắt giảm độ trễ bắt tay vì các vòng đi-về tốn kém xảy ra gần người dùng, và lưu đệm phản hồi API ở các vị trí rìa rút ngắn đường đi cho các yêu cầu phổ biến. Đánh đổi là vô hiệu hóa bộ đệm: dữ liệu của bạn càng gần và càng được lưu đệm, càng khó bảo đảm độ mới, nên hãy tường minh về những gì có thể cũ và trong bao lâu. Điều này liên hệ với thảo luận về lưu đệm và hiệu năng ở chương 3.5.

Làm ranh giới mạng có khả năng phục hồi theo mặc định

Mọi lệnh gọi từ xa là một chỗ mạng có thể làm hại bạn, nên hãy bọc từng cái trong cùng một kỷ luật. Đặt một thời gian chờ tường minh trên mọi lệnh gọi, vì một phụ thuộc bị treo sẽ làm cạn nhóm kết nối và nhóm luồng của bạn và làm đình trệ mọi thứ phía sau. Chỉ thử lại các thao tác an toàn để lặp lại, dùng độ lùi lũy thừa với nhiễu để một gợn sóng không thành cơn bão thử lại đồng bộ, và giới hạn tổng số lần thử và tổng thời gian. Thêm một bộ ngắt mạch để sau một ngưỡng thất bại bạn thất bại nhanh trong một khoảng làm nguội thay vì chất yêu cầu lên một dịch vụ đang chìm. Những mẫu này được bao quát sâu trong chương 3.3; điểm ở đây là chúng thuộc về ranh giới mạng một cách đặc thù, lý tưởng là như mặc định nền tảng dùng chung thay vì thứ mỗi đội phát minh lại.

Hãy lập ngân sách thời gian chờ xuống chuỗi gọi. Nếu một yêu cầu hướng người dùng có ngân sách hai giây và băng qua bốn bước nhảy, mỗi bước nhảy phải biết còn bao ít thời gian và thất bại nhanh thay vì thử lại vào hư không. Tái sử dụng kết nối qua gộp nhóm và keep-alive để bạn không trả một cú bắt tay TCP và TLS mới cho mỗi yêu cầu, và theo dõi độ trễ đuôi, không chỉ trung bình, vì một phần trăm chậm nhất là thứ người dùng nhớ và là thứ lan truyền dưới tải.

Thiết kế và quản trị cấu trúc liên kết mạng của bạn

Trong đám mây, mạng của bạn là phần mềm bạn cấu hình, vì vậy hãy cấu hình nó có chủ đích. Đặt khối lượng công việc trong một đám mây riêng ảo (VPC) và phân đoạn nó: các tầng hướng công khai, tầng ứng dụng và tầng dữ liệu trong các mạng con riêng với quy tắc chỉ cho phép lưu lượng nên tồn tại. Kiểm soát lưu lượng đi ra chặt như lưu lượng đi vào. Truy cập đi ra không kiểm soát là cách dữ liệu rời đi trong một vụ xâm phạm và là cách các khối lượng công việc bị xâm nhập với tới máy chủ chỉ huy-và-điều khiển, nên hãy định tuyến lưu lượng đi ra qua các cổng được kiểm soát và cho phép danh sách các đích thực sự cần với tới. Hãy lên kế hoạch cho IPv6 thay vì coi nó là chuyện nghĩ sau, vì cạn kiệt địa chỉ và yêu cầu đối tác cuối cùng sẽ buộc nó và trang bị bổ sung rất đau đớn.

Hãy áp dụng một mô hình bảo mật không tin cậy: ngừng coi “bên trong mạng” là đáng tin, và xác thực cùng cấp quyền cho mọi yêu cầu dựa trên danh tính thay vì vị trí mạng. Trong thực tế điều này nghĩa là TLS tương hỗ giữa các dịch vụ, thông tin xác thực sống ngắn, và chính sách không giả định một yêu cầu an toàn chỉ vì nó đến từ một mạng con lân cận. Một lưới dịch vụ có thể cung cấp phần lớn điều này một cách đồng nhất. Bằng cách chạy một proxy sidecar bên cạnh mỗi dịch vụ, một lưới cho bạn TLS tương hỗ, thử lại và thời gian chờ nhất quán, và đo đạc từ xa theo từng bước nhảy mà không đổi mã ứng dụng. Nó thêm độ phức tạp vận hành và chút độ trễ, nên hãy áp dụng khi số lượng dịch vụ làm cho việc thực thi đồng nhất, không cần mã đáng với chi phí chung. Không tin cậy và phân đoạn được phát triển thêm trong các chương 4.3 và 8.3.

Đánh đổi: ưu và nhược điểm

Quyết định	Ưu điểm	Nhược điểm / chi phí
Bộ cân bằng tải L7 / cổng API	Định tuyến thông minh, kết thúc TLS, xác thực, giới hạn tốc độ, khả năng quan sát	Thêm độ trễ mỗi yêu cầu, một phụ thuộc dùng chung quan trọng
Bộ cân bằng tải L4	Nhanh, bất khả tri giao thức, rẻ	Không thấy hoặc hành động trên HTTP được, không định tuyến nhận biết nội dung
Kết thúc TLS ở rìa	Bắt tay nhanh hơn, backend đơn giản hơn	Bước nhảy nội bộ không mã hóa trừ khi bạn mã hóa lại
CDN và lưu đệm rìa	Lợi ích độ trễ lớn, hấp thụ tăng đột biến và tấn công	Vô hiệu hóa bộ đệm và dữ liệu cũ, thêm chi phí và cấu hình
Lưới dịch vụ	mTLS đồng nhất, thử lại, đo đạc từ xa mà không đổi ứng dụng	Độ phức tạp vận hành, độ trễ và chi phí tài nguyên của sidecar
HTTP/3 trên QUIC	Không chặn đầu hàng đợi tầng vận chuyển, thiết lập nhanh, di chuyển kết nối	Công cụ mới hơn, UDP đôi khi bị bóp nghẹt, gỡ lỗi khó hơn

Căng thẳng trung tâm là giữa kiểm soát và đơn giản. Mỗi thành phần có năng lực bạn thêm ở ranh giới mạng (cổng L7, lưới, CDN, proxy đi ra) mua cho bạn trí thông minh định tuyến, thực thi bảo mật và khả năng hiển thị, và mỗi cái cũng thêm một bước nhảy, một chế độ thất bại, và một thứ để vận hành. Hãy giải quyết bằng cách chỉ đẩy các mối quan tâm dùng chung sang hạ tầng dùng chung khi đủ nhiều đội cần chúng để biện minh cho trọng lượng vận hành, và bằng cách giữ đường nhanh ngắn. Một công ty khởi nghiệp hai người kết thúc TLS ở bộ cân bằng tải được quản lý rồi xong đang thực hiện một đánh đổi tốt hơn cùng đội đó tự làm một lưới dịch vụ. Một doanh nghiệp nghìn dịch vụ không có TLS tương hỗ đồng nhất và kiểm soát đi ra đang thực hiện một đánh đổi tệ hơn.

Câu hỏi để thảo luận với đội của bạn

TLS kết thúc ở đâu trong từng đường yêu cầu của bạn, và mọi người có vẽ nó giống nhau không? Nghe như chuyện vặt cho đến khi có sự cố. Nếu một nửa đội tin lưu lượng được mã hóa từ đầu đến cuối và nửa kia biết nó được giải mã ở rìa và gửi dạng văn bản thuần đến backend, bạn vừa có lỗ hổng bảo mật vừa có cái bẫy gỡ lỗi. Với một tổ chức lớn câu hỏi này ánh xạ trực tiếp sang tuân thủ: cơ quan quản lý và kiểm toán viên sẽ hỏi dữ liệu công dân hay khách hàng đi qua ở dạng rõ ở đâu, và “chúng tôi không chắc” là một phát hiện. Hãy mang một sơ đồ thực của một đường thật từ máy khách đến cơ sở dữ liệu, đánh dấu mọi điểm nơi mã hóa bắt đầu và dừng và ai giữ từng chứng chỉ và khóa. Câu trả lời nên cho bạn biết bạn có cần mã hóa lại nội bộ không, TLS tương hỗ thuộc về đâu, và chứng chỉ nào sẽ làm sập một dịch vụ nếu hết hạn. Nếu không ai vẽ được tự tin, khoảng trống đó là nhiệm vụ đầu tiên của bạn.
Điều gì xảy ra với hệ thống của bạn khi DNS chậm hoặc sai, và bạn đã thực sự kiểm thử chưa? DNS ở thượng nguồn của gần như mọi yêu cầu, vậy mà hầu hết các đội chưa bao giờ quan sát hệ thống của mình dưới sự suy giảm DNS. Một bộ phân giải chậm thêm độ trễ cho mọi kết nối mới, một bộ đệm cũ có thể gửi lưu lượng đến một máy chủ đã ngừng hoạt động, và một thay đổi bản ghi sai có thể nuốt cả dịch vụ trong vài giây. Trong một doanh nghiệp lớn bán kính ảnh hưởng rộng hơn vì khám phá dịch vụ nội bộ, tích hợp đối tác và điểm cuối đám mây đều dựa vào phân giải tên. Hãy mang các thiết lập TTL DNS của bạn, chỉ số độ trễ phân giải nếu có, và sổ tay vận hành cho một thay đổi bản ghi sai, rồi hỏi bạn thực sự có thể chuyển lưu lượng nhanh thế nào trong một sự cố. Câu trả lời nên quyết định liệu bạn có giám sát phân giải như chỉ số hạng nhất, điều chỉnh TTL cho cả sự linh hoạt lẫn hiệu quả bộ đệm, và diễn tập chuyển đổi dự phòng DNS không. Nếu bạn chưa bao giờ gây ra một thất bại DNS trong một bài kiểm thử có kiểm soát, thí nghiệm đó thuộc về lịch.
Mẫu khả năng phục hồi nào ở ranh giới mạng là mặc định nền tảng, và cái nào mỗi đội đang phát minh lại? Thời gian chờ, thử lại có giới hạn với nhiễu, bộ ngắt mạch, gộp nhóm kết nối và truy vết từng bước nhảy rẻ nhất và đáng tin cậy nhất khi được xây một lần và mọi người thừa hưởng. Để cho từng đội, chúng trôi dạt: một số lệnh gọi không có thời gian chờ, một số thử lại các thao tác không lũy đẳng, một số không phát đo đạc mức kết nối, và các khoảng trống chỉ hiện ra dưới tải. Với một đội lớn đây là lựa chọn tổ chức về nơi khả năng phục hồi sống, trong một thư viện dùng chung hay tầng nền tảng so với rải rác qua các dịch vụ. Hãy mang một cuộc kiểm toán mẫu các dịch vụ đếm bao nhiêu cái đặt thời gian chờ tường minh trên mọi lệnh gọi từ xa và lan truyền một định danh tương quan từ đầu đến cuối. Nếu con số đó thấp, cách sửa là đầu tư nền tảng, và chuẩn hóa nó cũng làm cho khả năng phục hồi kiểm thử được và kiểm toán được, điều ngày càng quan trọng trong các lĩnh vực chịu quy định. Câu trả lời nên cho bạn biết có nên tài trợ một năng lực nền tảng mạng hay tiếp tục trả tiền cho sự không nhất quán trong các sự cố.
Mỗi khối lượng công việc của bạn hiện có thể với tới gì trên internet công cộng, và ai đã ký duyệt từng đích đi ra đó? Lưu lượng đi vào nhận sự chú ý vì đó là nơi kẻ tấn công gõ cửa, nhưng lưu lượng đi ra mới là cách dữ liệu thực sự rời đi trong một vụ xâm phạm và cách một khối lượng công việc bị xâm nhập gọi về máy chủ chỉ huy-và-điều khiển. Hầu hết các đội liệt kê được cái gì nói chuyện với họ dễ hơn nhiều so với họ nói chuyện với cái gì, và sự bất đối xứng đó chính là khoảng trống kẻ tấn công khai thác. Cân nhắc đối lập là ma sát: một danh sách cho phép các đích được duyệt làm chậm lập trình viên muốn gọi một API bên thứ ba mới ngay hôm nay, nên cuộc tranh luận trung thực là bạn đánh đổi bao nhiêu sự tiện lợi lấy bán kính ảnh hưởng thu nhỏ. Hãy mang các quy tắc đi ra hiện tại của một dịch vụ đại diện, một bản ghi nơi nó thực sự kết nối trong tuần qua, và quy trình (nếu có) để phê duyệt một đích mới. Với các hệ thống doanh nghiệp và chính phủ đây không phải vệ sinh tùy chọn mà là mục kiểm toán: bảo vệ ranh giới và bản kiểm kê đi ra chính xác là thứ cơ quan quản lý và quy tắc ranh giới mạng yêu cầu bạn xuất trình, và “mọi khối lượng công việc đều với tới được mọi nơi” là một phát hiện bạn sẽ được bảo phải khắc phục.
Thời gian chờ và thử lại của bạn có kết hợp thành một ngân sách mạch lạc xuống mỗi chuỗi gọi không, hay mỗi bước nhảy đoán riêng lẻ? Một yêu cầu hướng người dùng đi qua bốn dịch vụ có một hạn chót duy nhất mà người dùng thực sự cảm nhận, vậy mà mỗi bước nhảy thường đặt thời gian chờ cục bộ của riêng nó, thử lại vào một dịch vụ đã bỏ cuộc, và thổi bay ngân sách đầu-cuối trong khi làm thêm việc. Với một đội lớn mối nguy là nổi lên: các thời gian chờ theo dịch vụ riêng hợp lý cộng dồn thành các đình trệ lan truyền và bão thử lại đồng bộ mà không đội nào thấy được từ bảng điều khiển của mình. Căng thẳng là giữa quyền tự chủ cục bộ, nơi mỗi đội tự chỉnh giới hạn, và một hạn chót được lan truyền mà mọi bước nhảy đọc và rút ngắn khi thời gian bị tiêu. Hãy mang một đường yêu cầu thực với chính sách thời gian chờ và thử lại ở mỗi bước nhảy, ngân sách đầu-cuối mà sản phẩm hứa, và các số đo độ trễ đuôi (p99, không phải trung bình) dưới tải. Trong các bối cảnh chịu quy định và sẵn sàng cao, hãy gắn điều này với mục tiêu khôi phục của bạn: một chuỗi không thể thất bại nhanh trong ngân sách của nó biến một phụ thuộc chậm thành vi phạm mục tiêu mức dịch vụ, và vi phạm đó là con số ban lãnh đạo và kiểm toán viên sẽ yêu cầu bạn giải thích.
Ở số lượng dịch vụ và hồ sơ lưu lượng nào thì việc thực thi đồng nhất (lưới dịch vụ, cổng L7, lưu đệm rìa) xứng đáng với trọng lượng vận hành của nó, và hôm nay bạn đang ở đâu trên đường cong đó? Mỗi thành phần có năng lực bạn thêm ở ranh giới mạng mua trí thông minh định tuyến, bảo mật và khả năng hiển thị, và mỗi cái cũng thêm một bước nhảy, một chế độ thất bại, và một thứ để vận hành suốt ngày đêm. Áp dụng lưới quá sớm và bạn nhấn chìm một nhúm dịch vụ trong độ phức tạp sidecar; áp dụng quá muộn và bạn có một nghìn dịch vụ không có TLS tương hỗ đồng nhất hay thử lại nhất quán. Những cân nhắc cạnh tranh là giá trị của việc thực thi nhất quán, không cần mã qua nhiều đội so với chi phí thực của việc chạy mặt phẳng điều khiển, độ trễ thêm, và những người khan hiếm có thể gỡ lỗi nó. Hãy mang số lượng dịch vụ hiện tại và đường cong tăng trưởng của bạn, tỷ lệ dịch vụ đã dùng máy khách dùng chung cung cấp cùng bảo đảm, và khoảng dư độ trễ bạn có để tiêu. Với một doanh nghiệp hay cơ quan lớn quyết định này cũng là quản trị: một lưới hay cổng trung tâm cho phép đội nền tảng triển khai chính sách khắp nơi cùng lúc, mạnh mẽ cho tuân thủ và nguy hiểm nếu điểm nghẽn đơn lẻ đó bị cấp thiếu nguồn lực, vì vậy hãy lập ngân sách nó như hạ tầng lõi với mục tiêu sẵn sàng riêng, không phải một dự án phụ.

Góc nhìn theo lĩnh vực

Công ty khởi nghiệp. Hãy dựa vào hạ tầng được quản lý và dành sự chú ý kỹ thuật khan hiếm cho sản phẩm, không phải gói tin. Một bộ cân bằng tải L7 được quản lý kết thúc TLS với chứng chỉ tự gia hạn, cộng một CDN phía trước ứng dụng của bạn, mua cho bạn lưu lượng được mã hóa, cân bằng tải, nhanh toàn cầu mà không cần đội vận hành. Bọc mọi lệnh gọi bên ngoài trong một máy khách dùng chung nhỏ với thời gian chờ và thử lại có giới hạn, và cưỡng lại một lưới dịch vụ cho đến khi bạn có nhiều dịch vụ hơn hẳn số người để vận hành.

Doanh nghiệp nhỏ. Bạn không có chuyên gia mạng và ngân sách eo hẹp, vì vậy hãy coi kết nối là thứ bạn mua đã cấu hình sẵn thay vì xây. Chọn một nhà cung cấp đám mây hay nền tảng mà mặc định đã cho bạn chứng chỉ tự động, quản lý DNS và một tường lửa hợp lý, và bật những gì họ cung cấp thay vì tự lắp ráp. Ở nơi bạn phải quyết định, hãy ưu tiên phương án được quản lý: trả tiền cho nhà cung cấp gia hạn chứng chỉ và giám sát DNS rẻ hơn nhiều so với sự cố mà một lần hết hạn bị quên gây ra.

Doanh nghiệp lớn. Vấn đề của bạn là sự nhất quán qua nhiều đội và vùng: TLS tương hỗ đồng nhất, thời gian chờ và thử lại được chuẩn hóa, đi ra được kiểm soát, và giám sát chứng chỉ cùng DNS mà không đội đơn lẻ nào có thể bỏ qua. Hãy đẩy những điều này vào hạ tầng nền tảng dùng chung (lưới dịch vụ, cổng nội bộ, thư viện máy khách dùng chung) để khả năng phục hồi được thừa hưởng thay vì phát minh lại, và quản lý ranh giới mạng với cùng ngân sách sẵn sàng và khả năng quan sát như bất kỳ dịch vụ lõi nào. Hãy phân đoạn VPC, quản trị đi ra tập trung, và coi cấu trúc liên kết là phần mềm bạn kiểm toán.

Chính phủ. Quy tắc mua sắm, minh bạch và trách nhiệm giải trình công định hình mọi ranh giới. Hãy dẫn lưu lượng hướng internet qua một nhúm cổng được gia cố, giám sát, kiểm kê mọi điểm cuối bên ngoài, và vận hành kiến trúc không tin cậy nơi các dịch vụ xác thực theo danh tính với thông tin xác thực sống ngắn thay vì theo vị trí mạng. Hãy coi quản lý DNS và chứng chỉ là hạ tầng quan trọng với giám sát chuyên dụng, vì một chứng chỉ hết hạn duy nhất trên một dịch vụ hướng đến công dân mời gọi sự soi xét cả công khai lẫn lập pháp, và giữ bằng chứng có thể kiểm toán để các cuộc rà soát bảo vệ ranh giới tìm thấy một thiết kế có tài liệu, có thể bảo vệ.

Ví dụ

Công ty khởi nghiệp. Một công ty phần mềm-như-một-dịch-vụ mười người chạy mọi thứ đằng sau một bộ cân bằng tải L7 được quản lý duy nhất kết thúc TLS với chứng chỉ được gia hạn tự động, và đặt một CDN phía trước ứng dụng web và API. Sự kết hợp đó cho họ tải trang nhanh toàn cầu, hấp thụ các đợt tăng lưu lượng thỉnh thoảng từ một lần ra mắt sản phẩm, và che chắn nguồn gốc của họ mà không cần đội vận hành riêng. Họ đặt một thời gian chờ tường minh và một thử lại có giới hạn trên mọi lệnh gọi đến nhà cung cấp thanh toán và dịch vụ email, bọc trong một máy khách dùng chung nhỏ, để một bên thứ ba chậm không bao giờ làm treo một yêu cầu người dùng. Họ cưỡng lại việc thêm lưới dịch vụ: với một chục dịch vụ, chi phí vận hành sẽ làm nhỏ bé lợi ích, và hạ tầng được quản lý đã cho họ lưu lượng được mã hóa, cân bằng tải.

Doanh nghiệp lớn. Một nhà bán lẻ đa quốc gia chạy qua ba vùng đám mây và một trung tâm dữ liệu tại chỗ cũ, được nối bằng các liên kết riêng thay vì internet công cộng để lưu lượng hàng tồn kho và thanh toán không bao giờ đi qua mạng mở. Mỗi vùng nằm trong một VPC được phân đoạn với các mạng con công khai, ứng dụng và dữ liệu riêng, và mọi lưu lượng đi ra chảy qua các cổng đi ra cho phép danh sách các đích được duyệt, để một khối lượng công việc bị xâm nhập không thể lặng lẽ rút dữ liệu. Hàng trăm dịch vụ giao tiếp qua một lưới dịch vụ thực thi TLS tương hỗ ở mọi nơi và áp dụng thử lại, thời gian chờ và truy vết đồng nhất, cho phép đội nền tảng trung tâm triển khai chính sách thử lại mới mà không chạm mã ứng dụng. Giám sát chứng chỉ tập trung cảnh báo hết hạn trước nhiều ngày và tự động hóa xoay vòng chúng trước khi bất kỳ khách hàng nào nhận ra.

Chính phủ. Một cơ quan quốc gia vận hành dưới các quy tắc bảo vệ ranh giới mạng dẫn mọi lưu lượng hướng internet qua một nhúm cổng được gia cố, giám sát, nhất quán với mô hình kết nối internet đáng tin. Lưu lượng liên cơ quan chạy qua các kết nối riêng, và mọi điểm cuối bên ngoài được kiểm kê, để các đội bảo mật biết chính xác cái gì có thể vào và ra. Cơ quan vận hành một kiến trúc không tin cậy trong đó các dịch vụ xác thực với nhau theo danh tính với thông tin xác thực sống ngắn, và không yêu cầu nào được tin chỉ vì xuất phát từ bên trong chu vi. Quản lý DNS và chứng chỉ được coi là hạ tầng quan trọng với giám sát chuyên dụng, vì một chứng chỉ hết hạn hoặc một thay đổi vùng sai có thể đưa một cổng thông tin trợ cấp hướng đến công dân ngoại tuyến và tạo ra sự soi xét cả công khai lẫn lập pháp.

Luận chứng kinh doanh: động lực, ROI và TCO

Kỷ luật mạng được mua rẻ và sự vắng mặt của nó phải trả giá ở thời điểm tệ nhất có thể. Khoản đầu tư chủ yếu là một lần và mang hình dạng nền tảng: máy khách dùng chung với thời gian chờ và thử lại, quản lý chứng chỉ tự động, giám sát DNS, một VPC được phân đoạn hợp lý, và lưu đệm rìa. Mỗi cái mang lợi cho mọi đội thừa hưởng nó, nên chi phí biên theo đội thấp trong khi lợi ích cộng dồn. Đặc biệt một CDN thường tự hoàn vốn hai lần, cắt giảm chi phí băng thông nguồn trong khi cải thiện các con số chuyển đổi và tương tác theo sau từ tải trang nhanh hơn.

Chi phí của việc bỏ qua công việc này được đo bằng sự cố và xâm phạm. Một chứng chỉ hết hạn hoặc một thay đổi DNS sai có thể đưa cả sản phẩm ngoại tuyến trong vài phút, với bản sửa bị trì hoãn khi các kỹ sư đuổi theo sai tầng. Một thời gian chờ thiếu có thể lan một phụ thuộc chậm thành đình trệ toàn nền tảng. Đi ra không kiểm soát biến một khối lượng công việc bị xâm nhập thành một sự cố rút dữ liệu. Hãy đóng khung lập luận với ban lãnh đạo bằng những thứ họ đã theo dõi: tính sẵn sàng, thời gian phục hồi trung bình, thời gian tải trang và rủi ro xâm phạm. Quản lý chứng chỉ và DNS tự động ngăn một loại sự cố tự gây ra, đầu tư rìa và CDN dịch chuyển một chỉ số hiệu năng sản phẩm, và phân đoạn cùng kiểm soát đi ra thu nhỏ bán kính ảnh hưởng xâm phạm. Lập luận tổng chi phí sở hữu là cái lặp lại xuyên suốt hướng dẫn này: xây năng lực vào chỉ bằng một phần nhỏ chi phí trang bị bổ sung sau sự cố buộc phải làm.

Phản mẫu và cạm bẫy

Giả định mạng đáng tin cậy và nhanh. Viết mã như thể lệnh gọi từ xa là cục bộ, không thời gian chờ, không thử lại, không xử lý “hết thời gian chờ nhưng có thể đã hoàn thành.”
Quản lý chứng chỉ thủ công. Theo dõi hết hạn trong bảng tính hay trí nhớ ai đó, bảo đảm một sự cố cuối cùng khi nó lặng lẽ hết hạn.
Bỏ qua DNS như một hệ thống vận hành. Không giám sát phân giải, TTL cẩu thả, và thay đổi bản ghi thực hiện không có sự chặt chẽ của một lần triển khai.
Thử lại không có tính lũy đẳng hay độ lùi. Tác dụng phụ trùng lặp và bão thử lại đồng bộ khuếch đại một gợn sóng nhỏ thành sự cố.
Tin mạng nội bộ. Coi bất cứ thứ gì bên trong chu vi là an toàn, với lưu lượng nội bộ không mã hóa và không cấp quyền dựa trên danh tính.
Đi ra không kiểm soát. Cho phép khối lượng công việc với tới bất kỳ đích đi ra nào, trao cho kẻ tấn công đường rút dữ liệu và kênh đến máy chủ chỉ huy.
Đường yêu cầu lắm lời. Chuỗi gọi đồng bộ sâu nơi mỗi bước nhảy thêm một vòng đi về, nên độ trễ đuôi phình ra dưới tải.
Áp dụng lưới dịch vụ quá sớm. Nhận độ phức tạp và độ trễ sidecar cho một nhúm dịch vụ mà một máy khách dùng chung sẽ phục vụ tốt hơn.

Mô hình trưởng thành

Mức 1, Khởi đầu: Lệnh gọi từ xa được coi như lệnh gọi cục bộ. Thời gian chờ và thử lại thiếu hoặc ngây thơ, và “hết thời gian chờ nhưng có thể đã hoàn thành” không được xử lý. Chứng chỉ và DNS được quản lý bằng tay và gây ra các sự cố bất ngờ. Không có phân đoạn, và lưu lượng nội bộ được tin theo mặc định. Công việc kết nối là phản ứng, chỉ xảy ra sau khi một sự cố buộc phải làm.
Mức 2, Phát triển: Một số đội đã áp dụng các thực hành cơ bản, nhưng chúng không nhất quán qua các dịch vụ. Thời gian chờ và thử lại đơn giản tồn tại ở vài nơi, TLS được kết thúc ở bộ cân bằng tải, và chứng chỉ phần lớn đã tự động. Một CDN đứng trước nội dung tĩnh và phân đoạn mạng cơ bản tồn tại, dù đi ra phần lớn mở và mỗi đội tự phát minh máy khách của mình. Điều một đội làm tốt thì đội khác chưa bắt đầu.
Mức 3, Chuẩn hóa: Mạng có khả năng phục hồi được lập tài liệu và thực thi toàn tổ chức. Thời gian chờ, độ lùi với nhiễu và bộ ngắt mạch là tiêu chuẩn qua các thư viện dùng chung hoặc một cổng mà mọi đội thừa hưởng. DNS và chứng chỉ được giám sát và tự động hóa như các hệ thống sản xuất, VPC được phân đoạn với đi vào và đi ra được kiểm soát, đo đạc mức kết nối được thu thập ở mọi nơi, và các nguyên tắc không tin cậy đang được áp dụng như chính sách thay vì thí nghiệm của một đội.
Mức 4, Quản lý: Ranh giới mạng được đo và kiểm soát theo các đường cơ sở, không chỉ được chuẩn hóa. Độ trễ phân giải, thời gian bắt tay TLS, tỷ lệ truyền lại và lỗi kết nối, độ trễ đuôi (p99, không phải trung bình), thời gian dẫn trước hết hạn chứng chỉ, và vi phạm chính sách đi ra được theo dõi trên bảng điều khiển với ngưỡng cảnh báo và ngân sách lỗi. Các quyết định đi/không đi và năng lực được dẫn dắt bởi dữ liệu đó, các bài diễn tập thất bại DNS và phụ thuộc được gây ra chạy theo lịch và kết quả được đo, và một hồi quy ở bất kỳ tín hiệu nào được bắt và có người sở hữu thay vì được phát hiện trong sự cố kế tiếp.
Mức 5, Điều phối: Mạng có khả năng phục hồi là mặc định nền tảng được cải thiện liên tục, tích hợp trong toàn tổ chức và thích ứng với thay đổi. TLS tương hỗ và cấp quyền dựa trên danh tính là đồng nhất, thường qua một lưới dịch vụ; chiến lược rìa và CDN được điều chỉnh theo dữ liệu độ trễ trực tiếp; đi ra được quản trị hoàn toàn; và các lựa chọn cấu trúc liên kết, nhà cung cấp và định tuyến được cân bằng lại khi chi phí, rủi ro và lưu lượng dịch chuyển. Các quyết định mạng được đan vào hoạch định năng lực, bảo mật và kinh doanh, và tổ chức suy luận tường minh về vòng đi về, độ trễ đuôi và chế độ thất bại ranh giới như lẽ đương nhiên.

Ý tưởng để thảo luận

Nếu nhà cung cấp DNS hay bộ phân giải chính của bạn suy giảm trong một giờ, bao nhiêu phần hệ thống của bạn vẫn hoạt động, và làm sao bạn biết?
Dịch vụ nào của bạn vẫn gửi lưu lượng không mã hóa một khi nó “ở bên trong” mạng, và cần gì để đóng khoảng trống đó?
Các chuỗi gọi đồng bộ sâu nhất trong kiến trúc của bạn ở đâu, và một yêu cầu người dùng điển hình thực sự phải chịu bao nhiêu vòng đi về mạng?
Thời gian chờ của bạn có kết hợp xuống chuỗi gọi thành một ngân sách mạch lạc không, hay mỗi tầng tự đặt và hy vọng?
Khối lượng công việc của bạn hiện có thể với tới gì trên internet công cộng, và ai đã duyệt từng đích đi ra đó?
Ở số lượng dịch vụ nào thì việc thực thi đồng nhất của lưới dịch vụ vượt chi phí vận hành của nó với tổ chức của bạn, và bạn gần đến đó đến đâu?

Những điểm cần ghi nhớ

Mạng là một phụ thuộc với các chế độ thất bại riêng; hãy thiết kế mọi lệnh gọi từ xa cho sự chậm trễ, mất mát và hoàn thành mơ hồ, không chỉ thành công hay thất bại rõ ràng.
Độ trễ được chi phối bởi vòng đi về và khoảng cách, nên hãy cắt giảm bước nhảy, tái sử dụng kết nối, và đưa dữ liệu gần người dùng hơn bằng CDN và rìa.
DNS và chứng chỉ TLS hỏng trong im lặng và kéo cả dịch vụ xuống; hãy tự động hóa và giám sát cả hai như các hệ thống sản xuất.
Cân bằng tải ở tầng phù hợp với lưu lượng, và chỉ đặt các mối quan tâm dùng chung sau cổng L7 khi chi phí sẵn sàng và khả năng quan sát được biện minh.
Làm ranh giới mạng có khả năng phục hồi theo mặc định bằng thời gian chờ, thử lại có giới hạn với nhiễu, và bộ ngắt mạch, lý tưởng là mặc định nền tảng được thừa hưởng.
Phân đoạn VPC của bạn, quản trị đi ra, lên kế hoạch cho IPv6, và áp dụng không tin cậy để “ở bên trong” mạng không mang lại sự tin cậy tự động.

Tài liệu tham khảo và đọc thêm

W. Richard Stevens, TCP/IP Illustrated, Volume 1: The Protocols
Ilya Grigorik, High Performance Browser Networking
Cricket Liu và Paul Albitz, DNS and BIND
Andrew S. Tanenbaum và David J. Wetherall, Computer Networks
Michael Nygard, Release It!: Design and Deploy Production-Ready Software
Evan Gilman và Doug Barth, Zero Trust Networks: Building Secure Systems in Untrusted Networks
Lee Calcote và Zack Butcher, Istio: Up and Running (các khái niệm lưới dịch vụ)
Internet Engineering Task Force, RFC 9110 (HTTP Semantics) và RFC 9000 (QUIC)
Peter Deutsch và James Gosling, “The Eight Fallacies of Distributed Computing”
National Institute of Standards and Technology, Special Publication 800-207: Zero Trust Architecture