Một Mô Hình 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. Vài nút lớn -- Hà Nội, Đà Nẵng, TP.HCM -- tỏa ra hàng chục kết nối đến các thành phố nhỏ hơn. Các nút lớn là Hub. Các thành phố nhỏ là Spoke. Thay vì bay thẳng từ mọi thành phố đến mọi thành phố khác (cần 435 tuyến cho 30 thành phố), tất cả lưu lượng chảy qua một vài hub. Ít tuyến hơn, nhiều phối hợp hơn, hiệu quả hơn rất nhiều.
Point-to-point (trên) và Hub-and-spoke (dưới): định tuyến qua hub trung tâm giảm đáng kể số kết nối. Nguồn: Wikipedia (public domain)
Logistics hoạt động tương tự. FedEx chuyển mọi thứ qua Memphis. Một gói hàng từ Đài Bắc đến Cao Hùng có thể bay qua Memphis trước -- tưởng vô lý, nhưng phân loại tập trung hiệu quả hơn chuyển tiếp điểm-đến-điểm.
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. Nhưng trong sự cố thương vong hàng loạt, nếu Hub sập, bệnh nhân không thể chờ.
Hub-Spoke của xGrid có hai điều chỉnh quan trọng: 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ể tự thăng cấp thành Hub mới trong vài phút.
Bố Cục Vật Lý: Một Trục Xương Sống, Nhiều Vệ Tinh
Triển khai xGrid không phải hai hộp và một dây cáp. Đó là một tô-pô có thể mở rộng xây dựng quanh một switch Ethernet:
┌─────────────────────┐
│ Hub A │
│ CIRS + MIRS + HIRS │
│ WiFi Hotspot │
│ mDNS broadcast │
└──────────┬──────────┘
│
┌─────────┴─────────┐
│ Ethernet Switch │
└──┬────┬────┬────┬─┘
│ │ │ │
┌──┴┐┌──┴┐┌──┴┐┌──┴┐
│ B ││ C ││ D ││ E │ ← Spokes
└───┘└───┘└───┘└───┘
Mỗi máy có WiFi hotspot riêng
Mỗi máy chạy MIRS đầy đủ
Mỗi máy giữ snapshot CIRS gần nhất
Hub chạy hệ thống tài nguyên (CIRS), hệ thống lâm sàng (MIRS) và kiểm kê kho (HIRS). Nó phát WiFi hotspot -- iPad kết nối vào đó cho mọi hoạt động lâm sàng. Nhiều Spoke kết nối đến Hub qua switch Ethernet, mỗi Spoke chạy MIRS để quản lý kho tại trạm riêng.
Switch là trục dữ liệu -- nhưng không phải điểm lỗi duy nhất. Nếu switch hỏng, mỗi RPi vẫn có WiFi hotspot riêng. Hoạt động lâm sàng trên iPad tiếp tục không gián đoạn tại mọi trạm. Chỉ có đồng bộ giữa các trạm bị tạm dừng.
Hai lớp mạng riêng biệt, theo thiết kế: Ethernet cho đồng bộ dữ liệu giữa các trạm. WiFi cho hoạt động lâm sàng trong mỗi trạm. Một lớp có thể hỏng mà không ảnh hưởng lớp kia.
Mỗi RPi Là Một Hệ Thống Hoàn Chỉnh — Golden Image
Đây là quyết định thiết kế quan trọng nhất trong toàn bộ kiến trúc: mỗi Raspberry Pi xuất xưởng với mọi thứ đã cài sẵn.
CIRS (tài nguyên), MIRS (lâm sàng), HIRS (kiểm kê kho) -- tất cả có mặt trên mọi thẻ SD. Vai trò không do phần cứng quyết định. Nó do một tập tin cấu hình duy nhất quyết định: /etc/xgrid/role.conf. Thay đổi một trường và Spoke trở thành Hub.
Điều này nghĩa là bạn không cần dự trữ "máy Hub" và "máy Spoke." Bạn dự trữ các bộ thay thế giống hệt nhau. Bất kỳ máy nào cũng thay thế được bất kỳ máy nào khác.
Triển Khai Theo Cấp — Từ Trạm Tiền Phương Đến Trung Tâm Y Tế
Không phải triển khai nào cũng cần năm máy. Tô-pô mở rộng theo nhiệm vụ:
| Cấp | Cấu hình | Kết nối | Tablet đồng thời |
|---|---|---|---|
| Trung tâm Y tế | 1 Hub + 4 Spoke | Switch 8 cổng | ~75 |
| Bệnh viện Khu vực | 1 Hub + 3 Spoke | Switch 5 cổng | ~60 |
| Bệnh viện Huyện | 1 Hub + 1 Spoke | Cáp trực tiếp | ~30 |
| Trạm Tiền phương | 1 Độc lập | Không cần | ~15 |
Cùng một Golden Image hoạt động ở mọi cấp. Sự khác biệt là bao nhiêu máy bạn triển khai và vai trò gán cho chúng -- không phải phần mềm chúng mang theo.
Mất Kết Nối Không Phải Là Lỗi — Đó Là Trạng Thái Được Mong Đợi
Trong hệ thống truyền thống, mất liên kết mạng kích hoạt cảnh báo, giảm dịch vụ và khởi động quy trình phục hồi.
Trong xGrid, mất liên kết mạng không kích hoạt bất cứ điều gì nhìn thấy được đối với nhân viên lâm sàng. Cả hai hệ thống tiếp tục hoạt động đầy đủ chức năng -- cơ sở dữ liệu riêng, giao diện lâm sàng riêng, trạm tablet riêng.
Nguyên tắc thiết kế cơ bản: mỗi Spoke là một hệ thống hoàn chỉnh. Hub cung cấp phối hợp, không phải năng lực. Khi mất phối hợp, điều duy nhất thay đổi là thời điểm đồng bộ.
Đồng Bộ Ba Giai Đoạn
Khi trục Ethernet khỏe mạnh, Hub và Spoke đồng bộ qua quy trình ba giai đoạn:
Giai đoạn 1 — Xác minh: Hub kiểm tra sức khỏe mỗi Spoke. Không phản hồi trong 30 giây -- bỏ qua. Kiểm tra căn chỉnh đồng hồ đảm bảo cả hai thiết bị thống nhất về thời gian hiện tại. Nếu chênh lệch hơn 30 giây, đồng bộ bị từ chối để ngăn hỏng timestamp.
Giai đoạn 2 — Đẩy (Hub đến Spoke): Sự kiện lâm sàng chảy ra ngoài: hồ sơ bệnh nhân, đăng ký, đơn thuốc, dấu hiệu sinh tồn, bản ghi bàn giao. Hub đẩy snapshot đầy đủ CIRS đến mọi Spoke mỗi năm phút. Các snapshot được lưu cục bộ trên mỗi Spoke -- 12 bản gần nhất, một cửa sổ sao lưu cuốn chiếu một giờ.
Giai đoạn 3 — Kéo (Spoke đến Hub): Sự kiện tài nguyên chảy vào trong: thay đổi kho, hoạt động ngân hàng máu, hồ sơ phẫu thuật, nhật ký cấp phát.
Sáu Chiến Lược Giải Quyết Xung Đột
Hai thiết bị sửa đổi cùng một bản ghi trong thời gian mất kết nối. Khi kết nối lại, phiên bản nào thắng?
| Chiến lược | Loại dữ liệu | Logic |
|---|---|---|
| Thêm cả hai | Dấu hiệu sinh tồn, bàn giao, cấp phát | Sự kiện bất biến — giữ cả hai |
| Mới nhất thắng | Nhân khẩu bệnh nhân | So sánh timestamp, bản cập nhật gần nhất thắng |
| Hub thắng | Đăng ký, đơn thuốc, phẫu thuật | CIRS (Hub) có thẩm quyền |
| Cộng cả hai | Số lượng kho | Cộng tiêu thụ cả hai bên |
| Luôn chặn | Sản phẩm máu, chất kiểm soát | Không bao giờ tự giải quyết — cần người xác minh |
| Tại chỗ thắng | Trạng thái thiết bị | Người vận hành có mặt tại chỗ được ưu tiên |
Cộng cả hai cho kho: Hub tiêu thụ 5 băng, Spoke tiêu thụ 3. Đáp án đúng không phải "ai cập nhật cuối cùng" -- đáp án đúng là 5 + 3 = 8 đã tiêu thụ.
Luôn chặn cho sản phẩm máu: Một đơn vị máu được đánh dấu "đã cấp" trên cả hai trạm đồng thời không thể giải quyết bằng bất kỳ quy tắc tự động nào. Ai đó cần xác minh vật lý đơn vị máu đó thực sự ở đâu.
Rút Dây Là Đi — Spoke Thăng Cấp Thành Hub
Đây là khả năng mạnh mẽ nhất trong toàn bộ kiến trúc.
Bạn đang vận hành triển khai 1 Hub + 3 Spoke tại sự cố thương vong hàng loạt. Hai giờ sau, chỉ huy báo cáo một điểm thu gom thương vong thứ hai cách mười km. Bạn cần một trạm y tế hoạt động ở đó ngay.
Bạn đi đến một Spoke. Rút cáp Ethernet. Cho vào túi với pin và iPad. Lái đến địa điểm mới. Cắm điện. SSH vào và chạy một lệnh:
sudo xgrid-promote
Quy trình thăng cấp là một máy trạng thái nguyên tử. Nếu bất kỳ bước nào thất bại, toàn bộ hoạt động rollback -- máy quay về chế độ Spoke.
iPad kết nối WiFi mới, mở PWA, và bạn đang nhìn vào một trạm y tế hoạt động đầy đủ mang dữ liệu bệnh nhân từ Hub gốc -- tối đa năm phút trước.
Hub Sập — Tiếp Quản Trong Năm Phút
Hub hỏng phần cứng. Mỗi Spoke liên tục giám sát nhịp tim Hub -- mỗi 30 giây. Ba lần thất bại liên tiếp (90 giây im lặng) kích hoạt banner đỏ trên PWA: "Hub offline."
Người vận hành quyết định: Spoke nào tiếp quản? Họ nhấn nút thăng cấp trên PWA hoặc chạy xgrid-promote qua SSH.
Tổn thất dữ liệu bệnh nhân tối đa là năm phút -- khoảng cách giữa các lần đẩy snapshot.
Tại sao không thăng cấp tự động? Vì trong môi trường mất kết nối, bạn không thể phân biệt "Hub bị phá hủy" với "cáp Ethernet bị lỏng." Thăng cấp tự động có nguy cơ tạo ra hai Hub đều nghĩ mình là chính -- tình trạng split-brain. Thăng cấp phải là quyết định của con người.
Bảo Vệ Split-Brain — Epoch, Không Phải Tin Tưởng
Mỗi lần Spoke thăng cấp thành Hub, bộ đếm epoch trong role.conf tăng lên. Epoch được nhúng trong mọi snapshot, mọi mDNS broadcast, mọi handshake đồng bộ.
Phát hiện zombie. Hub A (epoch 1) sập và Spoke B thăng cấp (epoch 2). Sau đó ai đó cắm Hub A lại. Khi khởi động, nó quét mạng và phát hiện Hub broadcast epoch 2 -- cao hơn epoch 1 của nó. Hub A tự động hạ cấp thành Spoke.
Xác nhận Spoke. Khi Spoke kết nối lại, nó kiểm tra epoch của mọi Hub. Nếu tìm thấy hai Hub với epoch khác nhau, nó từ chối tự động kết nối lại cho đến khi con người giải quyết.
Cô lập cụm. Mỗi triển khai mang cluster_id duy nhất. Spoke chỉ chấp nhận Hub có cluster_id khớp.
Phát Hiện Dịch Vụ — Không Có IP Cố Định
xGrid sử dụng mDNS (multicast DNS) qua avahi-daemon. Khi Hub khởi động, nó broadcast _xgrid-hub._tcp trên mạng cục bộ. Spoke lắng nghe broadcast này. Khi phát hiện Hub mới với cluster ID hợp lệ và epoch cao hơn, chúng cập nhật mục tiêu kết nối tự động.
Không cần cập nhật tập tin cấu hình. Không cần nhớ địa chỉ IP. Mạng tự mô tả chính nó.
Headless — iPad Là Bảng Điều Khiển
RPi của xGrid không bao giờ có màn hình. Không bao giờ có bàn phím. Không cáp HDMI, không ngoại vi USB.
Mọi công việc lâm sàng diễn ra qua PWA trên WiFi. Quản trị hệ thống qua SSH. Một người với laptop có thể quản trị năm trạm từ một chiếc ghế gấp.
Tổng phần cứng mỗi trạm: một Raspberry Pi, một dây nguồn, một cáp Ethernet (nếu không độc lập). Footprint triển khai đủ nhỏ để vừa một ba lô.
Hợp Nhất Trạm — Khi Phải Sơ Tán
Khi một trạm phải sơ tán, dữ liệu cần hợp nhất vào trạm còn sống. Bốn chế độ hợp nhất xử lý các tình huống khác nhau:
- Hợp nhất đầy đủ: Tất cả dữ liệu chảy vào trạm đích
- Hợp nhất một phần: Chỉ chuyển các danh mục tài nguyên được chọn
- Nhập bản sao lưu: Khôi phục từ bản sao lưu di động
- Đóng khẩn cấp: Tắt trạm với bảo toàn dữ liệu hoàn chỉnh
Mỗi lần hợp nhất ghi lại chính xác những gì đã di chuyển. Đường mòn kiểm toán này trả lời câu hỏi luôn nảy sinh sau thảm họa: "Khi trạm đó sơ tán, mọi thứ đã đi đâu?"
Thiết Kế Cho Mất Kết Nối
Hầu hết hệ thống phân tán bắt đầu từ tiền đề "mạng đáng tin cậy" và thêm xử lý ngoại lệ cho khi không.
xGrid bắt đầu từ tiền đề "mạng không đáng tin cậy" và tối ưu cho khi nó tình cờ hoạt động.
Sự đảo ngược này tạo ra thiết kế khác biệt căn bản:
- Mỗi nút là một hệ thống hoàn chỉnh (không phải thin client phụ thuộc server)
- Mỗi máy xuất xưởng với tất cả phần mềm cài sẵn (vai trò là tập tin cấu hình, không phải biến thể phần cứng)
- Bất kỳ Spoke nào cũng có thể thăng cấp thành Hub
- Đồng bộ là batch định kỳ (không phải streaming real-time)
- Giải quyết xung đột là hành vi mặc định (không phải xử lý ngoại lệ)
- Hub cũ tự hạ cấp (vì epoch counter là sự thật, không phải chính sách)
Dây cáp sẽ bị đá. Switch sẽ bị hất khỏi bàn. Hub sẽ bị trúng.
Không có cái nào là chế độ lỗi. Chúng là chuyển đổi tô-pô.
Bài liên quan: Offline-First Is Not a Fallback · ISBAR Is More Than a Handoff Format