Migrate cấu trúc Monolith sang Google Kubernetes Engine (GKE) - Migrate theo stage

cloudFun

Bài viết này sẽ đi chi tiết qua toàn bộ hành trình migrate cấu trúc monolith sang microservice, quá trình, thứ tự và các migrate stage và cách xử lý data migration. Mỗi câu chuyện sẽ được gắn với case study thực tế mà một khách hàng thực sự đã trải qua những bước đó.
Capture.PNG

Dưới đây là tất cả các bài viết trong miniseries này.
Migrating a Monolith to GKE: Tổng quan
Migrating a monolith to GKE: Quá trình migrate
Migrate Monolith to GKE: Migrate theo stage
Migrate Monolith to GKE: Cần ưu tiên cái nào trước?
Migrate Monolith to GKE: Câu chuyện của khách hàng
Bài viết này sẽ chi tiết cách migrate một tính năng theo stage.

Các nội dung
• Cách chuẩn bị môi trường Google Cloud để migrate
• Cách phân tích sự phụ thuộc của các dịch vụ dự định migrate
• Cách migrate các tính năng từ enviroment đang dùng sang microservice environment dựa trên đám mây mới

Điều kiện tiên quyết
Trước khi bắt đầu, sẽ rất hữu ích nếu hiểu rõ những điều sau đây:
• Các khái niệm và cấu trúc cơ bản của Google Cloud để nhận ra tên của các sản phẩm.
• Xem lại các video trước trong loạt Get Cooking in Cloud series .

Hãy cùng CloudFUN xem video dưới đây:

Use-case giả định

The Ice-cream-theory, một cửa hàng kem trực tuyến (giả định). Họ đang trên hành trình migrate trang web kiến trúc monolith sang microservice và cần hướng dẫn trong việc chuyển dịch vụ mircoservice đầu tiên của họ sang GKE. Họ cũng có loại kem (tưởng tượng) tốt nhất trên hành tinh.

Trong số tất cả các tính năng họ có thể migrate (xem bài viết tiếp theo để biết thêm thông tin về cách xác định điều đó), họ đã quyết định chuyển giỏ hàng của mình từ ứng dụng monolith cũ sang GKE.

Nhìn chung, Ice-cream-theory được khuyến nghị sử dụng để migrate từng tính năng của trang web sang môi trường mới, tạo ra các microservices khi được yêu cầu. microservices đó có thể gọi lại hệ thống cũ khi cần.

Migrate theo stage như thế này có hai lợi thế:
1. Các dự án nhỏ hơn dễ làm việc hơn, giảm thiểu sai sót và sai lầm tốn kém.
2. Cho phép xử lý từng migrate riêng lẻ mà không bị quá tải.

Cùng CloudFUN xem cách làm nhé.

Trước hết: Chuẩn bị môi trường đám mây
1_1rEhC5hFqI1qZVOdLcugxQ.png


Mise en place
là một cluster từ ẩm thực của Pháp, có nghĩa là “đặt vào vị trí” hoặc “tất cả mọi thứ ở vị trí của nó” và đề cập đến việc thiết lập các bước chuẩn bị cần thiết trước khi nấu. Điều đó có nghĩa là cần đảm bảo môi trường sắp migrate đến được thiết lập đúng trước khi migrate các tính năng sang đó.
Source: https://pixabay.com/illustrations/cooking-baking-recipe-book-chef-hat-4206076/

Trước khi chuyển đổi tính năng thành microservice trên GKE, cần một nơi để đặt chúng. Vì vậy, môi trường Google Cloud cần được chuẩn bị sẵn sàng.

Điều đầu tiên cần chuẩn bị là Organization của Google Cloud.

Sau đó, cần đảm bảo chỉ những người được ủy quyền mới có thể truy cập tài nguyên bằng Policies của Google Cloud để kiểm soát quyền truy cập vào resources của Google Cloud.

Tiếp theo, đã đến lúc tạo ra một kế hoạch để triển khai tài nguyên, theo cách tiêu chuẩn hóa và có thể tái tạo, sử dụng cơ sở hạ tầng làm mã, sử dụng các công cụ như Deployment Manager và Terraform.

Tại thời điểm này, nhóm Ice-cream-theory được khuyến nghị nghiên cứu GKE và các tính năng của nó để có thể điều chỉnh chúng theo nhu cầu của họ. Điều này có nghĩa là thay đổi một số giá trị mặc định của GKE và tăng cường bảo mật cluster.

Sau khi GKE được thiết lập, đã đến lúc xây dựng CI / CD pipeline, sử dụng các công cụ như Spinnaker, Jenkins hoặc các sản phẩm Google Cloud như Cloud Build và Container Registry. Làm điều này sớm trong dự án sẽ tránh được các vấn đề trong quá trình sản xuất.

Cuối cùng, cần quyết định cách miscroservice giao tiếp với nhau và xem giải pháp dựa trên API nào sẽ tốt hơn cho nhu cầu của họ, Apigee hoặc kết nối riêng tư như kết nối đám mây.

Sau khi xác định môi trường lưu trữ, đã đến lúc bắt đầu migrate các tính năng.

Hiểu tính năng phụ thuộc
1_8V7BnZsCjruEPYQFvna4rQ.png

Trước khi nấu (migrate các tính năng), điều quan trọng là phải hiểu công thức. Trong trường hợp này, cần nhận thức rõ sự phụ thuộc của tính năng được migrate.
Source: https://pixabay.com/vectors/recipe-label-icon-symbol-spoon-575434/

Điều đầu tiên cần phân tích là sự phụ thuộc của tính năng giỏ hàng với phần còn lại của hệ thống. Điều đó có thể thực hiện bằng cách suy luận qua các bước mà người dùng thực hiện khi tương tác với trang web:
  • Người dùng thực hiện lựa chọn kem và nhấp vào “Thêm vào giỏ hàng của tôi”. Điều đó kích hoạt lệnh gọi API từ trình duyệt của người dùng đến giỏ hàng
  • Khi giỏ hàng nhận được yêu cầu, nó sẽ kiểm tra xem kem đã chọn có trong kho hay không bằng cách thực hiện liên kết API đến hệ thống kho.
  • Nếu mặt hàng đó còn hàng, giỏ mua hàng ghi nhận thông tin “Carter có một kem dâu tây trong giỏ hàng”
  • Cuối cùng, khi người dùng check out và đi đến quá trình thanh toán, giỏ hàng được hệ thống thanh toán phụ truy vấn để tính tổng. Và sau khi thanh toán hoàn tất, hệ thống thanh toán phụ sẽ thông báo đến tính năng giỏ hàng để làm trống giỏ hàng.
Vì vậy, nếu phân tích điều này, ở cấp độ cao, tính năng giỏ hàng này có bốn phụ thuộc, nó được gọi bởi frontend và hệ thống thanh toán, và nó truy vấn database và hệ thống kho.

Bây giờ các phụ thuộc đã được xác định, hãy để ý tới việc lựa chọn database cho tính năng này. Document database phù hợp để lưu trữ giỏ hàng, vì giỏ hàng có thể dễ dàng được sao chép bởi ID người dùng mà không cần quan tâm đến các quan hệ trong database.

Cloud Firestore rất phù hợp cho mục đích này, đó là một document database NoSQL được quản lý và không có máy chủ.

Migrate tính năng sang môi trường mới
1_Eu7WjG70sARzSqceT1_Q8w.png

Khi migrate xong tính năng này, mọi việc có vẻ đã thuận lợi hơn rất nhiều.
Source: https://pixabay.com/vectors/food-plate-fish-vegetable-prawns-576547/

Bây giờ đến phần lớn nhất. migrate các tính năng giỏ hàng thực tế. Để đơn giản hóa, hãy giả sử Ice-cream-theory có thể sắp xếp thời gian bảo trì cho trang web của họ.
  • Đầu tiên, họ sẽ cần tạo một microservice mới có thể gọi hệ thống kho và sử dụng Cloud Firestore để triển khai API giỏ hàng.
  • Sau đó, tạo code xuất các mục mua hàng từ hệ thống giỏ mua hàng cũ và viết chúng vào Cloud Firestore. Kịch bản này cần được viết theo cách có thể chạy lại nhiều lần nếu cần nhưng chỉ sao chép các giỏ hàng đã thay đổi kể từ lần trước.
  • Sau đó, tạo code sao chép các giỏ hàng từ Cloud Firestore trở lại hệ thống phụ cũ, trong trường hợp chúng cần quay ngược lại quá trình migrate.
  • Sau đó, expose API giỏ hàng với Apigee.
  • Họ sẽ cần chuẩn bị và thử nghiệm sửa đổi hệ thống thanh toán và frontend để các hệ thống này có thể gọi hệ thống giỏ hàng mới.
  • Một lần nữa cần migrate dữ liệu đã chuẩn bị trước đó để tất cả dữ liệu được đồng bộ hóa mà không mất bất kỳ bản ghi giỏ hàng nào trong tiến trình.
  • Tại thời điểm này, cần đặt trang web ở chế độ bảo trì.
  • Migrate lại dữ liệu.
  • Triển khai các sửa đổi đã được thử nghiệm trên frontend và hệ thống thanh toán với hệ thống sản xuất cũ.
Sau khi hoàn thành, tắt chế độ bảo trì trong trang web và chạy lưu lượng truy cập thông qua microservice mới!

Phần kết luận
Tính năng giỏ hàng của website Ice-cream-theory hiện là một microservice được lưu trữ trên Google Cloud.
Theo thời gian, khi hệ thống có xu hướng dựa trên microservice nhiều hơn , toàn bộ hệ thống sẽ trở nên lỏng lẻo hơn so với trong một ứng dụng monolith, việc migrate các tính năng trở nên dễ dàng hơn, sửa đổi và triển khai tính năng cũng dễ dàng hơn.
Migrate theo stage có hai lợi thế: các dự án nhỏ dễ làm việc hơn, giảm thiểu sai sót và sai lầm tốn kém. Và nó cho phép xử lý từng migrate riêng lẻ mà không bị quá tải.

Nếu đang tìm cách chuyển một ứng dụng Monolith sang microservice, bài viết này có thể là một hướng dẫn thú vị về các bước liên quan thông qua use case Ice-cream-theory. Hãy theo dõi để biết thêm các bài viết trong loạt Get Cooking in Cloud series và đọc thêm các tài liệu tham khảo bên dưới.

Nguồn: https://medium.com/
 
Top