Thảo luận về microservice - Page 8

RPG29 · #71 07-12-2019, 12:02

Quote:

Originally Posted by dreamnight

Đã sử dụng cho một digital bank trong PoC và nó khá cồng kềnh, team không đủ strong và knowledge thì code tè lè dễ bay màu khi lên Staging lắm. Với nữa những thứ trên chỉ là in-theory và khi làm thực tế độ phức tạp nó cao gấp n lần nhé. Nếu dự án bạn đang theo chỉ mới làm tầm < 1 năm thì khuyên hãy sử dụng chiến thuật divide and conquer từng module một trước đã rồi hãy bóc tách ra thành micro-services. Mình đã thấy nhiều team bay màu chỉ vì think as netflix để rồi khi chạy thì run as hobit.

Anw, kinh nghiệm bản thân đã làm hơn 3 năm micro-services chỉ khuyên bạn rằng coi thử app bạn đang cần giải quyết problem gì, các pattern trên có phải best solution (dựa theo công thức time + money + resource) nhất không thôi. Đừng đú theo trend khi bạn còn không đủ sức giải quyết cái problem đó trên 1 cái app monolith.

Sau mấy năm quay lại cái thớt này thì tư duy em khác nhiều rồi. Nói chung bài toán đảm bảo transaction trong microservices là bài toán khó. Cách đơn giản nhất em chọn là CDC + Message Broker để decouple giữa các service, tất nhiên cũng phải thiết kế lại flow phía trên cho phù hợp

dreamnight · #72 08-12-2019, 10:35

Quote:

Originally Posted by RPG29

Sau mấy năm quay lại cái thớt này thì tư duy em khác nhiều rồi. Nói chung bài toán đảm bảo transaction trong microservices là bài toán khó. Cách đơn giản nhất em chọn là CDC + Message Broker để decouple giữa các service, tất nhiên cũng phải thiết kế lại flow phía trên cho phù hợp

Message Broker rất hay nhưng cách implementation vẫn phụ thuộc vào 3rd party. Sau này bạn làm nhiều sẽ hiểu 1 software mà có quá nhiều 3rd party thì chỉ khiến việc service maintenance càng cồng kềnh, càng khó trace exception hơn thôi. Lúc đó mình lại quay ngược bài toán về resources để có dedicated 1 người full-time cho cái 3rd party đó. Nói chung với mình ko có best solution, chỉ có fittest solution thôi. Problem-solution vốn dĩ là 1 cặp trời sinh mà :">

kenptit · #73 15-12-2019, 08:43

Quote:

Originally Posted by RPG29

Sau mấy năm quay lại cái thớt này thì tư duy em khác nhiều rồi. Nói chung bài toán đảm bảo transaction trong microservices là bài toán khó. Cách đơn giản nhất em chọn là CDC + Message Broker để decouple giữa các service, tất nhiên cũng phải thiết kế lại flow phía trên cho phù hợp

bác cho em hỏi nếu dùng Message Broker thì mình giao tiếp trực tiếp giữa các service qua nó luôn hay cần qua tầng gateway

RPG29 · #74 15-12-2019, 15:56

Quote:

Originally Posted by kenptit

bác cho em hỏi nếu dùng Message Broker thì mình giao tiếp trực tiếp giữa các service qua nó luôn hay cần qua tầng gateway

Gateway dùng để giao tiếp từ bên ngoài vào trong hệ thống.
Còn nội bộ bên trong hệ thống, giao tiếp giữa các service thì:
- Synchronize thì dùng Service Mesh (Istio, Consul Connect, Kuma...)
- Asynchronize thì Kafka, RabbitMQ...

2TbP · #75 16-12-2019, 02:59

sắp tới team mình viết microservices bằng go kết hợp với grpc nên cũng đag hóng k biết tương lại như nào

, mà thằng grpc như sinh ra để dùng cho microservice vậy

giao tiếp giữa các service thì đag cân nhắc sài hàng của amazon

dreamnight · #76 16-12-2019, 16:05

Quote:

Originally Posted by 2TbP

sắp tới team mình viết microservices bằng go kết hợp với grpc nên cũng đag hóng k biết tương lại như nào

, mà thằng grpc như sinh ra để dùng cho microservice vậy

giao tiếp giữa các service thì đag cân nhắc sài hàng của amazon

Ai lâu năm sẽ biết rpc là gì, grpc chỉ là 1 cách tối ưu hơn do google tạo ra. Dĩ nhiên nó lightweight hơn HTTP và connection có thể keep long live. Tuy nhiên cái nào cũng có trade off của nó, vì là long-live protocol nên nó đòi hỏi tầng underlying network giữa các services phải tốt để stream hay call, dễ dẫn đến network bottleneck khi stream 1 lượng lớn về 1 service, e.g log service, compression service. Ngoài ra vì nó là long-live connection nên việc deployment bị constraint order (thứ tự deploy).:">

_sharp_ · #77 17-12-2019, 10:44

Quote:

Originally Posted by RPG29

Gateway dùng để giao tiếp từ bên ngoài vào trong hệ thống.
Còn nội bộ bên trong hệ thống, giao tiếp giữa các service thì:
- Synchronize thì dùng Service Mesh (Istio, Consul Connect, Kuma...)
- Asynchronize thì Kafka, RabbitMQ...

Dùng gì mà nhiều vậy, sau viết CV list ra bao nhiêu cho đủ

RPG29 · #78 18-12-2019, 09:58

Quote:

Originally Posted by _sharp_

Dùng gì mà nhiều vậy, sau viết CV list ra bao nhiêu cho đủ

Có dùng hết đâu bác, chọn đại một thằng dùng thử thôi, đám kia từa tựa

kenptit · #79 18-12-2019, 10:00

Quote:

Originally Posted by RPG29

Gateway dùng để giao tiếp từ bên ngoài vào trong hệ thống.
Còn nội bộ bên trong hệ thống, giao tiếp giữa các service thì:
- Synchronize thì dùng Service Mesh (Istio, Consul Connect, Kuma...)
- Asynchronize thì Kafka, RabbitMQ...

Đội ơn bác

angry! · #80 18-12-2019, 20:37

Quote:

Originally Posted by 2TbP

sắp tới team mình viết microservices bằng go kết hợp với grpc nên cũng đag hóng k biết tương lại như nào

, mà thằng grpc như sinh ra để dùng cho microservice vậy

giao tiếp giữa các service thì đag cân nhắc sài hàng của amazon

Làm một thời gian rồi bạn sẽ thấy lạm dụng RPC sẽ tạo ra rất nhiều bottle neck. Nên cách tốt nhất vẫn là thiết kế để hạn chế viẹc dùng RPC, dùng quá nhiều RPC thì làm cha nó monolith cho rồi. Nên vấn đề này lại quy về bài toán, làm sao split service ra trong microservice architecture, và một trong những cách đó là dùng DDD - domain driven development. Nên architect không chỉ rành về architecture mà còn phải hiểu về business của system mình phải có cách dùng phù hợp, và cụ thể là cách chia service phù hợp.