Ngày 09 tháng 12 năm 2020 - Công nghệ máy tính
Khi quy mô ứng dụng ngày càng mở rộng, kiến trúc đơn thể không còn đủ khả năng đáp ứng được các nhu cầu kinh doanh ngày càng tăng của doanh nghiệp, từ đó dẫn đến sự xuất hiện của kiến trúc vi dịch vụ. Mặc dù vi dịch vụ mang lại nhiều lợi ích, nhưng cũng đồng thời tạo ra nhiều thách thức, nguyên nhân chủ yếu là do mức độ phức tạp tăng cao. Để giải quyết các vấn đề mà vi dịch vụ gây ra, đã xuất hiện xu hướng phổ biến về lưới dịch vụ (service mesh). Tuy nhiên, vào đầu năm 2020, Istio – một trong những thực thi nổi tiếng nhất của lưới dịch vụ – đã đi ngược lại xu hướng này bằng cách chuyển từ kiến trúc vi dịch vụ trở lại kiến trúc đơn thể. Vậy lý do đằng sau sự thay đổi này là gì? Có lẽ đây là cơ hội để chúng ta xem xét lại những lợi ích và vấn đề mà kiến trúc vi dịch vụ mang lại.
1. Vi dịch vụ có những ưu điểm gì?
Việc chia nhỏ một ứng dụng phức tạp theo kiến trúc đơn thể thành các vi dịch vụ theo từng lĩnh vực cụ thể cho phép các đội ngũ tập trung vào phạm vi quan tâm của mình, đảm bảo tính độc lập và hạn chế ảnh hưởng lẫn nhau. Những ưu điểm chính bao gồm:
-
Giao tiếp và triển khai độc lập: Các vi dịch vụ tách biệt giúp xác định rõ ràng ranh giới giữa chúng. Mỗi dịch vụ có thể sử dụng ngôn ngữ lập trình hoặc bộ công cụ kỹ thuật khác nhau, giao tiếp thông qua các giao thức nhẹ như HTTP hoặc RPC. Với chu kỳ sống riêng biệt, các dịch vụ có thể triển khai độc lập mà không cần phải điều phối hay chờ đợi lẫn nhau. Do kích thước nhỏ và tốc độ cập nhật nhanh, tổng thể hệ thống có thể phát triển song song, giống như một dây chuyền sản xuất hiệu quả.
-
Ranh giới bảo mật rõ ràng: Mỗi vi dịch vụ thuộc các lĩnh vực khác nhau có thể yêu cầu mức độ bảo mật khác nhau. Kiến trúc vi dịch vụ cho phép thiết lập các chiến lược bảo vệ phù hợp với từng dịch vụ, từ đó nâng cao tính an toàn tổng thể của hệ thống.
2. Vi dịch vụ có những bất lợi gì?
Mục tiêu ban đầu của hầu hết các đội ngũ khi áp dụng kiến trúc vi dịch vụ là nhằm giảm thiểu độ phức tạp của ứng dụng hoặc hệ thống, chia nhỏ một vấn đề lớn thành nhiều vấn đề nhỏ hơn để xử lý dễ dàng hơn. Tuy nhiên, sau khi phân chia, số lượng vi dịch vụ có thể rất lớn, dẫn đến việc chuỗi gọi liên kết trở nên phức tạp, thậm chí khó quan sát hơn theo thời gian. Một vấn đề quan trọng khác là yêu cầu vận hành trở nên cực kỳ cao. Trước đây, chỉ cần triển khai một runtime duy nhất, mọi thứ đều đơn giản. Ngày nay, việc triển khai một ứng dụng đòi hỏi phải quản lý hàng loạt vi dịch vụ, cùng với các mối liên hệ phụ thuộc và yêu cầu hệ thống phức tạp. Cuối cùng, việc chuyển sang kiến trúc vi dịch vụ không làm giảm độ phức tạp của hệ thống mà còn làm tăng thêm. Chính vì vậy, các công nghệ như container hóa và dàn xếp container đã ra đời để giải quyết những vấn đề này.
3. Istio có kiến trúc như thế nào cwin222 trước đây?
Sau khi tìm hiểu về ưu và nhược điểm của kiến trúc vi dịch vụ, chúng ta hãy xem Istio có cấu trúc như thế nào trước khi có sự thay đổi lớn này?
Kiến trúc tổng thể của Istio trước đây như hình dưới đây minh họa, tương tự như các lưới dịch vụ khác trong ngành, chia thành hai phần: mặt dữ liệu và mặt kiểm soát. Mặt dữ liệu bao gồm một nhóm các proxy (hay còn gọi là sidecar), được triển khai cùng với các phiên bản dịch vụ và chịu trách nhiệm đại diện cho win 911 tất cả lưu lượng vào và ra của dịch vụ. Mặt kiểm soát nằm ngoài các dịch vụ này, chịu trách nhiệm quản lý và kiểm soát tập hợp các proxy ở mặt dữ liệu.
Ban đầu, mặt kiểm soát của Istio được thực hiện theo kiến trúc vi dịch vụ, bao gồm các phần chính sau:
- Pilot: Chịu trách nhiệm cấu hình proxy trong quá trình chạy.
- Galley: Theo dõi các bản cập nhật cấu hình, kiểm tra tính hợp win 789 club lệ và phân phối cấu hình.
- Citadel: Xử lý việc cấp chứng chỉ, tạo khóa và tích hợp với cơ quan chứng nhận (CA).
- Injector: Thực hiện việc tiêm tự động vào dịch vụ.
Vậy tại sao Istio lại quyết định quay trở lại kiến trúc đơn thể?
Sau khi áp dụng kiến trúc vi dịch vụ, mặc dù mỗi dịch vụ có thể được phát triển và cập nhật độc lập, nhưng đối với người dùng cuối, họ vẫn cần một hệ thống thống nhất để triển khai và cung cấp dịch vụ. Việc xác định lỗi gặp phải trong quá trình sử dụng Istio trở nên khó khăn hơn do sự phức tạp của các mô-đun bên trong. Vì vậy, Istio bắt đầu cân nhắc việc quay lại kiến trúc đơn thể để đơn giản hóa việc sử dụng.
4. Kiến trúc Istio hiện tại trông như thế nào?
Dưới đây là biểu đồ kiến trúc Istio sau khi quay trở lại kiến trúc đơn thể. Có thể thấy rằng mặt kiểm soát vốn bị phân chia thành nhiều vi dịch vụ đã được hợp nhất thành một dịch vụ đơn lẻ tên là istiod. Điều này giúp việc cài đặt, triển khai, sử dụng, cấu hình, bảo trì và gỡ lỗi trở nên đơn giản hơn, đồng thời tiết kiệm tài nguyên hệ thống.
5. Bài học từ sự thay đổi kiến trúc của Istio?
Cuối cùng, chúng ta hãy thảo luận về những bài học mà sự thay đổi kiến trúc của Istio mang lại cho chúng ta.
Trước tiên, đây là một sự điều chỉnh kiến trúc dựa trên đặc thù của Istio, phù hợp hơn với kiến trúc đơn thể và không đại diện cho xu hướng chung của ngành. Thứ hai, kiến trúc vi dịch vụ gần như là tiêu chuẩn của các ứng dụng hiện đại, mang lại nhiều lợi ích nhưng cũng làm tăng đáng kể độ phức tạp của hệ thống. Trong thiết kế hệ thống, chúng ta cần phân tích kỹ lưỡng khách hàng mục tiêu, trường hợp sử dụng và tỷ lệ hiệu quả chi phí khi áp dụng kiến trúc vi dịch vụ. Đồng thời, việc phân chia vi dịch vụ cần được thực hiện với mức độ phù hợp, tránh việc chia quá lớn hoặc quá nhỏ, tùy thuộc vào tình huống thực tế của hệ thống. Dù chọn phương pháp nào, mục tiêu cuối cùng của chúng ta vẫn là làm cho hệ thống trở nên “đơn giản” hơn.
[1] Giới thiệu về istiod: đơn giản hóa mặt kiểm soát [2] Istio như một ví dụ về khi nào không nên sử dụng vi dịch vụ
#Thiết kế kiến trúc #Lưới dịch vụ #Istio