Vì sao kiến trúc dựa trên hàng đợi thông điệp dạo này không còn được ưa chuộng nữa?

xguru · 2024-06-21T11:03:01+09:00

Cho đến tận đầu những năm 2010, người ta vẫn nói nhiều về việc xây dựng hệ thống phân tán dựa trên MQ, nhưng dạo gần đây lại không còn nhiều bài viết về chủ đề này Một vài giả thuyết mình nghĩ tới như sau, không biết có phải một trong số này không, hay mọi người còn có góc nhìn nào khác: Redis xử lý được hầu hết các trường hợp sử dụng, kể cả caching, nên việc vận hành riêng một message broker không còn nhiều giá trị. Còn Kafka thì đi hẳn về quy mô rất lớn. DB (nếu hiểu theo nghĩa rộng) đã xử lý tải lớn tốt hơn rất nhiều, nên các tác vụ mang tính “tạm thời” giờ được xử lý ngay trong kho lưu trữ chính Người ta nhận ra rằng kiến trúc dựa trên MQ không hoạt động tốt như kỳ vọng, nên giờ chuyển sang cách khác Thực ra công nghệ MQ giờ đã bước vào giai đoạn trưởng thành, không còn đủ mới lạ để người ta viết bài nữa. Nhưng nó vẫn đang được dùng rất rộng rãi hnthrowaway_99 Nhiều kiến trúc từng “hot” vào cuối những năm 2000 đến đầu những năm 2010 cuối cùng đã biến mất sau khi người ta nhận ra rằng “bạn không phải Google. Công ty của bạn cũng sẽ không bao giờ trở thành Google” Thời đó có một khát vọng rất lớn là “xây dựng theo cách mà các tập đoàn thành công đã xây dựng” Nhưng sau đó, nhiều người nhận ra rằng với 99% công ty thì mức độ phức tạp đó là không cần thiết Khi phần cứng và các cơ sở dữ liệu tiêu chuẩn ngày càng tốt hơn, số công ty thực sự cần những “Scalability Trick” như vậy ngày càng ít đi Ngưỡng của tôi cho câu hỏi “có lý do gì mà chúng ta không làm tất cả việc này bằng Postgres không?” giờ đã cao hơn rất nhiều so với 10 năm trước Các bình luận bên dưới bình luận này Giờ đã có những máy đơn lẻ lớn hơn rất nhiều với chi phí hợp lý. Trước đây cần một cụm nhỏ, còn giờ một hệ thống đơn cũng có thể gánh được rất nhiều loại workload khác nhau Nói thật thì tôi từng tham gia vài dự án ở Google nhằm loại bỏ queue. Nên có lẽ vấn đề còn hơn cả chuyện “giảm độ phổ biến” biglain Hơi cay nghiệt nhưng theo tôi, kiến trúc MQ và các bài blog về nó phần lớn là kiểu “Resume Driven Development”. Trên thực tế, người ta làm những thứ hoàn toàn có thể chạy trên một chiếc laptop đơn mà không cần phải vượt ra khỏi monolith. Có lẽ chính những người đó là những người xây nên các thảm họa microservice ác mộng, ngốn AWS hàng chục nghìn đô mỗi tháng Những người “ưu tiên tích lũy thành tích kỹ thuật cho sự nghiệp hơn là giải quyết vấn đề kinh doanh thực tế theo cách thực dụng” giờ đang chuyển sang hype AI và viết blog về AI tuckerconnelly Gần đây tôi đã chuyển từ microservice về monolith vì microservice quá phức tạp và có quá nhiều mã trùng lặp. Không có microservice thì nhu cầu với message queue cũng giảm đi Với các tác vụ bất đồng bộ, tôi từng dùng RabbitMQ trong một dự án, nhưng nó cho cảm giác quá cũ và bị thiết kế quá mức Và nhiều công cụ xung quanh nó (Celery) cũng không tốt bằng các công cụ hiện đại xây quanh Redis (bullmq) Với các quy trình nhiều tầng theo kiểu DAG, tôi thích xử lý mọi thứ trong một job lớn nếu có thể, hoặc chia thành một số ít job nhỏ hơn Nếu thật sự cần DAG thì đã có công cụ được làm riêng cho việc đó (Airflow). Nhưng tôi nghe nói rất khó debug vấn đề, nên tốt nhất vẫn nên tránh nếu có thể Cá nhân tôi vẫn dùng Redis single-node vì kiến trúc multi-node của Redis quá mức phức tạp đến vô lý và gặp vấn đề khi scale. Nhưng sharding thủ công thì với tôi vẫn ổn và chạy tốt Bình luận của kypro về bài này Theo kinh nghiệm của tôi, monolith không làm giảm độ phức tạp mà chỉ chuyển nó sang chỗ khác Vấn đề lớn nhất của monolith là các mối quan tâm giữa các domain không được tách biệt rõ ràng và minh bạch, nên theo thời gian codebase monolith rất dễ biến thành một mớ spaghetti code đan chéo khủng khiếp Điều này càng đúng khi bạn xây dựng dự án lớn với nhiều lập trình viên, đặc biệt nếu có nhiều người không thực sự hiểu hết độ phức tạp domain của phần code họ đang động vào Monolith phù hợp cho dự án nhỏ với ít lập trình viên, nhưng ngoài trường hợp đó thì đa số sẽ hối hận trong vài năm sau khi xây monolith Tôi cũng không đồng ý về chuyện mã trùng lặp. Nếu dùng cùng một ngôn ngữ và chia sẻ package giữa các dự án, tôi không hiểu vì sao đó lại là vấn đề lớn Dù sao thì khi làm việc với microservice, tôi chưa từng gặp các vấn đề như vậy Tôi cũng muốn đặt câu hỏi liệu trung bình microservice có thực sự phức tạp hơn monolith hay không Điều tôi thích nhất ở kiến trúc microservice là việc hiểu và đóng góp vào từng microservice riêng lẻ đơn giản đến mức nào Kiến trúc và provisioning của microservice có thể phức tạp hơn, nhưng từ góc nhìn của lập trình viên làm việc trên từng microservice, nó đơn giản hơn rất nhiều so với monolith democracy Có vẻ ý này là đúng: “Công nghệ MQ giờ chỉ đơn giản là đã trưởng thành, không còn thú vị đến mức đáng để viết bài, nhưng vẫn đang được sử dụng rộng rãi” Kiến trúc dựa trên messaging vẫn rất phổ biến Các bình luận về bài này casper14: Đồng ý. Nó chỉ đơn giản đã trở thành một công cụ. Cũng như giờ chẳng còn ai viết bài về cách dùng máy ảo trên cloud nữa bwhaley: Đây mới là câu trả lời đúng. Gần như mọi hệ thống phân tán chạy ở quy mô lớn đều có dùng message queue ở mức độ nào đó ipsum2: Khả năng cao là vậy. Trước đây các bài viết về chuyện rewrite Angular sang React rất hút view, còn giờ ai cũng chỉ dùng React hoặc viết về việc rewrite React sang Vue busterarm Tôi sẽ đưa ra một câu trả lời không mấy được ưa thích Queue, stream và Pub/Sub là những khái niệm mà đa số kỹ sư không thực sự hiểu rõ Họ không biết khi nào cần dùng, cũng không biết dùng cho đúng, và lại mang đi dùng sai mục đích Tôi vẫn đang làm việc với tất cả những thứ trên (SQS/SNS/RabbitMQ/Kafka/Google Pub/Sub) Tôi làm ở một công ty chỉ tuyển những kỹ sư “xuất sắc nhất”, tốt nghiệp từ 3–4 trường hàng đầu Bắc Mỹ, và đây gần như là công việc đầu tiên của hầu hết mọi người Các kỹ sư của chúng tôi đã làm những chuyện điên rồ như sau: Đẩy hàng chục nghìn message 100MB lên RabbitMQ trong chớp mắt rồi thắc mắc vì sao nó nổ tung Thường xuyên gửi message kích thước khá lớn qua RabbitMQ dù đã có đủ loại cảnh báo bảo đừng làm thế Bắt đầu dự án mới trong năm 2024 với phiên bản RabbitMQ mới nhất nhưng lại định dùng classic queue Tạo quorum queue mà không có chính sách replication, hay nói đúng hơn là chẳng làm gì để có HA cả Expose cluster ra Internet trong khi user quản trị vẫn là guest/guest Kiến trúc sư cấp cao nhất trong tổ chức tuyên bố một pattern kiến trúc mới, tổ chức họp toàn công ty và demo nó Họ ca ngợi một “đức tính/pattern” mới là nhét message vào queue, rồi tạo một backchannel để consumer thứ hai có thể xử lý message trong queue theo kiểu on-demand (và như thế thì nó không còn là queue nữa) Và ngoài tôi ra thì không ai hỏi “tại sao lại đưa vào queue những message cần được xử lý theo đúng thứ tự?”, thế là cái “pattern” đó bén rễ luôn! Dùng Kafka làm message queue mặc định Truyền dữ liệu từ data center trung tâm tới các data center phân tán khắp thế giới, đặt global lock lên object và chặn mọi thứ cho tới khi từng data center đích xác nhận đã nhận object cập nhật. Sau đó vẫn tuyên bố quy trình này là bất đồng bộ vì dữ liệu được gửi cùng với AJAX request Kết quả là dù mọi người không cần phải làm điều gì quá ghê gớm, họ vẫn xoay xở được. Thế nên công cụ vừa bị dùng sai, lạm dụng, lại cũng bị dùng chưa đủ Ở những nơi dùng đúng cách, có lẽ bạn sẽ chẳng bao giờ nghe họ nói nhiều về nó Sự thật quan trọng: trong tổ chức của chúng tôi có hơn 30 microservice cho mỗi kỹ sư. Làm ơn giết tôi đi. Tôi thà trở thành Kurt Cobain còn hơn là làm ở một tổ chức khác có hàng nghìn microservice trong một monorepo khổng lồ Các bình luận về bài này zug_zug: Nếu bổ sung dữ liệu thực tế để củng cố giả thuyết này thì Tôi từng làm ở một startup tại New York dùng Akka (queueing hướng sự kiện của Scala) Tại sao lại như vậy? Có phải vì người quản lý từ công ty trước từng “cứu” công ty bằng cách này khi “mọi thứ quá chậm”, nên sang công ty mới liền bắt buộc áp dụng? Công việc nào thực sự cần queueing? Chỉ là hiển thị 401k của nhân viên trên website, cho phép họ điều chỉnh phân bổ tài sản, và gửi vài trăm email mỗi ngày Đúng như dự đoán, người ta hầu như chẳng mấy khi đăng nhập vào website 401k đó Sau khoảng một năm làm việc ở đó, tôi nhận ra server luôn bị cấu hình sai và về cơ bản concurrency cho web request là 0 (Không ai nhận ra vì 2 server production luôn đủ để xử lý toàn bộ traffic cần thiết) Cuối cùng Akka bị loại bỏ vì chỉ làm tăng thêm độ phức tạp hoàn toàn không cần thiết Tháng trước công ty này lại gọi thêm một vòng vốn kèm lựa chọn cash-out, rõ ràng định giá đã tăng và có vẻ họ vẫn đang làm ăn tốt scary-size: Nghe không giống là chỉ tuyển kỹ sư “xuất sắc” lắm nhỉ? roncesvalles: Có vẻ như không có quy trình review thiết kế. Nếu là tôi, tôi sẽ tuyển lập trình viên 2–5 năm kinh nghiệm từ các trường vô danh thay vì người mới tốt nghiệp trường nổi tiếng. Lượng kiến thức và sự trưởng thành mà kỹ sư phần mềm tích lũy trong 5 năm đầu sự nghiệp là cực lớn, có lẽ còn nhiều hơn toàn bộ phần còn lại của sự nghiệp cộng lại. burutthrow Tôi nghĩ MQ đã khá commoditized Nếu mua Confluent, RedPanda hoặc MSK dưới dạng dịch vụ, bạn không cần tự quản lý Kafka nữa Change Data Capture (CDC) cũng đã rất mạnh và trở thành xu hướng chính thống. Ghi dữ liệu vào RDBMS rồi capture các thay đổi để lan truyền sang hệ thống khác giờ tương đối dễ Ví dụ, điều này có nghĩa là message queue chỉ còn là xương sống để hệ CDC dùng truyền message, nên người ta không còn viết nhiều về Kafka nữa Những kiến trúc như vậy rõ ràng vẫn tồn tại và đáp ứng được ràng buộc của đa số tổ chức Với các queue kiểu ghi một lần đọc nhiều lần như Kafka, có thể dùng để expose API cho các bộ phận khác trong tổ chức. Nhiều công ty dùng pattern này để trộn và dùng lại dữ liệu giữa nhiều team Một team nhỏ mà sở hữu rất nhiều microservice thì nghe giống kiểu development vì CV, nhưng ở công ty có hơn 100 kỹ sư thì pattern này lại hợp lý angarg12 MQ là một công cụ trong hộp đồ nghề của distributed systems. Khi phù hợp thì nó hoạt động rất tốt Nếu giả thuyết nào của bạn đúng nhất thì tôi nghĩ là câu này: “người ta thường viết blog về những thứ mới mẻ và hào nhoáng” Cá nhân tôi luôn dùng queue trong thiết kế, đặc biệt khi truyền dữ liệu giữa các hệ thống khác nhau cần mức độ decoupling cao Nỗi đau duy nhất tôi từng gặp là khi phải backfill 7 ngày dữ liệu từ upstream system, khiến queue bị tắc bởi các request cũ Nếu cứ để chạy bình thường thì phải mất hơn 100 giờ mới xử lý hết dữ liệu, và độ trễ của dữ liệu mới cũng sẽ tăng khủng khiếp Cách giải quyết là xóa queue thủ công rồi tự backfill lại phần dữ liệu mới nhất bị thiếu Cần cẩn thận với kích thước queue không bị giới hạn, nhưng tôi vẫn nghĩ đây là một công cụ rất tốt rossdavidh MQ trên Gartner Hype Cycle hiện đã vượt qua “Peak of inflated expectations” đi qua “trough of disillusionment” và đang tiến lên “Slope of Enlightenment”, thậm chí là “plateau of productivity” robertclaus Điều rất thú vị là bình luận “rõ ràng tất cả chúng ta vẫn dùng message queue và worker, chỉ là không còn viết về nó nữa” lại bị chìm xuống phía sau giữa các cuộc tranh cãi về microservice và khả năng scale thực tế Một kỹ sư junior đọc thread này có thể sẽ hiểu lầm rằng giờ không nên đẩy các tác vụ tính toán nặng ra khỏi web server sang worker nữa pm90 Các bài blog về chủ đề này giảm đi vì công nghệ đó đã trở nên nhàm chán Và đó là điều tốt. Ví dụ tài liệu chính thức của RabbitMQ giờ đã tốt hơn rất nhiều và rất hữu ích Người ta dùng nó như dùng Postgres/MySQL vậy Cũng không cần kỹ thuật gì quá thần kỳ để thiết kế kiến trúc quanh nó Tôi yêu phần mềm nhàm chán: “I love boring software” slowmovintarget Phần lớn các kiến trúc kiểu này trước đây chạy trong data center doanh nghiệp Sau khi chuyển sang cloud và xây các dịch vụ nhỏ stateless hơn (cùng với sự xuất hiện của SPA), nhu cầu với các hệ thống event-driven nhiều bước phức tạp giảm đi Ví dụ trên AWS, chỉ cần SQS và một ít SNS, hoặc Kinesis cho một vài trường hợp là đủ. Khi đó MQ không còn là trung tâm của thiết kế nữa Kiến trúc dựa trên MQ tốt cho xử lý dữ liệu nhưng không phù hợp lắm với website tương tác, và nếu đa số mọi người đang xây website tương tác thì dễ hiểu vì sao họ không chọn nó Tôi vẫn thiết kế event system cho xử lý dữ liệu (đặc biệt khi có business data bất biến mà về sau có thêm sự kiện mới, hoặc hóa ra trước đó ta “đã sai” hay lẽ ra cần biết một thông tin khác ở thời điểm trước) Nhưng với phần lớn ứng dụng thì... không cần mannyv Toàn bộ backend của chúng tôi là queue-based Nếu thứ gì đó là bất đồng bộ và không cần thời gian phản hồi nhanh, hãy dùng queue. Nó đơn giản, ổn định, và queue có thể kích hoạt lambda Dùng queue cũng giúp thu thập metric và dữ liệu hiệu năng dễ hơn Khi tải cao, queue có thể phình lên đến hàng triệu message rồi giảm dần theo thời gian Hoặc bạn có thể tạo hàng trăm lambda tùy ý để xử lý toàn bộ số message đó vishnugupta Theo kinh nghiệm của tôi, MQ đã bị trừu tượng hóa đi chứ không hề biến mất Ví dụ hàng đợi kiểu SQS + polling giờ đã trở thành một quy trình ít phải gọi server hơn. Vẫn có message queue ở đâu đó, chỉ là nó không còn lộ ra nữa AWS SNS, một lớp trừu tượng cao hơn SQS, giờ đã rất giàu tính năng đến mức trên thực tế có thể thay thế SQS Ngoài ra, vì streaming đã trở thành công nghệ rất ổn định, nên các use case trước đây dùng queue như một ống streaming đã chuyển sang hẳn các hệ thống streaming chuyên dụng memset Có thể vì lambda (cloud function) đang trở nên phổ biến hơn và được hỗ trợ trên nhiều nền tảng Khi thêm thứ gì đó vào queue thì rốt cuộc vẫn phải lấy nó ra và xử lý. Lambda làm việc đó chỉ với một lần invoke. Bạn cũng không cần tự chạy hay scale worker nữa Tôi nghĩ Kafka vẫn tiếp tục phổ biến vì nó được dùng như một kho dữ liệu tạm thời, và có hệ sinh thái lớn để thu thập từ stream Cá nhân tôi dùng queue rất nhiều và đang xây một giải pháp thay thế SQS mã nguồn mở. Cũng tự hỏi liệu một giải pháp thay thế lambda mã nguồn mở có hữu ích không liampulles “Giờ công nghệ MQ đã trưởng thành, không còn thú vị đến mức người ta muốn viết bài về nó nữa, nhưng vẫn đang được dùng rộng rãi” Chuẩn là vậy. Tôi nghĩ các use case đơn giản của giao tiếp bất đồng bộ dùng Pub/Sub đơn giản vẫn rất hữu ích và cũng không quá khó để áp dụng Chúng ta (với tư cách cộng đồng lập trình viên) đã đi qua giai đoạn event sourcing, mạng lưới phức tạp và việc xây dựng quy mô không cần thiết. Nói cách khác, chúng ta đã đi qua chu kỳ hype Team của chúng tôi dùng NATS cho Pub/Sub bất đồng bộ và Request/Response đồng bộ Đây là mô hình command-based và chúng tôi có một bảng log khổng lồ chứa mọi message đã gửi Schema và cách dùng các message này là nội bộ trong team, và chúng bị xóa khỏi NATS sau khi sử dụng Chúng tôi dùng at-least-once delivery và kỳ vọng message handler có tính idempotent Đã từng có một hai vấn đề do cấu hình sai NATS khiến message bị replay hoặc bị mất, nhưng nhìn chung rất thành công, và team chúng tôi chỉ có 3 người Theo tôi nó giống Kubernetes: chỉ cần bám vào phần cốt lõi và đừng cố quá thông minh thì nó sẽ hoạt động tốt

(news.ycombinator.com)

49 điểm bởi xguru 2024-06-21 | 11 bình luận | Chia sẻ qua WhatsApp

Cho đến tận đầu những năm 2010, người ta vẫn nói nhiều về việc xây dựng hệ thống phân tán dựa trên MQ, nhưng dạo gần đây lại không còn nhiều bài viết về chủ đề này
Một vài giả thuyết mình nghĩ tới như sau, không biết có phải một trong số này không, hay mọi người còn có góc nhìn nào khác:
- Redis xử lý được hầu hết các trường hợp sử dụng, kể cả caching, nên việc vận hành riêng một message broker không còn nhiều giá trị. Còn Kafka thì đi hẳn về quy mô rất lớn.
- DB (nếu hiểu theo nghĩa rộng) đã xử lý tải lớn tốt hơn rất nhiều, nên các tác vụ mang tính “tạm thời” giờ được xử lý ngay trong kho lưu trữ chính
- Người ta nhận ra rằng kiến trúc dựa trên MQ không hoạt động tốt như kỳ vọng, nên giờ chuyển sang cách khác
- Thực ra công nghệ MQ giờ đã bước vào giai đoạn trưởng thành, không còn đủ mới lạ để người ta viết bài nữa. Nhưng nó vẫn đang được dùng rất rộng rãi

hnthrowaway_99

Nhiều kiến trúc từng “hot” vào cuối những năm 2000 đến đầu những năm 2010 cuối cùng đã biến mất sau khi người ta nhận ra rằng “bạn không phải Google. Công ty của bạn cũng sẽ không bao giờ trở thành Google”
Thời đó có một khát vọng rất lớn là “xây dựng theo cách mà các tập đoàn thành công đã xây dựng”
Nhưng sau đó, nhiều người nhận ra rằng với 99% công ty thì mức độ phức tạp đó là không cần thiết
Khi phần cứng và các cơ sở dữ liệu tiêu chuẩn ngày càng tốt hơn, số công ty thực sự cần những “Scalability Trick” như vậy ngày càng ít đi
Ngưỡng của tôi cho câu hỏi “có lý do gì mà chúng ta không làm tất cả việc này bằng Postgres không?” giờ đã cao hơn rất nhiều so với 10 năm trước
Các bình luận bên dưới bình luận này
- Giờ đã có những máy đơn lẻ lớn hơn rất nhiều với chi phí hợp lý. Trước đây cần một cụm nhỏ, còn giờ một hệ thống đơn cũng có thể gánh được rất nhiều loại workload khác nhau
- Nói thật thì tôi từng tham gia vài dự án ở Google nhằm loại bỏ queue. Nên có lẽ vấn đề còn hơn cả chuyện “giảm độ phổ biến”

biglain

Hơi cay nghiệt nhưng theo tôi, kiến trúc MQ và các bài blog về nó phần lớn là kiểu “Resume Driven Development”. Trên thực tế, người ta làm những thứ hoàn toàn có thể chạy trên một chiếc laptop đơn mà không cần phải vượt ra khỏi monolith.
Có lẽ chính những người đó là những người xây nên các thảm họa microservice ác mộng, ngốn AWS hàng chục nghìn đô mỗi tháng
Những người “ưu tiên tích lũy thành tích kỹ thuật cho sự nghiệp hơn là giải quyết vấn đề kinh doanh thực tế theo cách thực dụng” giờ đang chuyển sang hype AI và viết blog về AI

tuckerconnelly

Gần đây tôi đã chuyển từ microservice về monolith vì microservice quá phức tạp và có quá nhiều mã trùng lặp. Không có microservice thì nhu cầu với message queue cũng giảm đi
Với các tác vụ bất đồng bộ, tôi từng dùng RabbitMQ trong một dự án, nhưng nó cho cảm giác quá cũ và bị thiết kế quá mức
Và nhiều công cụ xung quanh nó (Celery) cũng không tốt bằng các công cụ hiện đại xây quanh Redis (bullmq)
Với các quy trình nhiều tầng theo kiểu DAG, tôi thích xử lý mọi thứ trong một job lớn nếu có thể, hoặc chia thành một số ít job nhỏ hơn
Nếu thật sự cần DAG thì đã có công cụ được làm riêng cho việc đó (Airflow). Nhưng tôi nghe nói rất khó debug vấn đề, nên tốt nhất vẫn nên tránh nếu có thể
Cá nhân tôi vẫn dùng Redis single-node vì kiến trúc multi-node của Redis quá mức phức tạp đến vô lý và gặp vấn đề khi scale. Nhưng sharding thủ công thì với tôi vẫn ổn và chạy tốt
Bình luận của kypro về bài này
- Theo kinh nghiệm của tôi, monolith không làm giảm độ phức tạp mà chỉ chuyển nó sang chỗ khác
- Vấn đề lớn nhất của monolith là các mối quan tâm giữa các domain không được tách biệt rõ ràng và minh bạch, nên theo thời gian codebase monolith rất dễ biến thành một mớ spaghetti code đan chéo khủng khiếp
- Điều này càng đúng khi bạn xây dựng dự án lớn với nhiều lập trình viên, đặc biệt nếu có nhiều người không thực sự hiểu hết độ phức tạp domain của phần code họ đang động vào
- Monolith phù hợp cho dự án nhỏ với ít lập trình viên, nhưng ngoài trường hợp đó thì đa số sẽ hối hận trong vài năm sau khi xây monolith
- Tôi cũng không đồng ý về chuyện mã trùng lặp. Nếu dùng cùng một ngôn ngữ và chia sẻ package giữa các dự án, tôi không hiểu vì sao đó lại là vấn đề lớn
- Dù sao thì khi làm việc với microservice, tôi chưa từng gặp các vấn đề như vậy
- Tôi cũng muốn đặt câu hỏi liệu trung bình microservice có thực sự phức tạp hơn monolith hay không
- Điều tôi thích nhất ở kiến trúc microservice là việc hiểu và đóng góp vào từng microservice riêng lẻ đơn giản đến mức nào
- Kiến trúc và provisioning của microservice có thể phức tạp hơn, nhưng từ góc nhìn của lập trình viên làm việc trên từng microservice, nó đơn giản hơn rất nhiều so với monolith

democracy

Có vẻ ý này là đúng: “Công nghệ MQ giờ chỉ đơn giản là đã trưởng thành, không còn thú vị đến mức đáng để viết bài, nhưng vẫn đang được sử dụng rộng rãi”
Kiến trúc dựa trên messaging vẫn rất phổ biến
Các bình luận về bài này
- casper14: Đồng ý. Nó chỉ đơn giản đã trở thành một công cụ. Cũng như giờ chẳng còn ai viết bài về cách dùng máy ảo trên cloud nữa
- bwhaley: Đây mới là câu trả lời đúng. Gần như mọi hệ thống phân tán chạy ở quy mô lớn đều có dùng message queue ở mức độ nào đó
- ipsum2: Khả năng cao là vậy. Trước đây các bài viết về chuyện rewrite Angular sang React rất hút view, còn giờ ai cũng chỉ dùng React hoặc viết về việc rewrite React sang Vue

busterarm

Tôi sẽ đưa ra một câu trả lời không mấy được ưa thích
Queue, stream và Pub/Sub là những khái niệm mà đa số kỹ sư không thực sự hiểu rõ
- Họ không biết khi nào cần dùng, cũng không biết dùng cho đúng, và lại mang đi dùng sai mục đích
- Tôi vẫn đang làm việc với tất cả những thứ trên (SQS/SNS/RabbitMQ/Kafka/Google Pub/Sub)
Tôi làm ở một công ty chỉ tuyển những kỹ sư “xuất sắc nhất”, tốt nghiệp từ 3–4 trường hàng đầu Bắc Mỹ, và đây gần như là công việc đầu tiên của hầu hết mọi người
Các kỹ sư của chúng tôi đã làm những chuyện điên rồ như sau:
- Đẩy hàng chục nghìn message 100MB lên RabbitMQ trong chớp mắt rồi thắc mắc vì sao nó nổ tung
- Thường xuyên gửi message kích thước khá lớn qua RabbitMQ dù đã có đủ loại cảnh báo bảo đừng làm thế
- Bắt đầu dự án mới trong năm 2024 với phiên bản RabbitMQ mới nhất nhưng lại định dùng classic queue
- Tạo quorum queue mà không có chính sách replication, hay nói đúng hơn là chẳng làm gì để có HA cả
- Expose cluster ra Internet trong khi user quản trị vẫn là guest/guest
- Kiến trúc sư cấp cao nhất trong tổ chức tuyên bố một pattern kiến trúc mới, tổ chức họp toàn công ty và demo nó
  - Họ ca ngợi một “đức tính/pattern” mới là nhét message vào queue, rồi tạo một backchannel để consumer thứ hai có thể xử lý message trong queue theo kiểu on-demand (và như thế thì nó không còn là queue nữa)
  - Và ngoài tôi ra thì không ai hỏi “tại sao lại đưa vào queue những message cần được xử lý theo đúng thứ tự?”, thế là cái “pattern” đó bén rễ luôn!
- Dùng Kafka làm message queue mặc định
- Truyền dữ liệu từ data center trung tâm tới các data center phân tán khắp thế giới, đặt global lock lên object và chặn mọi thứ cho tới khi từng data center đích xác nhận đã nhận object cập nhật. Sau đó vẫn tuyên bố quy trình này là bất đồng bộ vì dữ liệu được gửi cùng với AJAX request
Kết quả là dù mọi người không cần phải làm điều gì quá ghê gớm, họ vẫn xoay xở được. Thế nên công cụ vừa bị dùng sai, lạm dụng, lại cũng bị dùng chưa đủ
Ở những nơi dùng đúng cách, có lẽ bạn sẽ chẳng bao giờ nghe họ nói nhiều về nó
Sự thật quan trọng: trong tổ chức của chúng tôi có hơn 30 microservice cho mỗi kỹ sư. Làm ơn giết tôi đi. Tôi thà trở thành Kurt Cobain còn hơn là làm ở một tổ chức khác có hàng nghìn microservice trong một monorepo khổng lồ
Các bình luận về bài này
- zug_zug: Nếu bổ sung dữ liệu thực tế để củng cố giả thuyết này thì
  - Tôi từng làm ở một startup tại New York dùng Akka (queueing hướng sự kiện của Scala)
  - Tại sao lại như vậy? Có phải vì người quản lý từ công ty trước từng “cứu” công ty bằng cách này khi “mọi thứ quá chậm”, nên sang công ty mới liền bắt buộc áp dụng?
  - Công việc nào thực sự cần queueing? Chỉ là hiển thị 401k của nhân viên trên website, cho phép họ điều chỉnh phân bổ tài sản, và gửi vài trăm email mỗi ngày
  - Đúng như dự đoán, người ta hầu như chẳng mấy khi đăng nhập vào website 401k đó
  - Sau khoảng một năm làm việc ở đó, tôi nhận ra server luôn bị cấu hình sai và về cơ bản concurrency cho web request là 0
  - (Không ai nhận ra vì 2 server production luôn đủ để xử lý toàn bộ traffic cần thiết)
  - Cuối cùng Akka bị loại bỏ vì chỉ làm tăng thêm độ phức tạp hoàn toàn không cần thiết
  - Tháng trước công ty này lại gọi thêm một vòng vốn kèm lựa chọn cash-out, rõ ràng định giá đã tăng và có vẻ họ vẫn đang làm ăn tốt
- scary-size: Nghe không giống là chỉ tuyển kỹ sư “xuất sắc” lắm nhỉ?
- roncesvalles: Có vẻ như không có quy trình review thiết kế. Nếu là tôi, tôi sẽ tuyển lập trình viên 2–5 năm kinh nghiệm từ các trường vô danh thay vì người mới tốt nghiệp trường nổi tiếng. Lượng kiến thức và sự trưởng thành mà kỹ sư phần mềm tích lũy trong 5 năm đầu sự nghiệp là cực lớn, có lẽ còn nhiều hơn toàn bộ phần còn lại của sự nghiệp cộng lại.

burutthrow

Tôi nghĩ MQ đã khá commoditized
Nếu mua Confluent, RedPanda hoặc MSK dưới dạng dịch vụ, bạn không cần tự quản lý Kafka nữa
Change Data Capture (CDC) cũng đã rất mạnh và trở thành xu hướng chính thống. Ghi dữ liệu vào RDBMS rồi capture các thay đổi để lan truyền sang hệ thống khác giờ tương đối dễ
Ví dụ, điều này có nghĩa là message queue chỉ còn là xương sống để hệ CDC dùng truyền message, nên người ta không còn viết nhiều về Kafka nữa
Những kiến trúc như vậy rõ ràng vẫn tồn tại và đáp ứng được ràng buộc của đa số tổ chức
Với các queue kiểu ghi một lần đọc nhiều lần như Kafka, có thể dùng để expose API cho các bộ phận khác trong tổ chức. Nhiều công ty dùng pattern này để trộn và dùng lại dữ liệu giữa nhiều team
Một team nhỏ mà sở hữu rất nhiều microservice thì nghe giống kiểu development vì CV, nhưng ở công ty có hơn 100 kỹ sư thì pattern này lại hợp lý

angarg12

MQ là một công cụ trong hộp đồ nghề của distributed systems. Khi phù hợp thì nó hoạt động rất tốt
Nếu giả thuyết nào của bạn đúng nhất thì tôi nghĩ là câu này: “người ta thường viết blog về những thứ mới mẻ và hào nhoáng”
Cá nhân tôi luôn dùng queue trong thiết kế, đặc biệt khi truyền dữ liệu giữa các hệ thống khác nhau cần mức độ decoupling cao
Nỗi đau duy nhất tôi từng gặp là khi phải backfill 7 ngày dữ liệu từ upstream system, khiến queue bị tắc bởi các request cũ
- Nếu cứ để chạy bình thường thì phải mất hơn 100 giờ mới xử lý hết dữ liệu, và độ trễ của dữ liệu mới cũng sẽ tăng khủng khiếp
- Cách giải quyết là xóa queue thủ công rồi tự backfill lại phần dữ liệu mới nhất bị thiếu
Cần cẩn thận với kích thước queue không bị giới hạn, nhưng tôi vẫn nghĩ đây là một công cụ rất tốt

rossdavidh

MQ trên Gartner Hype Cycle hiện đã
- vượt qua “Peak of inflated expectations”
- đi qua “trough of disillusionment”
- và đang tiến lên “Slope of Enlightenment”, thậm chí là “plateau of productivity”

robertclaus

Điều rất thú vị là bình luận “rõ ràng tất cả chúng ta vẫn dùng message queue và worker, chỉ là không còn viết về nó nữa” lại bị chìm xuống phía sau giữa các cuộc tranh cãi về microservice và khả năng scale thực tế
Một kỹ sư junior đọc thread này có thể sẽ hiểu lầm rằng giờ không nên đẩy các tác vụ tính toán nặng ra khỏi web server sang worker nữa

pm90

Các bài blog về chủ đề này giảm đi vì công nghệ đó đã trở nên nhàm chán
Và đó là điều tốt. Ví dụ tài liệu chính thức của RabbitMQ giờ đã tốt hơn rất nhiều và rất hữu ích
Người ta dùng nó như dùng Postgres/MySQL vậy
Cũng không cần kỹ thuật gì quá thần kỳ để thiết kế kiến trúc quanh nó
Tôi yêu phần mềm nhàm chán: “I love boring software”

slowmovintarget

Phần lớn các kiến trúc kiểu này trước đây chạy trong data center doanh nghiệp
Sau khi chuyển sang cloud và xây các dịch vụ nhỏ stateless hơn (cùng với sự xuất hiện của SPA), nhu cầu với các hệ thống event-driven nhiều bước phức tạp giảm đi
Ví dụ trên AWS, chỉ cần SQS và một ít SNS, hoặc Kinesis cho một vài trường hợp là đủ. Khi đó MQ không còn là trung tâm của thiết kế nữa
Kiến trúc dựa trên MQ tốt cho xử lý dữ liệu nhưng không phù hợp lắm với website tương tác, và nếu đa số mọi người đang xây website tương tác thì dễ hiểu vì sao họ không chọn nó
Tôi vẫn thiết kế event system cho xử lý dữ liệu (đặc biệt khi có business data bất biến mà về sau có thêm sự kiện mới, hoặc hóa ra trước đó ta “đã sai” hay lẽ ra cần biết một thông tin khác ở thời điểm trước)
Nhưng với phần lớn ứng dụng thì... không cần

mannyv

Toàn bộ backend của chúng tôi là queue-based
Nếu thứ gì đó là bất đồng bộ và không cần thời gian phản hồi nhanh, hãy dùng queue. Nó đơn giản, ổn định, và queue có thể kích hoạt lambda
Dùng queue cũng giúp thu thập metric và dữ liệu hiệu năng dễ hơn
- Khi tải cao, queue có thể phình lên đến hàng triệu message rồi giảm dần theo thời gian
- Hoặc bạn có thể tạo hàng trăm lambda tùy ý để xử lý toàn bộ số message đó

vishnugupta

Theo kinh nghiệm của tôi, MQ đã bị trừu tượng hóa đi chứ không hề biến mất
Ví dụ hàng đợi kiểu SQS + polling giờ đã trở thành một quy trình ít phải gọi server hơn. Vẫn có message queue ở đâu đó, chỉ là nó không còn lộ ra nữa
AWS SNS, một lớp trừu tượng cao hơn SQS, giờ đã rất giàu tính năng đến mức trên thực tế có thể thay thế SQS
Ngoài ra, vì streaming đã trở thành công nghệ rất ổn định, nên các use case trước đây dùng queue như một ống streaming đã chuyển sang hẳn các hệ thống streaming chuyên dụng

memset

Có thể vì lambda (cloud function) đang trở nên phổ biến hơn và được hỗ trợ trên nhiều nền tảng
Khi thêm thứ gì đó vào queue thì rốt cuộc vẫn phải lấy nó ra và xử lý. Lambda làm việc đó chỉ với một lần invoke. Bạn cũng không cần tự chạy hay scale worker nữa
Tôi nghĩ Kafka vẫn tiếp tục phổ biến vì nó được dùng như một kho dữ liệu tạm thời, và có hệ sinh thái lớn để thu thập từ stream
Cá nhân tôi dùng queue rất nhiều và đang xây một giải pháp thay thế SQS mã nguồn mở. Cũng tự hỏi liệu một giải pháp thay thế lambda mã nguồn mở có hữu ích không

liampulles

“Giờ công nghệ MQ đã trưởng thành, không còn thú vị đến mức người ta muốn viết bài về nó nữa, nhưng vẫn đang được dùng rộng rãi”
- Chuẩn là vậy. Tôi nghĩ các use case đơn giản của giao tiếp bất đồng bộ dùng Pub/Sub đơn giản vẫn rất hữu ích và cũng không quá khó để áp dụng
Chúng ta (với tư cách cộng đồng lập trình viên) đã đi qua giai đoạn event sourcing, mạng lưới phức tạp và việc xây dựng quy mô không cần thiết. Nói cách khác, chúng ta đã đi qua chu kỳ hype
Team của chúng tôi dùng NATS cho Pub/Sub bất đồng bộ và Request/Response đồng bộ
- Đây là mô hình command-based và chúng tôi có một bảng log khổng lồ chứa mọi message đã gửi
- Schema và cách dùng các message này là nội bộ trong team, và chúng bị xóa khỏi NATS sau khi sử dụng
- Chúng tôi dùng at-least-once delivery và kỳ vọng message handler có tính idempotent
Đã từng có một hai vấn đề do cấu hình sai NATS khiến message bị replay hoặc bị mất, nhưng nhìn chung rất thành công, và team chúng tôi chỉ có 3 người
Theo tôi nó giống Kubernetes: chỉ cần bám vào phần cốt lõi và đừng cố quá thông minh thì nó sẽ hoạt động tốt

11 bình luận

finnchoi 2024-06-25

Có những tình huống phù hợp cần đến hàng đợi. Tuy nhiên, với phần lớn quy mô và cách sử dụng, việc dùng hàng đợi hoặc vận hành theo cụm thường làm tăng độ phức tạp mà lại không mang đến nhiều lợi thế đáng kể về hiệu năng. Những kiến trúc phức tạp mà các công ty lớn, được xây dựng để phục vụ khả năng mở rộng và dữ liệu quy mô lớn, thường tự hào giới thiệu có thể sẽ không bao giờ thực sự trở nên phù hợp với hệ thống của bạn.

Những công nghệ mới hấp dẫn về mặt kỹ thuật và các kiến trúc đẹp mắt cũng cần được cân nhắc dựa trên các vấn đề thực tế để chọn ra giải pháp phù hợp. Trong đa số trường hợp, không có quá nhiều dữ liệu cần xử lý và PostgreSQL cũng thường đã đủ đáp ứng.

Chúng tôi nhận thấy vấn đề này và đang phát triển một DB có kiến trúc đơn giản nhưng vẫn có thể xử lý dữ liệu ở mức TB trên một node duy nhất. Dù có phần thận trọng, chúng tôi vẫn khuyên bạn nên xem đây như một lựa chọn khác.
Đưa dữ liệu án lệ vào trạng thái có thể tìm kiếm nhanh

dakbutfly 2024-06-24

Lập trình thủ tục nhìn chung dễ hiểu hơn, còn cách làm dựa trên MQ thì không tạo được cảm giác nắm bắt ngay hoặc khá khó để hiểu cấu trúc. Trong công ty, trình độ kiến thức thường không đồng đều, và trong trường hợp đó nếu dùng MQ với hiểu biết sai lệch thì có vẻ sẽ trở thành địa ngục.

Tôi nghĩ đây không chỉ là vấn đề của riêng MQ, mà là vấn đề thường xảy ra khi áp dụng các công nghệ đòi hỏi một mức độ kiến thức nhất định mà không có đào tạo bài bản tổng thể.

nemorize 2024-06-21

PHP thì MQ gần như là bắt buộc...

halfenif 2024-06-21

Chột dạ thật!

Hiện giờ tôi đang làm một toy project có tên chứa Quee đấy.

kandk 2024-06-21

Thành thật mà nói, nếu chỉ phục vụ trong phạm vi nội địa ở nước mình trong 99% trường hợp thì tôi nghĩ mấy thứ đó đều không cần thiết..

superwoou 2024-06-21

Có lẽ điều quan trọng không phải là phạm vi của dịch vụ, mà là tính chất của dịch vụ và mức độ cần cân nhắc hiệu quả chi phí, đúng không?

2024-06-21

[Bình luận này đã bị ẩn.]

bus710 2024-06-22

Có phải vì quy trình đưa ra quyết định vốn mang tính dọc nên kiến trúc “hướng quy trình” được ưa chuộng hơn hoặc được xem là phù hợp hơn không?
Nếu mỗi bộ phận và đội ngũ được tổ chức lỏng lẻo hơn, thì liệu một kiến trúc không hướng quy trình có thể vận hành trơn tru hơn, và nhờ đó các ứng dụng của những hàng đợi như thế này cũng hoạt động hiệu quả hơn hay không, mình khá tò mò.

savvykang 2024-06-21

Có vẻ như "phát triển theo định hướng CV" là từ khóa xuyên suốt hiện tượng theo trào lưu này.

hyeonseokoh94 2024-06-22

Wow, câu này đúng là danh ngôn thật, kiểu phát triển dựa trên CV ấy mà..

savvykang 2024-06-23

Còn có cả sản phẩm cùng dòng là phát triển theo cơn sốt.