Ngày 07 tháng 12 năm 2020 - Công nghệ máy tính
1. Service Mesh Là Gì?
Service mesh là một hệ thống chuyên trách quản lý tất cả các giao tiếp nội bộ giữa “dịch vụ với dịch vụ” trong các hệ thống phần mềm phân tán.
Trước khi tìm hiểu lý do tại sao service mesh xuất hiện, ta có thể bàn về quá trình tiến hóa của kiến trúc dịch vụ. Ban đầu, chúng ta sử dụng một ứng dụng monolith để cung cấp dịch vụ. Ví dụ, khi xây dựng một hệ thống thương mại điện tử, chúng ta thường áp dụng kiến trúc MVC ba lớp điển hình. Trong kiến trúc monolith, các chức năng như giỏ hàng, kiểm tra kho hàng và xử lý đơn đặt hàng đều là các hàm hoặc API nằm bên trong dịch vụ này. Vì vậy, các thao tác này chỉ là các cuộc gọi hàm trong cùng một quy trình, không liên quan đến giao tiếp qua mạng giữa các dịch vụ như RPC. Tuy nhiên, theo thời gian, chúng ta nhận thấy rằng kiến trúc monolith không còn đáp ứng được nhu cầu của chúng ta nữa, chẳng hạn như sự gia tăng đột biến của lượt truy cập người dùng hay độ phức tạp ngày càng tăng của logic kinh doanh. Một dịch vụ monolith đã không thể thỏa mãn cả yêu cầu chức năng lẫn hiệu suất. Do đó, chúng ta cần chia nhỏ nó thành nhiều dịch vụ độc lập dựa trên từng lĩnh vực nghiệp vụ cụ thể, đây chính là kiến trúc microservices. Ví dụ, các chức năng như giỏ hàng, kiểm tra kho hàng và xử lý đơn đặt hàng sẽ được tách ra thành các dịch vụ độc lập. Khi nhận được một yêu cầu mua sắm, chúng ta cần truy vấn vào các microservices khác nhau để xử lý nghiệp vụ, điều này dẫn đến giao tiếp qua mạng giữa các quy trình.
Và do sự bất ổn định của mạng lưới giao tiếp giữa các dịch vụ, một loạt các vấn đề nảy sinh: Làm thế nào để thực hiện lại yêu cầu khi thất bại? Làm thế nào để xử lý trường hợp yêu cầu vượt quá thời gian cho phép? Làm thế nào để giới hạn tốc độ khi có quá nhiều yêu cầu? Làm thế nào để thực hiện circuit breaker?… Các thư viện hỗ trợ dựa trên ngôn ngữ hoặc framework là một giải pháp, ví dụ như Eureka và Hystrix của Netflix. Tuy nhiên, việc giải quyết vấn đề giao tiếp giữa các dịch vụ bên trong dịch vụ tồn tại nhiều nhược điểm, chẳng hạn như phải can thiệp vào mã nguồn nghiệp vụ và bị ràng buộc bởi ngôn ngữ hoặc framework. Do đó, thiết kế service mesh dựa trên mô hình proxy, hoàn toàn tách biệt khỏi logic nghiệp vụ, đã trở thành xu hướng được ưa chuộng trong ngành.
Hình dưới đây minh họa cách triển khai một service mesh. Mỗi instance của dịch vụ đều có một proxy đi kèm, những proxy này được gọi là Sidecar, chịu trách nhiệm quản lý lưu lượng vào và ra của dịch vụ được đại diện. Tất cả các Sidecar này, khi kết hợp lại, tạo thành một service mesh. Nhờ vậy, dịch vụ chỉ cần tập trung vào logic nghiệp vụ, trong khi logic giao tiếp giữa các dịch vụ được chuyển sang service mesh, giúp đạt được sự tách biệt.
Do service mesh đại diện cho tất cả lưu lượng vào và ra của giao tiếp giữa các dịch vụ trong hệ thống phân tán, nó giống như đôi mắt của hệ thống, giúp nhà phát triển nắm bắt và quản lý mạng lưới gọi phức tạp mà không cảm thấy sợ hãi. Điều này làm cho hệ 2233win thống phân tán hoạt động như một kiến trúc monolith, đảm bảo khả năng quan sát tốt hơn.
2. Lịch Sử Phát Triển Của Service Mesh
- Đầu năm 2010, Twitter bắt đầu phát triển Finagle dựa trên Scala, từ đó Linkerd service mesh ra đời.
- Cuối năm 2013, SmartStack cung cấp cơ chế khám phá dịch vụ ngoài quy trình dựa trên HAProxy nhằm đáp ứng nhu cầu ngày càng tăng của kiến trúc microservices.
- Năm 2014, Netflix phát hành một bộ công cụ JVM bao gồm Prana, cho phép các dịch vụ được phát triển bằng ngôn ngữ khác nhau gọi qua HTTP.
- Năm 2016, NGINX phát triển Fabric Model, một sản phẩm tương tự service mesh dựa trên NGINX Plus.
- Sau năm 2017, Linkerd, Istio, Maesh, Kuma dần trở nên phổ biến.
3. Kiến Trúc Service Mesh
Sau phần giới thiệu trên, chúng ta đã hiểu rõ hơn về sự ra đời và các vấn đề mà service mesh giải quyết. Phần này sẽ xem xét tổng quan thiết kế và kiến trúc thông dụng của service mesh trong ngành, giúp chúng ta có cái nhìn sâu sắc hơn.
Service mesh chủ yếu bao gồm hai phần: Sidecar Proxy chịu trách nhiệm quản lý giao tiếp giữa các dịch vụ được gọi là mặt dữ liệu (data plane); UI, cấu hình và lệnh điều khiển hành vi của mặt dữ liệu được gọi là mặt kiểm soát (control plane).
4. Service Mesh Có Thể Làm Được Những Gì?
Do service mesh đại diện cho tất cả lưu lượng giao tiếp giữa các dịch vụ trong hệ thống, nó có thể thực hiện nhiều chức năng:
- Quản Lý Lưu Lượng: Cung cấp các tính năng như phát hành màu xám, phân phối lưu lượng theo quy tắc.
- Circuit Breaker Và Retries: Cung cấp xử lý thời gian chờ, circuit breaker và retries.
- Xác Thực Và Ủy Quyền: Cung cấp giao tiếp an toàn mTLS, xác thực và ủy quyền giữa các dịch vụ.
- Quan Sát Và Giám Sát: Cung cấp thống kê số lượng yêu cầu, thống kê độ trễ yêu cầu, tỷ lệ thành công của yêu cầu và theo dõi chuỗi phân tán.
5. Triển Khai Service Mesh
- Linkerd: Dự án ủi CNCF, 100% mã nguồn mở, được viết bằng Rust, mục tiêu là tối giản nhưng hiệu quả, proxy dữ liệu cực kỳ nhỏ (<10mb), tốc độ cực kỳ nhanh (<1ms).
- Istio: Sự thực hiện service mesh phổ biến nhất, dựa trên Envoy data plane, được hậu thuẫn bởi Google và IBM, có nhiều tính năng phong phú.
- Consul: Do HashiCorp phát triển, dựa trên Envoy data plane, hỗ trợ nhiều nền tảng.
- Kuma: Service mesh dựa trên API Gateway Kong.
- Traefik Mesh: Service mesh dựa trên API Gateway Traefik gốc đám mây.
Để so sánh chi tiết hơn, vui lòng tham khảo servicemesh.es.
6. Tương Lai Của Service Pk16vn Bet Mesh
Mecha - Kiến trúc microservices đa runtime. Xu hướng kiến trúc trong tương lai có thể là di chuyển tất cả các middleware truyền thống sang các runtime khác nhau, chỉ giữ lại logic nghiệp vụ trong dịch vụ. Microsoft Dapr là dự án thực tiễn đa runtime đầu tiên trong ngành.