Phát triển api gateway Đảm bảo an toàn hệ thống microservices

Đồ án tự phát triển API Gateway đảm bảo an toàn hệ thống Microservices sử dụng Java Spring Boot và Angular

BAN CƠ YẾU CHÍNH PHỦ

BAN CƠ YẾU CHÍNH PHỦ

LỜI CẢM ƠN

Lời đầu tiên, em xin chân thành cảm ơn các quý thầy cô trong trườngHọc viện Kỹ thuật Mật mã cũng như các thầy cô trong khoa An toàn thôngtin Thầy cô đã giúp em bồi đắp kiến thức cũng như những kỹ năng cần thiếttrong suốt thời gian là sinh viên học viện, cũng như sự quan tâm và tạo mọiđiều kiện thuận lợi cho em trong quá trình thực hiện đồ án.

Và để hoàn thành đồ án tốt nghiệp này, em xin được bày tỏ lòng cảmơn sâu sắc tới giảng viên hướng dẫn - người thầy đã tận tình giúp đỡ, trực tiếpchỉ dạy, hướng dẫn em trong suốt quá trình làm đồ án tốt nghiệp

Sau cùng xin được gửi lời cảm ơn chân thành tới gia đình, bạn bè đãđộng viên, đóng góp ý kiến và giúp đỡ em trong quá trình học tập, nghiên cứuvà hoàn thành đồ án tốt nghiệp.

Em xin chân thành cảm ơn!

Hà Nội, Ngày 08 tháng 06 năm 2022.SINH VIÊN THỰC HIỆN ĐỒ ÁN

Trần Văn Hải

LỜI CAM ĐOAN

Tôi xin cam đoan bản đồ án này do tôi tự nghiên cứu dưới sự hướngdẫn của

Để hoàn thành đồ án này, tôi chỉ sự dụng những tài liệu đã được ghitrong mục tài liệu tham khảo, ngoài ra không sử dụng tài liệu khác mà khôngđược ghi.

Nếu sai sót, tôi xin chịu mọi hình thức kỷ luật của Học Viện

Hà Nội, ngày 08 tháng 06 năm 2022SINH VIÊN THỰC HIỆN ĐỒ ÁN

Trần Văn Hải

LỜI NÓI ĐẦU 10

CHƯƠNG I TỔNG QUAN API GATEWAY 11

1.1 Kiến trúc monolithic và microservices 11

1.1.1 Kiến trúc một khối Monolithic 11

1.1.2 Kiến trúc microservices 12

1.2 Vấn đề khi sử dụng mô hình microservices 14

1.2.1 Khảo sát thực tế sử dụng mô hình microservices 14

1.2.2 Vấn đề gặp phải khi dụng microservice 15

1.2.3 Giải pháp cho hệ thống microservices 16

1.3 Tổng quan API Gateway 18

1.3.1 Định nghĩa API 18

1.3.2 API Gateway hoạt động 20

1.3.3 Đánh giá API Gateway 21

1.4 Kết luận chương 1 22

Chương II Phân tích, thiết kế API Gateway 23

2.1 Các thành phần của dịch vụ API Gateway 23

2.2 Phân tích các tính năng của API Gateway 29

2.2.1 Xác định đối tượng sử dụng 29

2.2.2 Tổng quan tính năng 29

2.2.3 Định tuyến yêu cầu 30

2.2.5 Hạn ngạch - Rate limiting 35

2.2.6 Ghi nhật ký, truy vết 37

2.2.7 Xác thực API, người dùng 39

2.3 An toàn microservice sử dụng API Gateway 42

2.4 Phân tích ứng dụng quản trị API Gateway – API Management 43

2.4.1 Xác định Actor 43

2.4.2 Biểu đồ use case tổng quát 44

2.4.3 Chi tiết Use case quản lý API 45

2.4.4 Chi tiết Use case quản lý ứng dụng 47

2.4.5 Chi tiết Use case quản lý hệ thống AM 48

2.4.6 Chi tiết Use case quản lý danh sách đen 49

2.4.7 Chi tiết Use case quản lý hạn ngạch 50

2.4.8 Chi tiết Use case thống kê 51

2.5 Thiết kế cơ sở dữ liệu 52

2.5.1 Cơ sở dữ liệu cho các chức năng quản trị ứng dụng AM522.5.2 Cơ sở dữ liệu cho API Gateway 53

2.5.3 Cơ sở dữ liệu cho nhật ký 54

2.6 Kết luận chương 2 54

Chương III Triển khai hệ thống 55

3.1 Kết quả quá trình phát triển 55

3.1.1 API Gateway 55

3.1.2 API Management Application 58

3.2 Thử nghiệm API Gateway 66

3.2.1 Mô hình hệ thống thử nghiệm 66

3.2.2 Kết quả thử nghiệm 67

3.3 Các kịch bản đảm bảo an toàn 68

DANH MỤC CÁC TỪ VIẾT TẮT

API Application programming interface

cURL Client Uniform Resource Locator

DANH MỤC HÌNH

Hình 1 1 Minh họa mô hình một khối 11

Hình 1 2 Minh họa cho mô hình microservices 13

Hình 1 3 Minh họa cho ứng dụng chưa dùng API Gateway 15

Hình 1 4 Minh họa cho hệ thống dùng API Gateway 16

YHình 2 1 Các thành phần cơ bản của API Gateway 24

Hình 2 2 Mô hình tổng thể luồng dữ liệu 25

Hình 2 3 Mô hình chi tiết luồng dữ liệu 26

Hình 2 4 Tổng quan use case 29

Hình 2 5 Minh họa proxy 31

Hình 2 6 Minh họa một hệ thống microservices 31

Hình 2 7 Biểu đồ tuần tự tính năng định tuyến yêu cầu 33

Hình 2 8 Biểu đồ tuần tự lọc danh sách đen 34

Hình 2 9 Minh họa chức năng quản lý blacklist 35

Hình 2 10 Thông báo lỗi thì IP thuộc blacklist 35

Hình 2 11 Biểu đồ tuần tự tính năng Rate limiting 37

Hình 2 12 Biểu đồ tuần tự tính năng ghi log 38

Hình 2 13 Biểu đồ tuần tự xác thực API 39

Hình 2 14 Biểu đồ tuần tự phơi và lấy token sử dụng OAuth Server 41

Hình 2 15 Xác minh token 42

Hình 2 16 Minh họa phân lớp mạng cho hệ thống 43

Hình 2 17 Use case tổng quan AM 44

Hình 2 18 Usecase chi tiết quản lý API 45

Hình 2 19 Usercase chi tiết quản lý ứng dụng 47

Hình 2 20 Usecase quản lý hệ thống AM 48

Hình 2 21 Usecase quản lý danh sách đen 49

Hình 2 22 Usecase quản lý hạn ngạch 50

Hình 2 23 Usecase thống kê 51

Hình 2 24 Database cho các chức năng quản lý AM 52

Hình 2 25 Database phục vụ API Gateway 53

Hình 2 26 Database lưu log API Gateway 54

Hình 3 1 Kết quả thông báo lỗi block 57

Hình 3 2 Kết quả quản lý hạn ngạch 57

Hình 3 3 Kết quả thông báo lỗi vượt quá hạn ngạch 58

Hình 3 4 Kết quả ghi log 58

Hình 3 5 Kết quả thông báo chưa xác thực API đăng ký 59

Hình 3 6 Kết quả thông báo chưa xác thực người dùng đăng ký 59

Hình 3 7 Kết quả của endpoint sau khi định tuyến thành công 60

Hình 3 8 Danh sách quản lý API 60

Hình 3 9 Giao diện Thiết kế API 61

Hình 3 10 Giao diện chi tiết API 62

Hình 3 11 Giao diện danh sách ứng dụng 62

Hình 3 12 Giao diện chi tiết ứng dụng 63

Hình 3 13 Giao diện quản trị người dùng, nhóm người dùng 63

Hình 3 14 Quản trị các chức năng trên AM 64

Hình 3 15 Giao diện quản lý danh sách đen 64

Hình 3 16 Giao diện quản lý hạn ngạch 65

Hình 3 17 Thống kê thời gian dùng dịch vụ gần nhất 65

Hình 3 18 Xem thống kê lỗi ngoại lệ 66

Hình 3 19 Xem log thông điệp đã trao đổi qua cổng dịch vụ 67

Hình 3 20 Hệ thống thử nghiệm 68

Hình 3 21 Các thưc mục lưu code thử nghiệm 68

Hình 3 22 APIs đăng ký để thử nghiệm 69

Hình 3 23 Kiểm tra hoạt động trên postman 69

Hình 3 24 Web thử nghiệm sau khi đã kết nối được API Gateway 70

Hình 3 25 Truy cập khi đã gửi chính xác token 70

Hình 3 26 Truy cập API khi gửi sai token 71

Hình 3 27 Truy cập khi không truyền token 71

Hình 3 28 Thông báo của hệ thống khi gửi yếu cầu vượt quá hạn ngạch 72

Hình 3 29 Chặn địa chỉ IP 73

LỜI NÓI ĐẦU

Trong thời đại phát triển mạnh mẽ của công nghệ thông tin, ngày càngcó nhiều hệ thống lớn sử dụng mô hình microservice

Trong đồ án này, em sẽ phát triển về một API Gateway Đấy là dịch vụ đểgiao tiếp giữa các máy khách, ứng dụng bên ngoài và tập hợp các dịch vụ bêntrong API Gateway sẽ hoạt động như một proxy ngược, chấp nhận, tổng hợp,thao tác và phân phối các lời gọi API từ máy khách đến các dịch vụ nội bộThông thường, các dịch vụ nội bộ hiện thị, giao tiếp với nhau diễn ra trongmột mạng con và không và không có sự truy cập trực tiếp từ bên ngoài Bởi vìhệ thống microservices có thể có kiến trúc khá phức tạp, điều này yêu cầu khảnăng tách biệt bên trong và bên ngoài để che chắn không muốn cho bên ngoàingười dùng khỏi sự phức tạp và bảo vệ an toàn không gian bên trong Tất cảthông tin liên lạc từ bên ngoài vào bên trong đều phải được kiểm soát và giámsát API Gateway sẽ cung cấp khả năng này

Đề tài này thực hiện được các nhiệm vụ như: nắm chắc lí thuyết về các kiếntrúc hệ thống, các phương pháp giao tiếp, cách thức hoạt động cơ bản, cáctính năng cần có của API Gateway,… Thực hiện phân tích bài toán sự dụnghệ thống microservice ưu nhược điểm khi sử dụng phương thức giao tiếp trựctiếp và giao tiếp qua API Gateway Xây dựng và phát triển dịch vụ APIGateway Thực hiện xây dựng và kết nối API Gateway với hệ thốngmicroservice.

Các mục cơ bản trong đồ án

Chương I: Tổng quan về API GatewayChương II: Phân tích, thiết kế API GatewayChương III: Triển khai hệ thống

CHƯƠNG I

TỔNG QUAN API GATEWAY1.1 Kiến trúc monolithic và microservices

1.1.1 Kiến trúc một khối Monolithic

Kiến trúc một khối là mẫu thiết kế được dùng nhiều nhất trong giới lậptrình web hiện nay bởi tính đơn giản của nó khi phát triển và khi deploy Mặcdù mỗi ứng dụng sẽ được triển khai theo những cách khác nhau, nhưng nhìnchung thì khi ứng dụng được lập trình theo kiến trúc một khối, kết quả thườngđạt được như sau:

 Có thể hỗ trợ nhiều loại client như browser hay các app native trên cảdesktop và mobile.

 Phơi API cho bên thứ ba.

 Tích hợp với các ứng dụng khác thông qua REST/SOAP web service hoặccác message queue.

 Có thể xử lý các request dạng HTTP, thực hiện logic nghiệp vụ, truy cậpcơ sở dữ liệu và có thể trao đổi dữ liệu với các hệ thống khác.

 Scale theo chiều dọc (vertical scalability) bằng cách tăng sức mạnh củaphần cứng nhưng sẽ dễ gặp rắc rối khi scale theo chiều ngang (horizontalscalability) khi thêm các chức năng, tùy biến mới thì phải xử lý một cục

Ví dụ một ứng dụng như sau: một hệ thống đặt phòng khách sạn trựctuyến nhận đơn đặt hàng trực tuyến từ khách hàng, xác minh phòng trống, xácminh tùy chọn thanh toán, đặt phòng và thông báo cho khách sạn Ứng dụng nàybao gồm một số layer và component bao gồm ứng dụng phía client, xây dựnggiao diện người dùng phong phú và một số thành phần phụ trợ khác chịu tráchnhiệm quản lý các đặt phòng, xác minh thanh toán, thông báo cho khách hàng /

khách sạn, v.v Ứng dụng sẽ được đóng gói và deploy bằng một file Web

Application Archive (WAR) duy nhất và được chạy trên một container như

Tomcat Hãy xem diagram dưới đây:

Hình 1 1 Minh họa mô hình một khối

1.1.2 Kiến trúc microservices

Kiến trúc microservices đang dần trở nên phổ biến trong những năm gầnđây nhờ khả năng mudule hóa và khả năng mở rộng Kiến trúc microservices cóthể cung cấp hầu hết các tính năng của một ứng dụng một khối Ngoài ra, nócung cấp nhiều tính năng và linh hoạt hơn, do đó nó là sự lựa chọn ưu việt choứng dụng phức tạp Không giống như kiến trúc một khối, khá khó để khái quáthóa kiến trúc microservice vì nó có thể thay đổi nhiều tùy thuộc vào trường hợpsử dụng và triển khai Nhưng nhìn chung thì chúng cũng có một số đặc điểm nhưsau:

 Các component trong kiến trúc microservice liên kết khá lỏng lẻo (loosecoupling) Các component có thể được phát triển, test, deploy và scale độc lậpmà không ảnh hưởng đến các component khác.

 Các component không cần phải được phát triển cùng một stack công nghệ.Điều này có nghĩa là một component có thể chọn stack công nghệ và ngônngữ lập trình của riêng nó.

 Chúng thường sử dụng các tính năng nâng cao như truy tìm dịch vụ(service discovery), cân bằng tải (load balance) đối với những service cần hiệunăng cao,…

 Các component chủ yếu là nhẹ và chúng làm theo chức năng riêng biệt Vídụ dịch vụ xác thực sẽ chỉ quan tâm xác thực người dùng vào hệ thống.

 Thường có một thiết lập giám sát (monitor) và xử lý sự cố.

Ví dụ một ứng dụng như sau: một hệ thống thương mại điện tử trực

tuyến khổng lồ, nơi khách hàng có thể xem các danh mục hàng hóa, đánh dấumục yêu thích, thêm các mặt hàng vào giỏ hàng, thực hiện và theo dõi đơn đặthàng, v.v Hệ thống có quản lý hàng tồn kho, quản lý khách hàng, nhiều phươngthức thanh toán, quản lý đơn hàng, v.v Ứng dụng này bao gồm một số modulevà component bao gồm API gateway, giao diện người dùng, xử lý xác thực ngườidùng, cân bằng tải, và một số ứng dụng khác chịu trách nhiệm quản lý kho, xácminh thanh toán và quản lý đơn hàng Nó cũng có giám sát hiệu suất và tự độngchuyển đổi dự phòng cho các service Ứng dụng được deploy bằng nhiều fileWAR trên các Docker container và được host trên một dịch vụ cloud Hãy xemdiagram dưới đây:

Hình 1 2 Minh họa cho mô hình microservices

1.2 Vấn đề khi sử dụng mô hình microservices

1.2.1 Khảo sát thực tế sử dụng mô hình microservices

Trong khi ứng dụng càng ngày càng cần thêm các tính năng mới, cầnphải mở rộng hệ thống để đáp ứng được các yêu cầu từ bộ phận kinh doanh vànghiệp vụ Các nhà phát triển phải giải quyết hàng loạt các vấn đề liên quanđến quản lý cơ sở dữ liệu, tìm cách phân tách các dịch vụ , kết nối các hệ

thống khác nhau Lúc này các nhà phát triển sẽ quan tâm đến mô hình tốt hơnđể mở rộng giá trị sử dụng của ứng dụng

Microservices Architecture là một mô hình kiến trúc để phát triển hệthống phần mềm Chúng được ứng dụng để thay đổi cho mô hình cấu trúcmột khối Nhờ khả năng mở rộng rất dễ dàng của kiến trúc này mà nó đượccoi là kiến trúc lý tưởng để xây dựng lên nền tảng phát triển diện rộng trêncác thiết bị di dộng, internet, web

1.2.2 Vấn đề gặp phải khi dụng microservice

Một hệ thống microservices trung bình sẽ có một vài cho tới hàngtrăm service khác nhau, nếu như client giao tiếp trực tiếp với các services( Direct client-to-microservice communication ) này thì sơ đồ giao tiếp giữaclient và hệ thống rất là rối và khó kiểm soát Dưới đây là hình ảnh mình họamột hệ thống như vậy:

BPM SERVICE

BUSSINESS SERVICE

MAIL FILTER SERVICE

FILES STORE SERVICECIAM SERVICE

INVENTORY SERVICE

Hình 1 3 Minh họa cho ứng dụng chưa dùng API Gateway

1.2.3 Giải pháp cho hệ thống microservices

Hệ thống sử dụng client kết nối trực tiếp với các API sẽ khó kiểm soátvà rối, cho nên mới xuất hiện một giải pháp đó chính là API Gateway (tạmdịch là cổng kết nối API) đóng vai trò là một cổng trung gian giữa client và hệthống microservices đằng sau.

API Gateway

API Gateway có thể coi là một cổng trung gian, nó là cổng vào duy

nhất tới hệ thống microservices, API gateway sẽ nhận các requests từ phía

client, chỉnh sửa, xác thực và điều hướng chúng đến các API cụ thể trên cácservices phía sau Khi này sơ đồ hệ thống của chúng ta sẽ trông như này.

API Gateway

BPM SERVICE

BUSSINESS SERVICE

MAIL FILTER SERVICE

FILES STORE SERVICECIAM SERVICE

INVENTORY SERVICE

Hình 1 4 Minh họa cho hệ thống dùng API Gateway

Ngoài nhiệm vụ chính là proxy request thì một hệ thống API Gatewaythường sẽ đảm nhận luôn vài vai trò khác như bảo mật API, monitoring,analytics số lượng requests cũng như tình trạng hệ thống phía sau.

1.3 Tổng quan API Gateway 1.3.1 Định nghĩa API

API ( Application Programming Interface ) là một giao diện của ứngdụng giúp một ứng dụng dễ dàng tiếp nhận các yêu cầu hoặc dữ liệu từ mộtứng dụng khác Bằng cách xác định các điểm vào uy tín, đơn giản và đượcphơi ra, API cho phép các nhà phát triển dễ dàng truy cập và tái sử dụng logicứng dụng được xây dựng bởi các nhà phát triển khác.

Ứng dụng API:

 Web API: là hệ thống API được sử dụng trong các hệ thống website Hầu hết các website đều ứng dụng đến Web API cho phép bạn kết nối, lấy dữ liệu hoặc cập nhật cơ sở dữ liệu Ví dụ: Bạn thiết kế chức nằng login thông Google, Facebook, Twitter, Github… Điều này có nghĩa là bạn đang gọi đến API của Hoặc như các ứng dụng di động đều lấy dữ liệu thông qua API.

 API trên hệ điều hành: Windows hay Linux có rất nhiều API, họ cung cấpcác tài liệu API là đặc tả các hàm, phương thức cũng như các giao thức kết nối Nó giúp lập trình viên có thể tạo ra các phần mềm ứng dụng có thể tương tác trực tiếp với hệ điều hành.

 API của thư viện phần mềm hay framework: API mô tả và quy định các hành động mong muốn mà các thư viện cung cấp Một API có thể có nhiều cách triển khai khác nhau và nó cũng giúp cho một chương trình viết bằng ngôn ngữ này có thể sử dụng thư viện được viết bằng ngôn ngữ khác Ví dụ bạn có thể dùng Php để yêu cầu một thư viện tạo file PDF được viết bằng C++.

Đối với Web API hiện nay đều tuân thủ theo tiêu chuẩn REST và HTTP, tạosự thân thiện dễ sử dụng với nhà phát triển Giúp người dùng dễ dàng truy

cập, dễ hiểu hơn Web API hiện đại dùng cho các đối tượng cụ thể, chẳnghạn như mobile developer với document, version khác nhau.

Đường dẫn tớinguồn trả lạinội dung cuốnsách

phương thứcGET để gọiAPI

sáchResponse data {

"title" : "book_title", "author" : "author_name", "published" : "publish_date"}

JSON Objectchứa thông tincủa cuốn sách

yêu cầu thànhcông

Sử dụng thông tin này, bạn có thể thực hiện yêu cầu cURL sau cho API nàyđể nhận thông tin về một cuốn sách:

curl -X GET https://www.mybooksapi.com/books/info?id=0385504217

1.3.2 API Gateway hoạt động

API Gateway nằm giữa người dùng bên ngoài và hệ thốngmicroservices bên trong Nó là một services đóng vai trò như một lối vào duynhất để truy cập vào các dịch vụ API Gateway sẽ thực hiện 2 công việc chính

 Điều hướng các request từ client đến service tương ứng Thực hiện điều hướng request đến một tập các service

API Gateway sẽ quản lý các endpoint của toàn bộ services, thay thế client đểnói chuyện với các services Đối với client, API Gateway và toàn bộ hệ thốngmicroservices phía sau trở thành một khối

Các tính năng cơ bản cần có của API Gateway:

 Routing : Quản lý các dịch vụ và phân phối request từ client đến dịch vụ tương ứng.

 Offloading : Cung cấp khả năng giảm tải thông qua cung cấp các cutting function sử dung chung bởi các microservices.

cross- Authentication and authorization (Xác thực và phân quyền): Xác thực rằng một dịch vụ dùng cụ thể có quyền truy cập API Mục đích của xác thực API là từ chối quyền truy cập vào dịch vụ tiêu dùng không kiểm tra xác thực

 Service discovery integration ( Tích hợp tìm kiếm dịch vụ): Để gửi yêu cầu API đến dịch vụ, khách hàng hoặc API Gateway phải biết vị trí của dịch vụ mà nó đang giải quyết Nó chính là đặc trưng của tính năng routing

 Response caching (Bộ nhớ đệm phản hồi): Lưu cache các luật và phản hồi mà API Gateway hay được nhận yêu cầu

 Rate limiting and throttling: Cấu hình ( điều chỉnh và hạn ngạch ) cho API của mình để giúp bảo vệ chúng khỏi bị choáng ngợp bởi quá nhiều yêu cầu

 Load balancing ( cân bằng tải)

 Logging, tracing ( nhật ký và truy tìm ): Ghi nhật ký để phục vụ tìm kiếm lỗi

 IP Blacklist: Danh sách IP cần phải chặn không được truy cập

 API Composition / Aggregration: Khả năng có thể tổng hợp yêu cầu từ nhiều service để cho ra kết quả mong muốn của client.

 Protocol translation : giải quyết bài toán về sự đa dạng của communication protocol (gRPC, REST, SOAP, … )

Có thể nhận thấy API gateway là một traffic bottle neck (nghẽn cổ chai)và single point of failure (một điểm thất bại gây lỗi cả hệ thống) nên nếu APIGateway bị quá tải hoặc không khả dụng thì sẽ là một thảm hoạ Chính vì vậytrong thiết kế thực tế, API Gateway thường hiếm khi được host bởi 1 instancemà thường là được host bởi nhiều instance với endpoint được attach vào loadbalancer của chính API Gateway từ đó cũng cấp khả năng high-availabiltycho API gateway.

1.3.3 Đánh giá API Gateway

 Lợi ích

 Đóng gói cấu trúc bên trong của ứng dụng, giảm sự phụ thuộc giữa client và ứng dụng

 Client chỉ cần nói chuyện với gateway thay vì các services

 Giảm thiểu trao đổi qua lại giữa client và ứng dụng từ đó đơn giản hoáclient code

 Các cross-cutting function được cung cấp để giảm tải cho services. Security : nếu không có API Gateway thì toàn bộ services sẽ cần được

exposed ra thế giới bên ngoài và tạo ra nguy cơ về an ninh Điểm hạn chế

 Khi xây dựng API Gateway vô tình chúng ta đã gắn chặt nó với internal microservices.

 API Gateway là single point of failure

 API Gateway có thể làm tăng response time thông qua việc tiến hành thêm các cuộc gọi network tuy ảnh hưởng đó không thực sự lớn so vớiroud trip của việc không thực hiện sử dung API Gateway

 Nếu không scale tốt thì API Gateway sẽ là một bottleneck

 API Gateway sẽ yêu cầu cần thêm chi phí phát triển và bảo trì trong tương lai khi mà nó chứa cả các custom logic và data aggregation. Developer sẽ cần update API Gateway để expose từng microservice’s

dịch vụ và phân phối request từ client đến dịch vụ tương ứng.

 Offloading : Cung cấp khả năng giảm tải thông qua cung cấp các cutting function sử dung chung bởi các microservices.

cross- Xác thực API, người dùng Điều chỉnh, giới hạn băng thông Ghi nhật ký, truy vết

 Danh sách đen IP/ dải IP

Phát triển ứng dụng API Management để quản lý API Gateway  Đăng ký API,

 Đăng ký ứng dụng,

 Quản lý các thông số của API Gateway

 Theo dõi hoạt động, logging các request từ bên ngoài

Ứng dụng API Management sẽ có vai trò quản lý API Gateway Mụcđích của ứng dụng này là đăng ký API, đăng ký ứng dụng, quản lý các thôngsố của API Gateway Không những thế ứng dụng này phải có thể theo dõihoạt động, logging các request từ bên ngoài

Hình 2 1 Các thành phần cơ bản của API Gateway

 API Management: Đây là phần để ta tạo các API, chia sẻ tài liệu, cung

cấp khóa và thu thập phản hổi các tính năng.

 API Gateway: Bảo vệ, quản lý và cân bằng các cuộc gọi API Đây là một

proxy API đơn giản chặn các yêu cầu API và áp dụng các chính sách nhưkiểm soát ngăn chặn và đảm bảo an toàn Điều chỉnh lượng truy cập vàoAPI, bảo đảm cho API trước các cuộc tấn công Xử lý tất cả các hoạt độngliên quan bảo mật và phát hành khóa Kiểm tra tính hợp lệ của các đăngký Nó cũng là công cụ thu thập số liệu thống kê sử dụng API

Dưới đây là các mô hình luồng dữ liệu sau khi vào API Gateway:

RequestBLACK LISTYESSYSTEMYESAPI

RESPONSE ERROR

RESPONSE NO

MÔ HÌNH TỔNG THỂ

Hình 2 2 Mô hình tổng thể luồng dữ liệu

MÔ HÌNH CHI TIẾT

NO Request CountNO

Rate Limit error

Bandwidth NO

Rate Limit

Exist URINO

Not Found

YESAPI publicNO

Token keyNO

TokenKey Not Found

YESToken is

TokenKey

Endpoint ErrorNO

Backend Error

Hình 2 3 Mô hình chi tiết luồng dữ liệuMô tả tổng quan các tính năng của API Gateway:

Kiểm tra Black List

Mục đích của kiểm tra Black list:

o Không cho phép một IP hoặc một dải IP được quyền truy cập vào hệthống

o Không cho phép một IP hoặc một dải IP truy cập vào 1 hoặc nhiều APIcủa hệ thống

o Không cho phép một IP hoặc một dải IP truy cập vào 1 hoặc nhiềuApplication của hệ thống.

Kiểm tra điều kiện mức System

Sau khi kiểm tra IP request lên không nằm trong danh sách Blacklist hệ thống tiếp tục kiểm tra điều kiện Mức System.

Mục đich của điều kiện mức System, điều kiện này được đặt ra chotoàn bộ hệ thống:

o Check số lượng request vào hệ thống.

o Check số lượng Bandwidth request vào hệ thống.

Kiểm tra điều kiện Request Bandwidth:

 Khi 1 request được gọi vào hệ thống, hệ thống sẽ tính toán dung lượngrequest (a)gửi lên cộng với tổng số dung lượng request đã thực hiệngọi lên thành công trước đó(b) Nếu số (a+b) <= QUOTA thì hệ thốngchuyển sang kiểm tra điều kiện tiếp theo Ngược lại hệ thống sẽ dừnglại không tính toán mà gửi lại cho Client thông báo: Số lượng dunglượng request vượt quá ngưỡng giới hạn.

 Sau mỗi lần request lên hệ thống thành công, hệ thống sẽ tính toándung lượng request gọi vào hệ thống và sẽ cộng dồn các dung lượnglại.

Kiểm tra điều kiện Request Count:

 Khi 1 request được gọi vào hệ thống, hệ thống sẽ tính toán request(a)gửi lên cộng với tổng số request đã thực hiện gọi lên thành côngtrước đó(b) Nếu số (a+b) <= QUOTA thì hệ thống chuyển sang kiểmtra điều kiện tiếp theo Ngược lại hệ thống sẽ dừng lại không tính toánmà gửi lại cho Client thông báo: Số lượng request vượt quá ngưỡnggiới hạn.

Sau mỗi lần request lên hệ thống thành công, hệ thống sẽ tính toánrequest gọi vào hệ thống và sẽ cộng dồn các request lại.

Kiểm tra điều kiện mức API:

Sau khi kiểm tra và pass qua mức System hệ thống kiểm tra mức

Mục đich của điều kiện mức API:

o Kiểm tra xem URL của Api request lên có tồn tại hay không.o Kiểm tra xem API trạng thái có đươc Published hay không.

Kiểm tra URL: hệ thống sẽ đọc URL để lấy thông tin: {context},

{version},{parttern} có trong bảng API version hay không? Nếu cóchuyển sang kiểm tra điều kiện tiếp theo, nếu không có dừng lại và trả kếtquả về cho Client với nội dung URL không tồn tại.

Kiểm tra xem API có ở trạng thái Published: hệ thống sẽ đọc

URL để lấy thông tin: {context},{version} có trong bảng API version đểlấy trạng thái CURRENT_STATE = 1 Nếu đúng hệ thống chuyển sangkiểm tra điều kiện tiếp theo Nếu không đúng hệ thống dừng lại và trả kếtquả về cho Client nội dung API hiện đang không được Public.

Kiểm tra điều kiện mức Application

Sau khi pass qua các điều kiện API hệ thống chuyển sang mức kiểmtra Application.

Mục đich của điều kiện mức Application:o Check xem Token gửi lên có đúng hay không.

o Check xem API này có đúng là được gán cho Application với Tokentruyền lên hay không.

o Check API được gán cho Application có Unlocked hay không.o Kiểm tra điều kiện Request Bandwidth Application

o Kiểm tra điều kiện Request Count Application

Định tuyến và kiểm tra với End-Point

Sau khi pass qua các điều kiện hệ thống chuyển sang mức kiểm traEnd-Point,

Mục đích: Kiểm tra thực hiện lấy dữ liệu từ End-Point.

Request sẽ được gửi sang End-Point, Nếu End-Point lỗi hệ thống trảdừng lại và trả về kết quả cho client là End-point hiện đang bị lỗi Nếuviệc gọi sang End-Point không bị lỗi hệ thống trả về cho client các kết quảnhận được từ End-point.

2.2 Phân tích các tính năng của API Gateway2.2.1 Xác định đối tượng sử dụng

1 External Services - Các ứngdụng, dịch vụ bên ngoài hệthống microservices

 Định tuyến yêu cầu Lọc danh sách đen Hạn ngạch tốc độ Xác thực

2.2.2 Tổng quan tính năng

Hình 2 4 Tổng quan use case

Như đã nói ở mục “Phạm vi đồ án” thì các chức năng chính mà APIGateway sẽ thực hiện được bao gồm

 Chức năng về định tuyến yêu cầu - Routing : Điều hướng các request từclient đến service Quản lý các dịch vụ và phân phối request từ client đến dịch vụ tương ứng.

 Các chức năng lọc, giảm tải các request không hợp lệ - Offloading : Cung cấp khả năng giảm tải thông qua cung cấp các cross-cutting function sử dung chung bởi các microservices.

 Xác thực API, người dùng Điều chỉnh, giới hạn băng thông Ghi nhật ký, truy vết

 Danh sách đen IP/ dải IP

2.2.3 Định tuyến yêu cầu

Một trong những chức năng chính của API gateway là định tuyến yêucầu API gateway thực hiện một số hoạt động vận hành API bằng cách địnhtuyến các yêu cầu đến dịch vụ tương ứng Khi nhận được yêu cầu, APIGateway sẽ tham khảo bản đồ định tuyến chỉ định dịch vụ nào để định tuyếnyêu cầu Ví dụ, bản đồ định tuyến có thể ánh xạ một phương thức HTTP vàđường dẫn đến URL HTTP của dịch vụ Phương thức này này giống hệt vớicác tính năng proxy ngược

Hình 2 5 Minh họa proxy

Trên hình là hình ảnh của một proxy thông thường Proxy là trung chuyển yêucầu truy cập internet của người dùng Internet gửi lại phản hồi và proxy phảiđịnh tuyến để gửi tới đúng máy của người dùng.

Hình 2 6 Minh họa một hệ thống microservices

Có thể thấy trên hình ảnh là yêu cầu của khách hàng tới một điểm duy nhất(API gateway) và yêu cầu định tuyến đến các dịch vụ bên trong.

Định tuyến (Routing) là cách thức để API Gateway chỉ ra đường dẫn URLsẽ trỏ tới action Nói một cách nôm na thì Routing chính là kẻ dẫn đường choWeb API sẽ gọi action nào tương đương với URL đã được cung cấp APIGateway sẽ lập trình đạt được kiểu định tuyến được gọi là attribute routing(định tuyến thuộc tính) Như tên gọi, attribute routing (định tuyến thuộc tính)sẽ là bộ định tuyến được xác định thông qua thuộc tính Route Ví dụ, bạn cóthể dễ dàng tạo ra URL bằng cách mô tả các đặc tính dựa trên việc thừa kếcác nguồn tài nguyên.

Với attribute routing (định tuyến thuộc tính), thì rất dễ dàng để đạt đượcđiều mong muốn là tạo ra URL có liên quan giữu nhiều tài nguyên Sau đây làmột vài ví dụ về mẫu URL khác mà định tuyến thuộc tính có thể tạo ra mộtcách dễ dàng

Ví dụ api 2 có các phiên bản khác nhau (trong này là version 1 và version 2:v1 v2): "/api/v1/products" nó sẽ được định tuyến tới controller version 1, cònđây là api cho vesion 2: "/api/v2/products".

API Gateway cũng lựa chọn các actions dựa trên HTTP Method củarequest (GET, POST, vv) Quy ước này bằng cách chọn method bằng bất kỳthuộc tính nào trong số các thuộc tính liệt kê sau đây.

 POST PUT DELETE

Hình 2 7 Biểu đồ tuần tự tính năng định tuyến yêu cầuMô tả tính năng:

1 Dịch vụ bên ngoài gửi yêu cầu tới API gateway

2 Lấy URL và http method Ví dụ URL là /petshop/1.0/user-info với phương thức POST

3 Trích xuất thông tin với regex expression “/([^/]+)/([^/]+)/?([^/]+)” ContextPath: petshop

 Version: 1.0

 Resource: user-info

4 Truy vấn cơ sở dữ liệu để lấy lên các thông tin về API, API version, API URL mapping

5 Thực hiện các chức năng filter khác

6 Gửi yêu cầu tới API bên trong với URL Mapping7 Lấy ra kết quả.

2.2.4 Danh sách đen cho IP/ dải IP

Bằng các yêu cầu trong danh sách IP đen, API Gateway có thể bảo vệcác máy chủ khỏi các cuộc tấn công thông thường hoặc sự lạm dụng củangười dùng

Hình 2 8 Biểu đồ tuần tự lọc danh sách đenMô tả tính năng:

1 Bên ngoài gửi yêu cầu tới API qua API Gateway2 API Gateway trích xuất thông tin IP đích

a API Gateway tìm kiếm IP đích trong bảng blacklist có thuộc IP hay dải địa chỉ IP không được cho phép hay không

3 Nếu có tồn tại trong bảng blacklist thì gửi ra thông báo chặn

4 Nếu không tồn tại trong bảng blacklist thì tiếp tục các tính năng khác và phản hồi kết quả sau cùng

Ví dụ: nếu người dùng độc hại lạm dụng hệ thống, tất cả các yêu cầu nhậnđược từ IP hoặc dải IP của người dùng cụ thể đó có thể bị chặn hoàn toàn

Hình 2 9 Minh họa chức năng quản lý blacklist

Hình trên ta có một IP được đưa vào danh sách đen là 192.168.16.101

Hình 2 10 Thông báo lỗi thì IP thuộc blacklist

2.2.5 Hạn ngạch - Rate limiting

Trong lĩnh vực quản lý API, hạn ngạch là một trong những khía cạnhcơ bản của việc quản lý lưu lượng truy cập vào các API của bạn Hạn ngạchcó thể dễ dàng trở thành một trong những cách dễ nhất và hiệu quả nhất đểkiểm soát lưu lượng truy cập vào các API của bạn.

Hạn ngạch có thể giúp giải quyết tình trạng lạm dụng API do các sự cốngẫu nhiên trong mà khách hàng gây ra, dẫn đến việc API bị chặn bởi các yêu

cầu Về mặt độc hại, một cuộc tấn công từ chối dịch vụ nhằm lấn át tàinguyên API cũng có thể dễ dàng thực hiện mà không có hạn ngạch.

Request Count limiting: Giới hạn tỷ lệ được tính theo yêu cầu mỗi

giây hoặc RPS Ví dụ: giả sử một nhà phát triển chỉ muốn cho phép kháchhàng gọi API tối đa 10 lần mỗi phút Trong trường hợp này, nhà phát triển sẽáp dụng giới hạn tỷ lệ cho API của họ được biểu thị là "10 yêu cầu mỗi 60giây" Điều này có nghĩa là máy khách sẽ có thể gọi thành công API lên đến10 lần trong bất kỳ khoảng thời gian 60 giây nào và sau đó người dùng sẽ bịlỗi cho biết giới hạn tỷ lệ của họ đã vượt quá nếu họ gọi đó là lần thứ 11 trongkhung thời gian đó.

Bandwidth Limiting: Mô tả giới hạn cho tốc độ dữ liệu gửi lên trong

một khoảng thời gian.

Ví dụ: Nếu băng thông 100100100 Mbps, điều đó có nghĩa là nó không thểchuyển hơn 100100100 megabits mỗi giây.

"Giới hạn được thi hành bằng cơ chế " leaky bucket ": API gateway sẽghi lại từng yêu cầu trong danh sách theo thời gian trong bộ nhớ tạm, đồngthời nó sẽ đếm số lượng yêu cầu nằm giữa thời gian hiện tại và thời gian tốiđa trong quá khứ Điều đó bao gồm giới hạn tỷ lệ (và xóa chúng khỏi danhsách) Nếu số lượng này vượt quá số lượng yêu cầu trong khoảng thời gian,yêu cầu bị chặn

Nếu bạn không muốn ném lại lỗi khi vượt quá hạn ngạch, bạn có thể sửdụng Throttling để thay vào đó xếp hàng yêu cầu Điều này có nghĩa là yêucầu sẽ được thử lại và thực hiện sau khi không vượt quá giới hạn tỷ lệ Nóitóm lại, hai cách mà yêu cầu có thể được xử lý khi chúng vượt quá giới hạnquy định là trả lại lỗi hoặc xếp hàng yêu cầu được thực thi sau “Trong đồ án

này sẽ đưa ra lỗi nếu vượt qua Rate limiting”

Mô tả tính năng:

1 Bên ngoài gửi request tới API Gateway

2 API Gateway sẽ lấy dữ liệu đang lưu trong cache

3 Kiểm tra thời gian đơn vị tính rate limit còn trong thời gian không ?4 Nếu không thì cập nhật thời gian tính mới

5 Nếu có thì cập nhật requestCount (bộ đếm request) và requestBandwidth – (bộ đếm băng thông)

6 Nếu vượt quá hạn ngạch hệ thống đã thiết kế thì thông báo lỗi

7 Nếu không vượt quá thì thực hiện các chức năng khác và phản hồi kết quả.

Hình 2 11 Biểu đồ tuần tự tính năng Rate limiting

2.2.6 Ghi nhật ký, truy vết

API Gateway phải có khả năng ghi lại các bản ghi, dữ liệu về sự kiệnxảy ra trong khi hoạt động Trong quá trình hoạt động luôn luôn có những sự

nguyên nhân sự cố giúp bạn khắc phục nó Tại vì trên môi trường productkhông thể tái hiện được lỗi xảy ra

Ví dụ: Khách hàng chuyển tiền không thành công bạn không thể yêu cầukhách hàng chuyển lại để bạn kiểm tra được Vậy nếu ghi log đúng bạn có thểthông qua đó tìm ra nguyên nhân lỗi để khắc phục.

Các dữ liệu cần ghi log: Dữ liệu đầu vào Dữ liệu đầu ra Thời gian yêu cầu Thời gian phản hồi

 Mã và chi tiết tiết lỗi nếu có

Hình 2 12 Biểu đồ tuần tự tính năng ghi logMô tả tính năng:

1 Bên ngoài gửi yêu cầu tới API Gateway

2 API Gateway thực hiện các tính năng khác đã đề cập bên trên3 API Gateway gửi yêu cầu tới API phía sau

4 API gửi phản hồi