Monolith, Nợ Kỹ Thuật, Xung Đột Con Người và Microservices

Một bài viết chiêm nghiệm về những sai lầm, những bài học đau đớn, và một lộ trình chi tiết để giải cứu một hệ thống công nghệ đang trên bờ vực sụp đổ.

Lời Mở đầu: Người Gác đền Cô độc của Pháo đài Monolith

Trong mọi tổ chức công nghệ đã tồn tại qua vài năm, thường có một “huyền thoại sống”. Đó là người lập trình viên duy nhất hiểu rõ mọi ngóc ngách của hệ thống cốt lõi, người duy nhất cả công ty nín thở gọi tên mỗi khi hệ thống sụp đổ. Tôi đã từng là người đó.

Hệ thống chúng tôi xây dựng khởi đầu như một giấc mơ, nhưng qua nhiều năm chắp vá đã biến thành một cơn ác mộng kiến trúc: một khối Monolith khổng lồ, phức tạp và mong manh. Bài viết này là một câu chuyện từ chiến hào – một bản post-mortem chi tiết về những gì đã sai, và quan trọng hơn, là một bản kế hoạch để giải thoát chúng tôi khỏi cái bóng của nó.

The complexity of a Monolith architecture versus the clarity of Microservices

Phần I: Cái bóng của Monolith – Phân tích một Di sản mục rỗng

Để hiểu tại sao phải thay đổi, chúng ta phải dũng cảm nhìn thẳng vào những vết thương mà hệ thống cũ đã gây ra.

1. Nợ Kiến trúc: “Quả cầu Bùn Lớn” (The Big Ball of Mud)

Hệ thống CRM cốt lõi của chúng tôi là một ví dụ kinh điển: Mọi thứ từ xác thực, quản lý đơn hàng, thanh toán, gửi email... đều được gói gọn trong một codebase duy nhất. Mọi lần deploy đều là một canh bạc.

  • ❌
    Tính liên kết chặt chẽ (Tight Coupling): Sửa một hàm nhỏ trong module thanh toán có thể vô tình làm sập chức năng gửi email. Không ai có thể tự tin 100% về tác động của một sự thay đổi.
  • ❌
    Điểm lỗi duy nhất (Single Point of Failure): Một lỗi rò rỉ bộ nhớ trong một chức năng ít quan trọng đã nhiều lần khiến toàn bộ hệ thống sụp đổ, làm tê liệt hoạt động kinh doanh.
  • ❌
    Công nghệ Tù đọng: Toàn bộ hệ thống bị khóa chặt vào một phiên bản Node.js đã lỗi thời. Việc nâng cấp là một dự án khổng lồ và đầy rủi ro.

2. Nợ Con người: Sự Rối loạn Chức năng trong Đội ngũ

Một kiến trúc tồi không chỉ tạo ra code tồi, nó còn tạo ra những hành vi tiêu cực và làm xói mòn văn hóa hợp tác, biến đồng đội thành đối thủ.

a. Nghịch lý của Team Backend: Những Người Gác đền của Pháo đài mục nát

Vì codebase quá phức tạp và nguy hiểm, mọi yêu cầu chỉnh sửa đều được xem như một mối đe dọa. Văn hóa phòng thủ, đổ lỗi ("API lỗi rồi", "Do Frontend gửi sai") và tích trữ kiến thức lên ngôi. Họ trở thành những người bảo vệ cho chính cái nhà tù đang giam giữ họ.

b. Ảo tưởng của Team Frontend: Bức tranh Đẹp trên một Bức tường Sắp sập

Sống trong "bến cảng an toàn ảo", họ có xu hướng xem trách nhiệm chỉ dừng lại ở việc biến Figma thành giao diện. Họ thiếu trách nhiệm end-to-end, không cảm thấy mình phải chịu trách nhiệm cho toàn bộ trải nghiệm của người dùng.

c. Cây cầu Gãy: Sự Thất bại của Quy trình Phân tích và Đảm bảo Chất lượng

Đây là mắt xích yếu nhất. Các dự án bắt đầu với yêu cầu "gạch đầu dòng" mơ hồ. BA chỉ mô tả bề mặt. Dev code trong chân không. QA trở thành "trạm trung chuyển bug" thay vì "hàng rào chất lượng", dẫn đến vòng lặp "chữa cháy" đau đớn và vô tận.

Phần II: Con đường đến Tự do – Lộ trình Thực tế đến Microservices

Chúng ta cần một cuộc cách mạng. Đây là lộ trình chuyển đổi, không phải như một trào lưu, mà là một giải pháp có chủ đích.

1. Hệ sinh thái Mới: Một Bản thiết kế cho Tương lai

Thay vì một khối duy nhất, chúng ta sẽ xây dựng một "thành phố" các dịch vụ chuyên biệt, tận dụng các nền tảng mã nguồn mở mạnh mẽ:

  • Quản lý Định danh & Phân quyền (IAM): Sử dụng Keycloak làm "Cơ quan Đăng ký Cư dân" trung tâm.
  • Trái tim Nghiệp vụ (CRM & Kế toán): Tận dụng Odoo làm "nguồn sự thật duy nhất" về dữ liệu kinh doanh.
  • Công cụ Tự động hóa Quy trình: Điều phối các luồng nghiệp vụ phức tạp bằng Camunda, cho phép BA thiết kế quy trình bằng sơ đồ BPMN.
  • Lớp Giao tiếp Khách hàng: Sử dụng Mautic cho Email Marketing và Novu cho thông báo đa kênh.
  • Cổng Thanh toán (Payment Gateway Service): Xây dựng một microservice riêng làm lớp trừu tượng (abstraction layer) để che giấu sự phức tạp của các nhà cung cấp.

2. Nền tảng Kỹ thuật & Bảo mật: Hệ Thần kinh của Thành phố Microservices

Để các dịch vụ giao tiếp an toàn và hiệu quả, chúng ta cần một nền tảng hạ tầng vững chắc trên AWS với triết lý "Zero Trust":

  • VPC & API Gateway: "Bức tường thành" và "cổng chính" được canh gác nghiêm ngặt, nơi mọi request từ bên ngoài đều phải đi qua.
  • Amazon EventBridge: "Hệ thần kinh trung ương", cho phép các service giao tiếp bất đồng bộ qua sự kiện, tránh sụp đổ dây chuyền.
  • Service-to-Service Authentication: Mọi giao tiếp giữa các microservice bên trong mạng nội bộ đều BẮT BUỘC phải được xác thực bằng JWT hoặc API Key.

3. Viên đá Nền tảng: Xác thực "Offline" để Tối đa hóa Tốc độ

Bảo mật là ưu tiên hàng đầu, nhưng nó không được làm chậm hệ thống. Đây là cách chúng ta thiết lập một hệ thống xác thực tập trung, an toàn và hiệu năng cao:

  1. Người dùng đăng nhập qua Keycloak và nhận về một JWT đã được ký bằng Khóa Riêng tư.
  2. Client đính kèm JWT vào mỗi request gửi đến API Gateway.
  3. ✨ The Magic Happens Here: API Gateway sử dụng Khóa Công khai của Keycloak (đã được cache) để tự xác thực chữ ký của JWT tại chỗ (offline). Nó không cần gọi mạng đến Keycloak, giúp quá trình này diễn ra với tốc độ cực nhanh.
  4. Nếu JWT hợp lệ, request được chuyển tiếp đến microservice backend. Mô hình này loại bỏ "nút thắt cổ chai", tạo ra một hệ thống phi trạng thái, an toàn và có khả năng mở rộng không giới hạn.

Xây dựng lại từ Nền móng

Hành trình này không chỉ đòi hỏi sự thay đổi về công nghệ, mà còn là một sự thay đổi sâu sắc về tư duy, văn hóa và quy trình. Những gì tôi đã chia sẻ là những vết sẹo, nhưng cũng là một niềm tin mãnh liệt rằng chúng ta có thể làm tốt hơn. Đây là con đường để biến một nhóm "thợ sửa ống nước" thành một đội ngũ "kiến trúc sư".

Để thực hiện một cuộc chuyển đổi phức tạp như vậy, việc có một đối tác chiến lược là vô cùng quan trọng. Khám phá ngay dịch vụ marketing online trọn gói TVD Media để nhận tư vấn về cách xây dựng chiến lược và quy trình công nghệ vững chắc, phục vụ cho sự tăng trưởng bền vững của doanh nghiệp.