Giaosucan's blog - Chia sẻ kiến thức theo cách bá đạo

Ticker

20/recent/ticker-posts

Microservice bình dân học vụ - part 1


 London, ngày không sương mù…

Nắng ấm, du khách kéo nhau ra hồ nước, nơi lý tưởng để ngắm thế giới đi qua
Những chiếc xe buýt 2 tầng màu đỏ, hình ảnh đặc trưng của London, dập dìu qua lại quảng trường và bồ câu bay rợp trời
Con sông Thames vẫn chảy hoài trong tâm trí người dân London và những ai yêu thành phố đắm mình trong lịch sử này
Tại một quán thịt chó gốc Việt Nam cạnh nhà thờ Westminster, trung tâm hệ thống nhà thờ Thiên Chúa giáo của vương quốc Anh
Ông CIO xiên một miếng chả chó cho vào mồm nhai nhồm nhoàm, húp 1 chén cuốc lủi 50 độ chà chà…
Hôm nay họp cổ đông, nghe muốn Chằm Zn luôn, các chú nghe thấy người ta nói cái gì chưa?


Thời buổi 4.0 rồi, công nghệ số rồi, phải AI, phải Microservice, phải Cloud Migration, phải FINOPs, phải x, phải y , zzz…
Thì cái Monolithic của mình cũng cũng mà anh, chục năm nay vẫn chạy tốt như tủ lạnh eletrolux . Ông HoE hớp ly bia rồi phân trần
Nhưng mà nó không đủ wow , các chú phải bắt trend, phải đu công nghệ, phải đập nó đi dựng nên Microservice nó mới bao uy tín
Này khó nha bro, migrate microservice phức tạp lắm nào là SAGA patternCommand Query Responsibility SegregationEvent SourcingStrangler Fig PatternBackend for Frontend, Service DiscoveryDatabase per ServiceChoreography Ông Head of Architect vừa húp bát rựa mận vừa tâm sự
Bà nói thiệt hả bà thơ?, ông HoE há hốc mồm, nhưng tôi không hỉu bà nói gì hết á, Choreography, Orchestor là gì, đang microservice là đi vũ công với nghe nhạc giao hưởng làm gì
Anh chỉ đi massage thôi chử chả đi nghe nhạc giao hưởng bao giờ, ông CIO lèm bèm, chú thông não cho anh mấy cái term cái, nghe loạn quá
Anh có xem engineering blog của Big tech không từ Netflix, Paypal họ xài nhiều event message, streaming như Kafka không, nó có lý do đằng sau cả đấy
Nghe nói Netflix chơi tới 36 con cluster Kafka xử lý hàng tỉ message hàng ngày
Paypal có khoảng 85+ kafka cluster, 1500 broker chứa 20K topic. Vào ngày black friday 2022, traffic volume tại thời điểm peak là 1.3 nghìn tỉ message/day.
Oh oh thấy mấy công ty migrate sang microservice cũng chơi kiến trúc event driven nhiều, message các kiểu
Nó bắt nguồn từ SAGA Pattern đó sếp, mô tả trong hệ thống phân tán, các service communication với nhau như thế nào. Saga là một tập hợp transactions của các services liên kết với nhau để thực hiện một yêu cầu từ business. Ví dụ giờ anh chỉ đạo bọn em chuẩn bị tiệc đi tiếp khách là cả một process dài như sớ luôn, đâu tiên em thư ký phải xếp lịch đón khách rồi báo cho em customer care là lên schedule đi (tiếp) khách, rồi mấy ông lãnh đạo lập agenda để họp với khách, rồi xxxx, yyyy…
Mà transaction nó cũng có bài bản cả, gọi là Choreography và Orchestrator
Orchestration vs Choreography, which one should you use? The pros and cons

Chú nói tiếng Eng hộ anh cái vừa Google ChatGPT mà nó trả lời anh nghe ngáo đá luôn
Dạ ra đời em nể mỗi anh. Để em giải thích non-tech cho anh nghe
Orchestration



Giờ anh giao cho em PM làm cái App thương mại điện tử như Shoppe, giá 5 chẹo, em (Orcheastor) nhận chỉ đạo rồi là ra lệnh cho mấy thằng đệ (microservice), đây gọi là command driven pattern, a chỉ làm việc trực tiếp với em, không quan tâm đến mấy thằng đệ. Hàng ngày em update output cho anh, còn sau em e làm gì anh ko cần care, miễn là deliver xong a giả em 5 chẹo là ok.
Làm thế cũng tiện quyền lực tập trung vào PM (Centralized control flow), có issue gì sếp cứ giã đầu chú (Easier to trace and debug) , chú thành ông nhạc trưởng dàn nhạc rồi đó. HoE xuýt xoa
Thế thì mày ốm đau què quịt thì tao chết à, dạ vâng Orchestor tuy đơn giản nhưng nó là Single Point of Failure, rồi nhỡ tao giao nhiều việc quá thì mày overload (botte neck) thì sao
Dạ vâng thế nên giờ người ta ưng Choreograpy, mô hình vũ công, thay vì anh giao việc cho em, anh viết sẵn plan (biên kịch) cho từng thằng đệ của em, nhưng thằng A thì làm plan Order, B làm plan Payment. Rồi chúng nó tự giao tiếp với nhau (event/message) để làm theo plan của anh thôi.
Saga choreography pattern - AWS Prescriptive Guidance
Như vậy thì em khỏe, em chỉ khoản lý nhân sự thêm bớt service thôi, task nặng thì em tuyển thêm mấy service mới , còn nhẹ em release đi . Mấy thằng đệ nó làm việc giao tiếp với nhau qua Message ( như xài Team/Email chat chit). Giúp loose coupling, Event-driven and decentralized.
Thế nên mấy cái kiến trúc mà cứ xài Queue là (kafka, event hub, event bus) là nó từ cái strategy này mà ra.
Ông CIO ngoạm thêm miếng đùi chó, rồi phề phà
Chú giải thích thì cũng cũng, nhưng mà nó mới có đại cương quá, thực tế còn bao nhiêu thứ chú chưa tính đến
Giờ chú quản lý mấy thằng đệ (service), một hôm thằng đệ nó ốm đau (service down), gọi mãi không thấy thì phải làm sao, cứ call (request) nó liên tục à thế có mà sập hệ thống message queue, Retry Pattern đâu, Circuit Breaker implement chưa
Rồi mấy thằng đệ có thằng có thể xem phải nhận nhiều task, thằng ít task. Thế control cost, scaling sao cho hợp lý. Thằng nhiều việc thì phải scaling up, thằng ít thì scale down, chơi CQRS chưa
Cái message kia độ vài nghìn message thì ok, nhỡ peak time nó lên vài triệu mấy service subscribe nó consume processing thế nào…
Chú monitoring and logging mấy cu đệ làm việc thế nào, giờ 3 thằng thì ok , 30 thằng monitoring nổi không
Mấy thằng đệ hàng ngày message communicate qua MS Team công ty thì cũng bảo mật, nhỡ hôm nào nó hứng lên nó message qua Zalo Facebook thì ISM to đùng, tính sao…

Thôi anh ơi, anh để em làm nốt đĩa thịt chó đã để em thở tí rồi em viết bài tiếp

Đăng nhận xét

0 Nhận xét