Trong thế giới kỹ thuật số có nhịp độ nhanh ngày nay, nơi tính linh hoạt và khả năng mở rộng là rất quan trọng, các doanh nghiệp không ngừng tìm cách cải thiện hiệu suất và khả năng bảo trì của các ứng dụng web của họ.
Một cách tiếp cận phổ biến để đạt được những mục tiêu này là chuyển từ kiến trúc nguyên khối sang kiến trúc phân tán (hoặc vi giao diện người dùng). Chuỗi bài viết này, "Hành trình di chuyển micro-frontend", chia sẻ kinh nghiệm cá nhân của tôi khi thực hiện quá trình di chuyển như vậy trong thời gian làm việc tại AWS.
TUYÊN BỐ TUYÊN BỐ TRÁCH NHIỆM : Trước khi bắt đầu, điều quan trọng cần lưu ý là mặc dù bài viết này chia sẻ trải nghiệm cá nhân của tôi nhưng tôi không thể tiết lộ bất kỳ chi tiết nội bộ hoặc sở hữu độc quyền nào về các công cụ, công nghệ hoặc quy trình cụ thể tại AWS hoặc bất kỳ tổ chức nào khác.
Tôi cam kết tôn trọng các nghĩa vụ pháp lý và đảm bảo rằng bài viết này chỉ tập trung vào các khái niệm và chiến lược chung liên quan đến hành trình di chuyển giao diện người dùng vi mô.
Mục đích là để cung cấp thông tin chi tiết và bài học kinh nghiệm có thể áp dụng trong bối cảnh rộng hơn mà không tiết lộ bất kỳ thông tin bí mật nào.
Tôi đã tìm hiểu về giao diện người dùng vi mô (tôi đoán là nhiều người trong số các bạn) từ bài viết trên blog của Martin Fowler. Nó trình bày các cách khác nhau để soạn kiến trúc giao diện người dùng vi mô theo cách không thể tin được vào khung.
Khi tìm hiểu sâu hơn về chủ đề này, tôi nhận ra rằng kiến trúc nguyên khối hiện tại của chúng tôi đang trở thành nút cổ chai đáng kể đối với năng suất của nhóm chúng tôi và cản trở hiệu suất tổng thể của ứng dụng của chúng tôi.
Một trong những yếu tố chính thúc đẩy tôi cân nhắc di chuyển là kích thước gói ngày càng tăng của ứng dụng của chúng tôi.
Sau khi tiến hành phân tích gói kỹ lưỡng vào mùa hè năm 2020, tôi phát hiện ra rằng kể từ lần ra mắt đầu tiên vào đầu năm 2019, kích thước gói (gzipped) đã tăng từ 450 KB lên 800 KB (gần 4 MB được phân tích cú pháp) - gần gấp đôi kích thước ban đầu.
Xem xét sự thành công của dịch vụ của chúng tôi và dự đoán sự tăng trưởng liên tục của nó, rõ ràng là xu hướng này sẽ tiếp tục ảnh hưởng đến hiệu suất và khả năng bảo trì của ứng dụng của chúng tôi.
Mặc dù rất hào hứng với khái niệm giao diện vi mô, nhưng tôi cũng nhận ra rằng chúng tôi chưa sẵn sàng áp dụng chúng do những thách thức cụ thể mà chúng tôi gặp phải:
Cơ cấu tổ chức nhỏ: Vào thời điểm tôi phân tích, tổ chức của chúng tôi tương đối nhỏ và tôi là kỹ sư giao diện người dùng toàn thời gian duy nhất trong nhóm. Việc di chuyển sang kiến trúc giao diện người dùng vi mô cần một khoản đầu tư đáng kể về cơ cấu tổ chức và nền tảng hoạt động.
Điều quan trọng là phải có một cấu trúc trưởng thành có thể xử lý hiệu quả kiến trúc phân tán và phản ánh sự phụ thuộc giữa các thành phần giao diện người dùng khác nhau.
Miền kinh doanh hạn chế: Mặc dù giao diện người dùng vi mô có thể được phân chia dựa trên bối cảnh giới hạn và khả năng kinh doanh (tìm hiểu thêm trong bài đăng “ Thiết kế theo hướng miền trong kiến trúc giao diện người dùng vi mô” ) miền kinh doanh cốt lõi của chúng tôi không đủ rộng để biện minh cho việc tách hoàn toàn thành nhiều giao diện vi mô. Tuy nhiên, có những ranh giới có thể nhìn thấy được trong ứng dụng nên cần phải khắc phục và chuyển đổi sang kiến trúc phân tán.
Xem xét các yếu tố này, tôi nhận ra rằng một cách tiếp cận dần dần là cần thiết. Thay vì di chuyển hoàn toàn sang giao diện người dùng vi mô, tôi nhằm mục đích xác định các khu vực cụ thể trong ứng dụng của chúng tôi có thể hưởng lợi từ kiến trúc phân tán.
Điều này sẽ cho phép chúng tôi giải quyết các vấn đề về hiệu suất và khả năng mở rộng mà không làm gián đoạn cấu trúc tổ chức tổng thể hoặc ảnh hưởng đến tính toàn vẹn của miền kinh doanh của chúng tôi. Nó cũng sẽ cho chúng tôi một khoảng thời gian để phát triển nhóm và quan sát các hướng kinh doanh.
Xin lưu ý rằng nếu bạn chỉ muốn giải quyết vấn đề về hiệu suất (kích thước gói) của ứng dụng thông qua việc sử dụng kiến trúc mciro-frontend, thì đó có thể không phải là ý tưởng hay nhất. Thay vào đó, sẽ tốt hơn nếu bắt đầu với kiến trúc nguyên khối phân tán sẽ tận dụng tải chậm (nhập động).
Hơn nữa, tôi nghĩ rằng nó sẽ xử lý các vấn đề về kích thước gói một cách nhẹ nhàng hơn so với kiến trúc giao diện người dùng vi mô vì kiến trúc giao diện người dùng vi mô rất có thể có một số mã được chia sẻ sẽ không được tách thành các khối của nhà cung cấp và nó sẽ được tích hợp vào gói ứng dụng ( đó là một trong những nhược điểm của kiến trúc phân tán như vậy — bạn cần phải đánh đổi giữa nội dung chia sẻ, thời điểm và cách thức chia sẻ).
Tuy nhiên, kiến trúc nguyên khối phân tán sẽ không mở rộng quy mô cũng như giao diện người dùng vi mô. Khi tổ chức của bạn phát triển nhanh chóng, nhóm của bạn cũng sẽ phát triển với tốc độ tương tự.
Sẽ có một nhu cầu thiết yếu là chia cơ sở mã thành các khu vực sở hữu khác nhau do các nhóm khác nhau kiểm soát.
Và mỗi nhóm sẽ cần có các chu kỳ phát hành riêng độc lập với các nhóm khác, mỗi nhóm sẽ đánh giá cao nếu cơ sở mã của họ hoàn toàn tập trung vào miền của họ và sẽ xây dựng nhanh (cách ly mã -> khả năng bảo trì tốt hơn/ít mã hơn để duy trì và build -> khả năng kiểm tra tốt hơn/ít kiểm tra hơn để duy trì và thực thi).
Để thu hút sự hỗ trợ từ ban lãnh đạo, tôi đã soạn thảo một tài liệu tầm nhìn kỹ thuật thuyết phục bao gồm phân tích hiệu suất toàn diện, bao gồm các số liệu quan trọng về web và phác thảo các giai đoạn khác nhau của quá trình di chuyển sang giao diện người dùng phân tán.
Một trong những giai đoạn trung gian của quá trình di chuyển này là thiết lập kiến trúc nguyên khối phân tán, trong đó nhiều mô-đun/tiện ích con có thể được phân phối không đồng bộ thông qua các kỹ thuật tải chậm trong khi tận dụng cơ sở hạ tầng dùng chung, chẳng hạn như bộ chứa S3 và CDN, giữa dịch vụ cốt lõi và tiện ích con .
Như tôi đã trình bày trong bài viết trước, ý tưởng chính của loại tài liệu này là mô tả tương lai mà bạn mong muốn sau khi các mục tiêu đã đạt được và các vấn đề lớn nhất được giải quyết. Nó không phải là về kế hoạch thực hiện!
Gần 1 năm sau, cuối cùng đã đến lúc thực hiện kế hoạch di chuyển micro-frontend của tôi. Với việc sắp mở rộng sang một miền mới và một nhóm lớn hơn theo ý của chúng tôi, chúng tôi đã được trang bị đầy đủ để thực hiện việc di chuyển.
Nó giống như một cơ hội vàng mà chúng tôi không thể bỏ lỡ.
Xét cho cùng, việc bị giới hạn trong kiến trúc nguyên khối có nghĩa là phải vật lộn vĩnh viễn với những hạn chế của nó.
Dòng thời gian hạn chế để mở rộng sang một miền mới đóng vai trò là chất xúc tác, thúc đẩy chúng tôi hướng tới việc xây dựng một kiến trúc có thể mở rộng và dễ bảo trì hơn ngay lập tức thay vì thực hiện các bước lặp lại ngắn và chậm!
Để thực hiện quá trình di chuyển và đồng thời xử lý công việc trong miền mới, chúng tôi đã chia các nhóm thành hai nhóm chuyên biệt. Tính năng hoạt động, có mức độ ưu tiên cao hơn, cần nhiều tài nguyên hơn và cần lặp lại với tốc độ nhanh hơn.
Để đảm bảo tính toàn vẹn và hiểu biết toàn diện về quy trình di chuyển, nên chỉ định một nhóm nhỏ chuyên trách chịu trách nhiệm cụ thể về việc xử lý quá trình di chuyển.
Tuy nhiên, chúng tôi không thể tiến hành công việc tính năng mà không đảm bảo trước rằng khái niệm giao diện người dùng vi mô sẽ chứng tỏ thành công.
Để giảm thiểu rủi ro và cung cấp một lộ trình rõ ràng, điều quan trọng là tạo ra một tài liệu thiết kế cấp thấp bao gồm các ước tính chính xác và đánh giá rủi ro kỹ lưỡng. Tài liệu này phục vụ như một kế hoạch chi tiết, vạch ra các bước cần thiết và cân nhắc cho việc di chuyển.
Cột mốc quan trọng trong quá trình này là sự phát triển của một bằng chứng về khái niệm sẽ chứng minh sự tích hợp thành công của tất cả các thành phần theo thiết kế.
Cột mốc quan trọng này, được đặt tên một cách khéo léo là “Điểm không thể quay lại”, nhằm mục đích xác thực tính khả thi và hiệu quả của kiến trúc giao diện người dùng vi mô.
Mặc dù tôi rất lạc quan về sự thành công của việc di chuyển, nhưng điều cần thiết là phải chuẩn bị cho các tình huống bất ngờ. Do đó, tôi nghĩ ra một Kế hoạch B, hoạt động như một chiến lược dự phòng trong trường hợp ý tưởng ban đầu không mang lại kết quả mong muốn.
Điều này bao gồm việc phân bổ thêm bảy ngày trong ước tính cụ thể để khiến tôi phải ôm gối khóc cộng thêm vài ngày để có một mục nhập mô-đun tính năng mới được kết nối với lõi thông qua quá trình tải chậm (bạn có nhớ nguyên khối được phân phối không?).
Khi thiết kế giao diện người dùng vi mô, nhìn chung có 3 cách tiếp cận bố cục, mỗi cách tập trung vào vị trí diễn ra quá trình phân giải ứng dụng thời gian chạy. Cái hay của những cách tiếp cận này là chúng không loại trừ lẫn nhau và có thể được kết hợp khi cần thiết.
Ý tưởng cơ bản là tận dụng một máy chủ proxy ngược để phân chia các gói giao diện người dùng vi mô trên mỗi trang và thực hiện tải lại trang cứng dựa trên URL tuyến đường.
Ưu điểm:
Nhược điểm:
Trạng thái chung sẽ không được đồng bộ hóa giữa các ứng dụng giao diện người dùng vi mô. Đây rõ ràng là một điểm không nên làm đối với chúng tôi vì chúng tôi đã thực hiện các hoạt động chạy nền lâu dài ở phía máy khách.
Bạn có thể lập luận rằng chúng tôi có thể duy trì ảnh chụp nhanh "hàng đợi" của thao tác này vào bộ nhớ cục bộ và đọc từ nó sau khi tải lại cứng, nhưng vì lý do bảo mật, chúng tôi không thể triển khai điều này.
Đây chỉ là một ví dụ về trạng thái toàn cầu, nhưng đây là một ví dụ khác về cách nó có thể trông như thế nào: trạng thái của bảng sidenav (mở rộng/thu gọn), thông báo bánh mì nướng, v.v.
Một cách tiếp cận khác đối với bố cục giao diện người dùng vi mô là bố cục bên cạnh, bao gồm việc kết hợp các giao diện người dùng vi mô ở lớp biên, chẳng hạn như CDN. Chẳng hạn, Amazon CloudFront hỗ trợ tích hợp Lambda@Edge , cho phép sử dụng CDN dùng chung để đọc và phân phát nội dung vi giao diện người dùng.
Ưu điểm:
Nhược điểm:
Thành phần phía máy khách là một cách tiếp cận khác đối với kiến trúc giao diện người dùng vi mô sử dụng các kỹ thuật điều phối giao diện người dùng vi mô phía máy khách, được tách rời khỏi triển khai máy chủ.
Trình phát chính trong kiến trúc này là một ứng dụng chứa (vỏ) có các trách nhiệm sau:
Ý tưởng chung là mỗi gói micro-frontend sẽ tạo ra 2 loại tệp nội dung:
{hash}/index.js: Đây đóng vai trò là điểm vào cho ứng dụng giao diện người dùng vi mô, với hàm băm đại diện cho một mã định danh duy nhất cho toàn bộ bản dựng.
Hàm băm hoạt động như một khóa tiền tố cho mỗi gói trong bộ chứa S3. Điều quan trọng cần lưu ý là có thể tồn tại nhiều điểm vào, nhưng hàm băm vẫn giữ nguyên cho tất cả chúng.
manifest.json: Đây là tệp kê khai chứa đường dẫn đến tất cả các điểm nhập cho ứng dụng giao diện người dùng vi mô. Tệp này sẽ luôn nằm trong thư mục gốc của bộ chứa S3, vì vậy bộ chứa có thể dễ dàng phát hiện ra nó.
Tôi khuyên bạn nên bật phiên bản của tệp này trong bộ chứa S3 để có thể quan sát các thay đổi tốt hơn. Nếu bạn đang sử dụng Webpack để xây dựng dự án của mình, tôi thực sự khuyên bạn nên sử dụng WebpackManifestPlugin để thực hiện tất cả các công việc nặng nhọc cho bạn.
Vùng chứa chỉ biết URL miền nguồn nội dung giao diện vi mô (nguồn gốc CDN) dựa trên giai đoạn và khu vực. Trong quá trình tải trang ban đầu, vùng chứa tải xuống tệp kê khai cho từng ứng dụng giao diện người dùng vi mô.
Tệp kê khai có kích thước rất nhỏ (~100 byte) để tránh ảnh hưởng đến thời gian tải trang và chia tỷ lệ tốt ngay cả khi tổng hợp nhiều giao diện người dùng vi mô trong một vùng chứa. Điều quan trọng là phải coi tệp kê khai là bất biến trong bộ lưu trữ bộ đệm của trình duyệt để ngăn bộ nhớ đệm tích cực.
Chọn đúng thư viện điều phối là thách thức lớn nhất trong thành phần này và sẽ được thảo luận trong chương sau.
Ưu điểm:
Nhược điểm:
Như tôi đã đề cập trước đó trong chương này, tất cả các mẫu bố cục này có thể được kết hợp và kết hợp trong cùng một ứng dụng trình bao. Đây là một ví dụ về những gì nó có thể trông giống như:
Tôi khuyên bạn nên bắt đầu với cách tiếp cận đồng nhất ngay từ đầu — chọn một mẫu bố cục phù hợp với bạn hơn và bắt đầu xây dựng cơ sở hạ tầng xung quanh nó.
Đối với chúng tôi, bố cục phía máy khách là lựa chọn tốt nhất, nhưng trong tương lai, chúng tôi đã cân nhắc việc chuyển đổi một số khu vực sang điều phối phía biên (dựa trên tính khả dụng của Lambda@Edge).
Khi nói đến việc triển khai thành phần phía máy khách trong kiến trúc giao diện người dùng vi mô, việc chọn thư viện điều phối phù hợp là một quyết định quan trọng.
Thư viện được chọn sẽ đóng một vai trò quan trọng trong việc quản lý tải động và điều phối các giao diện vi mô trong ứng dụng vùng chứa.
Một số thư viện phối hợp phổ biến tồn tại, mỗi thư viện có điểm mạnh và cân nhắc riêng.
Single-spa là một thư viện phối hợp được áp dụng rộng rãi, cung cấp cách tiếp cận linh hoạt và có thể mở rộng cho thành phần giao diện người dùng vi mô. Nó cho phép các nhà phát triển tạo một ứng dụng shell phối hợp tải và dỡ nhiều giao diện người dùng vi mô.
Single-SPA cung cấp khả năng kiểm soát chi tiết đối với các sự kiện trong vòng đời và hỗ trợ các khuôn khổ và công nghệ khác nhau.
Ưu điểm:
Nhược điểm:
Qiankun là một thư viện phối hợp mạnh mẽ được phát triển bởi nhóm Ant Financial (Alibaba). Nó sử dụng cách tiếp cận HTML một phần để sáng tác. Về phía ứng dụng giao diện người dùng vi mô, nó tạo ra một đoạn mã HTML đơn giản với tất cả các điểm nhập sẽ được tải.
Sau khi sử dụng tệp HTML này, bộ chứa sẽ thực hiện tất cả việc điều phối và gắn kết ứng dụng. Trong cấu hình này, một phần HTML đóng vai trò của tệp kê khai mà tôi đã nói ở chương trước.
Ưu điểm:
Nhược điểm:
Liên kết mô-đun , một tính năng do Webpack cung cấp, đã thu hút được sự chú ý và quảng cáo rầm rộ trong cộng đồng phát triển web. Công nghệ này cho phép các nhà phát triển chia sẻ mã giữa nhiều ứng dụng trong thời gian chạy, làm cho nó trở thành một tùy chọn hấp dẫn để xây dựng giao diện người dùng vi mô.
Với khả năng tích hợp liền mạch với Webpack và tính linh hoạt trong thời gian chạy, Liên kết mô-đun đã trở thành một lựa chọn phổ biến để quản lý và điều phối các giao diện người dùng vi mô.
Ưu điểm:
Nhược điểm:
Trong phần đầu tiên của loạt bài “Hành trình di chuyển giao diện người dùng vi mô”, chúng ta đã thảo luận về động lực đằng sau việc di chuyển từ một trang web nguyên khối sang một kiến trúc phân tán và các bước ban đầu được thực hiện để bán ý tưởng cho ban lãnh đạo.
Chúng tôi đã khám phá tầm quan trọng của tài liệu tầm nhìn kỹ thuật trình bày phân tích hiệu suất chi tiết và vạch ra các giai đoạn khác nhau của quá trình di chuyển.
Sau đó, chúng tôi đi sâu vào các cân nhắc thiết kế cho giao diện người dùng vi mô, thảo luận về ba cách tiếp cận: bố cục phía máy chủ, bố cục phía biên và bố cục phía máy khách.
Mỗi cách tiếp cận đều có ưu và nhược điểm và sự lựa chọn phụ thuộc vào nhiều yếu tố khác nhau như đồng bộ hóa trạng thái toàn cầu, trải nghiệm của khách hàng, độ phức tạp của cơ sở hạ tầng và bộ nhớ đệm.
Ngoài ra, chúng tôi đã khám phá các thư viện điều phối phổ biến, chẳng hạn như spa đơn, qiankun và Liên kết mô-đun, làm nổi bật các tính năng, lợi ích và thách thức tiềm năng của chúng.
Hãy tham gia cùng tôi trong các phần tiếp theo của loạt bài này khi chúng ta tiếp tục hành trình di chuyển đến giao diện người dùng vi mô, khám phá những thông tin chi tiết thú vị và có giá trị hơn trong suốt hành trình!
Được xuất bản lần đầu tại https://thesametech.com vào ngày 18 tháng 4 năm 2023.
Bạn cũng có thể theo dõi tôi trên Twitter và kết nối trên LinkedIn để nhận thông báo về các bài đăng mới!