3.2.1.Sơ đồ phân cấp chức năng
Chức năng tổng quát của CEMS được mô tả trong hình 3.1 bao gồm các phân hệ:
• Phân hệ quản lý người dùng (user management): cung cấp các tính năng
như tạo mới, cập nhật thông tin người dùng, tìm kiếm thông tin người dùng, đổi mật khẩu, quản lý danh sách nhóm quyền của người dùng (roles).
• Phân hệ quản lý khách hàng (customer management): cung cấp các tính năng như tạo mới, cập nhật thông tin khách hàng, tìm kiếm thông tin khách hàng, quản lý danh sách các trạm quan trắc của khách hàng (monitoring station).
• Phân hệ quản lý thiết bị (equipment management): cung cấp các tính năng
như tạo mới, cập nhật thông tin thiết bị, loại thiết bị (equipment category), tìm kiếm thông tin thiết bị.
• Phân hệ quản lý tài sản (asset management): cung cấp các tính năng như
tạo mới, cập nhật thông tin tài sản, loại tài sản (asset category), tìm kiếm thông tin tài sản, quản lý danh sách phiếu xuất kho (stock issued docket).
42
• Phân hệ báo cáo (reporting): cung cấp dịch vụ kết xuất ra các báo cáo theo
định kỳ về khách hàng, tài sản. Định dạng báo cáo kết xuất ra các tệp như PDF, excel.
Hình 3.1. Chức năng tổng quát của hệ thống CEMS
3.2.2.Sơ đồ use case tổng quát
Người sử dụng cần đăng nhập vào hệ thống để sử dụng các chức năng theo yêu cầu. Hình 3.2 mô tả sơ đồ use case tổng quát cho trường hợp người dùng sử dụng ứng dụng.
43
Theo sơ đồ ở hình 3.2, hệ thống CEMS có hai tác nhân là người quản trị hệ thống (admin) và người dùng (user). Cả hai đối tượng này đều có quyền thực hiện các thao tác như tạo mới (create), cập nhật (update) và tìm kiếm (search) các thông tin liên quan. Quản trị viên có quyền thực hiện các tác vụ tạo mới, cập nhật và tìm kiếm thông tin người dùng. Người sử dụng thông thường có quyền tạo mới, cập nhật và tìm kiếm các thông tin liên quan đến khách hàng (customer), thiết bị (equipment), tài sản (asset) và kết xuất các báo cáo liên quan đến khách hàng, tài sản (generate report). Bên cạnh đó, CEMS hỗ trợ chức năng xác thực người dùng thông qua tác vụ đăng nhập (login), đăng xuất (logout) và đổi mật khẩu (change password).
3.3. Giải pháp xây dựng hệ thống 3.3.1.Giải pháp triển khai 3.3.1.Giải pháp triển khai
CEMS được phát triển dựa trên kiến trúc microservices cho tầng dịch vụ và micro- frontends cho tầng giao diện.
3.3.2.Lựa chọn công nghệ, công cụ 3.3.2.1. Công nghệ cho tầng dịch vụ 3.3.2.1. Công nghệ cho tầng dịch vụ
Để xây dựng các microservices, đội dự án lựa chọn các công nghệ và công cụ chính sau:
• Ngôn ngữ lập trình: sử dụng Java 8.
• Cơ sở dữ liệu: sử dụng MySQL 8.
• Framework để xây dựng các microservices: Spring Boot, Spring Cloud, Spring Data JPA.
• Framework cho unit test: sử dụng Junit, Mockito kết hợp với Spring Boot Test.
• Quản lý logging: sử dụng ELK (Elasticsearch, Logstash, Kibana).
• Công cụ phân tích, đảm bảo chất lượng mã nguồn: sử dụng PMD24 kết hợp với SonaQube25.
3.3.2.2. Công nghệ cho tầng giao diện
Các framework được dùng cho tầng giao diện web gồm Angular, ReactJS và Single-SPA.
3.4. Giới thiệu tổng quan các công nghệ trong dự án
Trong mục này, luận văn tập trung giới thiệu một cách ngắn gọn một số framework chính được sử dụng trong dự án bao gồm Spring Boot và Single-SPA.
24 https://pmd.github.io/ 25 https://www.sonarqube.org/
44
3.4.1.Tổng quan về Spring Boot
Spring Boot26 là một module nằm trong hệ sinh thái của Spring framework, đã được phát triển và sử dụng rộng rãi trong việc xây dựng các ứng dụng trên nền Java. Sử dụng Spring Boot cho phép tăng tốc quá trình phát triển chương trình. Trên nền tảng Java, Spring Boot thể hiện được nhiều ưu điểm vượt trội so với một số framework khác như Micronaut27 hay Play28.
Bảng 3.1. So sánh Spring Boot, Micronaut và Play framework
Tiêu chí Spring Boot Micronaut Play
Mô hình lập trình
Reactive và Servlet Reactive Reactive và Servlet
Khả năng tích hợp với các công nghệ khác
Tích hợp dễ dàng với nhiều công nghệ, dịch vụ khác (Security, Service Discovery). Có nhiều module tiện ích thuộc hệ sinh thái của Spring framework.
Hạn chế trong việc tích hợp với các dịch vụ khác. Cần sử dụng thêm các thư viện của bên thứ ba.
Hạn chế trong việc tích hợp với các dịch vụ khác. Cần sử dụng thêm các thư viện của bên thứ ba. Ngôn ngữ lập trình Java, Groovy và Kotlin Java, Groovy và Kotlin Java và Scala Hỗ trợ dịch vụ điện toán đám mây AWS, Azure, Goolge Cloud Chưa hỗ trợ toàn diện cho AWS, Azure hay Google Cloud
Phải sử dụng thêm các plugin bên ngoài
26 https://spring.io/projects/spring-boot 27 https://micronaut.io/
45
3.4.2.Tổng quan về Single-SPA 3.4.2.1. Khái quát về Single-SPA 3.4.2.1. Khái quát về Single-SPA
Single-SPA29 là một framework viết bằng JavaScript, được sử dụng để phát triển các ứng dụng micro-frontends một cách nhanh chóng. Single-SPA mang lại nhiều tính năng hữu ích như [28]:
• Kết hợp được các ứng dụng xây dựng trên các framework khác nhau (Angular, ReactJS, VueJS) vào cùng một trang.
• Triển khai các micro-frontends một cách độc lập.
• Tái sử dụng được nhiều thành phần trong quá trình phát triển ứng dụng, giảm thiểu thời gian viết lại các đoạn mã nguồn lặp đi lặp lại.
• Cung cấp nhiều cơ chế khác nhau như “lazy loading”30 để tối ưu hóa hiệu năng trong quá trình khởi tạo, nạp ứng dụng.
Điểm khác biệt chính giữa một ứng dụng theo hướng SPA truyền thống và ứng dụng sử dụng single-spa nằm ở chỗ single-spa cho phép kết hợp nhiều chương trình SPA khác nhau vào trong cùng một ứng dụng thống nhất. So với một số công cụ khác như SystemJS31 hay Luigi32, single-spa được xem là một framework toàn diện để phát triển và tích hợp các micro-frontends tính đến thời điểm hiện tại.
3.4.2.2. Kiến trúc của ứng dụng single-spa
Ứng dụng single-spa được cấu thành bởi hai thành phần chính [29]:
• single-spa root config: thành phần này chịu trách nhiệm kết xuất ra các trang
HTML và JavaScript để đăng ký các ứng dụng.
• applications: thành phần này được xem là một tập các ứng dụng theo kiểu
SPA được đóng gói thành các module. Mỗi một module này có quy trình hoạt động như khởi tạo, đăng ký và hủy đăng ký để nạp vào trong cấu trúc DOM của ứng dụng.
Ví dụ trong hình 3.3 mô tả kiến trúc tổng thể của một ứng dụng single-spa. Ứng dụng này được tạo thành bởi ba ứng dụng con viết bằng AngularJS, ReactJS và VueJS. Các thành phần con được tích hợp lại vào một ứng dụng hợp nhất bằng cách sử dụng “single-spa-root config”.
29 https://single-spa.js.org/
30 https://developer.mozilla.org/en-US/docs/Web/Performance/Lazy_loading 31 https://github.com/systemjs/systemjs
46
Hình 3.3. Kiến trúc tổng thể của một ứng dụng single-spa
3.5. Kiến trúc tổng quan hệ thống 3.5.1.Mô hình hóa các microservices 3.5.1.Mô hình hóa các microservices
Để xác định các microservices, chúng ta áp dụng kỹ thuật DDD như đã trình bày trong chương 1 của luận văn. Trước hết, chúng ta cần xác định các vùng ngữ cảnh riêng của hệ thống, thuật ngữ gọi là “Bounded Context”. Sau đó, chúng ta khoanh vùng các hành vi có mối quan hệ và cùng thực hiện một chức năng trong một miền nghiệp vụ lại với nhau. Dựa theo yêu cầu chức năng của CEMS như mô tả ở mục 3.2, ta xác định được sáu vùng ngữ cảnh chính của hệ thống gồm vùng chứa các hành vi liên quan đến người dùng (user context), vùng chứa các hành vi liên quan đến khách hàng (customer contex), vùng chứa các hành vi liên quan đến thiết bị (equipment context), vùng chứa các hành vi liên quan đến tài sản (asset context), vùng chứa các hành vi liên quan đến báo cáo (report context), và vùng chứa các hành vi liên quan đến việc xác thực, phân quyền của hệ thống (authentication context). Mỗi vùng nghiệp vụ đều chứa các hành vi cơ bản như tạo mới (create), cập nhật (update) và tìm kiếm dữ liệu (search). Riêng vùng nghiệp vụ quản lý việc xác thực, phân quyền chứa các hành vi như đăng nhập (login), đăng xuất (logout) và đổi mật khẩu (change password). Các phân vùng nghiệp vụ này được mô tả trong hình 3.4.
47
Hình 3.4. Phân vùng các hành vi trong hệ thống CEMS
Từ việc phân hoạch trên, hệ thống CEMS có sáu microservices gồm: user-service (quản lý thông tin người dùng), customer-service (quản lý thông tin khách hàng), equipment-service (quản lý thông tin thiết bị máy móc), asset-service (quản lý thông tin tài sản), reporting-service (kết xuất báo cáo), và authentication-service (quản lý việc xác thực và phân quyền). Dựa trên các phân vùng hành vi nghiệp vụ này, chúng ta cũng sẽ xác định được các micro-frontends tương ứng để quản lý các dịch vụ tương tác người dùng trong ứng dụng.
3.5.2.Kiến trúc tổng thể của CEMS
Kiến trúc hệ thống CEMS được mô tả trong hình 3.5. Tầng giao diện giao tiếp với các microservices qua cổng API và được thực hiện thông qua REST API. CEMS hỗ trợ chuẩn định dạng dữ liệu dưới dạng JSON. Chi tiết về cách cài đặt và nhiệm vụ của từng thành phần trong kiến trúc này sẽ được giải thích cụ thể trong các mục tiếp theo của luận văn.
48
Hình 3.5. Kiến trúc tổng thể hệ thống CEMS
3.5.3.Xây dựng mô hình dữ liệu
Để đảm bảo nguyên tắc triển khai độc lập và giảm thiểu sự phụ thuộc giữa các thành phần, mỗi microservice trong CEMS sẽ sử dụng một cơ sở dữ liệu riêng biệt. Dựa vào phân vùng nghiệp vụ của bài toán như mô tả ở mục 3.5.1, ta xác định được bốn lược đồ cơ sở dữ liệu chính dành cho các đối tượng gồm người dùng (user-db), khách hàng (customer-db), thiết bị (equipment-db) và tài sản (asset-db). Đối với tác vụ kết xuất báo cáo, dữ liệu sẽ được tổng hợp từ thông tin của khách hàng và tài sản, và được lưu riêng ở vùng dữ liệu dành cho báo cáo (reporting-db). Mô hình tổ chức dữ liệu cho hệ thống được thể hiện trong hình 3.6.
Sau khi có được mô hình cơ sở dữ liệu chung ở trên, chúng ta cần xây dựng cơ sở dữ liệu cho từng microservice. Để thực hiện điều này, trước hết chúng ta áp dụng kỹ thuật thiết kế hướng miền nhằm xác định các lớp thực thể chứa các thông tin cần quản lý liên quan đến từng miền nghiệp vụ của hệ thống, sau đó chúng ta cần xác định mối quan hệ giữa các thực thể dựa theo các quy tắc nghiệp vụ của bài toán để đưa ra được sơ đồ lớp cho các lớp thực thể này. Sơ đồ trong hình 3.7 minh họa mối quan hệ giữa các lớp thực thể trong module user-service.
49
Hình 3.6. Mô hình cơ sở dữ liệu của CEMS
Hình 3.7. Mối quan hệ giữa các lớp thực thể trong module user-service
Theo sơ đồ lớp trong hình 3.7, module user-service có bốn lớp thực thể tham gia bao gồm lớp vị trí (position) lưu thông tin về vị trí, chức danh người dùng; lớp nhóm quyền (group role) lưu thông tin về nhóm quyền, lớp phòng ban (department) lưu thông tin về các phòng ban và lớp người sử dụng ứng dụng (app user) lưu các thông tin liên quan đến người dùng (họ tên, địa chỉ, mật khẩu…). Các lớp thực thể này sẽ được ánh xạ với từng bảng trong cơ sở dữ liệu thông qua kỹ thuật ORM để chuyển đổi mô hình từ các lớp Java sang từng bảng tương ứng trong lược đồ cơ sở dữ liệu. Việc xây dựng cơ sở dữ liệu cho các microservice khác được thực hiện theo cách tương tự.
50
3.6. Thiết kế và cài đặt tầng dịch vụ
Trong phần này, luận văn tập trung trình bày cách thiết kế và cài đặt chi tiết của một microservice. Một số thành phần quan trọng trong tầng dịch vụ như cách xây dựng cổng API, thiết kế mô hình “đăng ký và khám phá dịch vụ” cũng sẽ được làm rõ.
3.6.1.Kiến trúc cụ thể của một microservice
Mỗi microservice phát triển bằng Spring Boot được tổ chức thành các thành phần cơ bản sau:
• Lớp điều khiển (controller): có nhiệm vụ đóng gói các API để kết xuất ra
bên ngoài cho các đối tượng sử dụng. Lớp này đón nhận các yêu cầu từ phía người dùng, tương tác với lớp dịch vụ và gửi trả lại dữ liệu cho người dùng thông qua REST API.
• Lớp dịch vụ (service): có nhiệm vụ đóng gói các logic nghiệp vụ của bài
toán dựa trên các quy tắc về nghiệp vụ. Nó thực hiện tương tác với kho lưu trữ để lấy dữ liệu và xử lý tập dữ liệu đó theo từng yêu cầu cụ thể. Một số tác vụ khác như kiểm tra tính hợp lệ của dữ liệu theo các quy tắc nghiệp vụ cũng có thể được thực hiện tại tầng này.
• Kho lưu trữ (repository): thực hiện tác vụ kết nối và tương tác với cơ sở dữ
liệu để truy xuất hoặc lưu trữ dữ liệu. Để thực hiện các yêu cầu này, kho lưu trữ sẽ phải liên kết với lớp thực thể. Trong ứng dụng Spring Boot, mỗi kho lưu trữ có thể được triển khai bằng Spring Data JPA33 hoặc dùng kết hợp với một số ORM framework khác như Hibernate34 hoặc MyBatis35.
• Lớp thực thể (entity): mỗi entity được gọi là lớp thực thể đại diện cho một
đối tượng cần quản lý trong miền nghiệp vụ của bài toán. Các thực thể này sẽ được ánh xạ với từng bảng trong cơ sở dữ liệu thông qua kỹ thuật ORM.
• Bộ lọc (filter): mỗi filter được gọi là một bộ lọc, nó đóng vai trò như một
thành phần trung gian thực hiện việc tiền xử lý các yêu cầu từ phía người dùng trước khi chúng được gửi tới lớp điều khiển.
• Thành phần “Bean Factory”: có chức năng quản lý việc khởi tạo các đối
tượng cũng như kiểm soát vòng đời hoạt động của các đối tượng trong ứng dụng.
• Thành phần “Bean Configuration”: được dùng để quản lý cấu hình các đối
tượng (beans) trong ứng dụng, ví dụ quản lý thông tin nguồn dữ liệu (data source), quản lý các thành phần để ánh xạ, chuyển đổi dữ liệu (object mapper) và bất cứ đối tượng nào do lập trình viên tự định nghĩa.
33 https://spring.io/projects/spring-data-jpa 34 https://hibernate.org/
51
• Thành phần “DTO” (Data Transfer Object)36: thực hiện việc trung chuyển dữ liệu giữa các tầng, người ta sử dụng các DTO. Mỗi một DTO có nhiệm vụ đóng gói dữ liệu từ tầng nghiệp vụ để kết xuất ra cho phía người dùng. Như vậy, bằng cách phân lớp như trên, mỗi một microservice được chia tách thành các gói riêng biệt. Các thành phần bên trong ứng dụng sẽ được gắn kết với nhau thông qua cơ chế “tiêm sự phụ thuộc” (DI37). Với cách tổ chức này, mỗi microservice đảm bảo được tính đơn nhiệm, độc lập và làm giảm sự phụ thuộc chặt giữa các thành phần. Tổng quan về các thành phần và mối quan hệ giữa chúng trong một microservice được mô tả trong hình 3.8.
Hình 3.8. Kiến trúc tổng thể của một microservice
3.6.2.Xây dựng cổng API
Để quản lý và xử lý tập trung các yêu cầu từ phía máy khách, CEMS sử dụng Zuul API Gateway, một thành phần được cung cấp bởi Spring Cloud38.
Zuul sử dụng Netflix Ribbon39 để triệu gọi các microservices và hỗ trợ sử dụng các thành phần như Eureka Client40, Client Load Balancer41, Caching42. Để thực hiện tiền
36 https://martinfowler.com/eaaCatalog/dataTransferObject.html 37 https://docs.oracle.com/javaee/7/tutorial/injection002.htm 38 https://spring.io/projects/spring-cloud 39 https://github.com/Netflix/ribbon 40 https://cloud.spring.io/spring-cloud-netflix/multi/multi__service_discovery_eureka_clients.html 41 https://spring.io/guides/gs/spring-cloud-loadbalancer/ 42 https://cloud.spring.io/spring-cloud-static/spring-cloud-aws/2.0.0.RELEASE/multi/multi__caching.html
52
xử lý các yêu cầu trước khi gọi tới các microservices, Zuul cung cấp một thành phần gọi là ZuulFilter (cơ chế hoạt động của nó về cơ bản giống như một ServletFilter43).
Một cổng API thực hiện các chức năng như mô tả trong hình 3.9:
• Chức năng định tuyến (routing): có nhiệm vụ tiếp nhận và điều hướng các yêu cầu từ phía client tới từng microservice cụ thể.
• Chức năng bảo mật (security): chức năng này được thiết lập kết hợp với Spring Security44.
• Chức năng lọc (filter): thực hiện việc lọc các yêu cầu.
• Chức năng ghi log: thực hiện logging.
Hình 3.9. Vai trò của cổng API trong CEMS
Để cấu hình một Zuul API Gateway, ta sử dụng các chỉ thị là @EnableEurekaClient và @EnableZuulProxy. Đoạn mã nguồn trong hình 3.10 minh họa cách cấu hình cho một Zuul API Gateway.
43 https://www.oracle.com/java/technologies/filters.html 44 https://spring.io/projects/spring-security
53
Hình 3.10. Cấu hình Zuul API Gateway