Trường hợp chuyển đổi hệ thống quy mô lớn và chiến lược tách rời

baeba · 2025-05-13T10:00:11+09:00

Key Takeaways Đã thúc đẩy chuyển đổi bằng cách tách dần từng phần mà không cần thay thế toàn bộ hệ thống hiện có. Đã thay thế việc truy cập trực tiếp vào mainframe bằng hệ thống dữ liệu thời gian thực dựa trên CDC. Dùng GraphQL thay cho REST để loại bỏ nhiều lớp BFF và đảm bảo tính linh hoạt cùng khả năng bảo trì. Làm rõ trách nhiệm và quyền sở hữu của nhóm bằng cấu trúc nhóm xoay quanh domain (Team Topologies). Chuyển đổi hệ thống an toàn và cung cấp giá trị ổn định thông qua triển khai dần dần và tự động hóa. Trường hợp áp dụng: Một nửa hệ thống vẫn sống sót ngay cả khi gặp sự cố Dù mainframe gặp sự cố, UI mới vẫn hoạt động bình thường nhờ kiến trúc streaming trên nền tảng cloud. Ngay cả khi hệ thống cũ bị ngừng hoạt động, hệ thống mới vẫn duy trì trải nghiệm khách hàng và chứng minh được khả năng phục hồi. Chiến lược cốt lõi: Tách rời nhiều lớp (Decoupling) Thiết kế hướng domain (DDD): Tái cấu trúc mô hình lấy mainframe làm trung tâm theo hướng thân thiện hơn với nghiệp vụ Team Topologies: Chuyển sang tổ chức nhóm theo chức năng Kiến trúc hướng sự kiện: Giảm mức độ kết dính giữa các hệ thống bằng phương thức bất đồng bộ Change Data Capture (CDC): Phát hiện thay đổi dữ liệu theo thời gian thực để kết nối hệ thống legacy với hệ thống mới Cấu trúc trước đây: Unified Web Portal 1.0 Dữ liệu từ nhiều mainframe được tích hợp qua ETL rồi cung cấp cho SQL DB và SaaS, nhưng phát sinh các vấn đề như thiếu tính thời gian thực, suy giảm chất lượng dữ liệu và gọi trực tiếp tới mainframe. Vấn đề Độ trễ dữ liệu do ETL gây ra Kết nối đồng bộ với mainframe thiếu tính đàn hồi Tạo ra vô số API BFF Nút thắt cổ chai theo cấu trúc tổ chức và chậm trễ phát hành Khi lưu lượng tăng đột biến, mainframe bị quá tải khiến toàn bộ dịch vụ gặp sự cố Thiết lập mục tiêu mới Mục tiêu kỹ thuật: tách mainframe khỏi web, loại bỏ BFF, tăng quyền tự chủ cho nhóm Mục tiêu kinh doanh: giảm liên hệ tới call center, cắt giảm chi phí giấy phép, nâng cao mức độ hài lòng của khách hàng Tổng quan kiến trúc mới Mainframe vẫn là system of record CDC → Kafka → domain DB (CosmosDB) GraphQL + REST API → BFF → UI Mọi thành phần được kết nối qua cấu trúc hướng sự kiện và message broker Bước 1: Change Data Capture Xây dựng system of reference bằng streaming dữ liệu thời gian thực Mainframe → Kafka → chuyển đổi → domain DB → cung cấp qua API Đảm bảo cấu trúc dữ liệu linh hoạt, không phụ thuộc vào schema của mainframe Bước 2: Domain-Driven Design + GraphQL Định nghĩa mô hình domain bằng DDD (Entity, Command, Event) Tổ chức mỗi domain thành một node GraphQL, tạo supergraph qua schema stitching Hỗ trợ cấu trúc truy vấn tối ưu, chỉ lấy dữ liệu cần thiết Thay đổi cấu trúc tổ chức: Team Topologies Tái tổ chức thành các stream-aligned team theo chức năng Những khu vực phức tạp (ví dụ: tích hợp mainframe) do nhóm chuyên trách quản lý Vận hành Enablement team để hỗ trợ về mặt kỹ thuật Mở rộng theo hướng sự kiện: Sự kiện domain nội bộ + mẫu saga Phát sinh sự kiện khi domain thay đổi bằng mẫu Outbox Đồng bộ công việc trên mainframe và CDC bằng Parallel Saga Xây dựng workflow dựa trên state machine → ứng phó được cả các luồng phức tạp Thách thức Cần thay đổi nhận thức trong tổ chức về việc áp dụng cấu trúc hướng sự kiện Việc đảm bảo observability là bắt buộc do cấu trúc bất đồng bộ Tác vụ batch trên mainframe → gây quá tải cho pipeline CDC Độ phức tạp trong quản lý schema GraphQL và bài toán áp dụng federated approach Các mối quan tâm chung như xác thực/logging được quản lý bằng package riêng và tự động hóa Chiến lược phát hành: Release train + Feature Flag Mỗi nhóm triển khai độc lập, sau đó tích hợp tại repository triển khai Xây dựng pipeline triển khai theo từng môi trường bằng Kustomize Dùng feature flag để tách phát hành tính năng/bảo mật, đồng thời duy trì phát triển trunk-based Áp dụng kiến trúc hybrid Cho UWP 1.0 và UWP 2.0 cùng tồn tại để thực hiện chuyển đổi dần dần Chuyển tuần tự yêu cầu người dùng sang hệ thống mới bằng edge routing Kết luận: Xây dựng nền tảng có thể tiến hóa Tách hoàn toàn frontend khỏi mainframe Đảm bảo tốc độ và tính ổn định bằng cấu trúc lấy nhóm làm trung tâm Cải thiện mức độ hài lòng của khách hàng và chi phí vận hành Có được nền tảng linh hoạt, mở đường cho cả việc thay thế mainframe trong tương lai

(infoq.com)

9 điểm bởi baeba 2025-05-13 | 1 bình luận | Chia sẻ qua WhatsApp

Key Takeaways

Đã thúc đẩy chuyển đổi bằng cách tách dần từng phần mà không cần thay thế toàn bộ hệ thống hiện có.
Đã thay thế việc truy cập trực tiếp vào mainframe bằng hệ thống dữ liệu thời gian thực dựa trên CDC.
Dùng GraphQL thay cho REST để loại bỏ nhiều lớp BFF và đảm bảo tính linh hoạt cùng khả năng bảo trì.
Làm rõ trách nhiệm và quyền sở hữu của nhóm bằng cấu trúc nhóm xoay quanh domain (Team Topologies).
Chuyển đổi hệ thống an toàn và cung cấp giá trị ổn định thông qua triển khai dần dần và tự động hóa.

Trường hợp áp dụng: Một nửa hệ thống vẫn sống sót ngay cả khi gặp sự cố

Dù mainframe gặp sự cố, UI mới vẫn hoạt động bình thường nhờ kiến trúc streaming trên nền tảng cloud.
Ngay cả khi hệ thống cũ bị ngừng hoạt động, hệ thống mới vẫn duy trì trải nghiệm khách hàng và chứng minh được khả năng phục hồi.

Chiến lược cốt lõi: Tách rời nhiều lớp (Decoupling)

Thiết kế hướng domain (DDD): Tái cấu trúc mô hình lấy mainframe làm trung tâm theo hướng thân thiện hơn với nghiệp vụ
Team Topologies: Chuyển sang tổ chức nhóm theo chức năng
Kiến trúc hướng sự kiện: Giảm mức độ kết dính giữa các hệ thống bằng phương thức bất đồng bộ
Change Data Capture (CDC): Phát hiện thay đổi dữ liệu theo thời gian thực để kết nối hệ thống legacy với hệ thống mới

Cấu trúc trước đây: Unified Web Portal 1.0

Dữ liệu từ nhiều mainframe được tích hợp qua ETL rồi cung cấp cho SQL DB và SaaS,
nhưng phát sinh các vấn đề như thiếu tính thời gian thực, suy giảm chất lượng dữ liệu và gọi trực tiếp tới mainframe.

Vấn đề

Độ trễ dữ liệu do ETL gây ra
Kết nối đồng bộ với mainframe thiếu tính đàn hồi
Tạo ra vô số API BFF
Nút thắt cổ chai theo cấu trúc tổ chức và chậm trễ phát hành
Khi lưu lượng tăng đột biến, mainframe bị quá tải khiến toàn bộ dịch vụ gặp sự cố

Thiết lập mục tiêu mới

Mục tiêu kỹ thuật: tách mainframe khỏi web, loại bỏ BFF, tăng quyền tự chủ cho nhóm
Mục tiêu kinh doanh: giảm liên hệ tới call center, cắt giảm chi phí giấy phép, nâng cao mức độ hài lòng của khách hàng

Tổng quan kiến trúc mới

Mainframe vẫn là system of record
CDC → Kafka → domain DB (CosmosDB)
GraphQL + REST API → BFF → UI
Mọi thành phần được kết nối qua cấu trúc hướng sự kiện và message broker

Bước 1: Change Data Capture

Xây dựng system of reference bằng streaming dữ liệu thời gian thực
Mainframe → Kafka → chuyển đổi → domain DB → cung cấp qua API
Đảm bảo cấu trúc dữ liệu linh hoạt, không phụ thuộc vào schema của mainframe

Bước 2: Domain-Driven Design + GraphQL

Định nghĩa mô hình domain bằng DDD (Entity, Command, Event)
Tổ chức mỗi domain thành một node GraphQL, tạo supergraph qua schema stitching
Hỗ trợ cấu trúc truy vấn tối ưu, chỉ lấy dữ liệu cần thiết

Thay đổi cấu trúc tổ chức: Team Topologies

Tái tổ chức thành các stream-aligned team theo chức năng
Những khu vực phức tạp (ví dụ: tích hợp mainframe) do nhóm chuyên trách quản lý
Vận hành Enablement team để hỗ trợ về mặt kỹ thuật

Mở rộng theo hướng sự kiện: Sự kiện domain nội bộ + mẫu saga

Phát sinh sự kiện khi domain thay đổi bằng mẫu Outbox
Đồng bộ công việc trên mainframe và CDC bằng Parallel Saga
Xây dựng workflow dựa trên state machine → ứng phó được cả các luồng phức tạp

Thách thức

Cần thay đổi nhận thức trong tổ chức về việc áp dụng cấu trúc hướng sự kiện
Việc đảm bảo observability là bắt buộc do cấu trúc bất đồng bộ
Tác vụ batch trên mainframe → gây quá tải cho pipeline CDC
Độ phức tạp trong quản lý schema GraphQL và bài toán áp dụng federated approach
Các mối quan tâm chung như xác thực/logging được quản lý bằng package riêng và tự động hóa

Chiến lược phát hành: Release train + Feature Flag

Mỗi nhóm triển khai độc lập, sau đó tích hợp tại repository triển khai
Xây dựng pipeline triển khai theo từng môi trường bằng Kustomize
Dùng feature flag để tách phát hành tính năng/bảo mật, đồng thời duy trì phát triển trunk-based

Áp dụng kiến trúc hybrid

Cho UWP 1.0 và UWP 2.0 cùng tồn tại để thực hiện chuyển đổi dần dần
Chuyển tuần tự yêu cầu người dùng sang hệ thống mới bằng edge routing

Kết luận: Xây dựng nền tảng có thể tiến hóa

Tách hoàn toàn frontend khỏi mainframe
Đảm bảo tốc độ và tính ổn định bằng cấu trúc lấy nhóm làm trung tâm
Cải thiện mức độ hài lòng của khách hàng và chi phí vận hành
Có được nền tảng linh hoạt, mở đường cho cả việc thay thế mainframe trong tương lai

1 bình luận

mhj5730 2025-05-13

Việc cải tiến từng bước và tách dần microservice thực sự rất quan trọng... Đọc những bài như thế này mới thấy PM dẫn dắt dự án đó đúng là cực kỳ quan trọng và đáng nể. Quản lý từng này thứ đúng là ghê thật.