Phát triển api gateway Đảm bảo an toàn hệ thống microservices
Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (2.13 MB, 86 trang )
<span class="text_page_counter">Trang 1</span><div class="page_container" data-page="1">
BAN CƠ YẾU CHÍNH PHỦ
</div><span class="text_page_counter">Trang 2</span><div class="page_container" data-page="2">BAN CƠ YẾU CHÍNH PHỦ
</div><span class="text_page_counter">Trang 3</span><div class="page_container" data-page="3"><b>LỜI CẢM ƠN</b>
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 tồ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 q trình thực hiện đồ án.
Và để hồ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
<b>Trần Văn Hải</b>
</div><span class="text_page_counter">Trang 4</span><div class="page_container" data-page="4"><b>LỜI CAM ĐOAN</b>
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
Để hồ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, ngồ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
</div><span class="text_page_counter">Trang 5</span><div class="page_container" data-page="5"><b>LỜI NÓI ĐẦU...10</b>
<b>CHƯƠNG I TỔNG QUAN API GATEWAY...11</b>
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
<b>Chương II Phân tích, thiết kế API Gateway...23</b>
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
</div><span class="text_page_counter">Trang 6</span><div class="page_container" data-page="6">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 tồ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
<b>Chương III Triển khai hệ thống...55</b>
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
</div><span class="text_page_counter">Trang 8</span><div class="page_container" data-page="8"><b>DANH MỤC CÁC TỪ VIẾT TẮT</b>
API Application programming interface
cURL Client Uniform Resource Locator
</div><span class="text_page_counter">Trang 9</span><div class="page_container" data-page="9"><b>DANH MỤC HÌNH </b>
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 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
</div><span class="text_page_counter">Trang 10</span><div class="page_container" data-page="10">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 q 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
</div><span class="text_page_counter">Trang 11</span><div class="page_container" data-page="11">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
</div><span class="text_page_counter">Trang 12</span><div class="page_container" data-page="12"><b>LỜI NÓI ĐẦU</b>
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 ngồ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 ngồingười dùng khỏi sự phức tạp và bảo vệ an tồn khơng gian bên trong. Tất cảthơng tin liên lạc từ bên ngồ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
</div><span class="text_page_counter">Trang 13</span><div class="page_container" data-page="13"><b>CHƯƠNG I</b>
<b>TỔNG QUAN API GATEWAY</b>
<b>1.1. Kiến trúc monolithic và microservices</b><b>1.1.1. Kiến trúc một khối Monolithic</b>
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:
<small></small> Có thể hỗ trợ nhiều loại client như browser hay các app native trên cảdesktop và mobile.
<small></small> Phơi API cho bên thứ ba.
<small></small> 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.
<small></small> 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.
<small></small> 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 tố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 tốn, thơng báo cho khách hàng /
<b>khách sạn, v.v. Ứng dụng sẽ được đóng gói và deploy bằng một file Web</b>
</div><span class="text_page_counter">Trang 14</span><div class="page_container" data-page="14"><b>Application Archive (WAR) duy nhất và được chạy trên một container như</b>
Tomcat. Hãy xem diagram dưới đây:
Hình 1. 1. Minh họa mơ hình một khối
<b>1.1.2. Kiến trúc microservices</b>
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. Ngồ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 qthó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:
</div><span class="text_page_counter">Trang 15</span><div class="page_container" data-page="15"><small></small> 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.
<small></small> 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ó.
<small></small> 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,…
<small></small> 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.
<small></small> Thường có một thiết lập giám sát (monitor) và xử lý sự cố.
<i>Ví dụ một ứng dụng như sau: một hệ thống thương mại điện tử trực</i>
<i>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 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 tố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:</i>
</div><span class="text_page_counter">Trang 16</span><div class="page_container" data-page="16">Hình 1. 2. Minh họa cho mơ hình microservices
<b>1.2. Vấn đề khi sử dụng mơ hình microservices </b>
<b>1.2.1. Khảo sát thực tế sử dụng mơ hình microservices</b>
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ệ
</div><span class="text_page_counter">Trang 17</span><div class="page_container" data-page="17">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...
<b>1.2.2. Vấn đề gặp phải khi dụng microservice</b>
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 sốt. Dưới đây là hình ảnh mình họamột hệ thống như vậy:
</div><span class="text_page_counter">Trang 18</span><div class="page_container" data-page="18"><small>BPM SERVICE</small>
<small>BUSSINESS SERVICE</small>
<small>MAIL FILTER SERVICE</small>
<small>FILES STORE SERVICECIAM SERVICE</small>
<small>INVENTORY SERVICE</small>
Hình 1. 3. Minh họa cho ứng dụng chưa dùng API Gateway
<b>1.2.3. Giải pháp cho hệ thống microservices</b>
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
<b>API Gateway có thể coi là một cổng trung gian, nó là cổng vào duy</b>
nhất tới hệ thống microservices, API gateway sẽ nhận các requests từ phía
</div><span class="text_page_counter">Trang 19</span><div class="page_container" data-page="19">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.
<small>API Gateway</small>
<small>BPM SERVICE</small>
<small>BUSSINESS SERVICE</small>
<small>MAIL FILTER SERVICE</small>
<small>FILES STORE SERVICECIAM SERVICE</small>
<small>INVENTORY SERVICE</small>
Hình 1. 4. Minh họa cho hệ thống dùng API Gateway
Ngồi nhiệm vụ chính là proxy request thì một hệ thống API Gatewaythường sẽ đảm nhận ln 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.
</div><span class="text_page_counter">Trang 20</span><div class="page_container" data-page="20"><b>1.3. Tổng quan API Gateway 1.3.1. Định nghĩa API</b>
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
</div><span class="text_page_counter">Trang 21</span><div class="page_container" data-page="21">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 API Gateway hoạt động</b>
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
</div><span class="text_page_counter">Trang 22</span><div class="page_container" data-page="22"> Đ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à tồ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ị chố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
</div><span class="text_page_counter">Trang 23</span><div class="page_container" data-page="23"> 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.
<b>1.3.3. Đánh giá API Gateway</b>
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 hố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ì tồ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
</div><span class="text_page_counter">Trang 24</span><div class="page_container" data-page="24"> 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
</div><span class="text_page_counter">Trang 25</span><div class="page_container" data-page="25">Ứ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
</div><span class="text_page_counter">Trang 26</span><div class="page_container" data-page="26">Hình 2. 1. Các thành phần cơ bản của API Gateway
<b>API Management: Đây là phần để ta tạo các API, chia sẻ tài liệu, cung</b>
cấp khóa và thu thập phản hổi các tính năng.
<b>API Gateway: Bảo vệ, quản lý và cân bằng các cuộc gọi API. Đây là một</b>
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 số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:
</div><span class="text_page_counter">Trang 27</span><div class="page_container" data-page="27"><small>RequestBLACK LISTYESSYSTEMYESAPI</small>
<small>RESPONSE ERROR</small>
<small>RESPONSE NO</small>
<small>MƠ HÌNH TỔNG THỂ</small>
Hình 2. 2. Mơ hình tổng thể luồng dữ liệu
</div><span class="text_page_counter">Trang 28</span><div class="page_container" data-page="28"><small>MƠ HÌNH CHI TIẾT</small>
<small>NO</small> <sup>Request </sup><sub>Count</sub><small>NO</small>
<small>Rate Limit error</small>
<small>Bandwidth NO</small>
<small>Rate Limit </small>
<small>Exist URINO</small>
<small>Not Found </small>
<small>YESAPI publicNO</small>
<small>Token keyNO</small>
<small>TokenKey Not Found </small>
<small>YESToken is </small>
<small>TokenKey </small>
<small>Endpoint ErrorNO</small>
<small>Backend Error</small>
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:
<b>Kiểm tra Black List</b>
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.
</div><span class="text_page_counter">Trang 29</span><div class="page_container" data-page="29">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.
<b>Kiểm tra điều kiện mức System</b>
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.
<b>Kiểm tra điều kiện Request Bandwidth:</b>
Khi 1 request được gọi vào hệ thống, hệ thống sẽ tính tố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 tố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.
<b>Kiểm tra điều kiện Request Count:</b>
Khi 1 request được gọi vào hệ thống, hệ thống sẽ tính tố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 tố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 tốnrequest gọi vào hệ thống và sẽ cộng dồn các request lại.
<b>Kiểm tra điều kiện mức API:</b>
Sau khi kiểm tra và pass qua mức System hệ thống kiểm tra mức
</div><span class="text_page_counter">Trang 30</span><div class="page_container" data-page="30">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.
<b>Kiểm tra URL: hệ thống sẽ đọc URL để lấy thơng tin: {context},</b>
{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.
<b>Kiểm tra xem API có ở trạng thái Published: hệ thống sẽ đọc</b>
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.
<b>Kiểm tra điều kiện mức Application</b>
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
<b>Định tuyến và kiểm tra với End-Point</b>
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.
</div><span class="text_page_counter">Trang 31</span><div class="page_container" data-page="31"><b>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</b>
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
<b>2.2.2. Tổng quan tính năng</b>
Hình 2. 4. Tổng quan use case
</div><span class="text_page_counter">Trang 32</span><div class="page_container" data-page="32">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
<b>2.2.3. Định tuyến yêu cầu</b>
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
</div><span class="text_page_counter">Trang 33</span><div class="page_container" data-page="33">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
</div><span class="text_page_counter">Trang 34</span><div class="page_container" data-page="34">Có thể thấy trên hình ảnh là 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
</div><span class="text_page_counter">Trang 35</span><div class="page_container" data-page="35">Hình 2. 7. Biểu đồ tuần tự tính năng định tuyến 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ả.
</div><span class="text_page_counter">Trang 36</span><div class="page_container" data-page="36"><b>2.2.4. Danh sách đen cho IP/ dải IP</b>
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 hồn tồn.
</div><span class="text_page_counter">Trang 37</span><div class="page_container" data-page="37">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
<b>2.2.5. Hạn ngạch - Rate limiting</b>
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
</div><span class="text_page_counter">Trang 38</span><div class="page_container" data-page="38">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.
<b>Request Count limiting: Giới hạn tỷ lệ được tính theo yêu cầu mỗi</b>
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 đó.
<b>Bandwidth Limiting: Mơ tả giới hạn cho tốc độ dữ liệu gửi lên trong</b>
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 q 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
<b>này sẽ đưa ra lỗi nếu vượt qua Rate limiting” </b>
Mơ tả tính năng:
</div><span class="text_page_counter">Trang 39</span><div class="page_container" data-page="39">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 q 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
<b>2.2.6. Ghi nhật ký, truy vết</b>
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 ln ln có những sự
</div><span class="text_page_counter">Trang 40</span><div class="page_container" data-page="40">ngun 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 ngun 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 ngồi gửi 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
</div>
