IIMS – Kiến trúc Nhà cung cấp & Tích hợp (Provider & Integration Architecture)

Mục đích

Tài liệu này mô tả cách IIMS tích hợp với các hệ thống bên ngoài trong nền tảng hiện tại, dựa trên việc triển khai iims‑api và Flutter UI hiện nay.

Tài liệu giải thích:

Kiến trúc adapter và định tuyến thực tế đã được triển khai
Phạm vi và các giới hạn của tích hợp hiện tại
Lộ trình và các mở rộng được khuyến nghị cho tương lai

Mục tiêu là cung cấp một tài liệu tham chiếu chính xác và có thể kiểm toán cho kiến trúc sư, kỹ sư và chủ sản phẩm.

1. Triết lý Tích hợp (Hiện tại)

1.1 Tích hợp, không thay thế

IIMS không thay thế các hệ thống vận hành như giám sát, ticketing hay định danh.

Trong hiện tại:

Các hệ thống giám sát tiếp tục thu thập metric và sinh alert
Các hệ thống ticket tiếp tục quản lý quy trình
Các hệ thống định danh tiếp tục quản lý xác thực

IIMS đóng vai trò như một lớp điều phối và thông tin trung tâm, hợp nhất:

Ngữ cảnh inventory (site, asset)
Định tuyến và cấu hình
Alert, incident, maintenance và ticket

1.2 Độc lập nhà cung cấp (phạm vi hiện tại)

Trong hiện tại, IIMS được thiết kế độc lập nhà cung cấp, nhưng đang tích cực hỗ trợ:

Nhà cung cấp giám sát: Zabbix (triển khai chính)
Nhà cung cấp ticket: Zammad
Nhà cung cấp định danh: Keycloak

Domain model nội bộ không bao giờ phụ thuộc vào schema riêng của nhà cung cấp.

Ghi chú:

Prometheus và các nhà cung cấp khác đã được lên kế hoạch nhưng chưa kích hoạt
Vận hành đa nhà cung cấp được hỗ trợ về kiến trúc nhưng mới được sử dụng một phần

2. Các Thành phần Tích hợp Cốt lõi

2.1 Monitoring Target

Monitoring Target đại diện cho một kết nối đã được cấu hình tới một backend giám sát.

Ví dụ hiện tại:

Một máy chủ Zabbix

Vai trò:

Lưu endpoint, thông tin xác thực và loại nhà cung cấp
Điểm vào cho provisioning, telemetry, alert và đồng bộ maintenance

Target trả lời câu hỏi:
Asset này sử dụng hệ thống giám sát nào?

Ghi chú hiện tại:

Mô hình hỗ trợ nhiều target
Định tuyến giữa nhiều target được hỗ trợ về logic
Triển khai thực tế chủ yếu tập trung vào Zabbix

Kế hoạch:

Kích hoạt target Prometheus
Môi trường đa nhà cung cấp theo site
Khám phá năng lực provider và feature flag

2.2 Collector

Collector đại diện cho một proxy hoặc nhóm agent dùng để thu thập dữ liệu giám sát.

Ví dụ hiện tại:

Nhóm Zabbix proxy

Vai trò:

Xác định nguồn phát sinh lưu lượng giám sát
Điều khiển việc định tuyến asset tới proxy
Áp dụng ràng buộc định tuyến (site, tag, loại asset, giới hạn dung lượng)

Collector trả lời câu hỏi:
Asset này được giám sát từ đâu?

Hành vi hiện tại:

Collector được chọn dựa trên ràng buộc và chính sách tĩnh
Dung lượng được theo dõi nhưng chưa tối ưu động
Định tuyến mang tính quyết định và dựa trên chính sách

Kế hoạch:

Định tuyến theo dung lượng và cân bằng tải
Giám sát sức khỏe collector và failover tự động
Chính sách định tuyến theo địa lý và SLA

3. Mô hình Định tuyến Target và Collector

3.1 Nguyên tắc Định tuyến (Hiện tại)

Định tuyến xác định:

Monitoring target nào được gán cho asset
Collector nào thực hiện thu thập

Quyết định định tuyến dựa trên:

Cấu hình asset
Mặc định của site
Ràng buộc collector (site cho phép, tag, loại asset, dung lượng)

Đặc điểm hiện tại:

Dựa trên chính sách và mang tính quyết định
Nhận biết theo site
Không có cân bằng tải hay failover động

3.2 Luồng Định tuyến (Hiện tại)

Luồng provisioning điển hình:

Một asset được chọn để giám sát
IIMS xác định monitoring target (asset → site → mặc định)
IIMS đánh giá các ràng buộc định tuyến collector
Một collector được chọn
Yêu cầu được chuyển tới adapter nhà cung cấp

Điều này đảm bảo:

Chọn đúng backend
Định tuyến theo chính sách
Giám sát theo ngữ cảnh site

Kế hoạch:

Định tuyến nhiều ứng viên với chấm điểm
Tự động chuyển tuyến khi collector lỗi
Lựa chọn theo dung lượng và độ trễ

4. Mẫu Adapter

4.1 Mục đích của Adapter

Mỗi nhà cung cấp bên ngoài được tích hợp thông qua một lớp adapter.

Adapter:

Chuyển đổi thao tác miền của IIMS sang API riêng của nhà cung cấp
Chuẩn hóa phản hồi nhà cung cấp thành đối tượng miền của IIMS

Adapter cô lập nền tảng lõi khỏi API và schema của vendor.

4.2 Trách nhiệm của Adapter (Hiện tại)

Các trách nhiệm đã triển khai:

Adapter giám sát (Zabbix):

Provision asset và gán template
Khám phá telemetry và interface
Thu thập và chuẩn hóa alert
Hành động alert (acknowledge, đóng, suppress)
Đồng bộ maintenance

Adapter ticket (Zammad):

Tạo ticket từ incident
Truy vấn trạng thái ticket
Đồng bộ comment và đóng ticket (giới hạn)

Ghi chú:

Adapter chỉ lộ ra các đối tượng miền đã chuẩn hóa
ID riêng của nhà cung cấp chỉ được lưu trong external reference

Kế hoạch:

Kích hoạt adapter Prometheus
Đồng bộ hai chiều trạng thái ticket
Hỗ trợ nhiều ticket cho một incident
Tự động hóa maintenance phía provider

5. Registry Nhà cung cấp và Lớp Định tuyến

5.1 Provider Registry (Hiện tại)

IIMS duy trì một registry trung tâm:

Đăng ký adapter khi khởi động
Phân giải adapter theo loại provider
Cung cấp giao diện ổn định cho domain service

Registry được sử dụng bởi:

Router giám sát
Router ticket
Worker đồng bộ maintenance

5.2 Lớp Định tuyến

Lớp định tuyến:

Nhận yêu cầu miền (provisioning, telemetry, sync alert, ticketing)
Phân giải target và collector
Chọn adapter phù hợp
Chuyển tiếp yêu cầu tới provider

Lớp này che giấu toàn bộ độ phức tạp của provider khỏi:

Domain service
UI và workflow

Kế hoạch:

API giải thích và mô phỏng định tuyến (debug và UI)
Chiến lược định tuyến đa nhà cung cấp

6. Chiến lược Đa Nhà cung cấp

6.1 Phạm vi Hiện tại

Hỗ trợ về kiến trúc:

Nhiều monitoring target
Nhiều collector
Nhiều ticket target

Đã triển khai thực tế:

Zabbix là nhà cung cấp giám sát chính
Zammad là nhà cung cấp ticket chính

Ghi chú:

Các site khác nhau có thể dùng nhà cung cấp khác nhau, nhưng chưa được khai thác nhiều

6.2 Di trú và Đồng tồn tại (Hướng Kế hoạch)

Do nhà cung cấp đã được trừu tượng hóa:

Có thể thêm nhà cung cấp mới mà không đổi logic miền
Có thể loại bỏ nhà cung cấp cũ dần dần
UI và workflow không thay đổi

Kế hoạch:

Vận hành song song Zabbix + Prometheus
Tương quan alert xuyên nhà cung cấp
Công cụ hỗ trợ di trú và đối soát dữ liệu

7. Xử lý Lỗi và Khả năng Chịu lỗi

Hành vi hiện tại:

Lỗi provider được cô lập theo từng yêu cầu
Lỗi được ghi trong trạng thái sync và activity log
Worker nền retry các thao tác thất bại

Hạn chế:

Không có failover provider tự động
Không có định tuyến dựa trên sức khỏe

Kế hoạch:

Giám sát sức khỏe provider
Failover tự động giữa các target
Chiến lược định tuyến chế độ suy giảm

8. Bảo mật và Quản lý Bí mật

Nguyên tắc hiện tại:

Thông tin xác thực provider lưu trong Vault / secret store
Không lưu mật khẩu dạng plain text
Secret được inject tại runtime

Xác thực:

Người dùng → IIMS: qua Keycloak (OIDC)
IIMS → provider: dùng credential dịch vụ riêng

Kế hoạch:

Xoay vòng secret tự động
Version hóa credential theo target
Audit trail cho việc sử dụng credential

9. Mở rộng IIMS với Nhà cung cấp Mới

Để thêm một provider mới:

Triển khai adapter mới theo interface chuẩn
Đăng ký adapter trong provider registry
Cấu hình monitoring hoặc ticket target mới
Tùy chọn định nghĩa collector và ràng buộc định tuyến

Không cần thay đổi:

Core domain model
Giao diện người dùng
Quy trình incident và maintenance

10. Lộ trình Kiến trúc Tích hợp

Các trọng tâm kế hoạch:

Kích hoạt đa nhà cung cấp (Zabbix + Prometheus)
Định tuyến theo dung lượng và sức khỏe
Failover provider tự động
Tương quan alert xuyên nhà cung cấp
Đồng bộ ticket hai chiều
API khám phá năng lực provider
UI mô phỏng và debug định tuyến

11. Tổng kết

Trong hiện tại, kiến trúc tích hợp nhà cung cấp của IIMS cung cấp:

Trừu tượng adapter sạch
Registry và định tuyến trung tâm
Tách biệt target và collector
Tích hợp ổn định với Zabbix và Zammad

Điều này tạo nền tảng vững chắc cho vận hành độc lập nhà cung cấp.

Trong tương lai, nền tảng sẽ được mở rộng với:

Định tuyến thông minh
Failover tự động
Tương quan đa nhà cung cấp
Công cụ đồng bộ và di trú nâng cao

Các mở rộng này xây dựng trên kiến trúc hiện tại mà không phá vỡ quy trình đang có.