Rút Dây Là Đi — Thiết Kế Hub-Spoke Sinh Ra Cho Sự Mất Kết Nối

Trước hết, nói về một Hub-Spoke mà bạn đã biết

Có thể bạn chưa nghe thuật ngữ "tô-pô Hub-Spoke," nhưng bạn sử dụng nó mỗi ngày.

Mở bản đồ tuyến bay của bất kỳ hãng hàng không nào. Bạn sẽ thấy vài nút khổng lồ — Hà Nội, Đà Nẵng, TP.HCM — tỏa ra hàng chục tuyến bay dày đặc, kết nối đến vài chục thành phố nhỏ hơn. Các nút lớn là Hub (trục trung tâm), các thành phố nhỏ là Spoke (nan hoa).

Tại sao các hãng hàng không thiết kế như vậy? Bởi vì nếu mỗi thành phố đều bay thẳng đến mọi thành phố khác, 30 thành phố cần 435 tuyến bay. Nhưng nếu tất cả các thành phố trước hết bay đến Hub rồi nối chuyến từ Hub, chỉ cần 30 tuyến bay. Hub là người điều phối, tập trung xử lý việc điều độ, nối chuyến và phân bổ tài nguyên.

Mô hình này cũng rất phổ biến trong các hệ thống thông tin: một nút trung tâm điều phối nhiều nút ở biên. Dữ liệu tập trung tại Hub, Spoke phụ trách thao tác tuyến đầu.

Nhưng Hub-Spoke truyền thống có một giả định chí mạng: Hub luôn trực tuyến.

Chuyến bay có thể chờ sân bay Hub mở lại. Gói hàng có thể chờ trung tâm phân loại xử lý. Nhưng tại hiện trường thảm họa, nếu Hub sập, bệnh nhân không thể chờ.

Hub-Spoke của xGrid thực hiện hai thay đổi quan niệm then chốt: mỗi Spoke là một hệ thống hoàn chỉnh, không chỉ là một thiết bị đầu cuối. Và — bất kỳ Spoke nào cũng có thể tiếp quản ngay tại hiện trường để trở thành Hub mới.

Mất kết nối không phải là sự cố, mà là trạng thái được mong đợi

Hệ thống truyền thống xử lý việc mất kết nối mạng như một "sự cố" — phát hiện mất kết nối, kích hoạt cảnh báo, chờ phục hồi.

xGrid thiết kế sự mất kết nối như điều "bình thường." Mỗi thiết bị là một hệ thống hoàn chỉnh — có hệ thống tài nguyên riêng, cơ sở dữ liệu riêng. Mất kết nối chỉ là tạm thời mất khả năng đồng bộ, chứ không phải mất khả năng vận hành.

Đây chính là khác biệt lớn nhất giữa Hub-Spoke phiên bản xGrid và phiên bản hàng không: Spoke không phải là thiết bị đầu cuối chờ lệnh từ Hub, mà là một hệ thống hoàn chỉnh có thể vận hành độc lập. Thứ Hub cung cấp là sự phối hợp, không phải năng lực.

Mỗi nút là một hệ thống hoàn chỉnh

Đây là quan niệm then chốt nhất của toàn bộ thiết kế: mỗi thiết bị khi xuất xưởng đều là một trạm y tế hoàn chỉnh.

Vai trò không do phần cứng quyết định. Cùng một cỗ máy, có thể là Hub, cũng có thể là Spoke — khác biệt nằm ở vai trò nó đóng, không phải ở nó là linh kiện gì. Điều này nghĩa là bạn không cần chuẩn bị "máy chuyên dụng làm Hub" và "máy chuyên dụng làm Spoke." Trong kho không phải là "hai loại linh kiện," mà là "một đống thiết bị thay thế giống hệt nhau." Bất kỳ máy nào hỏng, lấy một máy mới từ thùng ra, cắm vào, tiếp tục.

Triển khai tối thiểu chỉ cần một cỗ máy, không cần bất kỳ hạ tầng mạng nào — một nguồn điện, một máy tính bảng, đó đã là một trạm y tế hoàn chỉnh. Cần mở rộng? Mang thêm một máy đến cắm vào, nó trở thành một Spoke mới. Một cỗ máy có thể gánh một trạm y tế tiền phương; một nhóm máy có thể gánh một trung tâm y tế. Cùng một thiết kế, co giãn theo quy mô.

Hai lớp mạng độc lập — một lớp đứt, lớp kia gánh

Triển khai của xGrid là hai lớp mạng độc lập chồng lên nhau: một lớp phụ trách vận hành (mỗi máy tự cung cấp vùng phủ sóng không dây, máy tính bảng kết nối vào máy gần nhất là làm việc được), một lớp phụ trách đồng bộ giữa trạm với trạm.

Mấu chốt là hai lớp này hoàn toàn độc lập. Lớp phụ trách đồng bộ bị đứt? Máy tính bảng của mỗi trạm vẫn tiếp tục vận hành, chỉ là giữa các trạm tạm thời mất đồng bộ. Vùng phủ sóng không dây của một máy nào đó bị hỏng? Đồng bộ vẫn chạy, máy tính bảng ở khu vực đó chỉ cần đổi sang kết nối vùng phủ sóng lân cận.

Một lớp đứt, lớp kia gánh. Đây chính là hình hài của "mất kết nối là trạng thái được mong đợi" khi được hiện thực hóa vào thiết kế mạng.

Bất kỳ Spoke nào cũng có thể tiếp quản

Đây là khả năng mạnh mẽ nhất của toàn bộ thiết kế, và nó có hai hình thái.

Chủ động mang đi. Trong sự cố thương vong hàng loạt, trung tâm chỉ huy thông báo có một điểm tập trung thương vong thứ hai xuất hiện cách mười km, cần mở ngay một trạm y tế thứ hai. Bạn đi đến một trong các Spoke, cho nó cùng pin và máy tính bảng vào ba lô, đến địa điểm mới cắm nguồn điện — nó trở thành một trạm y tế mới hoàn chỉnh, vận hành độc lập, mang theo toàn bộ dữ liệu bệnh nhân mà Hub gốc có cho đến cách đây không lâu. Không cần lập kế hoạch trước, không cần máy đặc biệt.

Bị động tiếp quản. Phần cứng của Hub hỏng — nguồn cháy, bị mảng trần rơi trúng. Mỗi Spoke đều liên tục giám sát xem Hub còn đó hay không. Sau khi xác nhận Hub thực sự đã ngoại tuyến, người vận hành chỉ định một trong các Spoke tiếp quản. Vì mỗi Spoke đều giữ trong tay một bản sao lưu gần như tức thời, tổn thất dữ liệu bệnh nhân sau khi tiếp quản có một giới hạn rõ ràng; vào lúc cao điểm thương vong dồn dập, người vận hành còn có thể tự tay ép giới hạn này xuống thấp hơn nữa.

Việc thăng cấp tiếp quản là một thao tác toàn vẹn thành công hoặc toàn vẹn thất bại — hoặc tiếp quản trọn vẹn, hoặc quay về nguyên trạng, không bao giờ xuất hiện thành phẩm dở dang "thăng cấp được nửa chừng thì kẹt lại."

Tại sao là quyết định của con người, không phải máy tự động? Vì trong môi trường mất kết nối, bạn không thể chắc chắn Hub thật sự hỏng, hay chỉ là dây mạng bị lỏng. Nếu hai Spoke cùng lúc tự động tiếp quản, bạn sẽ có hai Hub mỗi cái tự thu nhận bệnh nhân — gọi là split-brain, và việc hợp nhất dữ liệu về sau sẽ là một thảm họa. Vì vậy việc tiếp quản phải là quyết định có chủ ý của con người.

Hub xác sống và bảo vệ chống tách não — dựa vào cơ chế, không dựa vào tự giác

"Không thăng cấp hai máy cùng lúc" là một quy tắc. Nhưng quy tắc tại hiện trường thảm họa sẽ bị phá vỡ — lỡ có người trong lúc hỗn loạn nhấn thêm một lần thì sao?

Vì vậy chỉ dựa vào tự giác là không đủ. Thiết kế của xGrid khiến Hub đã lỗi thời tự nhường chỗ: khi một Hub cũ từng hỏng rồi được cắm điện lại khởi động lên, nó sẽ phát hiện tại hiện trường đã có một Hub "mới hơn một thế hệ" đang vận hành — nó không tìm cách giành lại quyền chủ, mà tự động lui xuống thành Spoke. Không cần ai đi tắt nó.

Tương tự, nếu một Spoke khi kết nối lại đồng thời thấy hai "trạm chính" mâu thuẫn với nhau, nó sẽ không tự ý chọn bừa một cái, mà dừng lại nhờ con người xác nhận. Mỗi triển khai cũng cô lập lẫn nhau, Spoke của bạn sẽ không vô tình kết nối vào Hub của triển khai bên cạnh.

Cơ chế này không thể ngăn chặn tách não một trăm phần trăm — nếu hai nhóm con hoàn toàn mất kết nối mỗi nhóm tự tiếp quản một Hub, bạn đúng là sẽ có hai Hub độc lập. Nhưng nó bảo đảm: ngay khoảnh khắc hai nhóm con kết nối lại với mạng, cái cũ hơn sẽ tự động nhường chỗ. Vấn đề chưa bao giờ là "làm sao ngăn chặn tách não mãi mãi," mà là "làm sao tự động sửa chữa nhanh nhất sau khi tách não xảy ra."

Giải quyết xung đột: tùy thuộc vào bản chất của dữ liệu

Hai thiết bị trong thời gian mất kết nối, mỗi cái sửa đổi cùng một bản ghi, khi kết nối lại thì làm thế nào?

Câu trả lời tùy thuộc dữ liệu là gì. Cái nào có thể cộng dồn thì cộng dồn — trạm chính tiêu thụ 5 cuộn băng, trạm vệ tinh tiêu thụ 3, đáp án đúng là 8 đã tiêu thụ, chứ không phải "lấy cái mới nhất làm chuẩn" (như thế sẽ làm mất một bên). Các bản ghi bất biến (dấu hiệu sinh tồn, bàn giao) thì cả hai bên đều giữ lại.

Quan trọng nhất là những dữ liệu mà cái giá của sai sót quá đắt, không cho phép tự động giải quyết: túi máu, chất kiểm soát. Một túi máu bị hai trạm đồng thời đánh dấu "đã cấp phát," đây không phải vấn đề có thể giải quyết bằng dấu thời gian. Hệ thống sẽ đánh dấu nó là xung đột, chờ nhân viên phụ trách đích thân xác minh.

Coi "phán đoán của con người" là đáp án đúng trong một số tình huống, chứ không phải một khiếm khuyết cần loại bỏ — đây là ranh giới then chốt khi thiết kế cho môi trường rủi ro cao.

Triết lý thiết kế: sinh ra cho sự mất kết nối

Phần lớn các hệ thống thiết kế với tiền đề "mạng là đáng tin cậy," rồi xử lý ngoại lệ cho trường hợp không đáng tin cậy.

xGrid thiết kế với tiền đề "mạng là không đáng tin cậy," rồi tối ưu cho trường hợp đáng tin cậy.

Sự đảo ngược này dẫn đến những quyết định thiết kế hoàn toàn khác biệt:

• Mỗi nút là một hệ thống hoàn chỉnh (không phải thiết bị đầu cuối chỉ hiển thị được màn hình)
• Vai trò do việc đóng vai quyết định, không do phần cứng quyết định (không cần "máy Hub đặc biệt")
• Đồng bộ là thao tác theo lô định kỳ (không phải kết nối liên tục thời gian thực)
• Giải quyết xung đột là hành vi mặc định (không phải xử lý ngoại lệ)
• Phán đoán của con người là đáp án đúng trong một số tình huống (không phải khiếm khuyết cần loại bỏ)
• Tiếp quản là quyết định có chủ ý của con người (vì split-brain nguy hiểm hơn việc chờ đợi)
• Nhưng Hub lỗi thời tự động nhường chỗ (vì đây là sự thật, không phải sự tự giác)

Dây mạng bị đá tuột không phải là sự cố. Switch bị đập hỏng không phải là ngày tận thế. Hub cháy rụi không phải là dấu chấm hết.

Chúng chỉ là điểm kích hoạt cho việc tái cấu trúc tô-pô.

---

Bài liên quan: "Offline-First" không phải là "tạm dùng được khi offline" · ISBAR không chỉ là định dạng bàn giao — khi truyền thống truyền miệng gặp dữ liệu có cấu trúc