Phân tách Monolith thành các Microservices – 12 Practice và Nguyên tắc Thiết kế tốt nhất

toannm

Phân tách Monolith và chuyển nó sang kiến trúc microservice là một việc có vẻ dễ dàng và sẽ khiến nhiều người có xu hướng đánh giá thấp sự phức tạp chung của sáng kiến đó.

Đã từng có một thời, các app được phát triển theo truyền thống dưới dạng monolith, được gói thành một tập hợp code và được deploy như một đơn vị duy nhất. Tuy nhiên, sự phức tạp của việc duy trì một kiến trúc monolith cùng với sự phức tạp của sản phẩm cộng thêm việc thiếu tốc độ để phát triển đã dẫn đến việc các doanh nghiệp tìm kiếm các lựa chọn thay thế mới để đảm bảo tính bền vững, linh hoạt và dễ dàng tích hợp.

Mặc dù phân tách Monolith và chuyển sang kiến trúc microservice có vẻ dễ dàng khiến nhiều doanh nghiệp có xu hướng đánh giá thấp sự phức tạp chung của sáng kiến này và dẫn đến những sai lầm nghiêm trọng.

Kiến trúc microservice về cơ bản đại diện cho vô số các microservice, tự động và độc lập, thực hiện một chức năng kinh doanh duy nhất. Hình ảnh bên dưới là đại diện của nhiều microservice đang được truy cập thông qua API gateway.

microservices-best-practices.png

Nếu đang cố gắng thực hiện một sự thay đổi tương tự từ kiến trúc monolith sang kiến trúc microservice hiện đại, việc hành động nôn nóng khi thiếu kiến thức có thể để lại hậu quả khôn lường. Rốt cuộc, không doanh nghiệp nào muốn chi phí của mình tăng lên hoặc gặp phải lỗi vào những thời điểm quan trọng trong lifecycle của sản phẩm.

Dưới đây là 12 practice tốt nhất của microservice cần phải tuân theo:

best-practices-microservices.jpg

Có data storage riêng biệt

Trước khi xem xét việc migrate, hãy tìm hiểu cách phân tách data storage theo các microservice cấu thành khác nhau. Điều này có thể được thực hiện bằng cách sử dụng architecture pattern như CQRS (Command and Query Responsibility Segregation) để tách biệt data của từng microservice.

Việc mỗi microservice không là chủ sở hữu duy nhất của data sẽ dẫn đến việc nhiều service truy cập database private, từ đó xảy ra các vấn đề kết nối giữa chúng. Mặc dù điều này không có nghĩa là data không thể được chia sẻ giữa các microservice, mà nó chỉ nên diễn ra thông qua API.

Xây dựng đội ngũ chuyên trách

Microservice chỉ hữu dụng khi nó có thể giúp tạo các cloud-native app. Tuy nhiên, điều này cũng có nghĩa là các bản cập nhật cần được phát hành tương đối nhanh chóng và trong real-time, mỗi giây bị mất do downtime có thể dẫn đến thiệt hại đáng kể cho doanh nghiệp. Do đó, việc phân bổ các nhóm chuyên trách cho mọi microservice sẽ hợp lý hơn nếu doanh nghiệp dự định mở rộng quy mô tuyến tính và hiệu quả.

Sẽ khó để các developers hình dung được kịch bản kết thúc hoàn chỉnh của các app quy mô lớn. Đối với họ, việc chuyển đổi công nghệ hoặc thay đổi mindset có thể mất rất nhiều thời gian và nỗ lực. Vì vậy, cần xây dựng các nhóm chuyên trách để giữ cho họ làm quen với các sắc thái của quản lý trong khi đảm bảo hiệu quả tối đa có thể là một practice tốt nhất của microservice nên được tuân theo.

Sự dụng tự động hoá cho Deployment độc lập

Việc phân tách kiến trúc monolith thành các microservice riêng lẻ sẽ không có ý nghĩa nếu chúng không thể được deploy độc lập. Ngoài ra, hãy đảm bảo thực hiện cấu trúc tự động hóa việc build và phát hành. Điều này không chỉ giúp giảm thời gian thực hiện tổng thể mà còn giúp phát hành nhanh hơn, đồng thời tăng cường quá trình deployment.

Với tự động hóa, microservice có thể được bọc trong các container và deploy hiệu quả cho mọi môi trường, bao gồm cả cloud.

Tận dụng lợi ích của REST API

REST API rất hữu ích cho microservice vì với nó, các developers không cần cài đặt bất kỳ phần mềm hoặc library bổ sung nào trong khi tạo REST API. Đồng thời, chúng rất linh hoạt do data không được gắn với bất kỳ phương pháp hoặc tài nguyên cụ thể nào. Kết quả là chúng có thể xử lý nhiều loại call, trả về các định dạng data khác nhau và thay đổi cấu trúc với triển khai chính xác của hypermedia.

Người dùng thậm chí không cần một framework hoặc SDK vì các HTTP request tương đối đầy đủ. Trong số bốn level của REST, chỉ cần bắt đầu ở level 0 và tiến lên level 3, theo đề xuất của Leonard Richardson, một chuyên gia về RESTful API.

Thấu hiểu sự thay đổi văn hóa

Việc chuyển từ kiến trúc monolith sang kiến trúc dựa trên microservice có thể không thuận lợi cho sự thay đổi đối với các developer cũ như mong đợi. Những developers này đã làm việc trong một môi trường đòi hỏi họ phải chạy thử nghiệm từ đầu đến cuối, nếu phải đột nhiên chuyển sang kiến trúc microservice, việc quản lý mong đợi sự trở lại của hiệu quả tối đa sẽ tương đối khó khăn.

Cần hiểu rằng đây là một sự thay đổi lớn và không chỉ là một hoạt động đơn lẻ. Các developer cần phải nhạy cảm với những kỳ vọng của môi trường làm việc mới và tầm nhìn dài hạn của công ty tác động đến năng lực làm việc hàng ngày của họ như thế nào.

Phá vỡ migrate thành các bước


Nếu chưa từng xử lý việc migrate trước đó, cần xác định tinh thần đó không phải là một nhiệm vụ dễ dàng. Hơn nữa, nếu đã chuẩn bị kế hoạch để thực hiện tất cả cùng một lúc, cần quay lại việc lên ý tưởng. Kiến trúc monolith thường liên quan đến một mạng lưới các repository, deployment, giám sát và các nhiệm vụ phức tạp khác nhau. Thay đổi (hoặc migrate) tất cả những điều này cùng một lúc có thể không khả thi đối với các nhóm và có thể để lại các lỗi và lỗ hổng.

Một trong những cách tốt nhất để xử lý vấn đề này là giữ lại cấu trúc monolith và phát triển bất kỳ khả năng bổ sung nào dưới dạng microservice. Khi có đủ các service mới (và các nhóm đã được làm quen về các quy trình mới) cần tìm ra cách để có thể chia kiến trúc cũ thành các thành phần có liên quan và bắt đầu migrate từng cái một.

43-micro-services-best-practices.jpg

Xây dựng hệ thống chia tách ngay trong hỗn hợp

Không có một hệ thống phân tách chính xác ngay từ khi bắt đầu dự án có thể dẫn đến những rắc rối lớn trong tương lai. Xác định các tương tác và quy trình giữa các mảnh ghép khác nhau là một trong những nguyên tắc thiết kế quan trọng nhất của microservice cần được tuân theo để làm cho tổng quan quá trình rõ ràng hơn, thậm chí còn hơn thế nếu người dùng đang trong giai đoạn migrate.

Mỗi hệ thống phân tách là duy nhất cho kiến trúc đang được xây dựng. Nó phụ thuộc vào phương pháp đang theo dõi và kết quả đang được mong đợi ở cuối.

Một tip là kiểm tra cấu trúc monolith để hiểu các lỗ hổng mà nó có và các thành phần gây ra nhiều rắc rối nhất và sau đó chuyển sang phần này thành một microservice.

Mặc dù, việc này chỉ khả thi thể nếu người dùng đã theo dõi hiệu suất của các thành phần riêng lẻ ở bước đầu tiên. Vì vậy, nếu giám sát không phải là thứ đang cần tập trung, thì đó là một nơi tuyệt vời để bắt đầu quá trình làm sạch.

microservices-tools-best-practices-845x684.jpg

Các công cụ giám sát có thể sử dụng:
Cô lập các quy trình Runtime

Có các quy trình khác nhau cho các verticals khác nhau, do đó người dùng cũng bị ràng buộc phải cách ly ở runtime level. Cần thực hiện một số distributed computing để thực hiện điều này từ một nhóm các lựa chọn có thể. Câu hỏi cần đặt ra là có cần áp dụng container, kiến trúc event, các phương pháp quản lý HTTP, service mesh và bộ ngắt mạch không? Hãy tìm điều này trước khi quá muộn.

Chọn công nghệ phù hợp với Microservice phù hợp


Mặc dù một thành viên trong nhóm có thể không coi trọng công nghệ hoặc ngôn ngữ đang được sử dụng, nhưng một thành viên khác có thể cho rằng tuổi thọ của sản phẩm phụ thuộc vào nó. Dù quan điểm khác nhau nhưng việc triển khai công nghệ trực tiếp và lặp đi lặp lại có thể giúp thực hiện các thay đổi dễ dàng hơn hoặc thậm chí thay thế nó sau này.

Sự lựa chọn ngôn ngữ có thể tùy thuộc vào sở thích cá nhân và mức độ thoải mái của các thành viên trong nhóm. Tuy nhiên bất cứ điều gì được làm, hãy chắc chắn rằng nhóm của mình được trang bị đủ để xử lý quyết định. Chẳng hạn, việc chọn một kiến trúc bao gồm hàng tá ngôn ngữ lập trình khác nhau cũng có thể chuyển thành một cuộc tuyển dụng thành viên mới, điều thường không được khuyến khích.

Nếu không chắc chắn công nghệ nào là tốt nhất cho dự án của mình, hãy xem xét các tham số sau trong quá trình ra quyết định:
  • Bảo trì.
  • Chịu lỗi.
  • Khả năng thay đổi quy mô.
  • Chi phí kiến trúc.
  • Triển khai dễ dàng.

microservices-tools-best-practices-845x684.jpg

Cân nhắc sử dụng Domain-Driven Design

Domain-Driven Design (DDD) có sự tương đồng với OOP được áp dụng cho các mô hình kinh doanh. Đó là một loại nguyên tắc thiết kế sử dụng các quy tắc và ý tưởng thực tế để thể hiện một mô hình hướng đối tượng. Nói một cách đơn giản hơn, microservice được thiết kế xung quanh các lĩnh vực kinh doanh của người dùng. Nó được sử dụng bởi các nền tảng như Netflix, những người sử dụng các server khác nhau để chạy phân phối nội dung và các tracking service liên quan.

Phân biệt các tài nguyên chuyên dụng và tài nguyên theo yêu cầu

Nếu mục đích chính là cung cấp trải nghiệm khách hàng vượt trội, hãy xem xét phân biệt tài nguyên chuyên dụng và tài nguyên theo yêu cầu. Điều này giúp gì? Ví dụ, hãy để một nền tảng thương mại điện tử xây dựng các microservice và kiến trúc cloud theo cách nhanh chóng (và an toàn) migrate workload giữa môi trường tại chỗ và trên nền tảng cloud. Điều này không chỉ làm tăng thời gian phản hồi mà còn giúp việc migrate sang môi trường làm việc dựa trên coud trực quan hơn nhiều lần.

Quản lý sự phụ thuộc vào các công cụ nguồn mở

Điều khá phổ biến đối ở các developer là việc sử dụng các công cụ microservice nguồn mở để bảo mật, giám sát, gỡ lỗi và ghi nhật ký. Tuy nhiên, cần đảm bảo rằng chúng không bị phụ thuộc quá nhiều vào các cách can thiệp vào hiệu suất hoặc bảo mật của kiến trúc. Tùy thuộc vào nhu cầu phát triển và các loại công cụ đang được sử dụng, hãy thực hiện các chính sách tổ chức phù hợp về việc sử dụng chúng. Điều này có thể liên quan đến:

  • Thiết lập repo chính thức cho các phiên bản phần mềm được phê duyệt.
  • Hiểu chuỗi cung ứng phần mềm nguồn mở.
  • Thiết lập quản trị để xử lý ngoại lệ.

Kết luận

Trước khi bắt đầu quá trình chuyển đổi hệ thống thành microservice, điều quan trọng là phải mục đích chính đáng. Việc lấy các tính năng đặc biệt của hệ thống và làm việc thay đổi một phần của hệ thống gây tổn thương tương đối nặng nề. Hãy bắt đầu theo cách tiếp cận gia tăng, trong đó người dùng đưa ra một phần không quá quan trọng của hệ thống và đánh giá cách thức hoạt động của nó, đó cũng là một cách tuyệt vời để mua lại các bên liên quan và tiến hành từ đó.

Ngoài các pratice tốt nhất cho các microservice, cần đảm bảo rằng người quản lý dự án có khả năng xử lý việc migrate và phát triển kiến trúc hướng dịch vụ từ đầu đến cuối. Quá trình migrate thực tế sẽ phụ thuộc rất nhiều vào lý do chính xác mong muốn thực hiện. Việc chuyển từ kiến trúc monolith sang kiến trúc dựa trên microservice sẽ cần thực hiện từng bước một và tiếp cận từ một phần nhỏ, không quan trọng trong hệ thống, để xem nó cách hoạt động. Điều này sẽ mở đường cho việc mua tổ chức để tạo thêm các microservice. Chỉ các doanh nghiệp hiểu được các sắc thái của sự thay đổi văn hóa theo hướng microservice mới có thể tận dụng công nghệ với tiềm năng đầy đủ.

Nguồn: https://dzone.com/articles/break-a-monolith-to-microservices-12-best-practice
 
Top