Chuẩn luôn 🤙Bản chất JDK Dynamic Proxy dùng Reflection để implement Interface, tuy mang tiếng chậm nhưng JVM hiện đại đã tối ưu cực tốt. Ngược lại, CGLIB dùng ASM thao tác bytecode để sinh Class con, lách được luật Interface nhưng lại "bó tay" trước từ khóa final và khá ngốn Metaspace. Chính sự linh hoạt này mà từ Spring Boot 2.0, CGLIB đã soán ngôi làm proxy mặc định, để hiểu được hoàn toàn và nắm vững kiến thức, bạn nên đọc thêm cả phần 2 nhé. Cảm ơn đã đọc bài viết của mìnggg
Hay nha bạn, tất nhiên phải đọc nhanh những change của AI trước. Tuy nhiên cũng có 1 vài giải pháp cho những vấn đề bạn kể trên khiến các agentic AI hoạt động 1 cách hiệu quả hơn. Mình sẽ viết nó trong loạt bài viết dịp "Mayfest" lần này. Hãy đón chờ nhé🥰
Cảm ơn góc nhìn của bạn nha! Quartz quả thực rất xuất sắc trong việc lập lịch phân tán (Clustered Scheduler) và giải quyết được vấn đề chạy trùng lặp tốt hơn ShedLock.
Tuy nhiên, Quartz chỉ giải quyết tốt bài toán 'Khi nào chạy' (Trigger) chứ chưa giải quyết triệt để bài toán 'Chạy như thế nào' (Orchestration) của các luồng nghiệp vụ phức tạp. Nếu Job đối soát tài chính dài hạn bị sập giữa chừng, Quartz chỉ có thể restart lại từ đầu (dễ gây lỗi double-spend nếu code không được xử lý idempotency cực kỳ kỹ).
Temporal đóng vai trò là một durable state machine, giúp lưu lại trạng thái từng bước chạy và phục hồi chính xác tại điểm sập. Cộng thêm khả năng quản lý retry/timeout và giao diện Web UI theo dõi trực quan, Temporal mang lại sự tin cậy cao hơn hẳn cho hệ thống tài chính bên mình. Rất mong nhận được thêm các đóng góp tiếp theo từ bạn!
Đọc bài của tác giả mới thấy cuộc chiến giữa JDK Dynamic Proxy và CGLIB nó ly kỳ như phim cung đấu vậy. Ông thì bắt buộc phải có Interface danh chính ngôn thuận mới chịu làm việc, ông thì chơi chiêu bẻ lái tạo Class con để lách luật. 😂
Tác giả phân tích nguồn gốc của 'gã thư ký' này rất sâu và trực quan, đọc xong phần 1 này mới thấy tự tin để sang phần 2 xem gã 'bẫy' anh em mình thế nào!
Bài viết quá hay! Spring nó lo hết từ A-Z làm anh em lười lặn xuống dưới xem bộ lòng Dynamic Proxy nó chạy thế nào. Đoạn giải phẫu hành vi của Proxy và lý do vì sao gọi nội bộ bị 'vượt rào' rất rõ ràng và chuẩn chỉnh. Đã upvote và bookmark lại để gửi cho mấy đứa em trong team đọc né bẫy!
Dùng Kafka bao lâu nay cứ gọi Producer.send() rồi Consumer.poll() như một cái máy, hôm nay mới được tác giả cho đi 'nội soi' chi tiết từng mảnh ghép Segment, Commit Log bên dưới. Bài viết quá hay, đi từ bản chất thế này mới thấm được vì sao nó lại đạt được tốc độ ánh sáng như vậy. Đã upvote!
Lúc DB có vài nghìn dòng: OFFSET 1000000 chạy vèo vèo, tự tin mình là master kiến trúc.
Lúc DB lên vài triệu dòng: Người dùng bấm sang trang cuối cùng một cái là CPU server nhảy lên 100%, sếp gọi điện hỏi thăm ngay lập tức. 😂
Bài viết phân tích đúng cái 'bẫy' kinh điển mà ai cũng từng ngã vào. Cảm ơn tác giả vì bài viết quá chất lượng và thực tế!
Lúc đọc bài viết: 'Áp dụng SOLID để code sạch, dễ mở rộng, nâng cấp hơn.' 🥰
Lúc sếp dí deadline: 'Thôi Single Responsibility cái gì tầm này nữa, gom hết vào một hàm cho nó chạy được trước 5h chiều nay đã rồi tính sau!' 😂
Tác giả phân tích cái đoạn 'nghệ thuật đánh đổi' chuẩn quá, không phải cứ nhét hết SOLID vào là thượng đẳng, quan trọng là phải đúng tầm. Bài viết quá chất lượng!
THẢO LUẬN
boilerplate: https://github.com/dinhuty/nextjs-16-boilerplate-full-agents-design-apple
Bạn triển khai nó trên thực tế chưa? Kết quả có tốt không bạn. Nó không hỗ trợ tiếng Việt, có lẽ nên thử jinaai/jina-colbert-v2.
Chuẩn luôn 🤙Bản chất JDK Dynamic Proxy dùng Reflection để implement Interface, tuy mang tiếng chậm nhưng JVM hiện đại đã tối ưu cực tốt. Ngược lại, CGLIB dùng ASM thao tác bytecode để sinh Class con, lách được luật Interface nhưng lại "bó tay" trước từ khóa final và khá ngốn Metaspace. Chính sự linh hoạt này mà từ Spring Boot 2.0, CGLIB đã soán ngôi làm proxy mặc định, để hiểu được hoàn toàn và nắm vững kiến thức, bạn nên đọc thêm cả phần 2 nhé. Cảm ơn đã đọc bài viết của mìnggg
Cảm ơn b, hay thì chia sẻ mọi người cùng đọc nhé
Comment này cũng nhiều chất xám đấy chứ, rất vui vì nó giúp bạn tỉnh ngộ, hay thì chia sẻ mọi người cùng đọc nhé
Bài tổng hợp đúng cái em cần luôn
Cảm xúc mô tả nghe rất chân thật, đọc xong bài này chắc người phỏng vấn mới là người phải đổ mồ hôi ấy chứ, dù sao cũm cảm ơn b nhé😁
rồi nha e Saga Pattern link bài viết: https://viblo.asia/p/microservices-thuc-chien-saga-pattern-nghe-thuat-quay-xe-rollback-an-toan-giua-chon-giang-ho-phan-tan-kNLr3vqOVgA
anh có bài về saga chưa a
Hay nha bạn, tất nhiên phải đọc nhanh những change của AI trước. Tuy nhiên cũng có 1 vài giải pháp cho những vấn đề bạn kể trên khiến các agentic AI hoạt động 1 cách hiệu quả hơn. Mình sẽ viết nó trong loạt bài viết dịp "Mayfest" lần này. Hãy đón chờ nhé🥰
Cảm ơn góc nhìn của bạn nha! Quartz quả thực rất xuất sắc trong việc lập lịch phân tán (Clustered Scheduler) và giải quyết được vấn đề chạy trùng lặp tốt hơn ShedLock.
Tuy nhiên, Quartz chỉ giải quyết tốt bài toán 'Khi nào chạy' (Trigger) chứ chưa giải quyết triệt để bài toán 'Chạy như thế nào' (Orchestration) của các luồng nghiệp vụ phức tạp. Nếu Job đối soát tài chính dài hạn bị sập giữa chừng, Quartz chỉ có thể restart lại từ đầu (dễ gây lỗi double-spend nếu code không được xử lý idempotency cực kỳ kỹ).
Temporal đóng vai trò là một durable state machine, giúp lưu lại trạng thái từng bước chạy và phục hồi chính xác tại điểm sập. Cộng thêm khả năng quản lý retry/timeout và giao diện Web UI theo dõi trực quan, Temporal mang lại sự tin cậy cao hơn hẳn cho hệ thống tài chính bên mình. Rất mong nhận được thêm các đóng góp tiếp theo từ bạn!
anh zai đừng trêu em nữa 🤣
3 năm mới thấy bác comeback 👋
Đọc bài của tác giả mới thấy cuộc chiến giữa JDK Dynamic Proxy và CGLIB nó ly kỳ như phim cung đấu vậy. Ông thì bắt buộc phải có Interface danh chính ngôn thuận mới chịu làm việc, ông thì chơi chiêu bẻ lái tạo Class con để lách luật. 😂 Tác giả phân tích nguồn gốc của 'gã thư ký' này rất sâu và trực quan, đọc xong phần 1 này mới thấy tự tin để sang phần 2 xem gã 'bẫy' anh em mình thế nào!
Bài viết quá hay! Spring nó lo hết từ A-Z làm anh em lười lặn xuống dưới xem bộ lòng Dynamic Proxy nó chạy thế nào. Đoạn giải phẫu hành vi của Proxy và lý do vì sao gọi nội bộ bị 'vượt rào' rất rõ ràng và chuẩn chỉnh. Đã upvote và bookmark lại để gửi cho mấy đứa em trong team đọc né bẫy!
Dùng Kafka bao lâu nay cứ gọi Producer.send() rồi Consumer.poll() như một cái máy, hôm nay mới được tác giả cho đi 'nội soi' chi tiết từng mảnh ghép Segment, Commit Log bên dưới. Bài viết quá hay, đi từ bản chất thế này mới thấm được vì sao nó lại đạt được tốc độ ánh sáng như vậy. Đã upvote!
Tuyệt vời, Hóng phần 2
Lúc DB có vài nghìn dòng: OFFSET 1000000 chạy vèo vèo, tự tin mình là master kiến trúc. Lúc DB lên vài triệu dòng: Người dùng bấm sang trang cuối cùng một cái là CPU server nhảy lên 100%, sếp gọi điện hỏi thăm ngay lập tức. 😂 Bài viết phân tích đúng cái 'bẫy' kinh điển mà ai cũng từng ngã vào. Cảm ơn tác giả vì bài viết quá chất lượng và thực tế!
Rất chi tiết, cảm ơn tác giả
Lúc đọc bài viết: 'Áp dụng SOLID để code sạch, dễ mở rộng, nâng cấp hơn.' 🥰 Lúc sếp dí deadline: 'Thôi Single Responsibility cái gì tầm này nữa, gom hết vào một hàm cho nó chạy được trước 5h chiều nay đã rồi tính sau!' 😂 Tác giả phân tích cái đoạn 'nghệ thuật đánh đổi' chuẩn quá, không phải cứ nhét hết SOLID vào là thượng đẳng, quan trọng là phải đúng tầm. Bài viết quá chất lượng!