Trong bài trước, Điạ ngục kiến trúc một khối chúng ta đã thấy kiến trúc một khối có những nhược điểm đáng sợ như thế nào.
Nhiều tập đoàn như Amazon, eBay, Netflix đã giải quyết vấn đề ứng dụng một khối bằng kiến trúc Microservices. Ý tưởng là chia nhỏ ứng dụng lớn ra thành các dịch vụ nhỏ kết nối với nhau.
Mỗi dịch vụ nhỏ thực hiện một số các chức năng chuyên biệt như quản lý đơn hàng, quản lý khách hàng… Mỗi dịch vụ là một ứng dụng nhỏ có kiến trúc đa diện lõi là business logic kết nối ra các adapter khác nhau. Một số dịch vụ nhỏ lộ đưa ra API cho dịch vụ nhỏ khác hay client gọi tới. Khi vận hành, mỗi dịch vụ nhỏ được chạy trong một máy ảo hoặc Docker container.
Mỗi chức năng giờ được thực thị bởi một dịch vụ nhỏ. Ứng dụng web cũng có thể chia nhỏ hơn chuyên cho từng đối tượng người dùng (một cho hành khách taxi, một cho tài xế). Thiết kế giao diện cho từng đối tượng người dùng giúp tối ưu trải nghiệm tốt hơn, tốc độ nhanh hơn, dễ tương thích hơn trong khi chức năng tối giản hơn.
Ứng dụng của người dùng cuối sẽ không được kết nối trực tiếp vào back-end services. Thay vào đó có API gateway đứng giữa.
Có ba khía cạnh để scale một hệ thống sử dụng Microservices, thứ nhất là trục Y với việc chia càng nhỏ dịch vụ ra càng nhiều càng tốt, thứ hai với trục X là việc clone các instance của mỗi services và hứng bằng load balancer, thứ ba với trục Z là data partitioning, bằng cách phân vùng những dịch vụ tương tự.
Biểu đồ dưới mô tả làm thế nào dịch vụ quản lý chuyến đi có thể được triển khai với Docker chạy trên Amazon EC2.
Kiến trúc Microservices ảnh hưởng lớn đến quan hệ ứng dụng và cơ sở dữ liệu. Thay vì dùng chung một cơ sở dữ liệu giữa các dịch vụ, mỗi dịch vụ sẽ có cơ sở dữ liệu riêng. Cách này đi ngược lại việc tập trung hóa cơ sở dữ liệu trong truyền thống. Hệ quả là sẽ có dư thừa dữ liệu, cơ chế foreign key ràng buộc quan hệ dữ liệu không thể áp dụng với bảng ở hai cơ sở dữ liệu tách biệt. Thiết kế này sẽ gây sốc đối với nhiều lập trình đã quá quen với mô hình client – server, ở đó cơ sở dữ liệu luôn là một trung tâm, tập hợp mọi bảng. Việc lưu trữ dữ liệu ở từng dịch vụ rất quan trọng nếu bạn muốn kiến trúc microservice thực sự hiệu quả vì nó đảm bảo loose coupling (ít ràng buộc) giữa các dịch vụ với nhau. Nhưng đây vũng chỉ là khuyến cáo, trong thực tế, vài dịch vụ vẫn có thể dùng chung một cơ sở dữ liệu để đảm bảo tính toàn vẹn dữ liệu được ưu tiên cao nhất.
Sơ đồ dưới đây là ví dụ về kiến trúc cơ sở dữ liệu cho các dịch vụ.
Từng dịch vụ nhỏ có thể tùy chọn công nghệ lưu trữ dữ liệu tối ưu nhất. Ví dụ, dịch vụ điều xe cần phải dùng cơ sở dữ liệu hỗ trợ việc truy vấn theo tọa độ tốt nhất.
Nhìn một cách tổng thể, kiến trúc Microservices tương tự như SOA (kiến trúc hướng dịch vụ). Cả hai đều có một tập các dịch vụ. Điểm khác là Microservices không dùng chuẩn do các tập đoàn lớn như IBM, Microsoft, Oracle đặt ra như web service specifications (WS-*) hay Enterprise Service Bus (ESB). Microservices hướng đến các chuẩn lightweight hơn như Protobuf, Thrift hoặc cởi mở, dễ đọc như JSON. Microservice không áp dụng một số phần của SOA như canonical schema. Có thể thấy Microservices gọn hơn, đa dạng hơn trong giao thức cũng như chuẩn dữ liệu.
Và cũng như mọi thứ khác trên thế gian này, đều có ưu điểm cũng như nhược điểm. Vậy những ưu điểm và nhược điểm của kiến trúc Microservices là gì, mời các bạn đón xem phần tiếp theo, Những ưu nhược điểm của Microservices.
Tạm biệt và hẹn gặp lại.
Techtalk via codealohicguy
