Luận án Tiến sĩ Kỹ thuật phần mềm: Phát triển phần mềm theo hướng chia nhỏ phần dịch vụ (microservices) và phần giao diện (micro-frontends)

Chia sẻ: _ _ | Ngày: | Loại File: PDF | Số trang:91

Thêm vào BST

Báo xấu

16
lượt xem 6
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Luận án nhắm tới mục đích nghiên cứu phương pháp xây dựng ứng dụng theo hướng kiến trúc microservices và micro-frontends, và tìm hiểu các kỹ thuật để phát triển ứng dụng theo hướng kiến trúc này sử dụng các công nghệ trên nền tảng Java như Spring Boot, Spring Cloud cũng như các công nghệ làm web như Angular, ReactJS hay VueJS.

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Luận án Tiến sĩ Kỹ thuật phần mềm: Phát triển phần mềm theo hướng chia nhỏ phần dịch vụ (microservices) và phần giao diện (micro-frontends)

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ BÙI THANH HOA PHÁT TRIỂN PHẦN MỀM THEO HƯỚNG CHIA NHỎ PHẦN DỊCH VỤ (MICROSERVICES) VÀ PHẦN GIAO DIỆN (MICRO-FRONTENDS) HÀ NỘI - 2021
ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ BÙI THANH HOA PHÁT TRIỂN PHẦN MỀM THEO HƯỚNG CHIA NHỎ PHẦN DỊCH VỤ (MICROSERVICES) VÀ PHẦN GIAO DIỆN (MICRO-FRONTENDS) NGÀNH: KỸ THUẬT PHẦN MỀM CHUYÊN NGÀNH: KỸ THUẬT PHẦN MỀM MÃ SỐ: 8480103.01 LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN NGƯỜI HƯỚNG DẪN KHOA HỌC: PGS.TS. TRƯƠNG ANH HOÀNG HÀ NỘI - 2021
LỜI CAM ĐOAN Tôi xin cam đoan bản luận văn thạc sĩ công nghệ thông tin “Phát triển phần mềm theo hướng chia nhỏ phần dịch vụ (microservices) và phần giao diện (micro-frontends)” là sản phẩm nghiên cứu của cá nhân tôi, được thực hiện dưới sự hướng dẫn của PGS.TS. Trương Anh Hoàng. Các nội dung được trình bày trong luận văn là công trình nghiên cứu của bản thân tôi, hoàn toàn không sao chép từ sản phẩm của người khác. Các nội dung kiến thức được tổng hợp từ nhiều nguồn tài liệu tham khảo và được trích dẫn rõ ràng. Tôi cam kết chịu trách nhiệm cho lời cam đoan của mình. Hà Nội, tháng 10 năm 2021 Tác giả Bùi Thanh Hoa i
LỜI CẢM ƠN Trước hết, tôi xin bày tỏ lòng biết ơn chân thành, sâu sắc của mình đến PGS.TS. Trương Anh Hoàng, người thầy đã hết sức tận tâm hướng dẫn và giúp đỡ tôi rất nhiều trong suốt quá trình hoàn thành luận văn. Tôi xin gửi lời cảm ơn tới các thầy cô giáo của khoa công nghệ thông tin, trường Đại Học Công Nghệ, Đại Học Quốc Gia Hà Nội, các thầy cô đã rất tận tình chỉ bảo, giúp đỡ và tạo mọi điều kiện để tôi có thể hoàn thành được quá trình học tập, nghiên cứu trong suốt thời gian qua tại trường. Cuối cùng, tôi xin được cảm ơn gia đình tôi và bạn bè cùng khóa, những người đã luôn khích lệ, động viên và giúp đỡ tôi trong thời gian qua. Hà Nội, tháng 10 năm 2021 Tác giả Bùi Thanh Hoa ii
MỤC LỤC LỜI CAM ĐOAN ...................................................................................................... i LỜI CẢM ƠN ........................................................................................................... ii BẢNG CÁC THUẬT NGỮ VÀ CHỮ VIẾT TẮT ................................................. vi DANH MỤC HÌNH VẼ, ĐỒ THỊ .......................................................................... vii DANH MỤC BẢNG BIỂU ...................................................................................... ix MỞ ĐẦU ................................................................................................................... 1 Lý do chọn đề tài ................................................................................................... 1 Mục tiêu nghiên cứu .............................................................................................. 1 Đối tượng và phạm vi nghiên cứu ......................................................................... 2 Phương pháp nghiên cứu ...................................................................................... 2 Kết cấu luận văn .................................................................................................... 2 CHƯƠNG 1. PHÁT TRIỂN PHẦN MỀM THEO HƯỚNG MICROSERVICES 4 1.1. Một số hướng kiến trúc phần mềm truyền thống ......................................... 4 1.1.1. Kiến trúc nguyên khối................................................................................. 4 1.1.2. Kiến trúc hướng dịch vụ ............................................................................. 6 1.1.3. ESB và việc tích hợp ứng dụng SOA ........................................................... 8 1.2. Sơ lược về kiến trúc microservices................................................................. 9 1.2.1. Kiến trúc microservices là gì? .................................................................... 9 1.2.2. Các mẫu thiết kế microservices ................................................................ 12 1.3. Nguyên tắc thiết kế microservices ................................................................ 19 1.3.1. Đảm bảo tính đơn nhiệm .......................................................................... 19 1.3.2. Áp dụng phương pháp thiết kế hướng miền............................................... 20 1.3.3. Sử dụng các chuẩn về API ........................................................................ 22 Tóm lược chương 1 .............................................................................................. 22 CHƯƠNG 2. PHÁT TRIỂN ỨNG DỤNG WEB THEO HƯỚNG MICRO- FRONTENDS ......................................................................................................... 24 2.1. Sơ lược về một số mô hình phát triển ứng dụng web phổ biến .................. 24 2.1.1. Mô hình web tĩnh...................................................................................... 24 iii
2.1.2. Mô hình web động .................................................................................... 24 2.1.3. Mô hình SPA ............................................................................................ 25 2.2. Kiến trúc micro-frontends............................................................................ 27 2.2.1. Tổng quan về micro-frontends............................................................... 27 2.2.2. Lợi ích của micro-frontends .................................................................. 30 2.3. Cơ chế tích hợp trong micro-frontends ....................................................... 30 2.3.1. Tích hợp tại thời điểm xây dựng ............................................................... 30 2.3.2. Tích hợp tại thời điểm thực thi.................................................................. 31 2.3.3. Điều hướng giữa các micro-frontends ...................................................... 36 2.4. Giao tiếp giữa các micro-frontends.............................................................. 38 Tóm lược chương 2 .............................................................................................. 40 CHƯƠNG 3. XÂY DỰNG ỨNG DỤNG THỬ NGHIỆM THEO HƯỚNG MICROSERVICES VÀ MICRO-FRONTENDS.................................................. 41 3.1. Giới thiệu hệ thống CEMS ........................................................................... 41 3.2. Các chức năng chính của CEMS.................................................................. 41 3.2.1. Sơ đồ phân cấp chức năng........................................................................ 41 3.2.2. Sơ đồ use case tổng quát .......................................................................... 42 3.3. Giải pháp xây dựng hệ thống ....................................................................... 43 3.3.1. Giải pháp triển khai ................................................................................. 43 3.3.2. Lựa chọn công nghệ, công cụ ................................................................... 43 3.4. Giới thiệu tổng quan các công nghệ trong dự án ........................................ 43 3.4.1. Tổng quan về Spring Boot ........................................................................ 44 3.4.2. Tổng quan về Single-SPA ......................................................................... 45 3.5. Kiến trúc tổng quan hệ thống ...................................................................... 46 3.5.1. Mô hình hóa các microservices ................................................................ 46 3.5.2. Kiến trúc tổng thể của CEMS ................................................................... 47 3.5.3. Xây dựng mô hình dữ liệu......................................................................... 48 3.6. Thiết kế và cài đặt tầng dịch vụ ................................................................... 50 3.6.1. Kiến trúc cụ thể của một microservice ...................................................... 50 iv
3.6.2. Xây dựng cổng API .................................................................................. 51 3.6.3. Xây dựng mô hình đăng ký và khám phá dịch vụ ...................................... 53 3.6.4. Quản lý cấu hình tập trung ....................................................................... 56 3.6.5. Xây dựng chuẩn giao tiếp API .................................................................. 57 3.6.6. Quản lý logging........................................................................................ 59 3.7. Thiết kế và cài đặt tầng giao diện ................................................................ 62 3.7.1. Mô hình tổng quát tầng giao diện ............................................................. 62 3.7.2. Kiến trúc của một micro-frontend............................................................. 63 3.7.3. Quản lý vòng đời các đối tượng trong một micro-frontend ....................... 64 3.7.4. Một số màn hình giao diện mẫu................................................................ 66 3.8. Kiểm thử ứng dụng....................................................................................... 68 3.8.1. Thực hiện kiểm thử đơn vị ........................................................................ 69 3.8.2. Thực hiện kiểm thử tích hợp ..................................................................... 71 3.8.3. Thực hiện kiểm thử giao diện ................................................................... 72 3.9. Triển khai ứng dụng ..................................................................................... 73 Tóm lược chương 3 .............................................................................................. 74 KẾT LUẬN ............................................................................................................. 75 1. Kết quả đạt được......................................................................................... 75 2. Đánh giá ưu nhược điểm và bài học kinh nghiệm ..................................... 75 3. Các tồn tại và hướng phát triển.................................................................. 77 TÀI LIỆU THAM KHẢO ...................................................................................... 78 v
BẢNG CÁC THUẬT NGỮ VÀ CHỮ VIẾT TẮT STT Từ viết tắt Từ viết đầy đủ Mô tả 1 API Application Programming Interface Giao diện lập trình ứng dụng 2 CI/CD Continuous Integration (CI) and Quá trình tích hợp và chuyển Continuous Delivery (CD) giao liên tục 3 CSS Cascading Style Sheet Một kiểu ngôn ngữ định dạng, trang trí cho tài liệu HTML 4 Client Client Phía máy khách 5 DDD Domain Driven Design Kỹ thuật thiết kế theo hướng miền 6 DI Dependency Injection Cơ chế tiêm sự phụ thuộc giữa các đối tượng 7 DOM Document Object Model Một chuẩn được định nghĩa bởi tổ chức W3C dùng để quản lý các đối tượng trong tài liệu HTML 8 ELK Elasticsearch, Logstash and Kibana Bộ ba công cụ phục vụ cơ chế ghi log 9 ESB Enterprise Service Bus Một thành phần trung gian để tích hợp các chương trình, dịch vụ khác nhau 10 ERP Enterprise Resource Planning Hệ thống hoạch định tài nguyên cho doanh nghiệp 11 Framework Framework Bộ khung phát triển ứng dụng 12 HTML Hypertext Markup Language Ngôn ngữ đánh dấu siêu văn bản 13 HTTP Hypertext Transfer Protocol Giao thức truyền tải siêu văn bản 14 JSON JavaScript Object Notation Một kiểu dữ liệu mở rộng của JavaScript 15 MVC Model View Controller Một mẫu thiết kế ứng dụng 16 ORM Object Relational Mapping Một kỹ thuật ánh xạ các đối tượng lập trình với từng bảng trong cơ sở dữ liệu quan hệ 17 SOA Service Oriented Architecture Kiến trúc hướng dịch vụ 18 SOAP Simple Object Access Protocol Một giao thức để truy cập dịch vụ web 19 Server Server Phía máy chủ 20 SPA Single Page Application Kiểu ứng dụng một trang 21 REST Representational State Transfer Một tiêu chuẩn thiết kế các API sử dụng cho các dịch vụ web 22 URL Uniform Resource Locator Địa chỉ định vị tài nguyên trên Internet 23 XML Extensible Markup Language Ngôn ngữ đánh dấu mở rộng vi
DANH MỤC HÌNH VẼ, ĐỒ THỊ Hình 1.1. Kiến trúc nguyên khối cho ứng dụng web ................................................... 5 Hình 1.2. Mô hình hoạt động của một hệ thống SOA .................................................. 7 Hình 1.3. Mô hình trục tích hợp ESB .......................................................................... 9 Hình 1.4. Hệ thống web bán hàng theo mô hình microservices ................................. 10 Hình 1.5. Mô hình cổng API trong hệ thống microservices ....................................... 13 Hình 1.6. Mô hình client-side discovery ................................................................... 15 Hình 1.7. Mô hình server-side discovery .................................................................. 16 Hình 1.8. Mô hình dùng riêng cơ sở dữ liệu .............................................................. 17 Hình 1.9. Mô hình dùng chung cơ sở dữ liệu ............................................................ 19 Hình 1.10. Miền nghiệp vụ hệ thống quản lý bán hàng ............................................. 21 Hình 1.11. Tổ chức của một microservice ................................................................. 21 Hình 2.1. Mô hình web tĩnh [15]............................................................................... 24 Hình 2.2. Mô hình web động .................................................................................... 25 Hình 2.3. Cơ chế hoạt động của mô hình CSR .......................................................... 26 Hình 2.4. Ba mô hình triển khai web truyền thống .................................................... 28 Hình 2.5. Trang thông tin sản phẩm của một web bán hàng ...................................... 29 Hình 2.6. Ba module riêng biệt của trang danh sách sản phẩm .................................. 29 Hình 2.7. Cấu trúc một trang web checkout-order ..................................................... 30 Hình 2.8. Tệp tin cấu hình quản lý gói thư viện trong ứng dụng................................ 31 Hình 2.9. Sử dụng iframe để tích hợp micro-frontends ............................................. 32 Hình 2.10. Tích hợp micro-frontends bằng JavaScript .............................................. 33 Hình 2.11. Tệp tin index.html ................................................................................... 35 Hình 2.12. Quản lý cấu hình trong tệp server.config ................................................. 35 Hình 2.13. Điều hướng các micro-frontends sử dụng frontend proxy ........................ 36 Hình 2.14. Điều hướng micro-frontends sử dụng app shell ....................................... 37 Hình 2.15. Ví dụ một RouterModule của Angular..................................................... 38 Hình 2.16. Giao tiếp giữa các micro-frontends sử dụng EventEmitter ....................... 39 Hình 2.17. Tạo một custom event trong Angular ...................................................... 40 Hình 3.1. Chức năng tổng quát của hệ thống CEMS ................................................. 42 Hình 3.2. Sơ đồ use case tổng quát của hệ thống CEMS ........................................... 42 Hình 3.3. Kiến trúc tổng thể của một ứng dụng single-spa ........................................ 46 Hình 3.4. Phân vùng các hành vi trong hệ thống CEMS............................................ 47 Hình 3.5. Kiến trúc tổng thể hệ thống CEMS ............................................................ 48 Hình 3.6. Mô hình cơ sở dữ liệu của CEMS.............................................................. 49 Hình 3.7. Mối quan hệ giữa các lớp thực thể trong module user-service ................... 49 Hình 3.8. Kiến trúc tổng thể của một microservice ................................................... 51 Hình 3.9. Vai trò của cổng API trong CEMS ............................................................ 52 Hình 3.10. Cấu hình Zuul API Gateway ................................................................... 53 Hình 3.11. Cơ chế hoạt động của Eureka Service Registry........................................ 54 vii
Hình 3.12. Quy trình đăng ký và khám phá dịch vụ .................................................. 54 Hình 3.13. Cấu hình đăng ký dịch vụ sử dụng Eureka Server.................................... 55 Hình 3.14. Các dịch vụ được đăng ký trong Eureka Server ....................................... 55 Hình 3.15. Quản lý cấu hình tập trung với Spring Cloud Config ............................... 57 Hình 3.16. Lấy thông tin khách hàng theo mã khách hàng ........................................ 58 Hình 3.17. Lấy thông tin khách hàng dùng Http Get ................................................. 58 Hình 3.18. Ví dụ đặc tả chi tiết cho API: GET /customers/{customerCode} ............. 59 Hình 3.19. Cấu hình ghi log trong tệp application.properties .................................... 60 Hình 3.20. Cấu hình minh họa cho logstash và elasticsearch ..................................... 61 Hình 3.21. Mô hình hoạt động của ELK ................................................................... 61 Hình 3.22. Ví dụ thông tin log của module customer-service .................................... 62 Hình 3.23. Các micro-frontends trong hệ thống ........................................................ 62 Hình 3.24. Kiến trúc tổng thể của một micro-frontend .............................................. 63 Hình 3.25. Ví dụ tạo một thành phần web trong Angular .......................................... 64 Hình 3.26. Vòng đời hoạt động của ứng dụng single-spa .......................................... 65 Hình 3.27. Trang chủ của hệ thống CEMS................................................................ 66 Hình 3.28. Trang danh mục người dùng.................................................................... 66 Hình 3.29. Trang danh mục khách hàng.................................................................... 67 Hình 3.30. Trang danh mục trạm quan trắc ............................................................... 67 Hình 3.31. Trang thông tin chi tiết trạm quan trắc ..................................................... 68 Hình 3.32. Trang danh mục thiết bị........................................................................... 68 Hình 3.33. Các mức kiểm thử được áp dụng trong hệ thống CEMS .......................... 68 Hình 3.34. Các thành phần cơ bản của một microservice .......................................... 69 Hình 3.35. Minh họa một sơ đồ lớp thuộc module customer-service ......................... 70 Hình 3.36. Ví dụ thực hiện kiểm thử đơn vị với Mockito .......................................... 70 Hình 3.37. Minh họa kiểm thử tích hợp việc tạo mới một user .................................. 72 Hình 3.38. Ví dụ kiểm thử tích hợp trong lớp UserControllerIntegrationTest ............ 72 Hình 3.39. Đóng gói các microservices và tạo container ........................................... 73 Hình 3.40. Mô tả của một Dockerfile và docker-compose.yml.................................. 74 viii
DANH MỤC BẢNG BIỂU Bảng 1.1. So sánh kiến trúc nguyên khối, SOA và microservices.............................. 23 Bảng 3.1. So sánh Spring Boot, Micronaut và Play framework ................................. 44 Bảng 3.2. Một số mã HTTP thông dụng.................................................................... 58 ix
MỞ ĐẦU Lý do chọn đề tài Trong những năm gần đây, việc áp dụng kiến trúc microservices để xây dựng các ứng dụng doanh nghiệp ngày càng phổ biến. Sự ra đời của microservices đem lại nhiều lợi ích như làm giảm độ phức tạp trong việc xây dựng các ứng dụng lớn cho doanh nghiệp, tăng tính mở rộng cũng như nâng cao khả năng bảo trì hệ thống. Tại Việt Nam, nhiều công ty như Tiki, Viettel đều đã áp dụng mô hình microservices để xây dựng các giải pháp phần mềm phục vụ bài toán doanh nghiệp. Bên cạnh thuật ngữ microservices đã khá quen thuộc, hướng kiến trúc “micro- frontends” xuất hiện từ khoảng năm 2016. Micro-frontends ra đời mang lại một cách tiếp cận mới trong việc xây dựng tầng ứng dụng web theo hướng tách nhỏ phần giao diện thành nhiều module con, độc lập và tích hợp chúng lại với nhau. Tư tưởng của micro-frontends không hoàn toàn mới, mà nó được kế thừa từ hướng tiếp cận của microservices. Công nghệ làm web hiện nay có thể sử dụng nhiều thư viện và framework khác nhau như Angular, ReactJS hay VueJS. Việc xây dựng web bằng các công nghệ này một cách đơn lẻ có thể không gặp nhiều trở ngại, tuy nhiên khi xây dựng ứng dụng theo hướng micro-frontends thì việc tích hợp các module web khác nhau, viết bằng các công nghệ khác nhau gặp khá nhiều thử thách. Để phục vụ cho việc tích hợp các micro-frontends, một số framework ra đời như Single-SPA, Luigi hay FrintJS, trong đó Single-SPA là một framework mới có nhiều ưu điểm và được dùng khá rộng rãi. Tại công ty phần mềm FPT, việc xây dựng cũng như chuyển đổi các hệ thống phần mềm theo hướng microservices, micro-frontends và triển khai các ứng dụng này trên các nền tảng như Docker trở thành yêu cầu của nhiều dự án nhằm phục vụ các khách hàng đến từ các thị trường khác nhau như Việt Nam, Mỹ, Singapore…Các mảng công nghệ chủ yếu được sử dụng tại đây thuộc về các dòng Java (Oracle), .Net (Microsoft) và các công nghệ phát triển web (Angular, React, VueJS). Việc nắm vững các nguyên lý để triển khai ứng dụng theo hướng microservices, micro-frontends cũng như có kỹ năng, kiến thức để phát triển phần mềm theo hướng này là yêu cầu cấp thiết cho các lập trình viên tại FPT. Xuất phát từ nhu cầu thực tế ở trên và để phục vụ mục đích công việc tại công ty phần mềm FPT, tác giả lựa chọn đề tài “Phát triển phần mềm theo hướng chia nhỏ phần dịch vụ (microservices) và phần giao diện (micro-frontends)”. Mục tiêu nghiên cứu Luận văn nhắm tới mục đích nghiên cứu phương pháp xây dựng ứng dụng theo hướng kiến trúc microservices và micro-frontends, và tìm hiểu các kỹ thuật để phát triển 1
ứng dụng theo hướng kiến trúc này sử dụng các công nghệ trên nền tảng Java như Spring Boot, Spring Cloud cũng như các công nghệ làm web như Angular, ReactJS hay VueJS. Đối tượng và phạm vi nghiên cứu - Đối tượng nghiên cứu: đối tượng nghiên cứu của đề tài là phương pháp phát triển phần mềm theo hướng kiến trúc microservices, micro-frontends cùng các công nghệ liên quan như Spring Boot, Spring Cloud và Single-SPA. - Phạm vi nghiên cứu: phạm vi nghiên cứu của đề tài nằm trong lĩnh vực phát triển phần mềm và ứng dụng các kỹ thuật, công nghệ phục vụ cho dự án tại công ty phần mềm FPT. Phương pháp nghiên cứu Để thực hiện đề tài, tác giả áp dụng các phương pháp nghiên cứu sau: - Phương pháp nghiên cứu lý thuyết - Phương pháp nghiên cứu thực nghiệm - Phân tích, tổng hợp kinh nghiệm từ các dự án phần mềm mà tác giả đã tham gia Kết cấu luận văn Luận văn được tổ chức thành các phần chính sau: Mở đầu: Trình bày tổng quan về đề tài Chương 1: Trình bày cách thức phát triển phần mềm theo kiến trúc microservices. Trong chương này, luận văn tập trung làm rõ các nội dung: - Sơ lược về một số hướng kiến trúc phần mềm truyền thống như kiến trúc nguyên khối, kiến trúc hướng dịch vụ, công nghệ ESB - Tổng quan về kiến trúc microservices: sự ra đời, đặc điểm của microservices - Các mẫu thiết kế quan trọng được sử dụng trong microservices - Một số nguyên tắc thiết kế microservices Chương 2: Trình bày hướng xây dựng ứng dụng web sử dụng micro-frontends. Trong chương này, luận văn tập trung làm rõ các nội dung: - Sơ lược về một số mô hình phát triển web như mô hình web tĩnh, mô hình web động, mô hình web theo hướng SPA - Sự ra đời của kiến trúc micro-frontends - Các cơ chế tích hợp micro-frontends được thảo luận như: tích hợp theo hướng “build-time”, tích hợp theo hướng “run-time”, cách thức điều hướng và giao tiếp giữa các micro-frontends Chương 3: Trình bày cách thức xây dựng một ứng dụng thử nghiệm sử dụng kiến trúc microservices, micro-frontends. Một số nội dung chính trong quá trình thực nghiệm được làm rõ bao gồm: 2
- Áp dụng phương pháp thiết kế hướng miền để phân hoạch, thiết kế chương trình - Thiết kế và cài đặt tầng dịch vụ theo hướng microservices, sử dụng các công nghệ trên nền tảng Java như Spring Boot, Spring Cloud - Thiết kế và cài đặt tầng giao diện theo hướng micro-frontends, sử dụng các công nghệ như Single-SPA, Angular, ReactJS - Một số kỹ thuật kiểm thử microservices cũng được thảo luận như kiểm thử đơn vị, kiểm thử tích hợp và kiểm thử mức giao diện - Cách thức triển khai ứng dụng sử dụng Docker Phần kết luận: Tổng kết, đánh giá kết quả thu được của quá trình nghiên cứu cũng như các ưu nhược điểm, các hạn chế và hướng phát triển tương lai. 3
CHƯƠNG 1. PHÁT TRIỂN PHẦN MỀM THEO HƯỚNG MICROSERVICES Hiện nay, nhiều hướng kiến trúc phần mềm đã ra đời nhằm phục vụ các mục đích khác nhau cho từng loại hình ứng dụng. Một số loại hình kiến trúc như kiến trúc nguyên khối (monolithic), kiến trúc hướng dịch vụ (SOA) và đặc biệt là kiến trúc vi dịch vụ (microservices) đã được áp dụng rộng rãi. Mục tiêu của chương 1 tập trung vào việc tìm hiểu các đặc điểm và phương pháp phát triển ứng dụng theo hướng microservices. Bên cạnh đó, các phạm trù kiến thức cơ bản liên quan đến kiến trúc nguyên khối, kiến trúc SOA cũng sẽ được đề cập và giải thích một cách cụ thể. 1.1. Một số hướng kiến trúc phần mềm truyền thống Trước khi tìm hiểu về kiến trúc microservices, luận văn tập trung tóm lược lại sự phát triển của một số kiến trúc phần mềm phổ biến được sử dụng trong các ứng dụng doanh nghiệp. 1.1.1. Kiến trúc nguyên khối Trong công nghệ phần mềm, thuật ngữ monolithic được sử dụng để mô tả cho một loại hình kiến trúc mà ở đó các thành phần của hệ thống được xây dựng và nằm trong một khối duy nhất không thể chia tách. Vì đặc điểm này, kiến trúc monolithic còn được gọi là kiến trúc nguyên khối hay kiến trúc một khối. Thông thường, một ứng dụng theo mô hình kiến trúc một khối sẽ được phân tách thành các tầng hoặc lớp sau: phần giao diện người dùng (client), phần dịch vụ phía máy chủ (service) và phần cơ sở dữ liệu (database). Cả ba thành phần này được xây dựng, đóng gói và triển khai trong một khối duy nhất. Ví dụ trong hình 1.1 mô tả một cách tổng quát mô hình kiến trúc nguyên khối cho một ứng dụng web truyền thống. Theo sơ đồ này, ứng dụng được chia tách thành ba tầng chính gồm tầng giao diện người dùng (Web UI), tầng nghiệp vụ (Business Logic) và tầng truy cập dữ liệu (Data Access Object). Tầng giao diện chịu trách nhiệm tiếp nhận các dữ liệu từ phía người dùng thông qua các biểu mẫu trên trang web, tầng nghiệp vụ thực hiện việc đóng gói các quy tắc nghiệp vụ của bài toán và tương tác với tầng truy cập dữ liệu để thực hiện các giao tác như truy vấn hoặc lưu trữ dữ liệu. Có thể thấy trong mô hình ứng dụng nguyên khối các thành phần liên kết và phụ thuộc khá chặt với nhau, luồng xử lý dữ liệu sẽ đi từ tầng trên cùng và được xử lý lần lượt qua các thành phần tiếp theo. Chính sự gắn kết chặt chẽ này sẽ mang lại một số hạn chế nhất định của hướng kiến trúc mà chúng ta sẽ trao đổi cụ thể trong mục “Nhược điểm của kiến trúc nguyên khối” bên dưới. 4
Hình 1.1. Kiến trúc nguyên khối cho ứng dụng web Kiến trúc nguyên khối được sử dụng phổ biến cho hầu hết các ứng dụng ở mức vừa và nhỏ. Đây được xem là một giải pháp truyền thống từ trước tới nay để xây dựng ứng dụng bởi lẽ kiến trúc này đem lại một số ưu điểm nhất định như mô tả bên dưới. Ưu điểm của kiến trúc nguyên khối Dễ dàng phát triển: về mặt cấu trúc, chương trình được chia tách thành các gói dịch vụ riêng biệt hay còn gọi là các module. Các module này sẽ được tổ chức thành một khối duy nhất trong cùng một cấu trúc mã nguồn. Về mặt kỹ thuật, kiến trúc nguyên khối cho phép sử dụng thống nhất các công nghệ ở các tầng. Vì thế, việc phát triển ứng dụng theo cách này được xem là đơn giản, dễ dàng và tốn ít thời gian. Dễ dàng triển khai và vận hành: các module của chương trình được đóng gói và cài đặt thành một khối duy nhất, vì vậy việc triển khai và vận hành ứng dụng sẽ đơn giản. Bên cạnh các ưu điểm trên, kiến trúc nguyên khối cũng bộc lộ khá nhiều hạn chế như sau: Nhược điểm của kiến trúc nguyên khối Khó đáp ứng khả năng thay đổi: trong kiến trúc nguyên khối, các thành phần gắn kết với nhau một cách chặt chẽ và được tổ chức thành một khối duy nhất, không thể tách rời. Chính điều này sẽ gây khó khăn cho việc thay đổi (thêm hoặc bớt) các tính năng về nghiệp vụ, cũng như sự nâng cấp các yêu cầu về mặt công nghệ. 5
Khả năng chịu lỗi thấp: vì các thành phần liên kết chặt chẽ với nhau, nên mỗi khi có sự thay đổi ở một module này sẽ kéo theo sự thay đổi ở một module khác. Chính điều này làm giảm đi khả năng chịu lỗi của hệ thống. Khó khăn trong việc bảo trì: theo thời gian, kích cỡ chương trình gia tăng để áp ứng các yêu cầu thay đổi về nghiệp vụ. Việc bảo trì, tìm và sửa lỗi trong một khối mã nguồn lớn sẽ là một thách thức không nhỏ cho các nhà phát triển. Giới hạn về mặt công nghệ: ứng dụng theo hướng nguyên khối gây khó khăn cho việc cập nhật, nâng cấp các công nghệ. 1.1.2. Kiến trúc hướng dịch vụ Kiến trúc hướng dịch vụ (SOA) đã và đang được ứng dụng rộng rãi trong các hệ thống phần mềm doanh nghiệp. Theo định nghĩa của The Open Group, “Kiến trúc SOA là một hướng kiến trúc hỗ trợ theo hướng dịch vụ” [1]. Khái niệm “dịch vụ” ở đây được hiểu là một tập hợp các thành phần (các chương trình con) hay các module được phát triển để giải quyết một bài toán nghiệp vụ. Các dịch vụ này được phát triển và triển khai trên các máy tính khác nhau, chúng hoạt động và triệu gọi lẫn nhau trên môi trường mạng. Ở góc độ kỹ thuật, SOA là một cách thức tiếp cận cho phép các nhà phát triển xây dựng các thành phần phần mềm theo hướng các dịch vụ. Các gói dịch vụ này có thể tái sử dụng, và được truy cập thông qua các giao diện lập trình ứng dụng (API). Để xây dựng hệ thống SOA nhằm đảm bảo cho các thành phần có thể hoạt động, truy cập và trao đổi dữ liệu với nhau một cách dễ dàng, chúng ta cần một định dạng chuẩn về mặt dữ liệu và một bộ giao thức thống nhất. Hai chuẩn phổ biến ban đầu được sử dụng rộng rãi nhằm xây dựng ứng dụng SOA là SOAP và XML. Hai chuẩn này được coi là thành phần cốt lõi để đảm bảo việc truyền/gửi và nhận dữ liệu giữa các đối tượng trong mô hình SOA. Mô hình cơ bản của một hệ thống SOA bao gồm ba thành phần [2]: Thành phần sử dụng dịch vụ (service consumer): thành phần này có thể là một chương trình ứng dụng hoặc là một dịch vụ khác có yêu cầu sử dụng dịch vụ. Nó sẽ thực hiện việc xác định các dịch vụ trong kho đăng ký dịch vụ và thực thi nhiệm vụ bằng cách gửi một yêu cầu tới phía cung cấp dịch vụ. Thành phần cung cấp dịch vụ (service provider): nhiệm vụ chính của nó là chấp nhận và thực thi các yêu cầu được gửi tới từ phía sử dụng dịch vụ. Các dịch vụ do phía cung cấp dịch vụ xuất bản sẽ được đăng ký tại kho lưu trữ dịch vụ để cho phía sử dụng dịch vụ có thể truy cập được. Thành phần đăng ký dịch vụ (service registry): đây là nơi lưu trữ các dịch vụ để phục vụ cho bên sử dụng dịch vụ. 6
Sơ đồ trong hình 1.2 mô tả sự tương tác hoạt động giữa ba thành phần trên trong hệ thống SOA. Hình 1.2. Mô hình hoạt động của một hệ thống SOA Trong mô hình hoạt động ở trên, việc triệu gọi và trao đổi dữ liệu giữa ba bên (cung cấp dịch vụ, sử dụng dịch vụ, đăng kí dịch vụ) được thực hiện thông qua một chuẩn về giao thức (SOAP) và một quy ước về chuẩn dữ liệu (XML). Quá trình này được thực hiện theo các bước sau: • Bước 1: bên cung cấp dịch vụ xuất bản các gói dịch vụ và đăng ký vào kho đăng ký dịch vụ. • Bước 2: bên sử dụng dịch vụ muốn dùng dịch vụ nào sẽ gửi một yêu cầu tìm kiếm dịch vụ. • Bước 3: phía cung cấp dịch vụ gửi trả lại dữ liệu cho phía sử dụng. Bên cạnh SOAP/XML, hiện nay các chuẩn về REST và JSON được sử dụng phổ biến hơn nhờ các tính ưu việt của nó như sự đơn giản trong cấu trúc cũng như việc bóc tách dữ liệu dễ dàng. Ưu điểm của kiến trúc SOA Sử dụng SOA trong các bài toán doanh nghiệp đem lại những lợi ích cốt lõi sau: Tăng tính tái sử dụng: Việc thiết kế hệ thống theo SOA được thực hiện theo hai nguyên tắc cơ bản là module hóa và đóng gói dữ liệu. Bài toán được tổ chức và đóng gói thành các gói dịch vụ riêng rẽ. Các thành phần này liên kết một cách lỏng lẻo với nhau, và chúng có thể dễ dàng được sử dụng lại cho nhiều chương trình khác. Dễ dàng trong việc bảo trì: Do tính module hóa cao của kiến trúc nên việc bảo trì hệ thống sẽ dễ dàng hơn so với kiến trúc nguyên khối. Độ tin cậy và khả năng mở rộng cao: Việc phát triển, kiểm thử các dịch vụ cũng như mở rộng hệ thống theo hướng SOA sẽ dễ dàng hơn rất nhiều so với việc triển khai các công đoạn này trong các ứng dụng theo hướng nguyên khối. Chính điều này mang lại sự tin cậy và ổn định cho các sản phẩm phần mềm sử dụng SOA. 7
Dễ dàng trao đổi, cộng tác giữa các hệ thống: Nhờ sự thống nhất về mặt giao thức và chuẩn dữ liệu, cho nên các hệ thống phần mềm khác nhau, chạy trên nhiều nền tảng công nghệ khác nhau (Java, .Net hay PHP) hoàn toàn có thể cộng tác trao đổi với nhau miễn là tuân thủ các chuẩn chung được quy định trong hướng kiến trúc này. Nhược điểm của kiến trúc SOA Bên cạnh các lợi thế nêu trên, kiến trúc SOA cũng tồn tại nhiều hạn chế: Phức tạp trong việc quản lý các dịch vụ: Hệ thống SOA bao gồm nhiều dịch vụ hoạt động trao đổi và tương tác với nhau bằng cách gửi và nhận các thông điệp. Khi số lượng các dịch vụ tăng lên đi kèm với một lượng lớn các thông điệp được trao đổi thì việc đảm bảo sự hoạt động thông suốt của hệ thống là một thử thách không nhỏ. Chi phí cao cho quá trình phát triển: Bản thân kiến trúc SOA đã bao gồm sự phức tạp trong việc tổ chức các thành phần, các tầng/lớp trong kiến trúc. Chính vì thế, việc phát triển và triển khai hệ thống SOA sẽ đòi hỏi một chi phí cao hơn nhiều cho nguồn lực cũng như công nghệ (phần mềm, phần cứng) so với việc phát triển các hệ thống thông thường. Có thể nói từ lúc xuất hiện tới nay, SOA được xem là một phương pháp thiết kế và phát triển phần mềm được sử dụng rộng rãi và phổ biến nhờ những tính ưu việt của nó so với nhiều phương pháp truyền thống. SOA thực sự phù hợp cho các hệ thống phần mềm doanh nghiệp đòi hỏi độ phức tạp cao về mặt nghiệp vụ cũng như cách tổ chức (ví dụ các hệ thống phần mềm trong ngân hàng, hệ thống ERP). 1.1.3. ESB và việc tích hợp ứng dụng SOA Các hệ thống phần mềm theo hướng SOA gồm nhiều dịch vụ được triển khai phân tán. Nhằm tích hợp các dịch vụ, cũng như dữ liệu lại với nhau để việc quản lý và vận hành hệ thống được tập trung và thống nhất, người ta sử dụng công nghệ trục tích hợp (ESB). ESB được xem là một thành phần trung gian có mục đích chính là cung cấp khả năng tích hợp các module phần mềm riêng rẽ thành một hệ thống và đảm nhiệm vai trò điều phối công việc giữa các thành phần tích hợp đó [3]. Sơ đồ trong hình 1.3 mô tả việc tích hợp các dịch vụ, ứng dụng khác nhau trên một trục ESB. Bên cạnh việc tích hợp các dịch vụ, ESB còn cung cấp rất nhiều tính năng khác như quản lý việc định tuyến (routing), chuyển đổi dữ liệu (data transformation), cung cấp các cơ chế về bảo mật (security)…Một số ESB phổ biến được sử dụng rộng rãi như Mule ESB1, Oracle ESB2, và Fuse ESB3. Kiến trúc cũng như các công nghệ nền tảng đi kèm ESB rất phức tạp. Do đó, việc lựa chọn sử dụng ESB trong việc tích hợp các ứng 1 https://www.mulesoft.com/platform/soa/mule-esb-open-source-esb 2 https://docs.oracle.com/cd/E11036_01/doc.1013/e10295/esb_intro.htm 3 https://docs.huihoo.com/fuse/esb/4.1/getting_started/ESBGetStartedOverview.html 8
dụng theo hướng SOA là một bài toán lớn và cần được xem xét kỹ lưỡng dựa theo tình hình thực tế của từng doanh nghiệp. Hình 1.3. Mô hình trục tích hợp ESB 1.2. Sơ lược về kiến trúc microservices Các hệ thống phần mềm doanh nghiệp hiện nay đều lớn về mặt tổ chức cũng như phức tạp về mặt nghiệp vụ, vì thế việc xây dựng ứng dụng theo kiểu nguyên khối là điều không thiết thực và gặp nhiều trở ngại. Cùng với đó, việc chia sẻ dữ liệu giữa các hệ thống khác nhau là yêu cầu bắt buộc. Để giải quyết khó khăn này, các ứng dụng theo hướng SOA đã ra đời. Tuy nhiên, như đã phân tích ở trên, kiến trúc SOA vẫn tồn tại nhiều hạn chế trong việc quản lý, vận hành cũng như tích hợp hệ thống. Nhằm giải quyết những khó khăn này, hướng kiến trúc microservices đã ra đời. Microservices cung cấp cho các nhà phát triển một hướng tiếp cận mới trong việc xây dựng phần mềm theo hướng dịch vụ bằng cách tổ chức các thành phần phần mềm thành những module nhỏ. Các module này được coi là những ứng dụng riêng rẽ, được triển khai độc lập và giao tiếp với nhau thông qua các API. Vì những đặc tính này, có nhiều quan điểm cho rằng microservices thực chất là một bước tiến hóa tiếp theo của SOA. 1.2.1. Kiến trúc microservices là gì? Có nhiều định nghĩa khác nhau về microservices tùy theo ngữ cảnh và hướng tiếp cận. Theo tác giả James Lewis và Martin Fowler, microservices được hiểu như sau: “Microservices là một hướng tiếp cận trong việc phát triển một ứng dụng nguyên khối thành một tập các dịch vụ nhỏ, mỗi một dịch vụ này chạy trong một tiến trình riêng của nó và giao tiếp với nhau thông qua cơ chế mềm dẻo – thường là qua HTTP, giao diện lập trình ứng dụng (API).” [4] 9