[Microservices Series] Bài 3: Polyglot Architecture – Nghệ thuật "chọn vũ khí" (Khi Laravel và Go song kiếm hợp bích)

Chào anh em! Ở cuối bài 2, mình đã hứa sẽ chia sẻ về cách "chọn vũ khí" cho từng Service. Nếu trong kiến trúc Monolith, bạn bị "trói buộc" vào một ngôn ngữ và framework duy nhất từ đầu đến cuối, thì Microservices mang đến cho bạn một siêu năng lực: Polyglot Architecture (Kiến trúc đa ngôn ngữ).

Nhưng siêu năng lực nào cũng đi kèm với rủi ro tẩu hỏa nhập ma nếu không biết cách xài. Hôm nay, mình sẽ lấy luôn case study thực chiến từ hệ thống AFC (Automatic Fare Collection) của Metro để anh em dễ hình dung.

1. Tại sao không dùng một ngôn ngữ cho khoẻ?

Nhiều anh em sẽ hỏi: "Team em rành Laravel, tại sao không viết cả 10 cái services bằng Laravel cho đồng bộ, tuyển người cũng dễ?"

Đúng, đó là một lựa chọn an toàn và tối ưu cho chi phí nhân sự. Nhưng hãy nhớ lại triết lý của Microservices: Mỗi service giải quyết một bài toán nghiệp vụ với đặc thù khác biệt. Có bài toán cần xử lý logic siêu phức tạp với hàng tá quy tắc kinh doanh, có bài toán lại cần tốc độ phản hồi tính bằng milisecond để phục vụ hàng chục ngàn request cùng lúc. Bắt một công cụ làm tốt tất cả mọi thứ chẳng khác nào bắt một chiếc xe tải hạng nặng đi đua F1.

2. Thực chiến chia việc: Go cho Tốc độ, Laravel cho Nghiệp vụ

Trong hệ thống vận hành Metro, mình áp dụng chiến thuật "chia để trị" về mặt công nghệ như sau:

• Go (Golang) - "Lính đánh tia chớp": Mình dùng Go cho các service liên quan đến xử lý giao dịch tại cổng soát vé (Gate Service). Tại sao?

  • Khi hàng ngàn hành khách quẹt thẻ (Tap In/Tap Out) cùng một lúc trong giờ cao điểm, hệ thống cần xử lý siêu tốc, tính toán giá vé (Fare Calculation) và kích hoạt mở cổng ngay lập tức.

  • Cơ chế Goroutine của Go xử lý concurrency (đồng thời) cực kỳ xuất sắc. Nó ngốn rất ít RAM, CPU nhưng lại chịu tải trâu bò. Response time luôn được ép xuống mức thấp nhất, đảm bảo dòng người qua trạm không bị kẹt.

• Laravel (PHP) - "Bộ não quản trị": Mình dùng Laravel cho các service về CMS, cấu hình hệ thống, quản lý nhân sự và xuất báo cáo.

  • Nghiệp vụ cấu hình ga hoặc xuất báo cáo định kỳ thường cực kỳ lắt léo và thay đổi liên tục. Eloquent ORM của Laravel xử lý các relation phức tạp giữa các bảng dữ liệu rất "mượt".

  • Hệ sinh thái có sẵn của Laravel (Queue, Job, Middleware, Ecosystem) giúp mình code tính năng siêu tốc. Tốc độ ở đây không phải là tốc độ thực thi của CPU, mà là tốc độ deliver tính năng của Dev để đáp ứng nhanh yêu cầu từ Business.

Sự kết hợp này giúp hệ thống vừa vững như bàn thạch ở những điểm "nóng" về hiệu năng, vừa dễ maintain ở những khối nghiệp vụ phức tạp.

3. Mặt trái của Polyglot: Đừng biến dự án thành cái "Sở thú"

Nghe xịn là thế, nhưng đây là "cái giá" mà đội ngũ Engineer phải trả:

• Vận hành (DevOps) x N lần phức tạp: Thay vì viết 1 file Docker cho PHP, giờ bạn phải cấu hình môi trường, CI/CD pipeline, và monitor rủi ro cho cả PHP, Go, Node.js.

• Khó chéo cánh (Cross-functional): Khi service Go gặp sự cố lúc 2h sáng mà ông dev Go lại đang xin nghỉ phép, các anh em dev PHP nhìn vào syntax của Go cũng toát mồ hôi hột.

• Giao tiếp phức tạp: Service viết bằng Go và Laravel chạy ở hai tiến trình khác nhau. Chúng không thể gọi hàm nội bộ mà phải nói chuyện qua mạng.

Kinh nghiệm "xương máu"

Chỉ dùng công nghệ mới khi nó mang lại giá trị vượt trội và giải quyết được "nỗi đau" mà công nghệ hiện tại đang bất lực. Hãy giới hạn Tech Stack của hệ thống trong khoảng 2-3 ngôn ngữ cốt lõi (ví dụ PHP để làm mượt logic, Go/C++ để cày performance). Đừng để team có 5 người mà xài tới 5 ngôn ngữ chỉ vì "thấy dạo này trend đang hot".

Tạm kết

Polyglot Architecture là vũ khí hạng nặng của Microservices, giúp bạn tối ưu hóa từng mảnh ghép của hệ thống. Nhưng hãy cẩn thận đừng tự "bắn vào chân mình" bằng việc lạm dụng nó vô tội vạ.

Ở bài tiếp theo (Bài 4), chúng ta sẽ giải quyết một bài toán hóc búa: Khi các service chạy ở nhiều ngôn ngữ và server khác nhau, làm sao để chúng "nói chuyện" được với nhau một cách trơn tru, an toàn và không bị nghẽn mạng? Chúng ta sẽ cùng mổ xẻ Inter-service Communication (Nên dùng REST, gRPC, hay Message Broker?).

Trong dự án anh em đang làm, team đang dùng một Tech Stack thống nhất hay kết hợp nhiều ngôn ngữ? Đã có lần nào anh em bị "ngợp" vì nhảy vào maintain một service viết bằng ngôn ngữ lạ hoắc chưa? Cùng thảo luận nhé!