Tối giản việc đọc tin nổi bật, comment chất lượng nhiều reaction trên voz cho các fen bận rộn.

VozFen.com: [thảo luận] Microservices and Cloud Native Group

@RPG29 Joined: 07/2010
#1
Ưng 32

[thảo luận] Microservices and Cloud Native Group

RP…
RPG29

07/2010

@RPG29 07/2010
#4
Ưng 4
Cho mình hỏi ngu, mà mình cũng hỏi chơi thôi chứ cũng ko đang làm về MicroService:

- Trước mình luôn nghĩ là các service giao tiếp bằng API Rest/SOAP, vậy mà mấy hôm nay đọc được khái niệm "Service Bus", vậy cái này là gì vậy.

- Load Balancer là cái gì vậy. Mình đọc thì hiểu là "router làm nhiệm vụ route các request đến các server khác nhau", mà k biết đúng k.

Service Bus là một cái pattern có từ rất lâu rồi. Bác có thể nghe đến Enterprise Service Bus hay ESB chính là nó.
Cơ bản nó là một con đường để vận chuyển data giữa các service. Ví dụ có một thằng rất nổi tiếng là Apache Camel.
ESB thì em chưa dùng thực tế bao giờ chỉ biết vậy thôi. Nó có thể được implement bằng mấy thằng message broker như RabbitMQ, Kafka...

Load Balancer là một hardware hay software có nhiệm vụ distribute request/workload đồng đều giữa các service instance hay server.

ki…
kimcawin

07/2010

@kimcawin 07/2010
#25
Ưng 6
Kinh nghiệm bản thân khi lv vs distributed system & microservice có mấy vấn để nổi bật:
1. Làm sao để chia tách service -> áp dụng DDD để giải quyết
2. Làm sao để scale các service -> áp dụng CQRS, đối vs từng domain sẽ có phần đọc (query) & phần ghi (command). phần đọc scale thoải mái, phần ghi thì không
3. Làm sao để giao tiếp giũa các service -> syncronous = rest api, gRPC,... hoặc asyncronous = message broker (kafka, rabbitmq...)
4. Làm sao để đồng bộ dữ liệu giũa các service -> explixit (viết code để handle trực tiếp), 2 phase commit, DB transaction log tails, event sourcing

achitect của 1 hệ thống là cái cốt lõi, chỉn chu từ đầu luôn luôn tốt hơn, effort bỏ ra thiết kế microservice ngay ban đầu chác chắn nhỏ hơn nhiều khi migrate 1 hệ thống monolithic -> microservice. Tất nhiên là trừ khi bạn ko muốn migtate từ monolithic -> microservice

RP…
RPG29

07/2010

@RPG29 07/2010
#31
Ưng 5
Cảm ơn chia sẻ của các bác.

Nhân đây em muốn hỏi một vấn đề như sau: Giả sử mình có 4 service A B C D. Khi có một request gửi tới A, thì A sẽ xử lý sau đó tiếp tục gửi 3 request tương ứng tới B, C và D. Cả B, C, D đều có thể fail, và nếu fail ít nhất 1 trong 3 service B C D thì phải rollback lại ở các service khác. Vậy trường hợp này mình nên thiết kế như thế nào cho hợp lý?

Trên lý thuyết thì có thể dùng 2-Phases Commit (2PC) hoặc Saga nhưng mà thực tế thì nên cố gắng tránh depend giữa các service vì hiện thực 2PC hoặc Saga không dễ.

Cái nữa depend giữa các service đi ngược lại lợi ích của microservices là isolation, independent và làm tăng độ phức tạp cho việc phát triển, triển khai, vận hành...

Có một số thiết kế họ cho thêm component gọi là aggregation service nằm phía trên các microservices nhỏ để combine kết quả trả về từ các services, mình không thích cách thiết kế này vì nó làm tăng độ phức tạp rất nhiều.

na…
nautilux

10/2008

@nautilux 10/2008
#41
Ưng 6
Vàng quan điểm
Giờ mình ví dụ usecase như thế này: A là OrderService, B là BalanceService (quản lý số dư tài khoản), C là StorageService (quản lý hàng hoá trong kho), đại loại như thế (B hay C có thể là third-party service). Khi A process một order, thì nó phải gọi qua B để update số dư, và gọi qua C để update số lượng. Như vậy thì có gọi là A phụ thuộc vào B không nhỉ? Và nếu để không phụ thuộc thì trong trường hợp này mình nên thiết kế như thế nào cho hợp lý nhỉ?

p/s: Mấy cái mô hình micro-services này trước giờ mình toàn tự vẽ ra rồi code demo chơi chơi chứ chưa có dịp apply vô product thực tế nào nên hơi mù mờ, mong các thím chỉ giáo thêm
independent nghĩa là các services liên quan (A->B->C) đến nhau có thể đứng riêng mà không bị lỗi hay gây ra ảnh hưởng gì ngay cả khi các services liên quan lỗi, giả sử như C lỗi thì A và B vẫn hoạt động bt (trả ra error code / error message) và có thể hoàn tất 1 order đúng trình tự A -> B -> C ngay khi C online trở lại

và mình nói thêm là với bài toán như của bạn thì nên có 1 api gateway đứng trước, có thể liên lạc với nhau bằng message hoặc gì thì tùy


Ảnh nhặt trên mạng

ap…
apologize1232

@apologize1232
#42
Ưng 5
independent nghĩa là các services liên quan (A->B->C) đến nhau có thể đứng riêng mà không bị lỗi hay gây ra ảnh hưởng gì ngay cả khi các services liên quan lỗi, giả sử như C lỗi thì A và B vẫn hoạt động bt (trả ra error code / error message) và có thể hoàn tất 1 order đúng trình tự A -> B -> C ngay khi C online trở lại

và mình nói thêm là với bài toán như của bạn thì nên có 1 api gateway đứng trước, có thể liên lạc với nhau bằng message hoặc gì thì tùy
View attachment 41723

Ảnh nhặt trên mạng


cái diagram huyền thoại này rõ hơn thím nhỉ

hi…
hissteria

09/2006

@hissteria 09/2006
#45
Ưng 7
Vàng quan điểm
Start-up build project từ đầu mà cần ra sản phẩm nhanh thì cứ monolith mà làm cho nhanh và chuẩn. Nhưng phải nhớ tính đường để scalable và migrate to microservice sau này. Hệ thống chưa to chưa phải lo. Migrate hệ thống nhỏ và vừa nó ko quá kinh khủng. Đừng có nghe xui dại làm microservice từ đầu là ốm đòn nghe

ne…
netsstea

04/2011

@netsstea 04/2011
#102
Ưng 16
Vàng quan điểm
Mình cũng làm microservices production cho fintech, cũng tự build một vài dự án microservice, mình làm solution architect với code base luôn.
Stack thì java spring boot, netflix os, docker, kubernetes, openshift, aws, elk, elg... nhiều thứ lắm.
bản thân mình đánh giá. Nếu dự án nhỏ và cty nhỏ thì ko nên build micro service luôn, rất tốn resource, mà nên build dạng monilithic nhưng dạng mở, có thể tách các module thành microservice sau này. Mình cũng định làm một số bài hướng dẫn về build microservice từ con số 0. Đến cách setup hệ thông ci/cd cho nó. Mà lười quá, có thím nào máu thì anh em cùng làm cho vui, mình có thể hướng dẫn hoặc ngược lại