Chương 1 sẽ giới thiệu cái nhìn tổng quan về đề tài nghiên cứu, các công trình liên quan, mục tiêu nghiên cứu, đối tượng nghiên cứu và phạm vi nghiên cứu. Chương 2 sẽ mô tả kiến thức cơ bản về kiến trúc Mieroservice, phương thức giao tiếp giữa các Microservice, các biện phòng thủ cho Microservice hiện nay, các dạng tấn công tầng ứng dụng, giới thiệu các mô hình học sâu hiện nay. Mô hình đề xuất. Chương 3 mô tả chi tiết về Hệ thống API Gateway và các module của nó mà nhóm đề xuất, đặc biệt tập trung vào module Deep Learning phát hiện tấn công và tác dụng của sự tích hợp học liên kết để tăng khả năng phát hiện tấn công.
Thực nghiệm và đánh giá. Chương 4 trình bày quá xây dựng và thực nghiệm hệ thống, các kịch bản thực nghiệm của nhóm và phương thức đánh giá kết quả. Kết luận Chương 5 tổng kết quá trình nghiên cứu, xây dựng hệ thống và đề xuất các hướng triển trong tương lai. Chương 2 CƠ SỞ LÝ THUYET 2.
Tông quan về Microservice 2. Kién trúc Microservice Kiến trúc Microservice(MFA), hay còn gọi là Microservice, là một thiết kế kiến trúc phần mềm dựa trên dịch vụ, trong đó ứng dụng phân tách thành nhiều dịch vụ nhỏ, liên kết với nhau. Mỗi dịch vụ xử lý một chức năng cụ thể của ứng dụng như đăng ký người dùng mới hoặc truy vấn cơ sở dữ liệu. Trong kiến trúc Microservice, mỗi dịch vụ là một giao diện được xác định rõ ràng, hoạt động cùng với các dịch vụ khác nhưng có thể được phát triển, kiểm thử, mở rộng và triển khai một cách độc lập nhờ thiết kế polylithic của ứng dụng.
Giao diện này có thể được gọi khi có lời gọi API RESTful hoặc RPC từ người dùng. Microservices A | @--- SỐ T API Client —> Gateway 2. Đặc điểm kiến trúc Microservice e Tách rời: Các dịch vụ trong một hệ thống phần lớn được tách rời. Vì vậy, toàn bộ ứng dụng có thể dễ dàng được xây dựng, thay đổi và thu nhỏ.
e Thành phần hoá: mỗi dịch vụ được coi là các thành phần độc lập có thể dễ dàng thay thế và nâng cấp. e Phù hợp với doanh nghiệp: các lập trình viên hay các nhóm có thể làm việc độc lập với nhau trong quá trình phát triển. e Khả năng tự trị: Khả năng phân tán và phân cấp tạo ra tính linh hoạt và chống lại sự tập trung quyền lực. e Cơ sở mã riêng biệt: không có mẫu chuẩn hóa hoặc bất kỳ mẫu công nghệ nào.
Được tự do lựa chọn các công cụ hữu ích tốt nhất để có thể giải quyết van dé. e Phân phối liên tục: Cho phép phát hành phan mềm thường xuyên, liên tục. Lợi ích của kiến trúc Microservice e Khả năng nhanh nhẹn: Do các Microservice được triển khai độc lập, việc quản lý sửa lỗi và phát hành tính năng trở nên dé dàng hơn. Bạn có thé cập nhật một dịch vụ mà không cần triển khai lại toàn bộ ứng dụng, và có thể hoàn nguyên cập nhật nếu có vấn đề gì xảy ra.
Trong nhiều ứng dụng truyền thống, nếu phát hiện lỗi trong một phần của ứng dụng, nó có thể chặn toàn bộ quá trình phát hành. Các tính năng mới có thể bị trì hoãn chờ đợi việc sửa lỗi được tích hợp, kiểm thử và xuất bản. e Tập trung theo nhóm nhỏ: Một Microservice nên đủ nhỏ để một nhóm tính năng duy nhất có thể xây dựng, kiểm thử và triển khai nó. Nhóm nhỏ thúc day tính linh hoạt cao hơn.
Các nhóm lớn thường kém năng suất hơn vì giao tiếp chậm hơn, chi phí quản lý tăng lên và tính linh hoạt giảm. e Hệ thống mã nhỏ: Trong một ứng dung monolithic, theo thời gian, các phụ thuộc mã có xu hướng trở nên rối ram. Thêm một tính năng mới đòi 8 hỏi phải chạm vào mã ở nhiều vị trí. Bằng cách không chia sẻ code hoặc kho lưu trữ dữ liệu, kiến trúc Microservice giảm thiểu các phụ thuộc và giúp việc thêm các tính năng mới dễ dàng hơn.
e Kết hợp nhiều công nghệ: Các nhóm có thể chọn công nghệ phù hợp nhất với dịch vụ của họ, sử dụng kết hợp các ngăn xếp công nghệ khi cần thiết. e Tách biệt lỗi: Nếu một Microservice riêng lẻ không khả dụng, nó sẽ không làm gián đoạn toàn bộ ứng dụng, miễn là bất kỳ Microservice thượng nguồn nào được thiết kế để xử lý lỗi chính xác. Ví dụ, bạn có thể triển khai mẫu Ngắt mạch (Circuit Breaker) hoặc bạn có thể thiết kế giải pháp của minh để các Microservice giao tiếp với nhau bằng cách sử dụng các mẫu nhắn tin bất đồng bộ. e Khả năng mở rộng: Các dịch vụ có thể được mở rộng độc lập, cho phép bạn mở rộng các hệ thống phụ yêu cầu nhiều tài nguyên hơn, mà không cần mở rộng toàn bộ ứng dụng.
Bằng cách sử dụng một bộ dàn nhạc như Kubernetes, bạn có thé đóng gói mật độ dịch vụ cao hơn trên một host duy nhất, cho phép sử dụng tài nguyên hiệu quả hơn. e Tách biệt dữ liệu: Việc cập nhật lược đồ trở nên dễ dàng hơn nhiều vì chỉ có một Microservice duy nhất bị ảnh hưởng. Trong một ứng dung monolithic, việc cập nhật lược đồ có thể trở nên rất khó khăn vì các phan khác nhau của ứng dụng đều có thể chạm vào cùng một dit liệu, khiến bất kỳ thay đổi nào đối với lược đồ đều trở nên rủi ro. Các thách thúc của Microservice e Phức tap: Ứng dụng Microservice có nhiều thành phần hoạt động hơn so với ứng dụng monolithic tương đương.
Mỗi dịch vụ riêng lẻ đơn giản hơn, nhưng toàn bộ hệ thống lại phức tạp hơn. 9 e Phát triển và kiểm thử: Viết một dịch vụ nhỏ phụ thuộc vào các dich vụ phụ thuộc khác đòi hỏi cách tiếp cận khác so với việc viết một ứng dụng monolithic hoặc theo lớp truyền thống. Các công cụ hiện có không phải lúc nào cũng được thiết kế để hoạt động với các phụ thuộc dịch vu. Refactoring vượt qua các ranh giới dịch vụ có thể khó khăn.
Kiểm thử các phụ thuộc dịch vụ cũng là một thách thức, đặc biệt là khi ứng dụng phát triển nhanh chóng. e Thiếu sự kiểm soát: Cách tiếp cận phân cấp để xây dựng Microservice có những ưu điểm, nhưng cũng có thể dẫn đến vấn đề. Bạn có thể kết thúc với quá nhiều ngôn ngữ và framework khác nhau khiến ứng dụng khó bảo trì. Sẽ hữu ích nếu đặt ra một số tiêu chuẩn cho toàn bộ dự án, mà không hạn chế quá nhiều tính linh hoạt của các nhóm.
Điều này đặc biệt áp dụng cho các chức năng cắt ngang như ghi nhật ký. e Tắc nghẽn mạng và độ trễ: Việc sử dụng nhiều dịch vụ nhỏ, chỉ tiết có thể dẫn đến nhiều giao tiếp giữa các dịch vụ hơn. Ngoài ra, nếu chuỗi phụ thuộc dịch vụ quá dài (dịch vụ A gọi B, B gọi C .), độ trễ bổ sung có thể trở thành vấn đề. Bạn cần thiết kế API cẩn thận.
Tránh các API "nói nhiều", suy nghĩ về định dạng serialization và tìm kiếm các vị trí để sử dụng các mẫu giao tiếp không đồng bộ như cân bằng tải dựa trên hàng đợi. e Tính toàn vẹn dữ liệu: Với mỗi Microservice chịu trách nhiệm cho sự tồn tại dit liệu của riêng nó. Do đó, tính nhất quán của dữ liệu có thể là một thách thức. Sử dụng tính nhất quán cuối cùng (eventual consistency) bất cứ khi nào có thể.
e Kha năng quản lý: Dé thành công với Microservice, đòi hỏi một văn hóa DevOps chuyên nghiệp. Ghi nhật ký tương quan giữa các dịch vụ có thể 10 là một thách thức. Thông thường, nhật ký phải tương quan nhiều cuộc gọi dịch vụ cho một hoạt động của người dùng duy nhất. e Xung đột giữa các bản cập nhật: Cập nhật cho một dịch vụ không được làm gián đoạn các dịch vụ phụ thuộc vào nó.
Nhiều dịch vụ có thể được cập nhật bất kỳ lúc nào, vì vậy nếu không thiết kế cẩn thận, bạn có thể gặp vấn đề về khả năng tương thích ngược hoặc hướng tới tương lai. Giao tiếp trong Microservice Trong các ứng dung monolithic trong quá khứ, giao tiếp giữa các thành phan được gọi là giao tiếp giữa các tiến trình (inter-process communication) - nhưng điều cần lưu ý là tất cả các tiến trình này thực chất chỉ là một tiến trình duy nhất. Các thành phần trong ứng dung monolithic gọi lan nhau bằng cách sử dụng các gọi phương thức (method calls).NÑgười lập trình chỉ cần tạo lớp và gọi phương thức bên trong module mục tiêu. Tất cả các thành phần này đều chạy trong cùng một tiến trình.Ưu điểm của cách giao tiếp này là rất đơn giản.
Tuy nhiên, mặt trái của nó là các thành phần trở nên rất phụ thuộc lẫn nhau, gây khó khăn trong việc tách biệt và mở rộng độc lập từng thành phần. Một trong các thách thức lớn nhất khi chuyển đổi từ ứng dung monolithic sang kiến trúc Microservice là sự thay đổi cơ chế giao tiếp. Điều này là do các Microservice được phân tán va chúng giao tiếp với nhau thông qua giao tiếp giữa các dịch vụ trên lớp mạng. Mỗi Microservice có phiên bản và tiến trình riêng biệt.
Do đó, các dịch vụ phải tương tác với nhau bằng các giao thức giao tiếp giữa các dịch vụ như HTTP, gRPC hoặc giao thức message broker AMQP. Vì Microservice là một cấu trúc phức tap được phát triển và triển khai độc lập thành các dịch vụ riêng lẻ, nên chúng ta cần cần thận khi xem xét các loại hình giao tiếp và quản lý chúng trong giai đoạn thiết kế. Trước khi thiết kế giao tiếp Microservice, chúng ta cần hiểu về các kiểu giao 11 tiếp, chúng có thể được phân loại theo hai loại. Bước đầu tiên là xác định giao thức giao tiếp là đồng bộ (synchronous) hay không đồng bộ (asynchronous).
Giao tiếp đồng bộ Request MicroService A Waiting MicroService B Response Hình 2.2: Giao tiếp đồng bộ trong Microservice Về cơ bản, chúng ta có thể nói rằng giao tiếp đồng bộ sử dụng giao thức HTTP hoặc gRPC để trả về phản hồi đồng bộ. Trong giao tiếp đồng bộ, phí client sẽ gửi yêu cầu sử dụng giao thức HTTP/gRPC để để gửi yêu cầu đên dịch vụ và chờ đợi phản hồi. Điều này có nghĩa là phía client sẽ tạm ngưng luồng van hành của phiên làm việc này cho đến khi nhân được phản hồi từ dịch vụ. Client sẽ tiếp tục nhiệm vụ chỉ khi nhận được phản hồi từ phía dịch vụ.
Giao tiếp bat đồng bộ 1. Request MicroService A Not Waiting 4. Response Message Broker 2.3: Giao tiếp bat dong bộ trong Microservice Trong giao tiếp bất đồng bộ, client gửi yêu cầu nhưng không đợi phản hồi từ dịch vụ.