(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

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

MÃ SÞ: 8480103.01

NG¯âI H¯àNG DÀN KHOA HàC: PGS.TS TR¯¡NG ANH HOÀNG

HÀ NÞI - 2021

i

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

ii

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

Māc tiêu nghiên cāu 1

Đßi t°ÿng và ph¿m vi nghiên cāu 2

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

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

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.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

vi

1 API Application Programming Interface Giao diện lập trình āng dụng 2 CI/CD Continuous Integration (CI) and

Continuous Delivery (CD) Quá trình tích hợp và chuyển 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

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

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

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

vii

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

viii

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

ix

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

1

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

2

ā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 vn

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:

3

- Á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

4

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

5

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

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ệ

6

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

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ụ

7

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

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

8

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ế:

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ß

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

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]

10

Mát cách hiểu ngắn gán về microservices cÿa tác giả Sam Newman: <Microservices

là những service nhỏ, tự vận hành và có thể cộng tác với nhau.= [5]

Như vậy, bản chất cÿa microservices chính là SOA và nó mang các đặc điểm cÿa SOA Cách tiếp cận theo hướng microservices tập trung vào việc chia nhß mát āng dụng lớn thành nhiều dßch vụ nhß, và các dßch vụ này có thể kết nái, giao tiếp được với nhau Mßi mát dßch vụ được xem như mát chương trình āng dụng đác lập, thực hiện mát chāc năng riêng biệt trong miền nghiệp vụ mà nó đảm nhiệm

Chúng ta cùng xem xét mát ví dụ về mát hệ tháng phần mềm phục vụ việc bán hàng trực tuyến được triển khai theo hướng microservices như mô tả trong hình 1.4 Hệ tháng này bao gồm hai thành phần chính:

TÁng giao dißn (frontend)

TÁng dßch vā (backend): gồm có 3 microservices

• Product Service: quản lý thông tin về sản phẩm • Order Service: quản lý thông tin về đơn hàng • User Service: quản lý thông tin về ngưßi dùng

Mßi mát microservice là mát āng dụng đác lập, sử dụng mát cơ sá dữ liệu riêng và nó thực hiện mát nhiệm vụ chuyên biệt Tầng giao diện giao tiếp với tầng dßch vụ qua mát lớp trung gian, gái là cổng API Chi tiết về cổng API sẽ được thảo luận trong phần tiếp theo cÿa luận văn Việc giao tiếp giữa máy chÿ và máy khách cũng như giữa các microservices được thực hiện thông qua các REST API

Hình 1.4 Hệ thống web bán hàng theo mô hình microservices

Tóm l¿i, các khái niệm về microservices theo từng ngữ cảnh có thể khác nhau, nhưng đều tập trung nhấn m¿nh vào ba điểm cát lõi sau:

11

Tính hướng dịch vụ: Microservices có bản chất là SOA, và các microservices giao

tiếp với nhau qua môi trưßng m¿ng

làm giảm sự phụ thuác chặt chẽ giữa các thành phần trong hệ tháng Các dßch vụ có thể được sửa đổi, cập nhật mát cách riêng biệt với nhau, và việc thay đổi á mát dßch vụ này không yêu cầu đến sự cập nhật á mát dßch vụ khác

Tính đóng gói, khép kín: Mßi mát microservice là mát āng dụng riêng lẻ, được triển

khai và ho¿t đáng đác lập Trong quá trình phát triển cũng như bảo trì hệ tháng, việc sửa đổi mã nguồn cÿa mát microservice này sẽ không gây ra sự xung đát hay tác đáng tới chāc năng cÿa các microservice khác

Đặc điÃm cÿa ki¿n trúc microservices

Có nhiều khái niệm cũng như cách hiểu khác nhau về microservices, và cho tới nay chưa có mát đßnh nghĩa nào hoàn chỉnh về hướng kiến trúc này Khi mô tả về microservices, ngưßi ta đề cập tới mát sá tính chất quan tráng sau đây

Tính đơn nhiệm: Về mặt thiết kế, mßi mát dßch vụ trong hệ tháng microservices chỉ

tập trung vào giải quyết và hoàn thành mát tác vụ trong miền nghiệp vụ cÿa bài toán mà nó đảm nhiệm Đặc điểm này vì thế được gái là sự đơn nhiệm Nhìn á khía c¿nh khác, các dßch vụ trong hệ tháng được chia thành nhiều dßch vụ nhß Khái niệm <nhỏ= về mặt chāc năng, nghiệp vụ á đây cũng chính là yếu tá dẫn đến việc triển khai về mặt mã nguồn (lập trình) Mßi mát dßch vụ sẽ sử dụng mát cấu trúc mã nguồn nhß, và nó có thể dễ dàng được phát triển cũng như triển khai trong mát thßi gian ngắn

Tính đóng gói: Mßi mát microservice sẽ chỉ nên thực hiện mát nhiệm vụ riêng biệt,

và nó sẽ đóng gói toàn bá dữ liệu cũng như chi tiết về mặt cài đặt trong từng dßch vụ Mát cách lý tưáng, giới chuyên gia cho rằng mßi mát microservice chỉ nên sử dụng mát cơ sá dữ liệu riêng cho nó, và các dữ liệu này được giữ á māc riêng tư Đặc điểm cÿa sự đóng gói này đảm bảo sự phụ thuác lßng lẻo giữa các dßch vụ trong toàn hệ tháng

Khả năng tự trị: Khả năng này đảm bảo cho sự đác lập trong quá trình triển khai và

phát triển hệ tháng Điều đó có nghĩa là mßi mát microservice có thể được xây dựng đác lập bái mát đái ngũ phát triển, và được triển khai cài đặt trên từng máy riêng biệt

Tính đàn hồi: Đặc tính này đảm bảo trưßng hợp nếu mát module này bß trục trặc thì

sự hßng hóc đó là cô lập với các thành phần khác, và các dßch vụ khác vẫn có thể ho¿t đáng được mà ít chßu ảnh hưáng Sự đàn hồi là yếu tá làm tăng khả năng chßu lßi cho hệ tháng

cho việc má ráng hệ tháng Mßi khi có các yêu cầu bổ sung các tính năng mới về chāc năng nghiệp vụ hoặc cần sự nâng cấp về mặt công nghệ, quá trình cập nhật này có thể

12

được tiến hành đác lập cho từng module phần mềm mà không làm ảnh hưáng tới các thành phần khác

1.2.2 Các mÁu thi¿t k¿ microservices

Nhằm giải quyết những khó khăn, những vấn đề lặp đi lặp l¿i trong việc thiết kế cũng như triển khai chương trình, các mẫu thiết kế được sử dụng Trong phần này, luận văn tập trung vào giải thích mát sá mẫu thiết kế phổ biến nhất được áp dụng cho các hệ tháng microservices

• Kiểu dữ liệu mà tầng giao diện yêu cầu cũng khác nhau, ví dụ: āng dụng web yêu cầu đßnh d¿ng HTML, āng dụng mobile yêu cầu dữ liệu trả về theo đßnh d¿ng JSON.Vậy thành phần nào sẽ làm nhiệm vụ chuyển đổi đßnh d¿ng các kiểu dữ liệu trả về cho phía máy khách?

• Kiểu giao thāc mà phía máy khách yêu cầu cũng có thể khác nhau, ví dụ: āng dụng web sử dụng SOAP, āng dụng mobile l¿i sử dụng REST…Vậy làm sao để kiểm soát được các kiểu giao thāc khác nhau này?

Giải pháp

Để giải quyết các vấn đề trên, ngưßi ta đưa vào sử dụng mát thành phần gái là cổng API (thuật ngữ gái là API Gateway) [6] Cổng API thực chất là mát thành phần trung gian, nó được xem là mát điểm đầu vào cÿa tất cả các yêu cầu từ phía máy khách được gửi tới các microservices Nói mát cách khác, việc giao tiếp giữa máy khách và các microservices không được thực hiện trực tiếp, mà sẽ thông qua cổng API Sơ đồ hình 1.5 minh háa việc sử dụng cổng API cho āng dụng

13

Hình 1.5 Mô hình cổng API trong hệ thống microservices

Bằng cách sử dụng cổng API, các lßi gái từ tầng giao diện đến các microservices sẽ được quản lý tập trung Các yêu cầu từ phía máy khách sẽ đi qua cổng API Cổng API tiếp nhận các yêu cầu này, xử lý và thực hiện việc điều hướng tới các microservices phù hợp Trong nhiều trưßng hợp, cổng API còn thực hiện việc chuyển đổi, tổng hợp dữ liệu từ các microservices khác nhau rồi trả l¿i cho phía máy khách Bên c¿nh đó, ngưßi ta cũng có thể sử dụng cổng API để thực hiện mát sá tác vụ khác như chuyển đổi giữa các bá giao thāc (HTTP, SOAP, REST, Web Socket…), thực hiện cơ chế về xác thực ngưßi dùng hoặc cung cấp mát cách thāc tùy biến để t¿o ra các API cho phù hợp với từng yêu cầu cÿa phía giao diện

Bên c¿nh các ưu điểm, cổng API cũng bác lá mát sá h¿n chế nhất đßnh Thā nhất, vì cổng API là nơi tập trung xử lý mái yêu cầu từ phía máy khách, nên nó có thể trá thành nút thắt cổ chai cÿa āng dụng Thā hai, việc xử lý quá nhiều các yêu cầu t¿i đây có thể ảnh hưáng tới hiệu năng chương trình

Tồn t¿i các ưu và nhược điểm, cổng API vẫn luôn là mát thành phần thiết yếu cần được thiết kế, phát triển và quản lý trong các hệ tháng microservices Để triển khai cổng API cho āng dụng mát cách hiệu quả, chúng ta cần phải căn cā vào rất nhiều yếu tá như tình hình yêu cầu thực tế cÿa bài toán, áp dụng các công nghệ, kỹ thuật lập trình phù hợp, và phải sử dụng kết hợp với nhiều mẫu thiết kế khác nhau

1.2.2.2 Mô hình đng ký và khám phá dßch vā

Vấn đề phát sinh

Trong mô hình ho¿t đáng cÿa microservices, phía máy khách sẽ gửi yêu cầu tới mát dßch vụ trong tầng dßch vụ Để thực hiện lßi gái này, máy khách cần phải có thông tin cÿa dßch vụ cần gái, bao gồm đßa chỉ IP và cổng

14

Các microservices được cài đặt phân tán trên nhiều máy, và có thể triển khai trên các dßch vụ điện toán đám mây như Amazon Web Services (AWS) Trong mô hình này, thông tin đßa chỉ m¿ng cÿa từng dßch vụ được gán mát cách tự đáng, và nó có thể thay

đổi mát cách linh ho¿t mßi khi có các dßch vụ khác diễn ra như <tự động mở rộng=

(auto-scaling)4

Như vậy, có hai vấn đề chính cần quan tâm:

• Thā nhất, thông tin đßa chỉ m¿ng được gán mát cách đáng cho các dßch vụ Mßi khi đßa chỉ này thay đổi, phía sử dụng dßch vụ sẽ bß mất thông tin và cần phải có các cập nhật kßp thßi

• Thā hai, đßa chỉ cÿa các dßch vụ cần phải được phía sử dụng dßch vụ ghi nhớ và gắn kết chặt chẽ với nhau

Giải pháp

Để giải quyết yêu cầu trên, ngưßi ta đưa vào mô hình <đăng ký dịch vụ= (service

registry) và <khám phá dịch vụ= (service discovery)

Service registry là mát thành phần được t¿o ra để lưu trữ các thông tin mô tả cho từng dßch vụ [7] Mßi mát dßch vụ khi được t¿o ra và bắt đầu ho¿t đáng phải được đăng ký vào service registry và hÿy đăng ký mßi khi dßch vụ này ngừng ho¿t đáng Phía sử dụng dßch vụ gửi mát truy vấn tới service registry để tìm kiếm thông tin vß trí cÿa dßch vụ Thành phần đăng ký dßch vụ cần phải có mát cơ chế để kiểm tra xem các dßch vụ nào đang á tr¿ng thái ho¿t đáng nhằm đáp āng yêu cầu từ phía sử dụng dßch vụ Ho¿t đáng này được gái là quá trình khám phá dßch vụ [8] Hai mô hình khám phá dßch vụ

được sử dụng là <khám phá dịch vụ phía máy khách= (client-side discovery) và <khám

phá dịch vụ phía máy chủ= (server-side discovery) Trong phần tiếp theo, luận văn tập

trung giải thích cơ chế ho¿t đáng cÿa hai lo¿i hình khám phá dßch vụ này

Mô hình client-side discovery: Trong mô hình này, bên sử dụng dßch vụ sẽ gửi mát yêu cầu truy vấn đến thành phần đăng ký dßch vụ [9] Phía đăng ký dßch vụ tiếp nhận yêu cầu, xử lý yêu cầu và gửi trả l¿i kết quả cho bên sử dụng dßch vụ Sau khi tiếp nhận được thông tin phản hồi, máy khách sẽ sử dụng mát thuật toán về cân bằng tải để lựa chán ra mát dßch vụ phù hợp để gửi yêu cầu Sơ đồ trong hình 1.6 minh háa cơ chế ho¿t đáng cÿa mô hình khám phá dßch vụ phía máy khách

4 https://aws.amazon.com/autoscaling/

15

Hình 1.6 Mô hình client-side discovery

Lưu ý trong mô hình ho¿t đáng trên:

• Thông tin về đßa chỉ m¿ng cÿa mßi dßch vụ phải được đăng ký vào service registry mßi khi nó khái đáng, và được lo¿i bß khi dßch vụ kết thúc

• Để luôn cập nhật được vß trí đßa chỉ m¿ng cÿa từng dßch vụ, ngưßi ta sử dụng mát cơ chế gái là <tín hiệu tuần hoàn= (heartbeat mechanism5)

Điểm thuận lợi cÿa mô hình client-side discovery là sự đơn giản trong cơ chế ho¿t đáng Cái phāc t¿p nhất trong mô hình này nằm á chß cách thāc cài đặt và triển khai thành phần đăng ký dßch vụ Hiện nay, có rất nhiều nền tảng cũng như thư viện lập trình hß trợ việc triển khai đăng ký dßch vụ mát cách thuận tiện như Spring Cloud Netflix6

Điểm h¿n chế cÿa kỹ thuật này thể hiện á chß nó t¿o ra mát sự ràng buác khá chặt giữa máy khách với thành phần đăng ký dßch vụ Thêm vào đó, lập trình viên sẽ phải cài đặt mã nguồn á phần giao diện cho từng ngôn ngữ lập trình cũng như các bá khung lập trình (framework) được sử dụng bái dßch vụ phía máy khách

Mô hình server-side discovery: Mát mô hình khám phá dßch vụ khác được sử dụng

là kỹ thuật server-side discovery Sơ đồ trong hình 1.7 mô tả cách thāc ho¿t đáng cÿa phương pháp này Mô hình server-side discovery ho¿t đáng theo nguyên tắc sau:

Yêu cầu từ phía máy khách sẽ đi qua mát thành phần gái là bá đßnh tuyến hay bá cân bằng tải (router/load balancer) [10] Bá cân bằng tải thực hiện mát truy vấn gửi tới thành phần đăng ký dßch vụ và điều hướng yêu cầu này tới các dßch vụ đang ho¿t đáng Cũng giáng như mô hình client-side discovery, các dßch vụ cần phải thực hiện việc đăng ký với service registry mßi khi chúng khái đáng, và thực hiện hÿy đăng ký khi chúng ngừng ho¿t đáng

5 https://docs.oracle.com/cd/E19206-01/816-4178/6madjde6e/index.html 6 https://spring.io/projects/spring-cloud-netflix

16

Hình 1.7 Mô hình server-side discovery

Các dßch vụ điện toán đám mây hiện nay đều cung cấp các thành phần đßnh tuyến nhằm phục vụ yêu cầu từ phía ngưßi dùng Có thể kể đến mát sá dßch vụ như AWS Elastic Load Balancing7 (AWS ELB) hay Azure Load Balancing8 (Azure ELB), các dßch vụ này cung cấp mát phương pháp hiệu quả để thực hiện việc cân bằng tải lớp āng dụng trong hệ tháng Lợi ích chính mang l¿i từ việc sử dụng mô hình server-side discovery có thể kể đến như sau:

Thā nhất, phần cài đặt chi tiết cho quá trình khám phá dßch vụ được tách biệt khßi phía giao diện Máy khách chỉ thực hiện mát việc đơn giản là gửi yêu cầu tới thành phần cân bằng tải Bá phận cân bằng tải sẽ thực hiện các nhiệm vụ còn l¿i Điều có cũng có nghĩa rằng nó sẽ làm giảm đi phần cài đặt mã nguồn á phía máy khách

Thā hai, nếu sử dụng các dßch vụ điện toán đám mây sẵn có như AWS ELB hay Azure ELB như đã nói á trên, việc triển khai mô hình này rất đơn giản và tán ít thßi gian

1.2.2.3 MÁu thi¿t k¿ c¢ så dă lißu

Trong hệ tháng microservices, ngưßi ta đưa ra hai mô hình sử dụng cơ sá dữ liệu là

<dùng riêng cơ sở dữ liệu= (database per service) và <dùng chung cơ sở dữ liệu= (shared

database)

Dùng riêng c¢ så dă lißu

Vấn đề phát sinh

7 https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html 8 https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-overview

Giải pháp

Nhằm giải quyết các yêu cầu trên, mô hình <dùng riêng cơ sở dữ liệu= được sử dụng [11] Bản chất cÿa mô hình này là mßi mát dßch vụ sẽ sử dụng mát cơ sá dữ liệu riêng biệt Các dßch vụ khác nếu muán truy cập vào cơ sá dữ liệu này thì phải sử dụng các API do phía dßch vụ quản lý cơ sá dữ liệu đó cung cấp

Hình 1.8 Mô hình dùng riêng cơ sở dữ liệu

Theo cách triển khai cÿa mô hình này, mßi mát cơ sá dữ liệu sẽ thuác về mát dßch vụ và nó được đóng gói nhằm đảm bảo tính riêng tư cho chính dßch vụ đó Trong thực tế triển khai, chúng ta có thể sử dụng các cách sau để đảm bảo tính riêng tư về mặt cơ sá dữ liệu cho mßi mát dßch vụ:

• Cách 1: mßi mát dßch vụ sẽ sử dụng mát tập hợp các bảng riêng Các bảng

này chỉ thuác quyền quản lý cÿa mát dßch vụ nhất đßnh

• Cách 2: mßi mát dßch vụ sẽ sử dụng mát lược đồ cơ sá dữ liệu riêng biệt

18

• Cách 3: mßi mát dßch vụ sẽ sử dụng mát máy chÿ cơ sá dữ liệu riêng

Tùy chán thā nhất và thā hai dễ triển khai và tát ít chi phí Tuy nhiên, trưßng hợp sá lượng yêu cầu đến các dßch vụ tăng cao, đồng nghĩa với việc mát lượng lớn về dữ liệu cần phải xử lý, thì khi đó mßi mát dßch vụ cần sử dụng riêng mát máy chÿ để lưu trữ dữ liệu Lúc này lựa chán thā ba là phù hợp

Mô hình <dùng riêng cơ sở dữ liệu= mang l¿i nhiều ưu điểm Trước hết, nó đảm bảo mát sự kết nái lßng lẻo giữa các dßch vụ, điều đó có nghĩa là nếu có mát sự thay đổi á cơ sá dữ liệu cÿa mát dßch vụ này thì nó sẽ không tác đáng tới dßch vụ khác Ngoài ra, mßi mát dßch vụ có thể linh ho¿t trong việc lựa chán mát lo¿i cơ sá dữ liệu phù hợp cho mình tùy theo yêu cầu về mặt kỹ thuật, bài toán nghiệp vụ cũng như khả năng chi phí

Sự bất tiện cÿa mô hình này thể hiện á mát sá điểm sau:

• Các tác vụ thực hiện trải dài trên nhiều dßch vụ, mßi dßch vụ sử dụng mát cơ sá dữ liệu riêng biệt, do đó việc quản lý các giao dßch trá thành mát thách thāc

• Trưßng hợp cần phải truy vấn, kết nái để lấy dữ liệu từ nhiều cơ sá dữ liệu khác nhau sẽ tán nhiều công và việc thực hiện không dễ dàng

• Tán công và tăng đá phāc t¿p trong việc quản lý cũng như vận hành nhiều cơ sá dữ liệu

Dùng chung c¢ så dă lißu

Mô hình <dùng riêng cơ sở dữ liệu= bác lá những ưu và khuyết điểm như đã thảo

luận á trên Để áp āng linh ho¿t hơn trong triển khai hệ tháng, ngưßi ta còn đưa vào mát mô hình nữa gái là <dùng chung cơ sở dữ liệu= [12] Trong mô hình này, các microservices sử dụng chung mát cơ sá dữ liệu, và cơ sá dữ liệu này sẽ được chia nhß cho các dßch vụ khác nhau bằng cách phân tách theo các bảng Sơ đồ trong hình 1.9 minh háa cách dùng chung mát cơ sá dữ liệu cho ba microservices

Nhiều ý kiến cho rằng hình thāc dùng chung cơ cá dữ liệu là mát cách tiếp cận đi ngược l¿i nguyên tắc cÿa microservices Tuy nhiên, đây được xem là mát hình thāc khá tát và nó thực sự giải quyết được nhiều bài toán do những thuận tiện mà nó mang l¿i như: việc quản lý và vận hành mát cơ sá dữ liệu đơn lẻ sẽ đơn giản và ít tán kém, các giao dßch được quản lý tập trung sẽ hiệu quả và dễ dàng hơn việc quản lý các giao dßch phân tán

19

Hình 1.9 Mô hình dùng chung cơ sở dữ liệu

H¿n chế cÿa việc sử dụng chung cơ sá dữ liệu thể hiện á các điểm sau đây:

Thā nhất, các dßch vụ phụ thuác chặt với nhau vì cùng chung mát cơ sá dữ liệu Mßi khi có mát thay đổi á mát lược đồ dữ liệu này có thể gây tác đáng tới nhiều dßch vụ khác vì chúng truy xuất trực tiếp vào các bảng trong cùng mát cơ sá dữ liệu

Thā hai, vì dùng cùng mát cơ sá dữ liệu, nên nhiều tác vụ giao dßch sẽ bß tác đáng, can thiệp lẫn nhau

Thā ba, thực tế triển khai các hệ tháng á doanh nghiệp cho thấy rằng các yêu cầu về nghiệp vụ luôn lớn và phāc t¿p, điều đó làm gia tăng nhu cầu về lưu trữ cũng như truy cập dữ liệu Vì thế, việc chỉ sử dụng mát cơ sá dữ liệu chung cho tất cả các dßch vụ là mát điều khó khả thi và sẽ đem l¿i nhiều rÿi ro cho hệ tháng

1.3 Nguyên tÅc thi¿t k¿ microservices

Để thiết kế và triển khai mát hệ tháng microservices hiệu quả, chúng ta cần tuân thÿ nhiều nguyên tắc ví dụ như lựa chán các mẫu thiết kế phù hợp, hay sử dụng các công nghệ thích hợp cho dự án Trong phần này, luận văn tập trung nhấn m¿nh vào mát sá nguyên tắc thiết kế quan tráng cần được áp dụng khi xây dựng āng dụng theo hướng microservices

1.3.1 ĐÁm bÁo tính đ¢n nhißm

Mßi mát microservice sẽ chỉ chßu trách nhiệm cho mát chāc năng cụ thể trong miền nghiệp vụ mà nó đảm nhiệm Điều đó có nghĩa là các microservices phải được đóng gói theo từng miền chāc năng cÿa hệ tháng Tính đơn nhiệm là yêu cầu cát lõi không chỉ trong việc thiết kế kiến trúc microservices mà nó còn là mát tiêu chuẩn để đảm bảo có được mát bản thiết kế lớp tát trong các phương pháp thiết kế và lập trình nói chung

20

1.3.2 Áp dāng ph°¢ng pháp thi¿t k¿ h°áng miÁn

Kỹ thuật thiết kế theo miền, thuật ngữ gái là <Domain Driven Design= (DDD) được sử dụng để giải quyết các vấn đề phāc t¿p trong thiết kế và phát triển phần mềm DDD được áp dụng dựa trên các miền nghiệp vụ cÿa bài toán Đề cập tới kỹ thuật này, tác giả Eric Evans nhấn m¿nh vào ba nguyên tắc cát lõi sau [13]:

• DDD tập trung chính vào miền nghiệp vụ cũng như các miền logic nghiệp vụ cát lõi cÿa bài toán

• Các bản thiết kế phāc hợp đều dựa trên các mô hình cÿa miền

• Khi áp dụng DDD, cần có sự cáng tác giữa các chuyên gia về nghiệp vụ cũng như các đái ngũ chuyên môn kỹ thuật nhằm giải quyết các bài toán liên quan Hệ tháng microservices được tổ chāc và xây dựng dựa trên các chāc năng cÿa miền nghiệp vụ cho từng bài toán Mßi mát microservice đ¿i diện cho mát chāc năng nghiệp vụ trong mát miền xác đßnh Sử dụng DDD cho phép các nhà phát triển có thể phân rã chāc năng hệ tháng thành nhiều miền khác nhau Công đo¿n thiết kế kiến trúc bao quanh các miền logic đem l¿i mát cách thāc tiếp cận tự nhiên và dễ dàng trong phân ho¿ch, quản lý các module cÿa chương trình

Trong khuôn khổ cÿa luận văn, tác giả không đi sâu vào trình bày phương pháp và các kỹ thuật cụ thể cÿa DDD à đây, tác giả chỉ tóm lược l¿i mát sá thuật ngữ cát lõi được sử dụng trong phương pháp DDD [14]

• Ngữ cảnh riêng (bounded context): là thành phần trung tâm cÿa DDD Nó

quản lý tập hợp các miền, và là nơi để đßnh nghĩa ra các miền cũng như các miền con

• Logic miền (domain logic): liên quan tới các quy tắc nghiệp vụ cÿa bài toán

Logic miền là nơi mà các quy tắc nghiệp vụ cÿa bài toán cần xác đßnh các tác vụ như t¿o, lưu trữ hay cập nhật dữ liệu

• Mô hình miền (domain model): chāa các thông tin, tri thāc cũng như dữ liệu

và các mẫu thiết kế mà chúng ta cần để giải quyết bài toán

• Miền con (subdomain): mßi mát miền sẽ được phân rã thành các miền con để

tham chiếu đến các phần khác nhau trong logic nghiệp vụ bài toán

• Mẫu thiết kế (design patterns): cung cấp các giải pháp chung nhất nhằm giải

quyết các vấn đề phổ quát, lặp đi lặp l¿i

Hình 1.10 minh háa các đái tượng cơ bản cÿa mát hệ tháng quản lý bán hàng Các đái tượng miền á đây bao gồm đơn hàng (order), khách hàng (customer) và sản phẩm (product)

21

Hình 1.10 Miền nghiệp vụ hệ thống quản lý bán hàng

Sau khi phân rã các miền nghiệp vụ, mßi mát microservice sẽ được thiết kế để đảm bảo thực hiện các nhiệm vụ bao quanh miền nghiệp vụ cÿa nó Hình 1.11 minh háa tổng quát kiến trúc cho mát module (order microservice) được tổ chāc thành ba thành phần chính bao gồm:

• Lớp ứng dụng (application layer): kết xuất dữ liệu cÿa hệ tháng và xuất bản

ra cho phía ngưßi dùng thông qua các Web API

• Lớp miền nghiệp vụ (model layer): đóng gói các quy tắc nghiệp vụ, các thực

thể liên quan đến miền nghiệp vụ và cả các đái tượng thực hiện việc trung chuyển dữ liệu (data transfer object)

• Lớp hạ tầng (infrastructure layer): chßu trách nhiệm lưu trữ dữ liệu thông qua

các kỹ thuật như ORM9 và có thể đảm nhiệm các tác vụ khác như ghi nhật ký (logging) hay mã hóa dữ liệu

Hình 1.11 Tổ chức của một microservice

9 https://docs.oracle.com/cd/E13189_01/kodo/docs341/ref_guide_mapping.html

22

Sử dụng DDD là mát phương pháp hữu hiệu để phân ho¿ch các bài toán lớn, có đá phāc t¿p cao Trong việc thiết kế microservices, áp dụng DDD cho phép đảm bảo được tính đóng gói, đơn nhiệm và giảm thiểu sự phụ thuác chặt chẽ giữa các module

1.3.3 Sā dāng các chu¿n vÁ API

Công đo¿n thiết kế các API cho các dßch vụ cần phải được tháng nhất trong việc sử dụng các chuẩn hóa về quy tắc thiết kế nhằm đảm bảo sự thông suát trong giao tiếp giữa các microservices với nhau, cũng như sự giao tiếp giữa phía sử dụng dßch vụ và các microservices Thêm vào đó, việc tích hợp cũng như trao đổi giữa các hệ tháng khác nhau trên các nền tảng công nghệ, ngôn ngữ lập trình khác nhau sẽ thuận tiện hơn nếu chúng ta có mát cơ chế tháng nhất về việc thiết kế các API Hiện nay, mát sá chuẩn như OpenAPI10 hay Standard Rest11 đều đưa ra các đặc tả cũng như các tiêu chuẩn về việc thiết kế API và được sử dụng ráng rãi

Tóm l°ÿc ch°¢ng 1

Kết thúc chương 1, luận văn đã tập trung làm rõ phương pháp phát triển āng dụng theo hướng microservices trên các ph¿m trù như đặc điểm cÿa kiến trúc, việc áp dụng các mẫu thiết kế phổ biến cũng như các nguyên tắc thiết kế Để tóm lược l¿i các đặc trưng cÿa microservices so với kiến trúc nguyên khái và SOA, phần so sánh được thể hiện trong bảng 1.1

10 https://www.openapis.org/ 11 https://standards.rest/

23

Bảng 1.1 So sánh kiến trúc nguyên khối, SOA và microservices

Tiêu chí Ki¿n trúc nguyên khßi Ki¿n trúc SOA Ki¿n trúc microservices

Cấu trúc āng

dụng Các thành phần trong mát āng dụng được đóng gói thành mát khái duy nhất

Nhiều chương trình āng dụng chia sẻ các dßch vụ với nhau

Hệ tháng được chia tách thành nhiều dßch vụ nhß, ho¿t đáng đác lập với nhau

Triển khai Đóng gói chương trình thành mát đơn vß duy nhất triển khai trên mát máy

Hệ tháng có thể gồm nhiều dßch vụ, ho¿t đáng phụ thuác lẫn nhau, triển khai phân tán

Các dßch vụ ho¿t đáng riêng rẽ, không phụ thuác lẫn nhau, triển khai phân tán

Tính má ráng H¿n chế khi má ráng, nếu má ráng sẽ ảnh hưáng tới toàn bá āng dụng

Dễ má ráng hơn, có thể má ráng theo hướng thêm bớt các dßch vụ nhưng vẫn bß ảnh hưáng bái sự phụ thuác chặt giữa các thành phần

Đáp āng linh ho¿t sự má ráng

Lưu trữ dữ

liệu Dùng chung mát cơ sá dữ liệu Dùng chung mát cơ sá dữ liệu Sử dụng riêng cơ sá dữ liệu Ngôn ngữ lập

trình, công nghệ phát triển

Chỉ dùng mát ngôn ngữ và mát lo¿i công nghệ nhất đßnh

Thưßng sử dụng mát ngôn ngữ và mát lo¿i công nghệ

Mßi mát microservice có thể dùng mát ngôn ngữ lập trình và mát công nghệ riêng biệt Nhóm phát

triển Mát nhóm phụ trách toàn bá āng dụng Nhiều nhóm cùng phát triển và chia sẻ về chuyên môn

Các nhóm đác lập phát triển cho từng module, phụ trách công việc từ đầu đến cuái chu trình phát triển sản phẩm

2.1 S¢ l°ÿc vÁ mßt sß mô hình phát triÃn āng dāng web phổ bi¿n

Từ những năm 90, công nghệ làm web bắt đầu ra đßi và phát triển Trải qua mát khoảng thßi gian dài với rất nhiều sự thay đổi trong mô hình lập trình cũng như các dòng công nghệ web khác nhau, cho tới nay āng dụng web vẫn đóng vai trò là mát thành phần quan tráng, không thể thay thế trong lĩnh vực lập trình āng dụng Trước khi tìm hiểu về micro-frontends, mát sá mô hình phát triển āng dụng web truyền tháng sẽ được giới thiệu mát cách tổng quát

2.1.1 Mô hình web t*nh

Có thể nói, khái niệm <web tĩnh= là yếu tá đầu tiên và cũng là mô hình khái đầu trong việc xây dựng āng dụng web Trong mô hình này, HTML được sử dụng để thiết kế và hiển thß nái dung cho trang web Sá dĩ gái là web tĩnh vì mßi khi ngưßi dùng gửi yêu cầu tới máy chÿ web, trang HTML tương āng sẽ được tải về và hiển thß nái dung á phía trình duyệt, ngưßi dùng sẽ không thể thực hiện mát tương tác nào với trang web Mô hình web tĩnh đơn giản, tán ít chi phí cho việc phát triển cũng như vận hành, và nó chỉ phù hợp cho mát sá yêu cầu cơ bản cÿa ngưßi dùng Mát ví dụ đơn giản về mô hình web tĩnh được minh háa trong hình 2.1

Hình 2.1 Mô hình web tĩnh [15]

2.1.2 Mô hình web đßng

Web đáng cho phép nái dung cÿa trang web sẽ được thay đổi tùy theo yêu cầu cÿa phía ngưßi dùng Thông thưßng, ngưßi ta tổ chāc thông tin cÿa trang web thành các cơ sá dữ liệu để lưu trữ và xử lý Hệ tháng sẽ có các tính năng để cập nhật các nái dung

• Ngưßi dùng gửi yêu cầu đến máy chÿ web để triệu gái trang login.jsp

• Máy chÿ web tiếp nhận, xử lý yêu cầu và gửi trả l¿i cho ngưßi dùng mát phản hồi - chính là nái dung cÿa trang login.html

Mô hình web đáng cho phép ngưßi sử dụng tương tác với āng dụng để gửi và nhận các yêu cầu Web đáng đã và đang được sử dụng ráng rãi nhß vào những lợi ích thiết thực mà nó mang l¿i như thông tin cÿa web dễ dàng được cập nhật, nâng cao tính tương tác với ngưßi dùng cũng như đáp āng được các yêu cầu bài toán thực tế cÿa doanh nghiệp

2.1.3 Mô hình SPA

Trong mô hình web truyền tháng á trên, mßi khi ngưßi dùng gửi mát yêu cầu lên phía máy chÿ web, máy chÿ web tiếp nhận, xử lý yêu cầu và gửi l¿i cho phía ngưßi dùng nái dung trang web bao gồm các thành phần như HTML, CSS, JavaScript cùng với dữ liệu Phía máy chÿ làm tất cả mái nhiệm vụ để phục vụ cho bên ngưßi dùng Mô hình ho¿t đáng này được gái là <kết xuất phía máy chủ= hay <server-side rendering= (SSR) [16] à đây, mßi khi ngưßi dùng chuyển từ mát trang web này sang mát trang web khác, toàn bá nái dung cÿa trang mới sẽ được n¿p l¿i từ đầu và nó sẽ làm ảnh hưáng

12 https://www.oracle.com/java/technologies/jspt.html

26

đến băng thông cÿa hệ tháng cũng như tính trải nghiệm ngưßi dùng Để giải quyết mát sá vấn đề gặp phải như việc n¿p l¿i toàn bá trang hay cần nâng cao tính tương tác cÿa ngưßi dùng, ngưßi ta đưa ra mát kỹ thuật lập trình có tên là Ajax [17], được sử dụng kết hợp với mát sá thư viện lập trình bằng JavaScript như Jquery Tuy nhiên, tất cả những thay đổi này vẫn chưa thể đáp āng đÿ các yêu cầu ngày càng cao cÿa āng dụng web Thêm vào đó, mô hình SSR bác lá khá nhiều nhược điểm và cần mát phương pháp khác để thay thế

Nhằm giảm thiểu gánh nặng cho việc xử lý phía máy chÿ, mô hình <kết xuất phía

máy khách= hay <client-side rendering= (CSR) ra đßi [18] Trong mô hình CSR, các tác

vụ như t¿o nái dung trang HTML, xử lý và hiển thß dữ liệu cũng như điều hướng trang

được thực hiện á phía trình duyệt Āng dụng web theo cơ chế này được gái là <ứng

dụng một trang= hay <single-page application= (SPA) [19] Nói mát cách ngắn ngán,

SPA cho phép tất cả các thao tác cÿa ngưßi dùng được thực hiện trên mát trang duy nhất, và cấu trúc cÿa mát trang web sẽ được n¿p mát lần mà không cần n¿p l¿i kể cả khi thực hiện chuyển trang

Khi dùng SPA, mô hình phổ biến được sử dụng hiện nay là việc tách biệt giữa hai phần:

• Phần dịch vụ: tập trung xử lý các logic về nghiệp vụ, tiếp nhận các yêu cầu

từ phía giao diện, xử lý các yêu cầu và gửi trả l¿i dữ liệu cho phía giao diện thông qua các Web API

• Phần giao diện (SPA): tiếp nhận dữ liệu trả về từ phía dßch vụ, sử dụng dữ

liệu này để kết xuất ra nái dung hiển thß cho trang web

Với cách thāc này, ngưßi ta đã tách được āng dụng thành hai phần riêng biệt Sơ đồ trong hình 2.3 mô tả nguyên lý ho¿t đáng cÿa mô hình CSR

Hình 2.3 Cơ chế hoạt động của mô hình CSR

27 Cơ chế CSR được diễn giải như sau:

• Lần đầu tiên khi có yêu cầu gửi tới máy chÿ web, nái dung cÿa toàn bá trang HTML được n¿p về phía trình duyệt

• à những lần tiếp theo, khi có yêu cầu chuyển trang hoặc thực hiện mát tác vụ nào đó, máy khách sẽ gửi các yêu cầu Ajax lên máy chÿ web Máy chÿ tiếp nhận, xử lý yêu cầu này và gửi l¿i dữ liệu cần thiết cho phía máy khách • Phía máy khách nhận dữ liệu trả về và thực hiện việc cập nhật các phần nái

dung trên trang web bằng cách sử dụng JavaScript và DOM để tương tác với tài liệu HTML Dữ liệu thay đổi phần nào thì sẽ cập nhật l¿i phần đó, mà không cần phải n¿p l¿i toàn bá trang như trong mô hình web truyền tháng Phát triển web theo hướng SPA hiện nay đang là mát xu thế Nhiều hãng công nghệ lớn trên thế giới như Google, Facebook đều lựa chán SPA để t¿o ra những āng dụng web nhằm tận dụng tái đa những lợi ích mà nó đem l¿i, đồng thßi làm tăng tính trải nghiệm cho ngưßi dùng

2.2 Ki¿n trúc micro-frontends

Mßi mát mô hình web như đã thảo luận á trên đều có các ưu nhược điểm riêng, nhưng nhìn chung l¿i, āng dụng web được t¿o ra theo các hướng này đều mang đặc điểm cÿa kiến trúc nguyên khái Những mặt h¿n chế cÿa kiến trúc nguyên khái nói chung đã được trình bày trong chương 1 cÿa luận văn

Trong phần 2 cÿa chương 2, luận văn tập trung vào giải thích đặc điểm, cơ chế cÿa micro-frontends, mát hướng kiến trúc mới áp dụng cho việc phát triển āng dụng web

2.2.1 Tổng quan vÁ micro-frontends

<Micro-frontends= là mát thuật ngữ xuất hiện còn khá sớm Thuật ngữ này được đưa

ra lần đầu vào năm 2016, trong mát bài báo với tiêu đề <Micro-frontends=, được đăng

trên trang cÿa ThoughtWorks vào ngày 07/11/2016 [20] Mát cách tóm lược, frontends là mát hướng kiến trúc mà nó được phát triển từ tư tưáng cÿa microservices để áp dụng cho āng dụng phía giao diện Do vậy, nhiều ngưßi còn cho rằng micro-frontends thực chất là microservices cho tầng giao diện

micro-Trước khi đi vào tìm hiểu cụ thể về micro-frontends, chúng ta cùng điểm l¿i các mô hình triển khai āng dụng web phổ biến từ trước đến giß qua ví dụ bên dưới

Ba cách triển khai mát āng dụng web được mô tả trong hình 2.4 (từ trái qua phải):

• Kiểu 1: dùng kiến trúc nguyên khái, tầng giao diện và tầng dßch vụ chung mát

khái

• Kiểu 2: tách biệt hai tầng giao diện và dßch vụ Tầng dßch vụ vẫn là kiến trúc

nguyên khái

28

• Kiểu 3: tầng giao diện tách biệt, tương tác với các microservices thông qua

cổng API

Hình 2.4 Ba mô hình triển khai web truyền thống

à cả ba mô hình web trong hình 2.4, āng dụng tầng giao diện vẫn thưßng được sử dụng là kiểu āng dụng nguyên khái Với cách tiếp cận mới, micro-frontends hướng vào việc chuyển đổi āng dụng web nguyên khái, từ mát kiến trúc sử dụng chung mát cấu trúc mã nguồn duy nhất sang mát kiến trúc được kết hợp bái nhiều āng dụng phía giao diện

Tư tưáng cát lõi trong cách tiếp cận cÿa micro-frontends là tập trung vào việc xây dựng mát āng dụng web như là mát tập hợp cÿa nhiều thành phần con, các thành phần này được xây dựng bái các đái ngũ lập trình khác nhau Thực ra, tư tưáng này không mới, và nó cũng có nhiều điểm tương đồng với cách tiếp cận cÿa microservices Tuy nhiên, việc đưa ý tưáng này để áp dụng cho phần giao diện thì vẫn còn khá xa l¿ so với các mô hình làm web truyền tháng trước đây, bái các ph¿m trù liên quan đến micro-frontends mới chỉ xuất hiện trong khoảng thßi gian từ 5 đến 6 năm trá l¿i đây

Để hiểu rõ hơn về cách tiếp cận cÿa micro-frontends, chúng ta xem xét mát ví dụ sau

Hình 2.5 mô tả giao diện mát trang thông tin sản phẩm cÿa mát web bán hàng Bá cục cÿa trang này gồm ba thành phần: <Search= – thực hiện tính năng tìm kiếm sản phẩm, <Product List= – hiển thß danh sách sản phẩm và <Product Details= – hiển thß thông tin chi tiết cÿa mát sản phẩm mßi khi ngưßi dùng chán vào mát sản phẩm bên phần <Product List=

29

Hình 2.5 Trang thông tin sản phẩm của một web bán hàng

Theo hướng tiếp cận cÿa micro-frontends, để xây dựng trang thông tin sản phẩm á

trên, ngưßi ta sẽ phát triển riêng biệt ba thành phần: <Search=, <Product List= và <Product Details= Ba module này là ba āng dụng riêng biệt, được giao cho ba đái phát

triển, mßi đái có thể lựa chán các công nghệ khác nhau tùy theo thế m¿nh cÿa mình Sau khi xây dựng xong, các module này sẽ được tích hợp l¿i để làm thành mát trang hiển thß thông tin sản phẩm hoàn thiện

Hình 2.6 Ba module riêng biệt của trang danh sách sản phẩm

Đái với nhóm phát triển, chúng ta thấy rằng công việc được phân phái cho từng đái với tính chuyên môn hóa rõ ràng Mßi đái phụ trách mát phần việc chuyên biệt, và nhß đó tác đá xây dựng sản phẩm được đẩy lên cao do giảm được sự phụ thuác chặt giữa các thành phần

Như vậy, micro-frontends là mát hướng kiến trúc được đề xuất cho sự phát triển āng dụng web mà á đó ngưßi ta phân tách mát āng dụng theo hướng nguyên khái thành nhiều thành phần con Các thành phần này được xây dựng, phát triển đác lập và tích hợp l¿i để t¿o thành mát hệ tháng tổng thể Kế thừa tư tưáng cÿa microservices, các