Bằng cách tham khảo bài viết này, bạn sẽ có thể hiểu rõ hơn về kiến ​​trúc Microservice và khi nào nên sử dụng nó. Hơn nữa, bài viết này bao gồm các nội dung sau đây.

◼ Chữ viết tắt của bài báo

◼ Giới thiệu

◼ Hệ sinh thái microservice

◼ Kiến trúc nguyên khối so với Kiến trúc microservice

◼ Thách thức trong Microservices

◼ Khi nào nên sử dụng Microservices

Các từ viết tắt

• API: Giao diện lập trình ứng dụng
• MS: Dịch vụ vi mô
• NoSQL: Không chỉ SQL
• RTE : Môi trường thời gian chạy

Kiến trúc microservice là một cách tiếp cận để phát triển ứng dụng trong đó một ứng dụng lớn được xây dựng dưới dạng một bộ dịch vụ mô-đun (Điều này có nghĩa là (microservice) là một loại kiến ​​trúc ứng dụng trong đó ứng dụng được phát triển dưới dạng một bộ dịch vụ). Mỗi mô-đun hỗ trợ một mục tiêu kinh doanh cụ thể và sử dụng giao diện đơn giản được xác định rõ ràng để giao tiếp với các nhóm dịch vụ khác. Hơn nữa, có tối thiểu các dịch vụ quản lý tập trung, có thể được viết bằng các ngôn ngữ lập trình khác nhau như java, python, v.v. và sử dụng các công nghệ lưu trữ dữ liệu khác nhau như quan hệ và NoSQL trong kiến ​​trúc vi dịch vụ.

Có một số tính năng/đặc điểm chính của microservices như sau.

• Khả năng bảo trì cao và có thể kiểm tra được
• Liên kết lỏng lẻo (giao tiếp qua giao diện)
• Có thể triển khai độc lập
• Được tổ chức xung quanh khả năng kinh doanh
• Thuộc sở hữu của một nhóm nhỏ (nhóm liên chức năng)

Nói chung, hệ thống Microservices chứa các thực thể được liệt kê sau đây. Một số thực thể này là các giai đoạn trong quá trình phát triển phần mềm tiêu chuẩn và một số trong số đó là các quy trình cụ thể của Microservices sẽ cung cấp xương sống cho một hệ thống microservices hiệu quả.

Cân bằng tải

Trách nhiệm chính của bộ cân bằng tải là phân phối tải đến giữa nhiều phiên bản của vi dịch vụ. Chủ yếu có 2 loại cân bằng tải được gọi là khám phá máy khách (bộ cân bằng tải phía máy khách) và khám phá máy chủ (bộ cân bằng tải phía máy chủ). Trong quá trình khám phá ứng dụng khách, ứng dụng khách nói chuyện với cơ quan đăng ký dịch vụ và thực hiện cân bằng tải. Do đó, khách hàng cần phải biết về sổ đăng ký dịch vụ. Trong quá trình khám phá máy chủ, máy khách trao đổi với bộ cân bằng tải và bộ cân bằng tải trao đổi với cơ quan đăng ký dịch vụ. Do đó, dịch vụ khách hàng không cần phải biết đăng ký dịch vụ. Bằng cách nhìn vào các sơ đồ sau, bạn có thể hiểu rõ hơn về 2 loại cân bằng tải này.

Máy chủ khám phá dịch vụ

Chức năng khám phá dịch vụ cho phép các dịch vụ siêu nhỏ tự đăng ký khi khởi động thay vì theo dõi thủ công những dịch vụ siêu nhỏ hiện đang được triển khai cũng như máy chủ và cổng nào chúng ta cần. Do đó, nếu MS1 muốn nói chuyện với MS2, trước tiên, MS1 lấy thông tin chi tiết từ dịch vụ đăng ký thuộc về cảnh quan và sau đó nói chuyện với MS2. Ngoài ra, khi có một MS khác có tên là MS3 đã hoạt động lên hoặc xuống trong cùng một cảnh quan, dịch vụ đăng ký sẽ được cập nhật tự động.

Cổng API

Cổng API là một máy chủ. Nó là một điểm vào duy nhất vào một hệ thống. API Gateway đóng gói kiến ​​trúc hệ thống nội bộ. Nó cung cấp một API phù hợp với từng khách hàng. Nó cũng có các trách nhiệm khác như xác thực, giám sát, cân bằng tải, lưu vào bộ nhớ đệm, định hình và quản lý yêu cầu cũng như xử lý phản hồi tĩnh. API Gateway cũng chịu trách nhiệm định tuyến yêu cầu, thành phần và dịch giao thức. Tất cả các yêu cầu của khách hàng đều đi qua Cổng API. Sau đó, API Gateway định tuyến các yêu cầu đến vi dịch vụ thích hợp.

Cổng API xử lý yêu cầu theo một trong hai cách sau:

• Nó định tuyến hoặc ủy quyền các yêu cầu đến dịch vụ thích hợp.
• Phân tán (lan rộng) một yêu cầu đến nhiều dịch vụ.

Bây giờ chúng tôi biết có rất nhiều dịch vụ siêu nhỏ chạy trên các nút khác nhau trong cùng một hệ sinh thái. Do đó, chúng tôi cần giám sát chúng cùng nhau trong một hệ thống duy nhất. Bảng điều khiển Hystrix và bảng điều khiển quản trị Spring boot là một số ví dụ về công cụ giám sát. Có 5 nguyên tắc giám sát microservices như sau:

• Giám sát các thùng chứa và những gì bên trong chúng.
• Cảnh báo về hiệu suất dịch vụ.
• Giám sát các dịch vụ linh hoạt và đa vị trí.
• Giám sát các API.
• Giám sát cơ cấu tổ chức

Khi chúng ta triển khai các vi dịch vụ, chúng sẽ chạy trên các RTE khác nhau như JRE và Node.js vì việc triển khai các vi dịch vụ có thể được thực hiện bằng các công nghệ khác nhau. Ngoài ra, bạn biết rằng các dịch vụ siêu nhỏ này được triển khai theo cách đa ngôn ngữ. Do đó, các nút không biết RTE của vi dịch vụ đã triển khai và chúng tôi cần cài đặt thủ công trong mỗi nút. Nhưng khi đề cập đến Containerization, chúng tôi đóng gói RTE của mình bằng vi dịch vụ. Do đó, chúng tôi có thể chạy các vi dịch vụ ở mọi nơi mà không cần xem xét đến RTE và chúng tôi có thể quản lý cũng như cập nhật các dịch vụ này một cách dễ dàng.

Ngắt mạch

Nó là một thực thể rất quan trọng trong hệ sinh thái của microservices. Hầu hết thời gian điều này được định nghĩa là một mẫu. Đối với mục đích hiểu biết, điều này khá giống với bộ ngắt mạch trong nhà của bạn. Nó bảo vệ bạn khỏi thảm họa và ngăn chặn sự lan truyền của vấn đề đã phát sinh. Kịch bản tương tự đang xảy ra ở đây (bộ ngắt mạch trong MS) đối với các dịch vụ siêu nhỏ. Giả sử rằng ứng dụng khách gửi yêu cầu đến vi dịch vụ của nhà cung cấp và trong khi phản hồi đang đến thì có sự cố kết nối. Do đó, khách hàng chờ đợi phản hồi trong một thời gian dài và nó có thể ảnh hưởng đến các dịch vụ khác. Kể từ kiến ​​trúc bộ ngắt mạch, kênh có vấn đề sẽ bị loại bỏ và vấn đề chờ đợi trước đó được giải quyết. Hơn nữa, có ba trạng thái khác nhau của Circuit Breaker được gọi là Closed, Mở và Mở một nửa.

Kiến trúc nguyên khối vs Kiến trúc microservice

Giá bán

• Nguyên khối : Cao hơn khi dự án mở rộng quy mô
• Microservice : Cao hơn ở giai đoạn phát triển đầu tiên

• Monolithic : Cơ sở mã và cơ sở dữ liệu thống nhất cho toàn bộ sản phẩm
• Microservce: Nhiều tệp mã; mỗi dịch vụ xử lý một cơ sở và lưu trữ dữ liệu

• Monolithic : Toàn bộ cơ sở mã cần được triển khai
• Microservce: Mỗi microservice được triển khai riêng lẻ

• Nguyên khối: Cùng một ngăn xếp mã
• Microservce : Các ngăn xếp khác nhau (ngôn ngữ, môi trường thời gian chạy, v.v.)

Có một số thách thức khi chúng ta xử lý microservice như sau.

• Giao tiếp giữa các quá trình (thông qua mạng)
• Giao dịch phân tán
• Một số lượng lớn các dịch vụ
• Yêu cầu tự động hóa nhiều hơn

Bây giờ chúng ta đã hiểu rõ về microservice và những thách thức của chúng. Hãy xem kịch bản nào phù hợp với microservice.

• Công ty muốn xây dựng mã sạch, dễ đọc ngay lập tức và tránh nợ kỹ thuật
• Công ty có nguồn nhân lực phát triển microservices
• Công ty ưu tiên lợi ích dài hạn hơn lợi ích ngắn hạn
• Một nhóm các nhà phát triển sử dụng các công cụ và ngăn xếp công nghệ khác nhau
• Nền tảng phải có khả năng mở rộng cao và mở rộng sang các thị trường khác nhau