Trở lại năm 2019, tôi đã viết về cách tạo cửa hàng sự kiện trong Redis. Tôi đã giải thích rằng Redis Streams rất phù hợp cho một cửa hàng sự kiện, bởi vì chúng cho phép bạn lưu trữ các sự kiện trong một cơ chế chỉ dành cho phần phụ bất biến như nhật ký giao dịch. Bây giờ, với bản cập nhật của ứng dụng OrderShop mẫu được giới thiệu trong blog đó, tôi sẽ trình bày cách sử dụng Redis làm hàng đợi thư, chứng minh thêm nhiều trường hợp sử dụng của Redis Enterprise ngoài bộ nhớ đệm.
Xem nhanh các dịch vụ vi mô, dịch vụ cơ sở hạ tầng và hệ thống phân tán
Redis là một giải pháp tuyệt vời để tạo các dịch vụ cơ sở hạ tầng như hàng đợi tin nhắn và cửa hàng sự kiện, nhưng có một số điều bạn cần tính đến khi sử dụng kiến trúc microservices để tạo hệ thống phân tán. Cơ sở dữ liệu quan hệ thường tốt cho các ứng dụng nguyên khối, nhưng chỉ cơ sở dữ liệu NoSQL như Redis mới có thể cung cấp các yêu cầu về khả năng mở rộng và tính khả dụng cần thiết cho kiến trúc microservices.
Hệ thống phân tán ngụ ý một trạng thái phân tán. Theo định lý CAP, việc triển khai phần mềm chỉ có thể cung cấp hai trong số ba thuộc tính sau:tính nhất quán, tính khả dụng và dung sai phân vùng (do đó CAP). Vì vậy, để làm cho việc triển khai của bạn có thể chịu được lỗi, bạn phải lựa chọn giữa tính khả dụng và tính nhất quán. Nếu bạn chọn tính khả dụng, cuối cùng bạn sẽ có được tính nhất quán, có nghĩa là dữ liệu sẽ nhất quán nhưng chỉ sau một khoảng thời gian đã trôi qua. Việc chọn tính nhất quán ảnh hưởng đến hiệu suất vì nhu cầu đồng bộ hóa và cô lập các hoạt động ghi trong toàn bộ hệ thống phân tán.
Tìm nguồn cung ứng sự kiện, duy trì trạng thái của một thực thể kinh doanh, chẳng hạn như đơn đặt hàng hoặc khách hàng, như một chuỗi các sự kiện thay đổi trạng thái, đi đến tính khả dụng thay vì nhất quán. Nó cho phép các hoạt động ghi trở nên tầm thường, nhưng các hoạt động đọc tốn kém hơn vì trong trường hợp chúng trải dài trên nhiều dịch vụ, chúng có thể yêu cầu một cơ chế bổ sung như mô hình đọc.
Giao tiếp trong một hệ thống phân tán có thể được môi giới hoặc không qua môi giới. Các kiểu không môi giới đã được biết đến nhiều, với HTTP là ví dụ nổi tiếng nhất của nó. Như tên của nó, cách tiếp cận môi giới có một môi giới giữa người gửi và người nhận tin nhắn. Nó tách người gửi và người nhận, cho phép giao tiếp đồng bộ và không đồng bộ. Điều này dẫn đến hành vi linh hoạt hơn vì người tiêu dùng tin nhắn không cần phải có mặt tại thời điểm tin nhắn được gửi đi. Giao tiếp bị chia cắt cũng cho phép mở rộng quy mô độc lập giữa người gửi và người nhận.
(Để biết thêm thông tin, hãy xem bài đăng của chúng tôi về Nên chọn gì cho nhu cầu giao tiếp đồng bộ và không đồng bộ của bạn — Redis Streams, Redis Pub / Sub, Kafka, v.v.)
OrderShop:triển khai thương mại điện tử mẫu
“Hello World” của kiến trúc microservice là OrderShop, một triển khai đơn giản của hệ thống thương mại điện tử sử dụng cách tiếp cận dựa trên sự kiện. Ứng dụng mẫu này sử dụng một mô hình miền đơn giản, nhưng nó đáp ứng mục đích của ứng dụng.
OrderShop được sắp xếp bằng Docker Compose. Tất cả giao tiếp mạng được thực hiện qua gRPC. Các thành phần trung tâm là kho sự kiện và hàng đợi tin nhắn:mỗi và mọi dịch vụ được kết nối và chỉ với chúng qua gRPC. OrderShop là một triển khai mẫu bằng Python. Bạn có thể xem mã nguồn OrderShop trên GitHub.
(Lưu ý: Mã này không sẵn sàng sản xuất và chỉ dành cho mục đích demo!)
Chạy và vui
- Sao chép kho lưu trữ GitHub:https://github.com/redis-demos/ordershop-v2
- Chạy OrderShop v2 theo quy trình năm bước đơn giản:
- Khởi động ứng dụng với docker-compile up
- Mở trình duyệt của bạn và truy cập https:// localhost:5000 /
- Xem các sự kiện và duyệt trạng thái
- Chạy ứng dụng khách với python -m unittest tests / unit.py
- Mở một tab khác trong trình duyệt của bạn tới https:// localhost:8001 /
- Sử dụng redis:6379 để kết nối với cơ sở dữ liệu thử nghiệm
- Dừng ứng dụng bằng docker-compile down
Kiến trúc OrderShop v2
Trong trường hợp này, kiến trúc máy chủ bao gồm nhiều dịch vụ. Trạng thái được phân phối trên một số dịch vụ miền nhưng được lưu trữ trong một kho sự kiện duy nhất. Mô hình đọc thành phần tập trung logic để đọc và lưu trạng thái vào bộ nhớ đệm, như được hiển thị ở đây:
Các lệnh và truy vấn được giao tiếp qua Hàng đợi tin nhắn thành phần, trong khi các sự kiện được thông báo qua Cửa hàng sự kiện thành phần này cũng hoạt động như một bus sự kiện.
Dịch vụ cơ sở hạ tầng
Trong OrderShop v2, tất cả giao tiếp unicast xảy ra qua Hàng đợi tin nhắn thành phần. Đối với điều này, tôi sẽ sử dụng Redis Lists và đặc biệt, hai danh sách được kết hợp thành một cái gọi là "hàng đợi đáng tin cậy". Nó xử lý đồng bộ các lệnh đơn giản (ví dụ:các hoạt động đơn lẻ), nhưng các lệnh chạy lâu (ví dụ:hàng loạt, thư) không đồng bộ và hỗ trợ phản hồi cho các thông báo đồng bộ ngoài hộp.
Cửa hàng sự kiện dựa trên Redis Streams. Các dịch vụ miền (chỉ là hình nộm để chứng minh chức năng của OrderShop) được đăng ký vào các luồng sự kiện có tên theo chủ đề sự kiện (tức là tên tổ chức) và xuất bản các sự kiện lên các luồng này. Mỗi sự kiện là một mục nhập luồng với dấu thời gian sự kiện đóng vai trò là ID. Tổng các sự kiện đã xuất bản trong các luồng dẫn đến trạng thái của hệ thống tổng thể.
Dịch vụ ứng dụng
Mô hình đọc vào bộ nhớ đệm các thực thể được suy ra từ Cửa hàng sự kiện trong Redis bằng cách sử dụng mô hình miền. Bỏ qua bộ nhớ cache, nó không có trạng thái.
Cổng API cũng là không trạng thái và phục vụ REST-API trên cổng 5000. Nó chấm dứt các kết nối HTTP và định tuyến chúng đến mô hình đọc để đọc trạng thái (truy vấn) hoặc đến dịch vụ miền chuyên dụng để viết trạng thái (lệnh). Sự tách biệt khái niệm giữa các hoạt động đọc và ghi này là một mô hình được gọi là Phân tách trách nhiệm truy vấn lệnh (CQRS).
Dịch vụ miền
Các dịch vụ miền nhận các thao tác ghi qua Hàng đợi tin nhắn từ cổng API . Sau khi thực hiện thành công, họ xuất bản một sự kiện cho từng người trong số họ lên Cửa hàng sự kiện . Ngược lại, tất cả các thao tác đọc được xử lý bởi Mô hình đọc lấy trạng thái của nó từ Cửa hàng sự kiện .
Dịch vụ CRM (Dịch vụ Quản lý quan hệ khách hàng) không có trạng thái — dịch vụ này được đăng ký tham gia các sự kiện miền từ cửa hàng sự kiện và gửi email cho khách hàng bằng Dịch vụ thư .
Thực thể miền trung tâm là đơn đặt hàng. Nó có một trường được gọi là 'trạng thái' mà quá trình chuyển đổi được thực hiện bằng máy trạng thái, như được hiển thị trong sơ đồ bên dưới.
Các chuyển đổi này được thực hiện trong một số trình xử lý sự kiện, được đăng ký với các sự kiện miền (mẫu SAGA), ví dụ:
Khách hàng
Khách hàng được mô phỏng bằng cách sử dụng khung kiểm thử Đơn vị từ Python. Hiện đã có 10 bài kiểm tra đơn vị được triển khai. Xem qua tests / unit.py để biết thêm chi tiết.
Một giao diện người dùng đơn giản được cung cấp trên cổng 5000 để xem các sự kiện và trạng thái duyệt (sử dụng WebSockets).
Một vùng chứa RedisInsight cũng có sẵn để kiểm tra phiên bản Redis. Mở trình duyệt web tới https:// localhost:8001 / và sử dụng redis:6379 để kết nối với cơ sở dữ liệu thử nghiệm.
Kết luận
Redis không chỉ là một công cụ mạnh mẽ trong lớp miền (ví dụ:tìm kiếm danh mục) và lớp ứng dụng (ví dụ:cửa hàng phiên HTTP) mà còn trong lớp cơ sở hạ tầng (ví dụ:cửa hàng sự kiện hoặc hàng đợi tin nhắn). Sử dụng Redis xuyên suốt các lớp này giúp giảm chi phí hoạt động và cho phép các nhà phát triển sử dụng lại các công nghệ mà họ đã biết.
Hãy xem qua mã và thử thực hiện nó. Tôi hy vọng điều này sẽ giúp chứng minh tính linh hoạt và tính linh hoạt của Redis trong các dịch vụ miền và cơ sở hạ tầng cũng như chứng minh cách nó có thể được sử dụng ngoài bộ nhớ đệm.
Hãy cho tôi biết nó diễn ra như thế nào trên Twitter:@ martinez099.