Mình có mấy note nhỏ cho các vấn đề với Micro services của bạn:

1. Nếu thiết kế 1 service bị chậm mà cả hệ thống bạn domino đổ theo thì rõ ràng là thiết kế đang có vấn đề. Có thể đang micro services nhưng lại gọi rồi chờ nhau đồng bộ, thế thì thà Monolith cho xong. Nên vận dụng queue, retry - backoff nhuần nhuyễn hơn.
2. Khó trace log trong hệ thống Micro services. Đúng nhưng có rất nhiều giải pháp vì cả thế giới gặp vấn đề này rồi, bạn không phải đầu tiên. Có thể dùng Zipkin chẳng hạn. Mỗi request được gắn 1 Trace ID. Bạn có thể theo dõi toàn bộ luồng đi qua các service. Giao diện Zipkin hiển thị rõ ràng:

• Timeline
• Tổng thời gian xử lý
• Dịch vụ nào đang gây chậm

bồi hồi

Demo của bạn quá trẻ con so với cái title mà bạn đưa ra. Ứng dụng A2A protocol, còn phần code của bạn chỉ gửi mấy cái message qua lại lẫn nhau giữa đám agent, 1 điều mà langgraph nó đã làm từ rất lâu. Bạn có hiểu A2A protocol nó sẽ sending những gì giữa 2 agent không.

bài viết rất hay

Bài viết thông tin về Gemini CLI cho những người chưa biết. ✅ Tuy nhiên việc "chèn" ServBay vào hơi bị khiên cưỡng. Tải cả app về chỉ để cài NodeJS ? Trong khi hầu hết các developers (quan tâm đến Gemini CLI) thường đã có sẵn NodeJS hoặc dùng nvm. Cá nhân mình thấy ServBay không nên "xuất hiện" ở đây ❌ Thay vào đó tập trung vào hướng dẫn cách tích hợp vào các IDE (vd như VSCode) thì phù hợp hơn. Sau đó ở cuối bài viết có vài dòng giới thiệu về ServBay sẽ hợp lý hơn.

Chút ý kiến !

hay qua

Đúng rồi bn,, Kafka giờ hỗ trợ chế độ KRaft nên có thể bỏ được ZooKeeper. Nhưng, hiện tại nhiều hệ thống vẫn đang kiến trúc cũ này nên vẫn cần phương án cấu hình HA với ZooKeeper cho đến khi migrate hẳn sang KRaft sau.

Em chào anh ạ, em là một Junior dev, hiện tại em muốn học hỏi và tích lũy dần dần các kiến thức về Micros, nhưng về lượng kiến thức về nó rất lớn, em không chắc nên đi từ đâu là đúng trong road map, em có thể xin lời khuyên của anh được không ạ? Nếu là anh đang khuyên chính anh lúc mới bắt đầu tìm hiểu về nó thì anh sẽ nên đi như thế nào chẳng hạn ạ?

Hiện giờ kafka có kraft mode rồi thì phương án zookp này có vẻ sẽ không cần thiết lắm

Bài viết đem lại nhiều kiến thức bổ ích, chi tiết, giúp mình được học thêm một phương pháp hay để truy vấn cũng như khai thác hiệu quả DB.

Shopify làm monolith vẫn chạy ngọt với hàng triệu active users được, monolithic không phải là vấn đề.

Microservices là con dao hai lưỡi, muốn làm đc tốt cần người có nhiều kinh nghiệm dẫn dắt, scale đủ lớn để làm, nếu không thì chỉ có tự bóp dé.

Hiện tại Microservices cũng bớt trend lại rồi, nhiều cty đu trend build lên xong thở dốc nên đã rút được nhiều kinh nghiệm =)). Tốt nhất là build modular monolith, khi đã đủ lớn mạnh, domain được validate và clear và lượng user đủ nhiều để đánh giá thì khắc biết có cần tách service không và cần tách chỗ nào.

Theo quan điểm của mình , những dự án với lượng người dùng không lớn nên ưu tiên monolithic, và không nên đú Microservice .

1. Nhân lực nhiều hơn
2. Chi phí cao hơn
3. Nhiều đòi hỏi kiến thức hơn

Kinh nghiệm thực tế thì mình làm những công ty với mô hình ERP cũ monolithic vẫn hoạt động tốt, Chi phí để họ chuyển đổi sang Microservice là một vấn đề tài chính lớn với nhiều doanh nghiệp. Ở một góc nhìn thực tế của mình là vậy

Không liên quan tới microservices hay k nha bạn, bạn có thể tìm hiểu thêm về vertical slice architecture.

"Tổ chức code theo tính năng" - Theo em hiểu thì cách này dùng để cấu trúc cho các ứng dụng Microservice đúng ko anh?

Còn thua anh Biên nhiều lắm chớ 😁

ựa đẳng cấp quá, đúng là Phó Trùm group Flutter có khác

bài viết hay

bác cho e hỏi nx v20 làm thế nào để khi remote app không hoạt động k làm host app crash trường hợp load remote app thủ công?

DOM là "bản đồ" (khung xương) của toàn bộ HTML → JavaScript dùng bản đồ này để xem, thay đổi, thêm, xóa các thành phần trên trang web. Nếu không có DOM, JS không biết HTML có những gì để thao tác.

khá tổng hợp, góp ý tí

5.1 Server Side Rendering:

1. SSR không chạy JS phía server như đoạn nói:

“sau khi đã đi qua một lượt các script có trong trang web (bao gồm các link thư viện như cdn)” → ❌ Không đúng.

→ SSR thường không chạy JS client-side như các CDN, mà chỉ xử lý logic server, render HTML sẵn rồi gửi đi.

2. CDN FE library không liên quan đến việc “giảm áp lực cho server” trong SSR: CDN chỉ giúp client tải nhanh hơn, không giúp server “giảm việc render”.

✅ Viết lại đúng hơn:

5.1 Server Side Rendering (SSR)

Server side rendering là phương pháp render HTML ngay trên server, rồi gửi HTML hoàn chỉnh về trình duyệt.

Quy trình:

1. Người dùng gửi yêu cầu đến server.
2. Server xử lý logic, truy xuất dữ liệu, và render ra HTML hoàn chỉnh (có nội dung).
3. Trình duyệt nhận HTML, hiển thị ngay nội dung.
4. Sau đó, JS (nếu có) sẽ được tải về để thêm tính năng tương tác. JS chỉ dùng tương tác thêm chứ không gen DOM.

👉 Ưu điểm: hiển thị nội dung nhanh, tốt cho SEO. 👉 Nhược điểm: nếu tương tác nhiều thì cần load lại trang (trừ khi kết hợp thêm JS hydratation).

5.2 Client Side Rendering (CSR)

Client side rendering là phương pháp trong đó server chỉ trả về một HTML rỗng hoặc có rất ít nội dung, còn mọi thứ sẽ do JS render phía trình duyệt.

Quy trình:

1. Trình duyệt nhận HTML ban đầu (thường chỉ có <div id="root"></div>).
2. Trình duyệt tải JS (VD: React, Vue...).
3. JS tạo ra DOM, gọi API để lấy dữ liệu động (qua fetch/Ajax).JS này tạo ra DOM.
4. Nội dung được render và hiển thị phía client.

👉 Ưu điểm: tương tác mượt, SPA (single page app). 👉 Nhược điểm: chậm lần đầu, không tốt cho SEO nếu không có SSR hỗ trợ.