Kỹ thuật xử lý RPC để đảm bảo hiệu suất trong môi trường hàng trăm MSA được chia sẻ bởi các nhà phát triển Kakao và Toss
Nội dung này đề cập đến các kỹ thuật giao tiếp RPC giúp tối đa hóa hiệu suất trong môi trường MSA (Microservice Architecture) quy mô lớn. Không chỉ dừng lại ở việc thực hành gRPC đơn thuần, bạn sẽ được học cách triển khai giao tiếp giữa các dịch vụ một cách ổn định và hiệu quả trong môi trường vận hành thực tế, nơi hàng trăm microservices hoạt động đồng thời. Dựa trên ngôn ngữ Golang, khóa học tập trung vào thực tiễn từ việc viết cú pháp Protocol Buffers (proto), tự động tạo mã nguồn và triển khai dịch vụ, cấu trúc của gRPC và ưu điểm so với RPC truyền thống, cho đến các chiến lược tối ưu hóa hiệu suất. Để ngay cả những người không chuyên hay người mới bắt đầu phát triển server cũng có thể dễ dàng thấu hiểu, chúng tôi giải thích từng bước từ khái niệm RPC đến nguyên lý hoạt động bên trong của gRPC, giúp bạn trang bị năng lực thực chiến để áp dụng ngay vào dịch vụ thực tế.
Tôi đang phát triển tại Toss và là một lập trình viên tham gia và hỗ trợ trong khóa học này. Các bạn nhất định phải hiểu về giao tiếp RPC. Mọi người thường nói rằng họ đã triển khai MSA một cách đơn giản bằng HTTP, nhưng thực ra tôi không đồng ý với điều đó.
Thực tế, ngay cả khi tôi đi phỏng vấn trước đây, khi nói về kiến trúc MSA, họ có xu hướng nhất định sẽ hỏi về RPC, điều này cho thấy giao tiếp RPC trong MSA là một trong những yếu tố cực kỳ quan trọng về mặt tối ưu hóa tài nguyên và quản lý.
Tôi hy vọng khóa học này sẽ giúp ích rất nhiều cho các bạn.
5.0
Choi
100% đã tham gia
Tôi là một developer đã phát triển tại Kakao và cùng Hong tạo ra khóa học này!! Tôi nghĩ có rất nhiều người không thể giải thích tốt mối quan hệ liên kết giữa hai khái niệm RPC communication và MSA architecture, cũng như không hiểu rõ tầm quan trọng của tính tương thích giữa chúng.
Nếu bạn có thể nói rằng "Tôi đã triển khai MSA đến core level ở đâu đó", thì tôi nghĩ bạn nhất định phải có khả năng sử dụng RPC để tối ưu hóa tài nguyên ở tầng network và giải thích được những phần nào đã được cải thiện trong quá trình này.
Dựa trên chủ đề đó, tôi đã chuẩn bị khóa học này và hy vọng các bạn sẽ nhận được nhiều sự giúp đỡ sau khi xem khóa học. Cảm ơn các bạn!
5.0
이병석
100% đã tham gia
Nội dung thực sự rất hữu ích.. Tôi rất mong chờ các bài giảng khác và đã học được rất nhiều điều. Nói cụ thể thì:
1. Tôi đã hiểu được tại sao HTTP lại có giới hạn trong việc triển khai MSA.
2. Tôi đã biết được cách thiết kế RPC có thể đáp ứng các yêu cầu đa dạng từ cơ bản đến nâng cao.
3. Tôi đã biết được những phần cần phải xem xét trong quá trình sử dụng RPC.
4. Tôi đã có thể học những nội dung khó biết như tối ưu hóa kết nối hay tái sử dụng kết nối ở cấp độ protocol.
Cảm ơn rất nhiều vì bài giảng thực sự tuyệt vời.
Bạn sẽ nhận được điều này sau khi học.
“Tại sao cần có RPC?” – Hiểu bản chất của giao tiếp hiệu suất cao vượt xa cả REST
Chinh phục hoàn toàn gRPC – Từ thiết kế proto đến tự động tạo mã và xây dựng dịch vụ thực tế
Bí quyết chống đỡ hàng trăm microservices – Tiết lộ chiến lược đảm bảo hiệu năng kiểu Kakao
ĐỊNH NGHĨA GIAO DIỆN · order.proto
Nếu các dịch vụ cũng đang gọi nhau bằng REST
Các yêu cầu từ bên ngoài gửi đến dùng REST là đúng. Tuy nhiên, nếu các giao tiếp bên trong giữa các dịch vụ cũng dùng cùng phương thức đó, thì khi số lượng dịch vụ tăng lên, chi phí cho header và tuần tự hóa (serialization) cũng sẽ tăng theo.
Trình độ Nhập môn
Thực hành Go
Protocol Buffers
Truyền thông dạng luồng (Streaming)
Thời gian học không giới hạn
// Định nghĩa interface trước, và mã nguồn sẽ được tạo từ đâysyntax = "proto3";serviceOrderService {rpc CreateOrder (CreateOrderRequest) returns (Order);rpc WatchOrder (WatchRequest) returns (streamOrderEvent);rpc Chat (streamMessage) returns (streamMessage);}
gRPC định nghĩa giao diện bằng tệp tin thay vì tài liệu trước. Vì mã nguồn của máy chủ và máy khách được tạo ra từ tệp này, nên nếu quy cách không khớp, lỗi sẽ bị phát hiện ngay ở giai đoạn biên dịch.
1 · Định nghĩa vấn đề
Bên ngoài và bên trong là những vấn đề khác nhau
Đây không phải là câu chuyện về việc chọn một trong hai. Mà là câu chuyện về việc phân chia xem nên sử dụng cái gì vào vị trí nào.
Phân loại
Client ↔ Server
Dịch vụ ↔ Dịch vụ
Bên gọi
Trình duyệt và ứng dụng. Con người đọc và gỡ lỗi (debug)
Dịch vụ khác. Hầu như không có việc gì để con người phải xem xét.
Ưu tiên hàng đầu
Tính phổ biến và khả năng tương thích
Chi phí và độ trễ trên mỗi lần gọi
Số lần gọi
tương ứng với số lượng người dùng
Nó sẽ được nhân lên theo số lượng người dùng × số lượng dịch vụ
Lựa chọn đúng
REST / HTTP
gRPC — HTTP/2 · Multiplexing · Nén tiêu đề
Khi số lượng dịch vụ lên đến hàng trăm, chi phí overhead của header và chi phí tuần tự hóa (serialization) sẽ nhân lên theo số lượng cuộc gọi. Để đưa ra quyết định đó, bạn cần biết gRPC làm điều gì khác biệt.
2 · Bắt đầu
Đây là cuộc đối thoại đã thực sự diễn ra
Hai nhà phát triển hiện đang làm việc tại Kakao và Toss đã nói cùng một điều.
HHongTìm người đã từng triển khai gRPC để xây dựng MSA đến cấp độ core.
KNhà phát triển KakaoLà tôi đây. Không phải áp dụng cho toàn bộ nhưng một phần đang giao tiếp bằng gRPC. Các nhóm khác thì cũng đang dùng RPC hoặc JSON-RPC.
TNhà phát triển TossBên này cũng đang sử dụng một phần. Vì là giao thức nên tất nhiên cũng dùng cả WebSocket và truyền thông RPC.
KNhà phát triển KakaoTôi biết rằng Google cũng sử dụng RPC vì không thể dùng HTTP khi lưu lượng truy cập bùng nổ. Bởi vì khi số lượng dịch vụ càng nhiều, chi phí truyền thông mạng sẽ tăng lên theo cấp số nhân.
KNhà phát triển KakaoTùy vào tình hình của mỗi công ty mà sẽ khác nhau, nhưng khi xây dựng MSA mà không dùng gRPC thì quả thực hơi đáng tiếc.
TNhà phát triển TossTôi cũng đồng cảm. Tôi nghĩ có nhiều người nói rằng "Chúng tôi đã triển khai mọi thứ bằng MSA trong khi giao tiếp qua HTTP", nhưng thực tế thì đó không phải là cách triển khai hoàn hảo.
3 · Phương thức giao tiếp
Có bốn cách gọi khác nhau.
Tùy thuộc vào bên nào là luồng (stream) mà được chia làm bốn loại. Việc lựa chọn loại nào khi tạo chức năng thời gian thực sẽ được quyết định tại đây.
CLIENTSERVER
Unary
Một yêu cầu, một phản hồi. Đây là hình thức được sử dụng nhiều nhất và nhất định phải biết.
CLIENTSERVER
Server Streaming
Gửi yêu cầu một lần và nhận phản hồi chia làm nhiều lần. Được sử dụng trong trường hợp cần đẩy thông báo tiến độ.
CLIENTSERVER
Client Streaming
Gửi nhiều lần và nhận phản hồi một lần vào cuối cùng. Phù hợp cho các tác vụ tải lên theo nhóm.
CLIENTSERVER
Hai chiều
Cả hai bên gửi và nhận cùng một lúc. Chúng ta sẽ cùng xem xét các lưu ý về tính đồng thời.
Phần 5 nằm ở vị trí này. Ví dụ về ứng dụng nhắn tin trong bài thực hành cuối cùng sẽ cho thấy rõ những trường hợp mà chỉ riêng Unary là không đủ.
4 · Lộ trình học tập
Chúng ta sẽ tìm hiểu những gì và theo thứ tự nào
Bắt đầu bằng việc nắm bắt bối cảnh và thiết kế proto, sau đó trải qua các phương thức giao tiếp và tối ưu hóa, cuối cùng kết thúc bằng bài thực hành tổng thể.
01
Giới thiệu khóa học
Giới thiệu khóa học
Source Code
Tóm tắt nội dung bài giảng gRPC
Trang chủ gRPC chính thức
02
Sự khác biệt về ngôn ngữ theo từng môi trường phát triển
Tìm hiểu sự khác biệt giữa Java và Go đối với môi trường phát triển
03
Sự phát triển của hệ thống phân tán và những nhược điểm đi kèm
Tại sao nhiều giao thức khác nhau tồn tại và phát triển?
Các vấn đề tiêu biểu trong hệ thống phân tán và mô hình RPC
Tại sao Google lại sử dụng và áp dụng gRPC
Trắc nghiệm Phần 3
04
Protocol Buffers và cách viết .proto
Protocol Buffers và triết lý thiết kế tương ứng
Viết cú pháp .proto cơ bản và thiết lập mối quan hệ giữa các message
Các mẫu .proto nâng cao và mô hình hóa thông điệp thực tế
Câu đố Phần 4
05
Các kỹ thuật giao tiếp đa dạng trong gRPC
Truyền thông Unary RPC được sử dụng nhiều nhất và nhất định phải biết cùng với kỹ thuật tối ưu hóa
Truyền thông Streaming RPC, thứ thiết yếu được sử dụng trong truyền thông thời gian thực
Lưu ý về Bidirectional Streaming RPC và tính đồng thời
Trắc nghiệm Phần 5
06
Các kỹ thuật tối ưu hóa và tính năng triển khai trong gRPC
gRPC Performance Best Practice
Flow Control để ổn định truyền thông & Interceptors để tái sử dụng mã nguồn
gRPC Load Balancing & Sự hữu ích của Reflection
Dọn dẹp tài nguyên thông qua Graceful Shutdown & Tối ưu hóa thông qua Request Hedging
Trắc nghiệm Phần 6
07
Thực hành gRPC toàn tập
Thiết kế proto cho nền tảng thương mại điện tử như Kakao Shopping
Phân tích các tệp pb được tạo thông qua tính năng tạo mã tự động
Học cách triển khai gRPC thông qua phân tích eCommerce Business Logic
Phân tích mã nguồn và kiểm tra theo cấu trúc eCommerce gRPC Server và Client
Thiết kế proto cho nền tảng tin nhắn truyền thông hai chiều như KakaoTalk
Phân tích mã nguồn gRPC của Client và Server để truyền thông Stream
Câu đố Phần 7
5 · Thực hành
Tạo ra hai thứ từ con số 0
Để không chỉ dừng lại ở việc học ngữ pháp, chúng tôi thiết kế và triển khai hai dịch vụ có tính chất khác nhau.
LAB 01
Nền tảng thương mại điện tử
Tự thiết kế proto cho nền tảng mua sắm
Chúng ta sẽ cùng phân tích xem tệp pb được tạo tự động đã tạo ra những gì.
Phân tích logic nghiệp vụ và cấu hình server cũng như client
Sau khi cấu hình xong sẽ tiếp tục đến phần kiểm tra.
LAB 02
Nền tảng tin nhắn hai chiều
Thiết kế proto dưới dạng tin nhắn (messenger)
Phân tích mã nguồn server và client để truyền thông dạng stream
Bạn sẽ trực tiếp xác nhận xem đâu là những vị trí mà chỉ Unary thôi là không đủ.
Những lưu ý về tính đồng thời đã học ở phần trước sẽ được áp dụng tại đây
Thực hành sẽ được tiến hành bằng ngôn ngữ Go. Vì sự khác biệt về môi trường phát triển giữa Java và Go sẽ được chỉ ra trước ở phần 2 nên ngay cả khi bạn mới làm quen với Go, bạn vẫn có điểm bắt đầu.
Không chỉ dừng lại ở việc học cú pháp. Chúng ta sẽ cùng nhau xây dựng hai dịch vụ có tính chất khác nhau, từ khâu thiết kế proto cho đến khi hoàn thiện mã nguồn.
Nhà phát triển tò mò về cách xử lý giao tiếp trong các dịch vụ quy mô hàng trăm thực thể
Cấp thấp (Junior)
Lập trình viên backend chỉ biết về HTTP và chưa từng tiếp xúc với giao tiếp RPC
Lo ngại về khả năng mở rộng
Nhà phát triển đang cân nhắc giữa khả năng mở rộng lưu lượng truy cập và tính tương thích
Chuẩn bị xin việc
"MSA 구현했어요"에서 한 단계 더 들어가고 싶은 취업 준비생
7 · Thị trường hiện tại
Câu chuyện về việc AI thay thế lập trình viên
Tuyển dụng mới đang giảm dần, và các doanh nghiệp chỉ muốn chọn những người đã được kiểm chứng. Đây là những bài báo xuất hiện trong vài tháng gần đây.
2025Krafton, công ty vừa đạt doanh thu kỷ lục lịch sử, đã bắt đầu cắt giảm nhân sự. Lý do được đưa ra là để chuyển đổi thành một doanh nghiệp 'Ưu tiên AI' (AI First).
2025Các doanh nghiệp chuyên về phần mềm đang tạm dừng tuyển dụng lập trình viên mới. Cũng có dự báo cho rằng việc tuyển dụng lập trình viên cấp độ sơ cấp sẽ giảm mạnh 77%.
2025 có 53% nhà thiết kế trò chơi đã trả lời rằng "AI sẽ thay thế công việc của tôi". Các trường hợp thôi việc theo khuyến nghị cũng đã được báo cáo.
Khi doanh nghiệp càng bất an, phía người được tuyển dụng càng phải thể hiện sự khác biệt rõ rệt hơn. Việc biết tên một giao thức và việc giải thích được lý do tại sao lại chọn giao thức đó là hai câu chuyện hoàn toàn khác nhau.
8 · Đánh giá khóa học
Chia sẻ từ những người đã học trước đó
Tôi đã trích dẫn nguyên văn từ đánh giá khóa học trên Inflearn.
Nội dung thực sự rất hữu ích. Cụ thể là: Thứ nhất, tôi đã hiểu được tại sao việc triển khai bằng HTTP trong MSA lại có những hạn chế. Thứ hai, tôi đã biết cách thiết kế RPC có thể đáp ứng nhiều yêu cầu khác nhau từ cơ bản đến nâng cao. Thứ ba, tôi đã nắm được những khía cạnh cần cân nhắc trong quá trình sử dụng RPC. Thứ tư, tôi đã có thể học được những nội dung khó tìm thấy như tối ưu hóa kết nối hay tái sử dụng kết nối ở cấp độ giao thức.
Lee Byeong-seok · Viết sau khi hoàn thành 100% khóa học
Nội dung vô cùng hữu ích đến mức có thể khiến người ta phát cuồng vì phát triển phần mềm. Vì đây là chủ đề hiếm thấy nhưng lại đúng phần tôi quan tâm, nên tôi rất cảm ơn bạn đã cung cấp bài giảng như thế này.
Kẻ cuồng phát triển · Viết sau khi hoàn thành 92% khóa học
Phần lý thuyết và phần thực hành được phân bổ rất hợp lý. Đây là một bài giảng đáng đồng tiền bát gạo cho những ai muốn nhập môn gRPC.
Rojojun · Viết sau khi hoàn thành 100% khóa học
9 · Người tạo
Được tạo ra bởi ba người
Hai nhà phát triển hiện đang làm việc tại Kakao và Toss, cùng với Hong, một nhà phát triển máy chủ nền tảng tại Pangyo.
KAKAO · BACKEND & DATA ENGINEER
Choi
Từng làm việc tại các tổ chức tài chính lớn (cấp 1) và hiện đang đảm nhiệm vai trò kỹ sư backend và dữ liệu tại Kakao. Tôi cũng đang hoạt động với tư cách là người phỏng vấn.
"Khi nhắc đến MSA, trong buổi phỏng vấn chắc chắn sẽ hỏi về RPC."
TOSS · KỸ SƯ BACKEND
Nhà phát triển Toss
Tôi tốt nghiệp chuyên ngành Công nghệ thông tin tại một trường đại học ở tỉnh, từng làm việc tại Naver và hiện đang phát triển backend tại Toss.
"Nếu chỉ giao tiếp qua HTTP mà nói là đã hoàn thành xong MSA, thì thực tế đó vẫn chưa phải là hoàn thiện."
Người chia sẻ kiến thức · Phát triển máy chủ nền tảng Pangyo
Hong
Xuất thân là một người không chuyên về ngành kỹ thuật, hiện tại tôi đang phát triển backend cho nền tảng tại Pangyo. Tôi cùng các đồng nghiệp đang làm việc trong ngành tạo ra những bài giảng này.
"Khi biết rằng bên ngoài và bên trong là hai vấn đề khác nhau, sự lựa chọn của bạn sẽ thay đổi."
10 · Câu hỏi
Câu hỏi thường gặp về khóa học gRPC
Q.Tôi không biết Go thì có thể nghe bài giảng được không?
⌄
Thực hành sẽ được tiến hành bằng ngôn ngữ Go. Vì phần 2 sẽ đề cập đến sự khác biệt về môi trường phát triển giữa Java và Go trước, nên ngay cả những người đang sử dụng ngôn ngữ khác cũng có điểm bắt đầu. Ngoài ra, trọng tâm của bài giảng này không phải là cú pháp ngôn ngữ mà là thiết kế proto và phương thức giao tiếp, vì vậy việc nắm bắt cấu trúc quan trọng hơn là mã nguồn.
Q.Có nên bỏ REST để chuyển sang gRPC không?
⌄
Không phải vậy. Đối với các yêu cầu (request) từ bên ngoài gửi đến, REST vẫn thường là lựa chọn phù hợp ở nhiều vị trí. Vấn đề nằm ở phía bên trong, nơi các dịch vụ gọi lẫn nhau; khi số lượng cuộc gọi tăng lên, chi phí overhead của header và chi phí tuần tự hóa (serialization) sẽ bị nhân lên. Mục đích của bài giảng này là giúp bạn có thể phán đoán nên sử dụng cái gì vào vị trí nào.
Hỏi:Khóa học này đề cập đến Protocol Buffers ở mức độ nào?
⌄
Phần 4 hoàn toàn dành cho nội dung đó. Bắt đầu từ triết lý thiết kế, chúng ta sẽ đi qua các cú pháp cơ bản và cách thiết lập mối quan hệ giữa các thông điệp (message), cho đến các mô hình thiết kế thông điệp (message modeling patterns) nâng cao được sử dụng trong thực tế. Trong phần cuối cùng, chúng ta sẽ trực tiếp thiết kế hai hệ thống: thương mại điện tử và trình nhắn tin.
Q.Có đề cập đến truyền thông phát trực tuyến (streaming) không?
⌄
Trong phần 5, chúng ta sẽ bắt đầu từ Unary cho đến Streaming RPC và streaming hai chiều, đồng thời chỉ ra các vấn đề về tính đồng thời cần đặc biệt lưu ý trong streaming hai chiều. Ví dụ về nền tảng tin nhắn trong bài thực hành cuối cùng sẽ sử dụng nguyên vẹn nội dung này.
Q.Có nội dung nào về những thứ cần thiết trong vận hành không?
⌄
Phần 6 chính là nơi dành cho nội dung đó. Nó bao gồm các đề xuất liên quan đến hiệu suất, Flow Control để ổn định giao tiếp, Interceptor để tái sử dụng mã nguồn, Load Balancing và Reflection, cho đến Graceful Shutdown và Request Hedging.
Q.Nó có giúp ích cho việc chuẩn bị phỏng vấn không?
⌄
Khóa học này được xây dựng bởi một nhà phát triển đang là người phỏng vấn tại Kakao và một nhà phát triển hiện đang làm việc tại Toss. Cả hai đều cho biết rằng bất cứ khi nào chủ đề MSA được nhắc đến, họ đều hỏi về RPC. Việc biết tên giao thức và việc giải thích được lý do tại sao chọn nó là hai câu chuyện hoàn toàn khác nhau, và khóa học này tập trung vào vế sau.
Giao tiếp nội bộ được thiết kế khác biệt
Khi bạn biết được đâu là nơi chi phí sẽ nhân lên khi dịch vụ tăng dần, các lựa chọn của bạn sẽ thay đổi.
Có một không gian riêng để chia sẻ về những phần còn vướng mắc khi nghe giảng, những câu hỏi phát sinh khi áp dụng vào dịch vụ của chính mình, cho đến cả những câu chuyện về sự nghiệp. Những chỗ bạn bị tắc nghẽn thường cũng là nơi mà người khác gặp khó khăn.
Tôi bắt đầu học lập trình sau một thời gian dài lười biếng ở nhà và cảm thấy hứng thú với nó, hiện tại tôi đang đảm nhận việc phát triển máy chủ nền tảng (platform server) tại Pangyo. Tôi tiếp tục hoạt động với tư cách là người chia sẻ kiến thức vì muốn cung cấp cho các bạn phương pháp tôi đã học cũng như những vấn đề và giải pháp khác nhau mà các bạn có thể gặp phải trong thực tế.
Bài giảng không chỉ được tạo ra từ kiến thức của riêng tôi. Mọi bài giảng đều có sự đồng hành của những người cộng sự.
Tôi đang phát triển tại Toss và là một lập trình viên tham gia và hỗ trợ trong khóa học này. Các bạn nhất định phải hiểu về giao tiếp RPC. Mọi người thường nói rằng họ đã triển khai MSA một cách đơn giản bằng HTTP, nhưng thực ra tôi không đồng ý với điều đó.
Thực tế, ngay cả khi tôi đi phỏng vấn trước đây, khi nói về kiến trúc MSA, họ có xu hướng nhất định sẽ hỏi về RPC, điều này cho thấy giao tiếp RPC trong MSA là một trong những yếu tố cực kỳ quan trọng về mặt tối ưu hóa tài nguyên và quản lý.
Tôi hy vọng khóa học này sẽ giúp ích rất nhiều cho các bạn.
Nội dung thực sự rất hữu ích.. Tôi rất mong chờ các bài giảng khác và đã học được rất nhiều điều. Nói cụ thể thì:
1. Tôi đã hiểu được tại sao HTTP lại có giới hạn trong việc triển khai MSA.
2. Tôi đã biết được cách thiết kế RPC có thể đáp ứng các yêu cầu đa dạng từ cơ bản đến nâng cao.
3. Tôi đã biết được những phần cần phải xem xét trong quá trình sử dụng RPC.
4. Tôi đã có thể học những nội dung khó biết như tối ưu hóa kết nối hay tái sử dụng kết nối ở cấp độ protocol.
Cảm ơn rất nhiều vì bài giảng thực sự tuyệt vời.
Xin chào anh Byeong-seok Lee, cảm ơn anh đã để lại đánh giá tốt.
Anh đã liệt kê từng ưu điểm một cách chi tiết nên chắc chắn sẽ rất hữu ích cho những người tò mò về khóa học này. Tôi sẽ cố gắng tạo ra những khóa học bổ ích hơn nữa trong tương lai. Cảm ơn anh!
Xin chào Rojojun, cảm ơn bạn vì đánh giá tốt. Đây là một đánh giá rất động viên tinh thần. Tôi sẽ cố gắng cung cấp những bài giảng hữu ích hơn nữa!!
Chúc bạn có một ngày tốt lành!!
Đây là nội dung cực kỳ hữu ích đến mức có thể khiến tôi phát cuồng vì lập trình. Vì đây là chủ đề mà tôi quan tâm nhưng thường khó tìm thấy, nên tôi rất biết ơn khi được cung cấp khóa học như thế này. Tôi đã thỉnh thoảng xem các khóa học khác của người chia sẻ, và tôi sẽ mong chờ nhiều hơn nữa trong tương lai. Cảm ơn rất nhiều.
Xin chào anh/chị "người điên về lập trình", có vẻ như tôi đã đến với một khóa học có thể khiến mình điên về lập trình hơn nữa nên cảm thấy rất vui 😊😊 Cảm ơn anh/chị vì đánh giá tốt!
Tôi là một developer đã phát triển tại Kakao và cùng Hong tạo ra khóa học này!! Tôi nghĩ có rất nhiều người không thể giải thích tốt mối quan hệ liên kết giữa hai khái niệm RPC communication và MSA architecture, cũng như không hiểu rõ tầm quan trọng của tính tương thích giữa chúng.
Nếu bạn có thể nói rằng "Tôi đã triển khai MSA đến core level ở đâu đó", thì tôi nghĩ bạn nhất định phải có khả năng sử dụng RPC để tối ưu hóa tài nguyên ở tầng network và giải thích được những phần nào đã được cải thiện trong quá trình này.
Dựa trên chủ đề đó, tôi đã chuẩn bị khóa học này và hy vọng các bạn sẽ nhận được nhiều sự giúp đỡ sau khi xem khóa học. Cảm ơn các bạn!