Kiến trúc microservice được đặc trưng bởi các dịch vụ độc lập tập trung vào một chức năng kinh doanh cụ thể và được bảo trì bởi các nhóm nhỏ, độc lập. Kiến trúc microservice thường được sử dụng cho các ứng dụng web được phát triển trên AWS, vì nhiều lý do tốt. Chúng cung cấp nhiều lợi ích được biết đến như linh hoạt trong phát triển, tự do công nghệ, triển khai mục tiêu và nhiều hơn nữa. Mặc dù kiến trúc microservice phổ biến, nhiều ứng dụng frontend vẫn được xây dựng theo kiểu monolithic. Ví dụ, chúng có một cơ sở mã lớn tương tác với tất cả các microservice backend và được bảo trì bởi một đội ngũ lớn các nhà phát triển.
Hình 1. Phần phụ trợ microservice với monolith frontend
Micro-frontend là gì?
Kiến trúc micro-frontend giới thiệu các nguyên tắc phát triển microservice vào các ứng dụng frontend. Trong kiến trúc micro-frontend, các nhóm phát triển xây dựng và triển khai các ứng dụng frontend “con” độc lập. Các ứng dụng này được kết hợp bởi một ứng dụng frontend “cha” được sử dụng như một container để lấy, hiển thị và tích hợp các ứng dụng con khác nhau. Trong mô hình cha/con này, người dùng tương tác với những gì có vẻ như một ứng dụng đơn. Trong thực tế, họ đang tương tác với nhiều ứng dụng độc lập, được xuất bản bởi các nhóm khác nhau.
Hình 2. Phần phụ trợ microservice với micro-frontend
Lợi ích của Micro-frontend
So sánh với kiến trúc frontend monolith, kiến trúc micro-frontend cung cấp những lợi ích sau:
- Các tài liệu độc lập: Một nguyên tắc cốt lõi của việc phát triển microservice là các tài liệu có thể được triển khai độc lập, và điều này vẫn đúng đối với micro-frontend. Trong kiến trúc micro-frontend, các nhóm phát triển nên có thể triển khai các ứng dụng frontend của họ độc lập với tác động tối thiểu đến các dịch vụ khác. Những thay đổi đó sẽ được phản ánh bởi ứng dụng cha.
- Các nhóm độc lập: Mỗi nhóm là chuyên gia trong lĩnh vực của riêng mình. Ví dụ, các thành viên của nhóm dịch vụ thanh toán có kiến thức chuyên môn. Điều này bao gồm các mô hình dữ liệu, yêu cầu kinh doanh, các cuộc gọi API và tương tác người dùng liên quan đến dịch vụ thanh toán. Kiến thức này cho phép nhóm phát triển giao diện người dùng thanh toán nhanh hơn so với một nhóm lớn ít chuyên môn hơn.
- Tự do lựa chọn công nghệ: Sự độc lập cho phép mỗi nhóm lựa chọn công nghệ độc lập với các nhóm khác. Ví dụ, nhóm dịch vụ thanh toán có thể phát triển micro-frontend của họ bằng Vue.js và nhóm dịch vụ hồ sơ có thể phát triển giao diện người dùng của họ bằng Angular.
- Phát triển có thể mở rộng: Các nhóm phát triển micro-frontend nhỏ hơn và có thể hoạt động mà không làm gián đoạn các nhóm khác. Điều này cho phép chúng tôi nhanh chóng mở rộng phát triển bằng cách triển khai những nhóm mới để cung cấp các chức năng giao diện người dùng bổ sung thông qua các ứng dụng con.
- Dễ dàng bảo trì: Giữ các kho lưu trữ frontend nhỏ và chuyên môn cho phép chúng được hiểu dễ dàng hơn, và điều này đơn giản hóa việc bảo trì và kiểm thử dài hạn. Ví dụ, nếu bạn muốn thay đổi một tương tác trên một kiến trúc frontend monolith, bạn phải cô lập vị trí và phụ thuộc của tính năng đó trong ngữ cảnh của một cơ sở mã lớn. Loại hoạt động này được đơn giản hóa rất nhiều khi làm việc với các cơ sở mã nhỏ hơn liên quan đến micro-frontend.
Các thách thức của kiến trúc Micro-frontend.
Tuy nhiên, kiến trúc micro-frontend cũng đưa ra những thách thức sau:
- Tích hợp cha/con: Một kiến trúc micro-frontend đưa ra nhiệm vụ đảm bảo ứng dụng cha hiển thị ứng dụng con với tính nhất quán và hiệu suất tương tự như mong đợi từ một ứng dụng monolith. Điểm này sẽ được thảo luận thêm trong phần tiếp theo.
- Chi phí vận hành: Thay vì quản lý một ứng dụng frontend duy nhất, một ứng dụng micro-frontend có liên quan đến việc tạo và quản lý cơ sở hạ tầng riêng cho tất cả các nhóm.
- Trải nghiệm người dùng nhất quán: Để duy trì trải nghiệm người dùng nhất quán, các ứng dụng con phải sử dụng các thành phần UI, thư viện CSS, tương tác, xử lý lỗi và nhiều hơn nữa. Việc duy trì tính nhất quán trong trải nghiệm người dùng có thể khó khăn đối với các ứng dụng con ở các giai đoạn khác nhau trong vòng đời phát triển.
Xây dựng Micro-frontend
Thách thức khó khăn nhất với mô hình kiến trúc micro-frontend là tích hợp các ứng dụng con với ứng dụng cha. Ưu tiên trải nghiệm người dùng là rất quan trọng đối với bất kỳ ứng dụng frontend nào. Trong ngữ cảnh của micro-frontend, điều này có nghĩa là đảm bảo người dùng có thể dễ dàng điều hướng từ một ứng dụng con sang một ứng dụng khác trong ứng dụng cha. Chúng ta muốn tránh hành vi gây gián đoạn như làm mới trang hoặc đăng nhập nhiều lần. Trong định nghĩa cơ bản nhất của tích hợp cha/con, ứng dụng cha liên kết động và hiển thị các ứng dụng con khi ứng dụng cha được tải. Việc hiển thị ứng dụng con phụ thuộc vào cách mà ứng dụng con được xây dựng, và điều này có thể được thực hiện theo nhiều cách khác nhau. Hai trong số những phương pháp phổ biến nhất của tích hợp cha/con là:
- Xây dựng mỗi ứng dụng con như một thành phần web.
- Nhập mỗi ứng dụng con như một module độc lập. Các module này sẽ khai báo một hàm để tự hiển thị hoặc được nhập động bởi ứng dụng cha (như với module federation).
Đăng ký child apps làm thành phần web:
HTML
<html>
<head>
https://shipping.example.com/shipping-service.js
https://profile.example.com/profile-service.js
https://billing.example.com/billing-service.js
<title>Parent Application</title>
</head>
<body>
<shipping-service />
<profile-service />
<billing-service />
</body>
</html>Đăng ký child apps dưới dạng modules:
HTML
<html>
<head>
https://shipping.example.com/shipping-service.js
https://profile.example.com/profile-service.js
https://billing.example.com/billing-service.js
<title>Parent Application</title>
</head>
<body>
</body>
<script>
// Load and render the child applications form their JS bundles.
</script>
</html>Sơ đồ sau đây cho thấy một ví dụ về micro-frontend architecture được xây dựng trên AWS.
Hình 3. Micro-frontend architecture trên AWS
Trong ví dụ này, mỗi nhóm dịch vụ đang chạy một ngăn xếp độc lập, giống nhau để xây dựng ứng dụng của họ. Họ sử dụng các công cụ phát triển của AWS và triển khai ứng dụng lên Amazon Simple Storage Service (S3) với Amazon CloudFront. Các quy trình CI/CD sử dụng các thành phần chia sẻ như thư viện CSS, API wrappers hoặc các module tùy chỉnh được lưu trữ trong AWS CodeArtifact. Điều này giúp đảm bảo tính nhất quán cho các ứng dụng cha và con.
Khi bạn truy xuất ứng dụng cha, nó sẽ yêu cầu bạn đăng nhập vào nhà cung cấp danh tính và lấy JWT. Trong ví dụ này, nhà cung cấp danh tính là Amazon Cognito User Pool. Sau khi đăng nhập thành công, ứng dụng cha lấy các ứng dụng con từ CloudFront và hiển thị chúng bên trong ứng dụng cha. Hoặc, ứng dụng cha có thể chọn hiển thị các ứng dụng con khi bạn điều hướng đến một tuyến đường cụ thể. Các ứng dụng con không nên yêu cầu bạn đăng nhập lại vào nhà cung cấp người dùng Amazon Cognito. Chúng cần được cấu hình để sử dụng JWT được lấy bởi ứng dụng cha hoặc lấy một JWT mới từ Amazon Cognito một cách âm thầm.
Kết luận
Kiến trúc micro-frontend giới thiệu nhiều lợi ích quen thuộc của phát triển microservice cho các ứng dụng frontend. Một kiến trúc micro-frontend cũng đơn giản hóa quá trình xây dựng các ứng dụng frontend phức tạp bằng cách cho phép bạn quản lý các thành phần nhỏ độc lập.
Bài được dịch từ bài viết trên AWS Blogs, bạn có thể xem bài viết gốc tại đây.
AWS Study Group 