Microservices: Tại sao chúng có thể phải kết thúc khi monolith quay trở lại?

Sự chuyển đổi sang microservice bắt đầu có đà vào đầu những năm 2010, khi các công ty công nghệ nhận ra những hạn chế của kiến ​​trúc nguyên khối. Tuy nhiên, nhiều công ty như Amazon (Prime Video), Invision, Istio và Segment đang quay trở lại với kiến ​​trúc nguyên khối. Bài viết này sẽ khám phá lý do tại sao nhiều tổ chức thất bại khi chuyển đổi sang kiến ​​trúc microservices.

Một khối là gì?

Kiến trúc nguyên khối rất đơn giản: Người dùng yêu cầu dữ liệu và tất cả dữ liệu cũng như logic nghiệp vụ đều nằm trong một dịch vụ duy nhất. Tuy nhiên, các hệ thống nguyên khối phải đối mặt với những thách thức, chẳng hạn như khả năng mở rộng hạn chế, khó triển khai các bản cập nhật và tính dễ bị tổn thương đến những điểm thất bại duy nhất.

Để giải quyết vấn đề này, nhiều tổ chức đã cố gắng chuyển đổi sang kiến ​​trúc dựa trên vi dịch vụ để tận dụng các lợi thế như tính trừu tượng và đóng gói, triển khai nhanh hơn, bảo trì dễ dàng hơn và liên kết chặt chẽ hơn từng dịch vụ với quyền sở hữu của nhóm.

Tại sao lại là microservice?

Trong một microservice lý tưởng ngành kiến ​​​​trúcmỗi miền doanh nghiệp hoạt động như một dịch vụ độc lập với cơ sở dữ liệu riêng. Thiết lập này mang lại các lợi ích như khả năng mở rộng, tính linh hoạt và khả năng phục hồi tốt hơn. Hãy xem xét sơ đồ dưới đây.

thực tế

Tuy nhiên, các xu hướng gần đây cho thấy nhiều công ty đang rời xa điều này và gắn bó với mô hình nguyên khối. ngành kiến ​​​​trúc. Điều này là do rất khó đạt được mức độ hài hòa này trong thế giới thực. Thực tế thường trông giống như sơ đồ dưới đây.

Việc di chuyển sang kiến ​​trúc microservice được biết là gây ra các tương tác phức tạp giữa các dịch vụ, các cuộc gọi vòng tròn, các vấn đề về tính toàn vẹn dữ liệu và thành thật mà nói, gần như không thể loại bỏ hoàn toàn nguyên khối. Hãy cùng thảo luận lý do tại sao một số vấn đề này lại xảy ra khi di chuyển sang kiến ​​trúc vi dịch vụ.

Ranh giới tên miền không chính xác

Trong kịch bản lý tưởng, một dịch vụ sẽ bao gồm một hoặc nhiều miền kinh doanh hoàn chỉnh để mỗi miền độc lập trong một dịch vụ. Không bao giờ được chia một miền thành nhiều dịch vụ vì điều này có thể dẫn đến sự phụ thuộc lẫn nhau giữa các dịch vụ. Sơ đồ sau đây cho thấy cách một dịch vụ có thể chứa một hoặc nhiều miền để duy trì ranh giới rõ ràng.

Trong các hệ thống thế giới thực phức tạp, việc xác định ranh giới miền có thể là một thách thức, đặc biệt khi dữ liệu thường được khái niệm hóa theo một cách cụ thể. Sơ đồ sau đây cho thấy các hệ thống trong thế giới thực thường trông như thế nào trong một microservice ngành kiến ​​​​trúc khi ranh giới không được xác định trước hoặc các kỹ sư thêm các dịch vụ mới mà không xem xét ranh giới miền.

Nếu miền không được xác định rõ ràng thì mức độ phụ thuộc vào các dịch vụ khác sẽ tăng lên, dẫn đến nhiều vấn đề:

• Phụ thuộc vòng tròn hoặc cuộc gọi quá mức: Khi các dịch vụ phụ thuộc lẫn nhau, chúng yêu cầu trao đổi dữ liệu thường xuyên.
• Các vấn đề về tính toàn vẹn của dữ liệu: Việc phân chia một miền cho các dịch vụ sẽ khiến dữ liệu được ghép nối sâu bị phân chia trên nhiều dịch vụ.
• Quyền sở hữu nhóm mơ hồ: Nhiều nhóm có thể cần cộng tác trên các miền chồng chéo, dẫn đến thiếu hiệu quả và nhầm lẫn.

Dữ liệu và chức năng được kết hợp sâu sắc

Trong kiến ​​trúc nguyên khối, máy khách thường bỏ qua các giao diện được chỉ định và truy cập trực tiếp vào cơ sở dữ liệu vì việc thực thi đóng gói rất khó trong một cơ sở mã duy nhất. Điều này có thể khiến các nhà phát triển chọn lối tắt, đặc biệt nếu giao diện không rõ ràng hoặc có vẻ phức tạp. Theo thời gian, điều này tạo ra một mạng lưới các máy khách được kết nối chặt chẽ với các bảng cơ sở dữ liệu và logic nghiệp vụ cụ thể.

Khi chuyển sang microservice ngành kiến ​​​​trúcmỗi ứng dụng khách cần được cập nhật để hoạt động với các API dịch vụ mới. Tuy nhiên, vì máy khách bị ràng buộc chặt chẽ với logic kinh doanh của khối nguyên khối nên điều này đòi hỏi phải cấu trúc lại logic của chúng trong quá trình di chuyển.

Việc gỡ rối các phần phụ thuộc này mà không phá vỡ chức năng hiện có cần có thời gian. Một số cập nhật máy khách thường bị trì hoãn do tính phức tạp của công việc, khiến một số máy khách vẫn sử dụng cơ sở dữ liệu nguyên khối sau khi di chuyển. Để tránh điều này, các kỹ sư có thể tạo các mô hình dữ liệu mới trong một dịch vụ mới nhưng vẫn giữ các mô hình hiện có ở dạng nguyên khối. Khi các mô hình được liên kết sâu, điều này dẫn đến sự phân chia dữ liệu và chức năng giữa các dịch vụ, gây ra nhiều lệnh gọi giữa các dịch vụ và các vấn đề về tính toàn vẹn dữ liệu.

Di chuyển dữ liệu

Di chuyển dữ liệu là một trong những yếu tố phức tạp và rủi ro nhất khi chuyển sang microservice. Điều cần thiết là phải chuyển chính xác và đầy đủ tất cả dữ liệu có liên quan sang các vi dịch vụ mới. Nhiều quá trình di chuyển dừng lại ở giai đoạn này vì tính phức tạp, nhưng việc di chuyển dữ liệu thành công là chìa khóa để hiện thực hóa lợi ích của vi dịch vụ. Những thách thức chung bao gồm:

• Tính toàn vẹn và nhất quán của dữ liệu: Lỗi trong quá trình di chuyển có thể dẫn đến mất dữ liệu hoặc không nhất quán.
• Khối lượng dữ liệu: Việc truyền lượng lớn dữ liệu có thể tốn nhiều tài nguyên và thời gian.
• Thời gian ngừng hoạt động và tính liên tục trong kinh doanh: Việc di chuyển dữ liệu có thể yêu cầu thời gian ngừng hoạt động, có khả năng làm gián đoạn hoạt động kinh doanh. Việc chuyển đổi suôn sẻ với tác động tối thiểu đến người dùng là rất quan trọng.
• Kiểm tra và xác thực: Cần phải kiểm tra nghiêm ngặt để đảm bảo dữ liệu được di chuyển chính xác, đầy đủ và hoạt động tốt trong dịch vụ mới.

Phần kết luận

Kiến trúc microservices có thể trông hấp dẫn nhưng việc chuyển đổi từ nguyên khối là một thách thức. Nhiều công ty thấy mình bị mắc kẹt ở trạng thái nửa chừng, điều này làm tăng độ phức tạp của hệ thống, gây ra các vấn đề về tính toàn vẹn dữ liệu, sự phụ thuộc vòng tròn và quyền sở hữu nhóm không rõ ràng. Việc không thể tận dụng tối đa lợi ích của microservice trong thế giới thực là lý do khiến nhiều công ty quay trở lại phương pháp tiếp cận nguyên khối.

Supriya Lal là trưởng nhóm công nghệ của tổ chức nền tảng thương mại tại kêu lên.