Đồ á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
TỔNG QUAN API GATEWAY
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ập trình web hiện nay bởi tính đơn giản của nó khi phát triển và khi deploy Mặc dù mỗi ứng dụng sẽ được triển khai theo những cách khác nhau, nhưng nhìn chung 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ặc các message queue.
Có thể xử lý các request dạng HTTP, thực hiện logic nghiệp vụ, truy cập cơ 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ủa phần cứng nhưng sẽ dễ gặp rắc rối khi scale theo chiều ngang (horizontal scalability) 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ực tuyến nhận đơn đặt hàng trực tuyến từ khách hàng, xác minh phòng trống, xác minh tùy chọn thanh toán, đặt phòng và thông báo cho khách sạn Ứng dụng này bao gồm một số layer và component bao gồm ứng dụng phía client, xây dựng giao diện người dùng phong phú và một số thành phần phụ trợ khác chịu trách nhiệ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
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át hóa kiến trúc microservice vì nó có thể thay đổi nhiều tùy thuộc vào trường hợp sử 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 (loose coupling) Các component có thể được phát triển, test, deploy và scale độc lập mà 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ôn ngữ 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ệu nă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ấu mụ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 đặt hà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ương thức thanh toán, quản lý đơn hàng, v.v Ứng dụng này bao gồm một số module và component bao gồm API gateway, giao diện người dùng, xử lý xác thực người dù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ác minh thanh toán và quản lý đơn hàng Nó cũng có giám sát hiệu suất và tự động chuyể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 xem diagram dưới đây:
Hình 1 2 Minh họa cho mô hình microservices
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ần phả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úc mộ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ó được coi 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ên cá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àng tră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ữa client 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ọa một hệ thống như vậy:
FILES STORE SERVICE CIAM 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át và rối, cho nên mới xuất hiện một giải pháp đó chính là API Gateway (tạm dị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 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ác services phía sau Khi này sơ đồ hệ thống của chúng ta sẽ trông như này.
FILES STORE SERVICE CIAM SERVICE
Hình 1 4 Minh họa cho hệ thống dùng API GatewayNgoài nhiệm vụ chính là proxy request thì một hệ thống API Gateway thườ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.
Tổng quan API Gateway
API ( Application Programming Interface ) là một giao diện của ứng dụ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à được phơ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ấp cá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ạo sự 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ẳng hạn như mobile developer với document, version khác nhau.
Bảng dưới đây mô tả ví dụ về REST API trả ra thông tin của một cuốn sách
Thông tin Giá trị Mô tả
URL https://www.mybooksapi.com/books/ info Đường dẫn tới nguồn trả lại nội dung cuốn sách
HTTP Method GET Sự dụng phương thức GET để gọi API
Query param Id = ‘0385504217’ Id của cuốn sách Response data {
"title" : "book_title", "author" : "author_name", "published" : "publish_date"
JSON Object chứa thông tin của cuốn sách
Response code 200 ( Status code ) yêu cầu thành cô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?id85504217
API Gateway nằm giữa người dùng bên ngoài và hệ thống microservices bên trong Nó là một services đóng vai trò như một lối vào duy nhấ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ống microservices 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 cross- cutting function sử dung chung bởi các microservices.
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 API Gateway bị quá tải hoặc không khả dụng thì sẽ là một thảm hoạ Chính vì vậy trong thiết kế thực tế, API Gateway thường hiếm khi được host bởi 1 instance mà thường là được host bởi nhiều instance với endpoint được attach vào load balancer của chính API Gateway từ đó cũng cấp khả năng high-availabilty cho API gateway.
Đó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
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ới roud 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 endpoints.
Thêm vào đó việc thay đổi internal microservice có thể dẫn đến sự thay đổi ở tầng API Gateway.
Kết luận chương 1
Nội dung chương 1: Nắm vững được vấn đề, bài toán, tổng quan các kiến thức tăng tính về các mô hình hệ thống, API Gateway, …
Phát triển API Gateway thực hiện được các công việc - tính năng sau:
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.
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
Phát triển ứng dụng API Management để quản lý API Gateway
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ông số của API Gateway Không những thế ứng dụng này phải có thể theo dõi hoạt động, logging các request từ bên ngoài
Phân tích, thiết kế API Gateway
Các thành phần của dịch vụ API Gateway
Dịch vụ API Gateway sẽ bao gồm một nhóm bao gồm hai ứng dụng.Trong đó có ứng dụng cổng trung gian (API Gateway), ứng dụng quản lý API trên cổng trung gian (API Management) API Gateway sẽ kết nối trực tiếp với các dịch vụ hiện có (Existing Services) bên trong môi trường RuntimeBackend Dưới đây là hình ảnh minh họa cho các thành phần của dịch vụ APIGateway
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ào API, bảo đảm cho API trước các cuộc tấn công Xử lý tất cả các hoạt động liê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 đăng ký 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:
Request BLACK LIST YES SYSTEM YES API
Hình 2 2 Mô hình tổng thể luồng dữ liệu
BLACK LIST SYSTEM API APPLICATION END-POINT
Rate Limit NO error YES
Hình 2 3 Mô hình chi tiết luồng dữ liệu
Mô tả tổng quan các tính năng của API Gateway:
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 API củ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ều Application 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 Black list 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 cho toà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ượng request (a)gửi lên cộng với tổng số dung lượng request đã thực hiện gọi lên thành công trước đó(b) Nếu số (a+b)