Microservices là gì?

Microservice Architecture

Mục lục

Toggle

Microservices là các dịch vụ nhỏ, tách biệt đại diện cho 1 phần nhỏ tương ứng trong business domain của bạn. Với kiến trúc Monolithic, bạn sẽ có 1 server lớn chịu trách nhiệm giải quyết tất cả các requests. Việc này sẽ gây khó khăn rất nhiều trên phương diện scale.  Microservices có thể cân bằng traffic theo nhu cầu của doanh nghiệp. Nếu đang nhận được 1 lượng lớn thanh toán, bạn có thể scale up thiết bị thanh toán và giữ các dịch vụ khác ở mức sử dụng 1 lượng nhỏ hơn các services.

Microservices có nhiều lợi ích cho các nhóm Agile và DevOps. Lập trình viên kiêm diễn giả quốc tế Martin Fowler đã chỉ ra rằng: Netflix, eBay, Amazon, Twitter, PayPal và các ứng dụng công nghệ nổi tiếng khác đều đã phát triển từ kiến ​​trúc nguyên khối sang microservices.

Microservices giải quyết những khó khăn của hệ thống nguyên khối bằng cách mô-đun hóa càng nhiều càng tốt. Ở dạng đơn giản nhất, microservices giúp xây dựng một ứng dụng dưới dạng một bộ các dịch vụ nhỏ, mỗi dịch vụ chạy trong quy trình riêng và có thể triển khai độc lập. Các dịch vụ này có thể được viết bằng các ngôn ngữ lập trình khác nhau và có thể sử dụng các kỹ thuật lưu trữ dữ liệu khác nhau. Các dịch vụ vi mô thường được kết nối thông qua API và có thể tận dụng nhiều công cụ và giải pháp tương tự đã phát triển trong hệ sinh thái dịch vụ web và RESTful.

Mô tả kiến trúc Microservices

Trong kiến trúc Microservices, các service (dự án) tồn tại độc lập nhau về xử lý (process), lưu trữ (database) và request (client/server model). Hình minh họa bên dưới là minh họa 1 thành phần trong kiến trúc microservices (lưu ý là nó không liên quan đến phần bài toán đề cập bên dưới).

Ví dụ bạn xây dựng một hệ thống bán hàng dựa trên Microservices (như Teamcrop chẳng hạn) thì giả sử một đơn hàng được mô tả với các thông tin sau “Hôm nay có nhân viên A tạo một đơn hàng B tại cửa hàng C và xuất từ kho D” thì bạn cần tối thiểu 4 service (project) với database độc lập:

• Employee service (sử dụng table tc_employee)
• Store service (sử dụng table tc_store)
• Inventory service (sử dụng table tc_warehouse)
• Order service (sử dụng table tc_order). Trong đó table tc_order chỉ chứa khóa ngoại – tức ID của Nhân viên, ID của cửa hàng, ID của nhà kho theo đúng tinh thần thiết kế chuẩn hóa database.

Bởi vì theo kiến trúc Microservices nên hệ thống bạn sẽ chạy 4 dịch vụ khác nhau như trên và chạy ở tối thiểu 4 instance (container, server) khác nhau.

Lợi ích của phương pháp microservices

Microservices ngày càng được sử dụng phổ biến tại các doanh nghiệp sản xuất phần mềm nhờ mang lại một số lợi ích như:

• Mã nguồn tinh gọn: Bởi vì hệ thống được cấu hình từ các dự án nhỏ và mỗi dự án đều rất đơn giản cũng như tập trung vào một hoặc một số nghiệp vụ chính. Vì vậy, code base và độ phức tạp của chúng đều không cao. Nhờ vậy, nó sẽ giúp các tính năng vận hành mượt mà, dễ dàng hơn trong bảo trì hay mở rộng phát triển.
• Tối ưu hóa bảo mật cho mã nguồn: Việc nhân viên ở dự án nào chỉ được truy cập vào một mã nguồn của dự án đó sẽ đảm bảo khả năng kiểm soát dữ liệu tốt hơn.
• Được tồn tại độc lập: Khi có 4 dự án khác nhau và được triển khai riêng biệt nhưng một dịch vụ nào đó chết thì các dịch vụ khác vẫn sẽ hoạt động bình thường, VD service xử lý ảnh có thể viết bằng C++, service tổng hợp data có thể viết bằng Python,..
• Scale hoàn toàn độc lập: Tùy vào nhu cầu sử dụng của hệ thống mà bạn có thể mở rộng quy mô riêng cho dịch vụ đó. Ví dụ như đơn hàng dịch vụ mà sử dụng thường xuyên nên chạy từ máy chủ 2 đến 3 để gia tăng hiệu suất.

Nhược điểm của Microservices

• Nhà phát triển thường xuyên phải đối phó với sự phức tạp khi tạo ra một hệ thống phân tán.
• Cần phải implement việc communication giữa các inter-services
• Handle partial failure rất phức tạp bởi vì luồng xử lý cần phải đi qua nhiều service khác nhau.
• Khi thực hiện các requests trải rộng trên nhiều service cần đòi hỏi sự phối hợp giữa các team.
• Khó khăn trong việc đảm bảo toàn vẹn cho cơ sở dữ liệu nếu như triển khai theo các cấu trúc dạng phân vùng.
• Việc triển khai và quản lý microservices nếu như làm thủ công theo cách làm với ứng dụng thì sẽ rất phức tạp.
• Lập trình viên cần phải xử lý các sự cố kết nối chậm, lỗi nếu như thông điệp không được gửi hoặc nếu như thông điệp được gửi đến nhiều đích đến vào các thời điểm khác nhau.

VD:Nếu ở website bạn hiện 1 table view với thông tin sau:

thì bạn sẽ làm như thế nào và tối ưu nhất? Có thể trong đầu các bạn đã nghĩ đến JOIN, nhưng xin thưa, đây không phải là ứng dụng Monolithic, mà đây là microservice và 4 database table này ở 4 database server khác nhau nên không có chuyện JOIN gì cả, và ở table đơn hàng (tc_order) bạn chỉ có EmployeeID, StoreID và WarehouseID.

Một số chiến lược cơ bản

Để giải quyết bài toán hiển thị ở trên, bạn chỉ có thể tiếp cận theo hướng lấy dữ liệu trực tiếp từ service liên quan. Từ EmployeeID, gọi sang service Employee, từ StoreID thì gọi sang service Store…để lấy các thông tin cần hiển thị. Việc này sẽ dẫn đến giao tiếp liên service (inter-service communication).

Trong kiến trúc Microservices, càng hạn chế gọi liên service càng tốt vì các service sinh ra để phục vụ bên ngoài chứ không phải để phục vụ liên service, dẫn đến performance hệ thống sẽ bị giảm, vì nếu thiết kế không tốt, các service bị die hầu như do các service gọi lẫn nhau gây quá tải chứ từ client chưa chắc quá tải .

Ngoài ra, gọi liên service sẽ có overhead vì vẫn có giao thức kết nối đi kèm (như HTTPS, Protobuf..) nên phải hạn chế. Do đó, cách dễ dàng tiếp cận nhất là sử dụng cache để không phải request nhiều đến các service mà chỉ cần mò vào cache. Có thể sử dụng Redis hoặc memcache cho tính năng này. Nhiệm vụ còn lại của bạn chỉ là làm sao clear cache một cách hiệu quả mà thôi.

Như vậy, với 1 đơn hàng, bạn sẽ cần thêm 3 request đến cache để fetch thêm thông tin (employee, store và warehouse) trước khi trả về client để hiển thị đầy đủ thông tin.

6 điều cần tuân thủ khi thiết kế kiến trúc Microservices

Khi thiết kế Microservices Architecture, developer cần tuân thủ 6 điều sau để xây dựng được kiến trúc chất lượng:

1. Single Responsibility Principle (SRP): Nguyên tắc của một service là có phạm vi và chức năng giới hạn, tập trung vào một nhiệm vụ để quá trình phát triển và triển khai dịch vụ trở nên nhanh chóng hơn.
2. Trong quá trình thiết kế, bạn nên xác định và giới hạn các services theo chức năng nghiệp vụ thực tế.
3. Đảm bảo microservices có thể phát triển và triển khai độc lập thành từng module.
4. Mục tiêu của thiết kế của microservices sẽ phục vụ một nghiệp vụ chứ không chỉ đơn giản làm các dịch vụ nhỏ hơn.
5. Kích thước hợp lý của một service là kích thước đủ để đáp ứng yêu cầu của một chức năng trong hệ thống.
6. Một microservice không nên có quá nhiều hàm hay chức năng hỗ trợ xung quanh và định dạng thông báo/ messaging đơn giản.

Bạn có thể tham khảo thêm 1 số bài viết liên quan bảo mật tại đây

========================================

P.A Việt Nam cung cấp đa dạng các cấu hình Máy Chủ Ảo và Máy Chủ Riêng
Cloud Server
Cloud Server Pro
Máy Chủ Riêng

Tham khảo các ưu đãi: https://www.pavietnam.vn/vn/tin-khuyen-mai/