Khi xây dựng hệ thống quản lý đa tài khoản, điều nên xác định trước không phải giao diện mà là các trường và vòng đời của lớp thiết bị. Trừu tượng hóa sai sẽ gây ra chuỗi tái cấu trúc khi số tài khoản tăng hoặc loại thiết bị thay đổi.
Khi phát triển một hệ thống quản lý đa tài khoản, phiên bản đầu tiên thường được nghĩ từ giao diện: tạo danh sách tài khoản, gắn một hồ sơ trình duyệt cho từng tài khoản rồi gọi các giao diện để thực hiện thao tác. Cách này có vẻ đủ dùng cho đến khi hệ thống thực sự chạy.
Cách triển khai đầu tiên thường rất trực tiếp. Tài khoản A trỏ tới hồ sơ 001, tài khoản B trỏ tới hồ sơ 002, còn tài khoản C gắn với một điện thoại đám mây. Vấn đề xuất hiện ở ba chỗ: đội vận hành báo một máy bị hỏng và hỏi có thể chuyển tài khoản A sang điện thoại đám mây hay không, nhưng câu trả lời là phải sửa cơ sở dữ liệu, thao tác thủ công và chấp nhận rủi ro; khi tích hợp một nguồn thiết bị mới và hỏi cách thêm vào, kết quả là phải tái cấu trúc mô-đun tài khoản; hoặc muốn cùng một tài khoản dùng môi trường trình duyệt vào buổi sáng và điện thoại đám mây vào buổi chiều theo khung giờ, điều gần như không thể tổ chức gọn gàng.
Ba tình huống này trông không liên quan, nhưng chỉ có một nguyên nhân gốc: thực thể tài khoản đang chứa những thứ vốn không thuộc về nó. Thiết bị đang đăng nhập, các thiết bị đã từng dùng, tham số fingerprint và địa chỉ egress đều được lưu trên tài khoản. Vì vậy đổi thiết bị đồng nghĩa với sửa tài khoản, và một thay đổi kéo theo ảnh hưởng toàn hệ thống.
Tách thiết bị thành một loại đối tượng riêng
Sau khi tách, tài khoản và thiết bị nên có quan hệ nhiều-nhiều. Tài khoản không lưu fingerprint mà chỉ ghi nhận hiện đang gắn với thiết bị nào. Việc đổi thiết bị phải là một thao tác nguyên tử, lịch sử gắn kết được giữ trong một bảng riêng, và mỗi thiết bị có một định danh duy nhất, là định danh duy nhất được dùng bên ngoài, đồng thời trạng thái có thể được truy vấn theo thời gian thực.
Mục đích không phải làm mô hình đẹp hơn. Cách này rút ngắn khoảng cách giữa điều đội vận hành muốn điều chỉnh và phần mã đội phát triển phải thay đổi, và khoảng cách đó tăng theo số lượng thiết bị.
Bốn nhóm trường mà lớp trừu tượng phải định nghĩa rõ
Một lớp trừu tượng thiết bị có khả năng mở rộng chỉ cần trả lời bốn vấn đề ra bên ngoài.
- ID môi trường: duy nhất và ổn định. Các lớp phía trên chỉ tham chiếu môi trường bằng ID này; số nội bộ, tên container và ID tiến trình không được để lộ
- Gắn kết egress: môi trường đi ra qua egress mạng nào và múi giờ, ngôn ngữ, DNS đi kèm có được cấu hình thành một bộ thống nhất hay không. Tách egress riêng cho phép đổi egress mà không phải thay đổi chính môi trường
- Trạng thái: đang tạo, sẵn sàng khởi động, đang chạy, đang bị tác vụ chiếm dụng, bất thường, chờ thu hồi. Không có mô hình trạng thái thì không thể quản lý pooling và thu hồi
- Vòng đời: ai kích hoạt tạo, khởi động, chiếm dụng, giải phóng và thu hồi; xử lý thế nào khi tác vụ hết thời gian; và ai dọn dẹp khi môi trường xảy ra bất thường
Trạng thái và vòng đời thường bị gộp vào một trường. Đây là cách dễ nhất nhưng cũng đắt nhất. Trạng thái trả lời môi trường hiện đang thế nào; vòng đời trả lời ai được phép tác động lên nó ở bước tiếp theo. Trong production, rắc rối thật sự gần như luôn nằm ở phần sau: tác vụ bị crash nhưng không ai giải phóng môi trường, hoặc môi trường vẫn đang chạy đã bị thu hồi và tới lần khởi động tiếp theo mới phát hiện egress đã thay đổi.
Trừu tượng hóa sai sẽ trả giá khi mở rộng
Với mười môi trường, có thể chưa thấy vấn đề. Khi lên hàng chục hoặc hàng trăm, vấn đề bùng ra cùng lúc:
- Thêm một loại thiết bị mới phải sửa mô-đun tài khoản, khiến phạm vi kiểm thử hồi quy mở rộng từ lớp thiết bị sang lớp tài khoản
- Đổi thiết bị phải sửa cơ sở dữ liệu, khiến đội vận hành ngại đụng vào và hệ thống dần chỉ còn lập trình viên mới có thể bảo trì
- Không có bản ghi trạng thái và chiếm dụng, các môi trường còn lại sau khi thoát bất thường không được thu hồi và môi trường zombie tích tụ ngày càng nhiều
- Tác vụ, nội dung và tự động hóa ở lớp trên đều được xây dựng trên giả định quan hệ một-một giữa tài khoản và thiết bị, nên khi đổi giả định này phải làm lại toàn bộ chuỗi
Thiết bị từ các nguồn khác nhau có cách triển khai rất khác nhau: môi trường trình duyệt cục bộ và điện thoại đám mây dùng các giao diện hoàn toàn khác. Vai trò của lớp trừu tượng là đặt chúng phía sau cùng một bộ giao diện. Khi thêm một loại thiết bị, chỉ cần bổ sung một adapter triển khai khởi động, dừng và truy vấn trạng thái; logic lớp trên không cần thay đổi. Cũng có một cách kiểm tra đơn giản xem lớp trừu tượng có đúng hay không: khi thêm một loại thiết bị, phần mã cần sửa có chỉ nằm trong một tệp hay không?
Giai đoạn đầu càng ít càng tốt
Khi mô hình kỹ thuật đã ổn định, giao diện sẽ trở nên tự nhiên hơn. Hãy tổ chức menu theo đối tượng nghiệp vụ, tách riêng tài khoản, tác vụ và thiết bị, thay vì theo cấu hình, tham số và nhật ký. Trạng thái và bất thường nên là phần nổi bật nhất vì người dùng muốn biết có vấn đề hay không, chứ không phải có bao nhiêu bản ghi.
Về chức năng, giai đoạn đầu chỉ cần danh sách thiết bị, thêm thiết bị và một luồng tác vụ tối thiểu khép kín từ đầu đến cuối. Hãy giảm menu tối đa, trước tiên làm cho một việc chạy trọn vẹn, còn phần chưa cần thì để sau.
Nếu không muốn tự xây dựng cách ly môi trường từ đầu, có thể dùng năng lực sẵn có. PurpleMark cung cấp môi trường độc lập và gắn kết egress, hỗ trợ tạo hàng loạt theo nhóm và truy vấn trạng thái. Lớp trên chỉ cần triển khai mẫu, chiếm dụng và lập lịch tác vụ để nguồn lực kỹ thuật tập trung vào logic nghiệp vụ.
Độ phức tạp của hệ thống đa tài khoản chưa bao giờ nằm ở số lượng tài khoản mà nằm ở quản lý vòng đời thiết bị. Hãy coi thiết bị trước hết là một tài nguyên có định danh, egress, trạng thái và vòng đời, để chức năng lớp trên không phải bị lật lại mỗi khi bổ sung một thứ mới.
