Xây dựng hệ thống pubsub chịu tải cao - vozForums
vozForums
Go Back   vozForums > Máy tính để bàn > Phần mềm > Phát triển Phần mềm
Reply
 
Thread Tools
  #1  
Old 11-06-2019, 20:41
freex's Avatar
freex freex is offline
Member
 
Join Date: 08-2010
Posts: 34
Xây dựng hệ thống pubsub chịu tải cao

Chào các bác,

Em đang làm cho 1 product về event, lượng tải lúc big event rất cao, tầm gần 1 triệu lượt transaction trong 1 ngày.
Mô hình của em lại là dạng microservice, giao tiếp kiểu api restful giữa các service với nhau.
Mô hình này em thấy không phù hợp lắm vì có nhiều service khi bị quá tải thì không cách nào retry call các api lại được, vì thế em đang muốn build 1 service pubsub ở giữa quản lý các message giao tiếp giữa các service này, cũng như retry lại sau nhiều khoảng thời gian khác nhau nữa.

Thiết kế của em như thế này:
Viết 1 service pubsub để làm trung gian xử lý, các message xử lý này sẽ lưu trữ lại để có thể retry sau 1 vài lần khi server subcribe bị chết, hoặc bị timeout vì quá tải.

Em có 3 vấn đề muốn tham khảo các bác:
+ Cần ghi lại các message này trước khi subcribe, em đang tính write vào filelog để logstash đẩy lên ELK, sau đó lên Kibana query để biết các message nào thành công, miss, fail .. từ đó có report để có thể update manual lại chẳn hạn.

+ Cần có 1 đầu event-driven để retry lại sau 1 khoảng thời gian nhất định. Em đang tính push error-message này vào rabbit-mq với delay-time, rồi sau đó lấy ra để gọi lại vào api của service subcribe sau 1 khoảng delay-time đó. Có bác nào làm nhiều với Rabbit có thể cho em biết khả năng chịu tải của nó không ạ?

+ Cần có 1 sự đảm bảo là service pubsub này ngỏm ở bất cứ giai đoạn nào thì lúc restart các message cũng không thể bị mất, cũng như nếu nó chết đi, thì cũng có 1 giải pháp nào đó để bọn service vẫn có thể call api trực tiếp cho nhau được.

Sorry vì hỏi các bác khá nhiều, thôi thì mong các bác xem như 1 topic để thảo luận để cùng nhau phát triển tư duy thiết kế hệ thống vậy nhé

Thank các bác
Reply With Quote
  #2  
Old 11-06-2019, 21:01
RPG29's Avatar
RPG29 RPG29 is offline
Đã tốn tiền
 
Join Date: 07-2010
Posts: 1,566
Re: Xây dựng hệ thống pubsub chịu tải cao

Sao không làm cái message broker/event storage ở giữa như RabbitMQ/Apache Kafka rồi đẩy hết event về đó hở bác? Consumer tèo thì restart lại xử lý tiếp?
Reply With Quote
  #3  
Old 11-06-2019, 21:04
freex's Avatar
freex freex is offline
Member
 
Join Date: 08-2010
Posts: 34
Re: Xây dựng hệ thống pubsub chịu tải cao

Quote:
Originally Posted by RPG29 View Post
Sao không làm cái message broker/event storage ở giữa như RabbitMQ/Apache Kafka rồi đẩy hết event về đó hở bác? Consumer tèo thì restart lại xử lý tiếp?
Mình muốn gom các message này về 1 service để xử lý, cũng như retry lại các message bị ngỏm .. mà không cần các publisher/comsumer phải take care việc này.

Một điều nữa, là các service hiện tại của mình đều gọi nhau bằng api restful, nếu dựng các thằng broker message ở giữa thì phải viết code lại 1 loạt các service consumer như vậy. Đây cũng là 1 trong những lý do mà mình muốn dựng 1 cái service pubsub ở giữa, để nhận api vào, và sau đó sẽ gọi api của bên nhận.

Ở bên dưới hệ thống này thì chắc sẽ là 2 service con đóng vai trò publisher và comsumer, và chắc vẫn là vẫn dùng RabbitMQ hoặc Kafka cho chúng mà thôi.

Last edited by freex; 11-06-2019 at 21:13.
Reply With Quote
  #4  
Old 12-06-2019, 09:44
_sharp_'s Avatar
_sharp_ _sharp_ is offline
Đã tốn tiền
 
Join Date: 11-2009
Location: Onepiece
Posts: 1,330
Re: Xây dựng hệ thống pubsub chịu tải cao

Quote:
Originally Posted by RPG29 View Post
Sao không làm cái message broker/event storage ở giữa như RabbitMQ/Apache Kafka rồi đẩy hết event về đó hở bác? Consumer tèo thì restart lại xử lý tiếp?
"tầm gần 1 triệu lượt transaction trong 1 ngày." đâu cần dùng đến RabbitMQ/Apache Kafka

Chủ thớt tính theo CCU đi, tính theo ngày thì lúc thiết kế hệ thống hơi dư thừa.
Reply With Quote
  #5  
Old 12-06-2019, 16:01
freex's Avatar
freex freex is offline
Member
 
Join Date: 08-2010
Posts: 34
Re: Xây dựng hệ thống pubsub chịu tải cao

Quote:
Originally Posted by _sharp_ View Post
"tầm gần 1 triệu lượt transaction trong 1 ngày." đâu cần dùng đến RabbitMQ/Apache Kafka

Chủ thớt tính theo CCU đi, tính theo ngày thì lúc thiết kế hệ thống hơi dư thừa.
1 triệu lượt thanh toán thôi bác. Còn số lượt checkout, listing .. các kiểu cao lắm chứ.

Với lại event flash sale nó theo khung giờ. Tới khung giờ có khi có cả vài ngàn đơn trong vài giây.
Reply With Quote
  #6  
Old 12-06-2019, 16:08
prescolt's Avatar
prescolt prescolt is offline
Senior Moderator
 
Join Date: 07-2006
Posts: 9,299
Re: Xây dựng hệ thống pubsub chịu tải cao

Cái này bên tiki đó hà
Reply With Quote
  #7  
Old 12-06-2019, 20:03
bribnt's Avatar
bribnt bribnt is offline
Đã tốn tiền
 
Join Date: 02-2013
Posts: 3,639
Re: Xây dựng hệ thống pubsub chịu tải cao

Quote:
Originally Posted by freex View Post
Mình muốn gom các message này về 1 service để xử lý, cũng như retry lại các message bị ngỏm .. mà không cần các publisher/comsumer phải take care việc này.

Một điều nữa, là các service hiện tại của mình đều gọi nhau bằng api restful, nếu dựng các thằng broker message ở giữa thì phải viết code lại 1 loạt các service consumer như vậy. Đây cũng là 1 trong những lý do mà mình muốn dựng 1 cái service pubsub ở giữa, để nhận api vào, và sau đó sẽ gọi api của bên nhận.

Ở bên dưới hệ thống này thì chắc sẽ là 2 service con đóng vai trò publisher và comsumer, và chắc vẫn là vẫn dùng RabbitMQ hoặc Kafka cho chúng mà thôi.
Thấy kafka có các tính năng như bác yêu cầu: lưu message vào persistent, lưu lại offset của consumer nên khi ngỏm có thể tiếp tục từ lần trước hoặc bắt đầu tự đầu nếu muốn. Chỉ là không phải rest api. Không biết có thể làm thêm một cái proxy đơn giản ở trước, để phần còn lại cho Kafka nó làm được không?

Sent from HiPhone 5 using vozFApp
Reply With Quote
  #8  
Old 13-06-2019, 08:37
noneedname's Avatar
noneedname noneedname is offline
Senior Member
 
Join Date: 08-2011
Location: Heaven
Posts: 519
Re: Xây dựng hệ thống pubsub chịu tải cao

Bác muốn dựng một con service lưu toàn bộ req/res của toàn bộ hệ thống để có thể retry?
Các service khác giao tiếp với con này theo cơ chế nào? http, tcp?
Bác bảo các service khác khi peek k scale nổi thì lấy gì đảm bảo con service pubsub này scale được? Có gì đảm bảo nó k bị lost data?
Con Elasticsearch kể cả bác có dựng cluster thì khả năng chịu tải của nó cũng là vấn đề, bác dự 1 ngày nó lưu bao nhiêu message, 500 triệu? Bác định query trong bao lâu? 1 ngày, 1 tháng?
E nghĩ bác nên nêu rõ vấn đề của hệ thống bên bác chứ dựng thêm 1 con khác vào theo ngu ý của e thì có thể sẽ phát sinh nhiều vấn đề với con bác mới dựng.
Reply With Quote
  #9  
Old 13-06-2019, 10:21
_sharp_'s Avatar
_sharp_ _sharp_ is offline
Đã tốn tiền
 
Join Date: 11-2009
Location: Onepiece
Posts: 1,330
Re: Xây dựng hệ thống pubsub chịu tải cao

Quote:
Originally Posted by freex View Post
...
Mô hình của em lại là dạng microservice, giao tiếp kiểu api restful giữa các service với nhau.
Mô hình này em thấy không phù hợp lắm vì có nhiều service khi bị quá tải thì không cách nào retry call các api lại được, vì thế em đang muốn build 1 service pubsub ở giữa quản lý các message giao tiếp giữa các service này, cũng như retry lại sau nhiều khoảng thời gian khác nhau nữa.
.....
+ Cần có 1 sự đảm bảo là service pubsub này ngỏm ở bất cứ giai đoạn nào thì lúc restart các message cũng không thể bị mất, cũng như nếu nó chết đi, thì cũng có 1 giải pháp nào đó để bọn service vẫn có thể call api trực tiếp cho nhau được.
Vậy thì có cách build con Pubsub HA cao nhất thôi, chơi combo multi cloud + datacenter đi.
Reply With Quote
  #10  
Old 15-06-2019, 18:09
vinhomn vinhomn is offline
Đã tốn tiền
 
Join Date: 10-2008
Location: 50cm trước màn hình.
Posts: 1,380
Re: Xây dựng hệ thống pubsub chịu tải cao

Khó hiểu thế nhỉ? đã gọi là service pubsub thì sẽ có publisher/subscriber(comsumer)
Giờ bác lại bảo là ko muốn code lại 1 loạt các service consumer??
Thông tin về việc xử lý gửi nhận request/response cũng mù mờ luôn. 1 service call api của 1 service khác là như nào? là call xong có response trả về? hay ko có? Nếu có response trả về thì ko ai gọi đấy publisher/subscriber cả nhé. Hay là muốn broadcast request đến nhiều service?
Cái tên service đặt là pubsub bác hiểu nghĩa là như nào? Loạn hết cả khái niệm lên ai dám đưa ra infrastructure cho bác đc .
Cái service "pubsub" kia của bác như cách em đọc hiểu từ đầu đến h thì nó là 1 con proxy kèm thêm tính năng log/push request vào 1 thằng data storage nào đó để retry khi cần (và logic retry kiểu gì, retry success thì làm gì tiếp thì em cũng chưa tưởng tượng ra luôn ). Các service khác thay vì gọi trực tiếp đến nhau thì giờ gọi thông qua con proxy. Thấy đơn giản là mỗi thế .
Reply With Quote
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

All times are GMT +7. The time now is 03:07.
Steam Powered by vBulletin® 0.1 pre-alpha
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.