Habr đang thay đổi thế giới. Chúng tôi đã viết blog được hơn một năm nay. Khoảng sáu tháng trước, chúng tôi đã nhận được phản hồi hoàn toàn hợp lý từ Khabrovites: “Dodo, bạn nói ở mọi nơi rằng bạn có hệ thống của riêng mình. Và hệ thống này là gì? Và tại sao một chuỗi cửa hàng bánh pizza cần nó?
Chúng tôi đã ngồi, suy nghĩ và nhận ra rằng bạn đúng. Chúng tôi cố gắng giải thích mọi thứ trên ngón tay của mình, nhưng nó xuất hiện thành từng mảnh vụn và không có mô tả đầy đủ nào về hệ thống. Thế là bắt đầu một hành trình dài thu thập thông tin, tìm kiếm tác giả và viết một loạt bài về Dodo IS. Đi nào!
Lời cảm ơn: Cảm ơn bạn đã chia sẻ phản hồi của bạn với chúng tôi. Nhờ anh ấy, cuối cùng chúng tôi đã mô tả hệ thống, biên soạn một radar kỹ thuật và sẽ sớm đưa ra một mô tả lớn về các quy trình của chúng tôi. Nếu không có bạn, chúng tôi sẽ ngồi đó thêm 5 năm nữa.
Series bài viết "Dodo IS là gì?" kể về:
- Đá nguyên khối ban đầu ở Dodo IS (2011-2015). (Trong tiến trình...)
- Con đường văn phòng hỗ trợ: căn cứ và xe buýt riêng biệt. (bạn đang ở đây)
- Con đường phía khách hàng: mặt tiền trên cơ sở (2016-2017). (Trong tiến trình...)
- Lịch sử của microservice thực sự. (2018-2019). (Trong tiến trình...)
- Đã cưa xong khối đá nguyên khối và ổn định kiến trúc. (Trong tiến trình...)
Nếu bạn muốn biết điều gì khác - hãy viết trong phần bình luận.
Ý kiến về mô tả theo trình tự thời gian từ tác giả
Tôi thường xuyên tổ chức một cuộc họp cho nhân viên mới về chủ đề "Kiến trúc hệ thống". Chúng tôi gọi đó là “Giới thiệu về Kiến trúc Dodo IS” và đây là một phần của quy trình giới thiệu dành cho các nhà phát triển mới. Nói dưới hình thức này hay hình thức khác về kiến trúc của chúng tôi, về các đặc điểm của nó, tôi đã sinh ra một cách tiếp cận lịch sử nhất định đối với mô tả.
Theo truyền thống, chúng tôi xem hệ thống như một tập hợp các thành phần (kỹ thuật hoặc cấp cao hơn), các mô-đun kinh doanh tương tác với nhau để đạt được một số mục tiêu. Và nếu quan điểm như vậy là hợp lý cho thiết kế, thì nó không hoàn toàn phù hợp để mô tả và hiểu. Có một số lý do ở đây:
- Thực tế khác với những gì trên giấy tờ. Không phải mọi thứ diễn ra như kế hoạch. Và chúng tôi quan tâm đến việc nó thực sự diễn ra và hoạt động như thế nào.
- Trình bày thông tin nhất quán. Trên thực tế, bạn có thể đi theo trình tự thời gian từ đầu đến trạng thái hiện tại.
- Từ đơn giản đến phức tạp. Không phổ biến, nhưng trong trường hợp của chúng tôi thì có. Kiến trúc đã chuyển từ những cách tiếp cận đơn giản hơn sang những cách tiếp cận phức tạp hơn. Thông thường thông qua sự phức tạp, các vấn đề về tốc độ triển khai và tính ổn định đã được giải quyết, cũng như hàng chục thuộc tính khác từ danh sách các yêu cầu phi chức năng ( nói rõ về độ phức tạp tương phản với các yêu cầu khác).
Vào năm 2011, kiến trúc Dodo IS trông như thế này:
Đến năm 2020, nó trở nên phức tạp hơn một chút và trở thành như thế này:
Quá trình tiến hóa này diễn ra như thế nào? Tại sao các bộ phận khác nhau của hệ thống cần thiết? Những quyết định kiến trúc đã được thực hiện và tại sao? Hãy cùng tìm hiểu trong loạt bài viết này.
Những vấn đề đầu tiên của năm 2016: tại sao các dịch vụ nên rời khỏi nguyên khối
Các bài viết đầu tiên trong chu kỳ sẽ nói về các dịch vụ đầu tiên tách khỏi khối nguyên khối. Để bạn hiểu rõ hơn, tôi sẽ cho bạn biết những vấn đề mà chúng tôi gặp phải trong hệ thống vào đầu năm 2016 mà chúng tôi phải giải quyết khi tách các dịch vụ.
Một cơ sở dữ liệu MySql duy nhất, trong đó tất cả các ứng dụng tồn tại vào thời điểm đó trong Dodo IS đã ghi hồ sơ của chúng. Hậu quả là:
- Tải nặng (với 85% yêu cầu được đọc).
- Cơ sở đã phát triển. Bởi vì điều này, chi phí và hỗ trợ của nó đã trở thành một vấn đề.
- Một điểm thất bại. Nếu một ứng dụng ghi vào cơ sở dữ liệu đột nhiên bắt đầu làm điều đó tích cực hơn, thì các ứng dụng khác sẽ tự cảm nhận được điều đó.
- Không hiệu quả trong lưu trữ và truy vấn. Thông thường, dữ liệu được lưu trữ trong một số cấu trúc thuận tiện cho một số tình huống nhưng không phù hợp với những tình huống khác. Các chỉ mục tăng tốc một số thao tác, nhưng có thể làm chậm các thao tác khác.
- Một số vấn đề đã được loại bỏ bằng cách tạo vội vàng các bộ đệm và bản sao đọc cho các cơ sở (đây sẽ là một bài viết riêng), nhưng chúng chỉ cho phép chúng có thêm thời gian và không giải quyết được vấn đề một cách cơ bản.
Vấn đề là sự hiện diện của chính khối nguyên khối. Hậu quả là:
- Bản phát hành duy nhất và hiếm.
- Khó khăn trong việc phát triển chung của một số lượng lớn người dân.
- Không có khả năng đưa vào các công nghệ mới, khuôn khổ và thư viện mới.
Các vấn đề với đế và đá nguyên khối đã được mô tả nhiều lần, chẳng hạn như trong bối cảnh xảy ra sự cố vào đầu năm 2018 (, и ), vì vậy tôi sẽ không ở quá nhiều. Hãy để tôi nói rằng chúng tôi muốn linh hoạt hơn khi phát triển dịch vụ. Trước hết, điều này liên quan đến những thứ được tải nhiều nhất và root trong toàn bộ hệ thống - Auth và Tracker.
Con đường Back Office: Cơ sở và xe buýt riêng biệt
điều hướng chương
Đề án nguyên khối 2016
Dưới đây là các khối chính của Dodo IS 2016 nguyên khối và ngay bên dưới là bảng điểm các nhiệm vụ chính của chúng.
Giao hàng thu ngân. Kế toán nhân viên giao hàng, phát lệnh cho nhân viên giao hàng.
Trung tâm liên lạc. Chấp nhận các đơn đặt hàng thông qua các nhà điều hành.
Chỗ. Các trang web của chúng tôi (dodopizza.ru, dodopizza.co.uk, dodopizza.by, v.v.).
Xác thực. Dịch vụ ủy quyền và xác thực cho văn phòng hỗ trợ.
Theo dõi. Đặt hàng theo dõi trong nhà bếp. Dịch vụ đánh dấu trạng thái sẵn sàng khi chuẩn bị đơn hàng.
Quầy thu ngân của Nhà hàng. Nhận đơn đặt hàng trong một nhà hàng, giao diện thu ngân.
Xuất khẩu. Tải lên các báo cáo trong 1C cho kế toán.
Thông báo và hóa đơn. Ra lệnh bằng giọng nói trong bếp (ví dụ: “Pizza mới về”) + in hóa đơn cho người giao hàng.
Quản lý ca. Các giao diện phục vụ công việc của trưởng ca: danh sách đơn hàng, biểu đồ hiệu suất, chuyển nhân viên sang ca.
Quản lý văn phòng. Giao diện cho công việc của bên nhận quyền và người quản lý: tiếp nhận nhân viên, báo cáo về công việc của tiệm bánh pizza.
Bảng điểm nhà hàng. Menu hiển thị trên TV trong tiệm bánh pizza.
quản trị viên. Cài đặt trong một tiệm bánh pizza cụ thể: thực đơn, giá cả, kế toán, mã khuyến mãi, khuyến mãi, biểu ngữ trang web, v.v.
Tài khoản cá nhân của nhân viên. Lịch làm việc của nhân viên, thông tin về nhân viên.
Ban động lực nhà bếp. Một màn hình riêng treo trong bếp và hiển thị tốc độ của những người làm bánh pizza.
Giao tiếp. Gửi sms và email.
Lưu trữ tập tin. Dịch vụ riêng để nhận và phát hành các tệp tĩnh.
Những nỗ lực đầu tiên để giải quyết vấn đề đã giúp chúng tôi, nhưng chúng chỉ là một thời gian nghỉ ngơi tạm thời. Chúng không trở thành giải pháp hệ thống, vì vậy rõ ràng là phải làm gì đó với các căn cứ. Ví dụ: để chia cơ sở dữ liệu chung thành nhiều cơ sở dữ liệu chuyên biệt hơn.
Bắt đầu dỡ bỏ nguyên khối: Phân tách xác thực và trình theo dõi
Các dịch vụ chính sau đó được ghi và đọc từ cơ sở dữ liệu nhiều hơn các dịch vụ khác:
- xác thực. Dịch vụ ủy quyền và xác thực cho văn phòng hỗ trợ.
- người theo dõi. Đặt hàng theo dõi trong nhà bếp. Dịch vụ đánh dấu trạng thái sẵn sàng khi chuẩn bị đơn hàng.
Auth làm gì?
Auth là một dịch vụ thông qua đó người dùng đăng nhập vào văn phòng hỗ trợ (có một lối vào độc lập riêng ở phía máy khách). Nó cũng được yêu cầu trong yêu cầu để đảm bảo rằng các quyền truy cập được yêu cầu có mặt và các quyền này không thay đổi kể từ lần đăng nhập cuối cùng. Thông qua đó, các thiết bị đi vào tiệm bánh pizza.
Ví dụ: chúng tôi muốn mở một màn hình với trạng thái của các đơn hàng đã hoàn thành trên TV treo trong hội trường. Sau đó, chúng tôi mở auth.dodopizza.ru, chọn "Đăng nhập với tư cách thiết bị", một mã xuất hiện có thể được nhập vào một trang đặc biệt trên máy tính của người quản lý ca, cho biết loại thiết bị (thiết bị). Bản thân TV sẽ chuyển sang giao diện mong muốn của tiệm bánh pizza và bắt đầu hiển thị tên của những khách hàng có đơn đặt hàng đã sẵn sàng ở đó.
Các tải từ đâu?
Mỗi người dùng đã đăng nhập của văn phòng hỗ trợ sẽ truy cập cơ sở dữ liệu, đến bảng người dùng cho từng yêu cầu, lấy người dùng ra thông qua truy vấn sql và kiểm tra xem anh ta có quyền truy cập và quyền cần thiết đối với trang này hay không.
Mỗi thiết bị chỉ làm điều tương tự với bảng thiết bị, kiểm tra vai trò và quyền truy cập của thiết bị. Một số lượng lớn các yêu cầu đối với cơ sở dữ liệu chủ dẫn đến việc tải và lãng phí tài nguyên của cơ sở dữ liệu chung cho các hoạt động này.
Đang dỡ xác thực
Auth có một miền biệt lập, nghĩa là dữ liệu về người dùng, thông tin đăng nhập hoặc thiết bị đi vào dịch vụ (tại thời điểm hiện tại) và vẫn ở đó. Nếu ai đó cần chúng, thì anh ta sẽ đến dịch vụ này để lấy dữ liệu.
ĐÃ TỪNG LÀ. Kế hoạch ban đầu của công việc như sau:
Tôi muốn giải thích một chút về cách nó hoạt động:
- Một yêu cầu từ bên ngoài đến phần phụ trợ (có Asp.Net MVC), mang theo cookie phiên, được sử dụng để lấy dữ liệu phiên từ Redis (1). Nó chứa thông tin về các quyền truy cập và sau đó quyền truy cập vào bộ điều khiển có mở (3,4) hay không.
- Nếu không có quyền truy cập, bạn cần thực hiện thủ tục ủy quyền. Ở đây, để đơn giản, nó được hiển thị như một phần của đường dẫn trong cùng một thuộc tính, mặc dù nó là phần chuyển tiếp sang trang đăng nhập. Trong trường hợp kịch bản tích cực, chúng tôi sẽ nhận được một phiên hoàn thành chính xác và chuyển đến Bộ điều khiển Backoffice.
- Nếu có dữ liệu, thì bạn cần kiểm tra xem nó có liên quan trong cơ sở dữ liệu người dùng không. Vai trò của anh ấy đã thay đổi, nên bây giờ anh ấy không được phép vào trang? Trong trường hợp này, sau khi nhận được phiên (1), bạn cần truy cập trực tiếp vào cơ sở dữ liệu và kiểm tra quyền truy cập của người dùng bằng lớp logic xác thực (2). Tiếp theo, đến trang đăng nhập hoặc vào bộ điều khiển. Một hệ thống đơn giản như vậy, nhưng không hoàn toàn chuẩn.
- Nếu tất cả các thủ tục được thông qua, thì chúng ta sẽ bỏ qua phần logic trong bộ điều khiển và phương thức.
Dữ liệu người dùng được tách biệt với tất cả các dữ liệu khác, nó được lưu trữ trong một bảng thành viên riêng biệt, các chức năng từ lớp logic AuthService cũng có thể trở thành các phương thức api. Ranh giới miền được xác định khá rõ ràng: người dùng, vai trò của họ, dữ liệu truy cập, cấp và thu hồi quyền truy cập. Mọi thứ trông để nó có thể được đưa ra trong một dịch vụ riêng biệt.
TRỞ NÊN. Vì vậy, họ đã làm:
Cách tiếp cận này có một số vấn đề. Ví dụ: gọi một phương thức bên trong một quy trình không giống như gọi một dịch vụ bên ngoài qua http. Độ trễ, độ tin cậy, khả năng bảo trì, tính minh bạch của hoạt động là hoàn toàn khác nhau. Andrey Morevskiy đã nói chi tiết hơn về những vấn đề như vậy trong báo cáo của mình. .
Dịch vụ xác thực và cùng với nó là dịch vụ thiết bị được sử dụng cho văn phòng hỗ trợ, tức là cho các dịch vụ và giao diện được sử dụng trong sản xuất. Xác thực cho các dịch vụ khách (như trang web hoặc ứng dụng dành cho thiết bị di động) diễn ra riêng biệt mà không cần sử dụng Auth. Việc phân tách mất khoảng một năm và bây giờ chúng tôi lại xử lý chủ đề này, chuyển hệ thống sang các dịch vụ xác thực mới (với các giao thức tiêu chuẩn).
Tại sao cuộc chia ly lại kéo dài như vậy?
Có rất nhiều vấn đề trên đường đi khiến chúng tôi chậm lại:
- Chúng tôi muốn chuyển dữ liệu người dùng, thiết bị và xác thực từ cơ sở dữ liệu dành riêng cho từng quốc gia thành một. Để làm điều này, chúng tôi phải dịch tất cả các bảng và cách sử dụng từ mã định danh int sang mã định danh UUId toàn cầu (gần đây đã làm lại mã này và dự án mã nguồn mở ). Việc lưu trữ dữ liệu người dùng (vì đó là thông tin cá nhân) có những hạn chế và đối với một số quốc gia, cần phải lưu trữ chúng một cách riêng biệt. Nhưng id toàn cầu của người dùng phải là.
- Nhiều bảng trong cơ sở dữ liệu có thông tin kiểm tra về người dùng đã thực hiện thao tác. Điều này đòi hỏi một cơ chế bổ sung cho tính nhất quán.
- Sau khi tạo ra các dịch vụ api, đã có một khoảng thời gian dài và dần dần chuyển đổi sang hệ thống khác. Việc chuyển đổi phải diễn ra liền mạch đối với người dùng và yêu cầu thao tác thủ công.
Sơ đồ đăng ký thiết bị trong tiệm bánh pizza:
Kiến trúc chung sau khi trích xuất dịch vụ Auth và Thiết bị:
Ghi. Đối với năm 2020, chúng tôi đang phát triển phiên bản Auth mới, dựa trên tiêu chuẩn ủy quyền OAuth 2.0. Tiêu chuẩn này khá phức tạp, nhưng nó rất hữu ích để phát triển dịch vụ xác thực chuyển tiếp. Trong bài viết "» chúng tôi Alexey Chernyaev đã cố gắng trình bày về tiêu chuẩn một cách đơn giản và rõ ràng nhất có thể để bạn tiết kiệm thời gian nghiên cứu nó.
Trình theo dõi làm gì?
Bây giờ về dịch vụ thứ hai được tải. Trình theo dõi thực hiện một vai trò kép:
- Một mặt, nhiệm vụ của nó là chỉ cho nhân viên trong bếp biết đơn hàng nào đang được thực hiện, sản phẩm nào cần nấu ngay.
- Mặt khác, để số hóa tất cả các quy trình trong nhà bếp.
Khi một sản phẩm mới xuất hiện trong một đơn đặt hàng (ví dụ: bánh pizza), sản phẩm đó sẽ chuyển đến trạm theo dõi Bán hàng. Tại trạm này, có một người thợ làm bánh pizza lấy một chiếc bánh có kích thước yêu cầu và cán mỏng, sau đó anh ta ghi chú trên bảng theo dõi rằng mình đã hoàn thành nhiệm vụ và chuyển phần đế bột đã cán sang trạm tiếp theo - “Khởi xướng” .
Ở đó, người làm bánh pizza tiếp theo đổ đầy bánh pizza, sau đó ghi chú trên bảng rằng anh ta đã hoàn thành nhiệm vụ của mình và đặt bánh pizza vào lò nướng (đây cũng là một trạm riêng phải được ghi chú trên bảng). Một hệ thống như vậy đã có ngay từ đầu ở Dodo và ngay từ khi Dodo IS bắt đầu tồn tại. Nó cho phép bạn theo dõi đầy đủ và số hóa tất cả các giao dịch. Ngoài ra, trình theo dõi gợi ý cách nấu một sản phẩm cụ thể, hướng dẫn từng loại sản phẩm theo sơ đồ sản xuất, lưu trữ thời gian nấu tối ưu cho sản phẩm và theo dõi tất cả các hoạt động trên sản phẩm.
Đây là cách màn hình của máy tính bảng trông giống như ở trạm theo dõi "Raskatka"
Các tải từ đâu?
Mỗi tiệm bánh pizza có khoảng năm máy tính bảng với thiết bị theo dõi. Vào năm 2016, chúng tôi có hơn 100 cửa hàng bánh pizza (và hiện tại là hơn 600). Mỗi máy tính bảng đưa ra yêu cầu đến phần phụ trợ cứ sau 10 giây và xóa dữ liệu từ bảng đơn hàng (kết nối với khách hàng và địa chỉ), thành phần đơn hàng (kết nối với sản phẩm và chỉ dẫn về số lượng), bảng kế toán động lực ( thời gian nhấn được theo dõi trong đó). Khi một nhà sản xuất bánh pizza nhấp vào một sản phẩm trên trình theo dõi, các mục trong tất cả các bảng này sẽ được cập nhật. Bảng đặt hàng nói chung, nó cũng chứa các phần chèn khi chấp nhận đơn đặt hàng, cập nhật từ các phần khác của hệ thống và nhiều bài đọc, chẳng hạn như trên TV treo trong tiệm bánh pizza và hiển thị các đơn đặt hàng đã hoàn thành cho khách hàng.
Trong khoảng thời gian vật lộn với tải, khi mọi thứ và mọi thứ được lưu vào bộ đệm và chuyển sang bản sao không đồng bộ của cơ sở, các hoạt động này với trình theo dõi tiếp tục chuyển đến cơ sở chính. Không được có bất kỳ độ trễ nào, dữ liệu phải được cập nhật, không đồng bộ là không thể chấp nhận được.
Ngoài ra, việc thiếu các bảng và chỉ mục riêng trên chúng không cho phép viết các truy vấn cụ thể hơn phù hợp với mục đích sử dụng của chúng. Ví dụ: một trình theo dõi có thể có chỉ mục cho một tiệm bánh pizza trên bảng đặt hàng có thể hiệu quả. Chúng tôi luôn xóa các đơn đặt hàng bánh pizza khỏi cơ sở dữ liệu theo dõi. Đồng thời, để nhận được một đơn đặt hàng, việc nó rơi vào tiệm bánh pizza nào không quá quan trọng, điều quan trọng hơn là khách hàng nào đã thực hiện đơn hàng này. Và có nghĩa là chỉ mục trên máy khách là cần thiết. Trình theo dõi cũng không cần lưu id của biên lai được in hoặc các chương trình khuyến mãi tiền thưởng liên quan đến đơn hàng trong bảng đơn hàng. Thông tin này không được dịch vụ theo dõi của chúng tôi quan tâm. Trong một cơ sở dữ liệu nguyên khối phổ biến, các bảng chỉ có thể là sự thỏa hiệp giữa tất cả người dùng. Đây là một trong những vấn đề ban đầu.
ĐÃ TỪNG LÀ. Kiến trúc ban đầu là:
Ngay cả sau khi được tách thành các quy trình riêng biệt, hầu hết cơ sở mã vẫn là chung cho các dịch vụ khác nhau. Mọi thứ bên dưới bộ điều khiển đều đơn lẻ và nằm trong cùng một kho lưu trữ. Chúng tôi đã sử dụng các phương pháp chung về dịch vụ, kho lưu trữ, cơ sở chung, trong đó đặt các bảng chung.
Trình theo dõi dỡ hàng
Vấn đề chính với trình theo dõi là dữ liệu phải được đồng bộ hóa giữa các cơ sở dữ liệu khác nhau. Đây cũng là điểm khác biệt chính của nó so với việc tách dịch vụ Auth, thứ tự và trạng thái của nó có thể thay đổi và sẽ hiển thị ở các dịch vụ khác nhau.
Chúng tôi chấp nhận đơn đặt hàng tại Thanh toán của Nhà hàng (đây là một dịch vụ), nó được lưu trữ trong cơ sở dữ liệu ở trạng thái "Đã chấp nhận". Sau đó, anh ta sẽ đến trình theo dõi, nơi anh ta sẽ thay đổi trạng thái của mình nhiều lần nữa: từ “Nhà bếp” thành “Đã đóng gói”. Đồng thời, một số tác động bên ngoài từ giao diện Thu ngân hoặc Quản lý ca có thể xảy ra với đơn hàng. Tôi sẽ đưa ra các trạng thái đơn hàng với mô tả của chúng trong bảng:
Sơ đồ thay đổi trạng thái đơn đặt hàng trông như thế này:
Trạng thái thay đổi giữa các hệ thống khác nhau. Và ở đây, trình theo dõi không phải là hệ thống cuối cùng trong đó dữ liệu được đóng lại. Chúng tôi đã thấy một số cách tiếp cận khả thi để phân vùng trong trường hợp như vậy:
- Chúng tôi tập trung tất cả các hành động đặt hàng trong một dịch vụ. Trong trường hợp của chúng tôi, tùy chọn này yêu cầu quá nhiều dịch vụ để hoạt động với đơn đặt hàng. Nếu chúng tôi dừng lại ở đó, chúng tôi sẽ nhận được khối thứ hai. Chúng tôi sẽ không giải quyết vấn đề.
- Một hệ thống thực hiện cuộc gọi đến một hệ thống khác. Tùy chọn thứ hai đã thú vị hơn. Nhưng với nó, chuỗi cuộc gọi là có thể (), tính kết nối của các thành phần cao hơn, khó quản lý hơn.
- Chúng tôi tổ chức các sự kiện và mỗi dịch vụ giao tiếp với dịch vụ khác thông qua các sự kiện này. Do đó, tùy chọn thứ ba đã được chọn, theo đó tất cả các dịch vụ bắt đầu trao đổi các sự kiện với nhau.
Việc chúng tôi chọn tùy chọn thứ ba có nghĩa là trình theo dõi sẽ có cơ sở dữ liệu riêng và đối với mỗi thay đổi theo thứ tự, nó sẽ gửi một sự kiện về điều này, mà các dịch vụ khác đăng ký và sự kiện này cũng rơi vào cơ sở dữ liệu chính. Để làm điều này, chúng tôi cần một số dịch vụ đảm bảo việc gửi tin nhắn giữa các dịch vụ.
Vào thời điểm đó, chúng tôi đã có RabbitMQ trong ngăn xếp, do đó, quyết định cuối cùng là sử dụng nó làm trình trung chuyển tin nhắn. Sơ đồ hiển thị quá trình chuyển đổi đơn hàng từ Nhân viên thu ngân nhà hàng qua Trình theo dõi, nơi đơn hàng thay đổi trạng thái và hiển thị trên giao diện Đơn hàng của Người quản lý. TRỞ THÀNH:
Đường dẫn thứ tự từng bước
Đường dẫn đặt hàng bắt đầu tại một trong các dịch vụ nguồn đặt hàng. Đây là Thu ngân của nhà hàng:
- Khi thanh toán, đơn đặt hàng đã hoàn toàn sẵn sàng và đã đến lúc gửi nó đến trình theo dõi. Sự kiện mà trình theo dõi được đăng ký sẽ được ném ra.
- Trình theo dõi, chấp nhận một đơn đặt hàng cho chính nó, lưu nó vào cơ sở dữ liệu của chính nó, tạo sự kiện “Đơn hàng được chấp nhận bởi Trình theo dõi” và gửi nó đến RMQ.
- Có một số trình xử lý đã đăng ký xe buýt sự kiện cho mỗi đơn đặt hàng. Đối với chúng tôi, thứ tạo nên sự đồng bộ với đế nguyên khối là rất quan trọng.
- Trình xử lý nhận một sự kiện, chọn dữ liệu quan trọng từ sự kiện đó: trong trường hợp của chúng tôi, đây là trạng thái của đơn hàng "Được Trình theo dõi chấp nhận" và cập nhật thực thể đơn hàng của nó trong cơ sở dữ liệu chính.
Nếu ai đó cần một đơn đặt hàng từ các đơn đặt hàng bảng nguyên khối, thì bạn cũng có thể đọc nó từ đó. Ví dụ: giao diện Đơn đặt hàng trong Trình quản lý ca cần điều này:
Tất cả các dịch vụ khác cũng có thể đăng ký đặt hàng các sự kiện từ trình theo dõi để sử dụng chúng cho chính họ.
Nếu sau một thời gian, đơn đặt hàng được đưa vào hoạt động, thì trạng thái của nó trước tiên sẽ thay đổi trong cơ sở dữ liệu (cơ sở dữ liệu của Trình theo dõi), sau đó sự kiện "Đang đặt hàng" sẽ được tạo ngay lập tức. Nó cũng được đưa vào RMQ, từ đó nó được đồng bộ hóa trong cơ sở dữ liệu nguyên khối và được phân phối tới các dịch vụ khác. Có thể có nhiều vấn đề khác nhau trên đường đi, bạn có thể tìm thêm chi tiết về chúng trong báo cáo của Zhenya Peshkov .
Kiến trúc cuối cùng sau những thay đổi trong Auth và Tracker
Tổng hợp kết quả trung gian: Ban đầu, tôi có ý tưởng gói lịch sử chín năm của hệ thống Dodo IS vào một bài báo. Tôi muốn nói một cách nhanh chóng và đơn giản về các giai đoạn tiến hóa. Tuy nhiên, khi ngồi xem tài liệu, tôi nhận ra rằng mọi thứ phức tạp và thú vị hơn nhiều so với vẻ ngoài của nó.
Suy nghĩ về những lợi ích (hoặc sự thiếu hụt) của những tài liệu đó, tôi đã đi đến kết luận rằng sự phát triển liên tục là không thể nếu không có biên niên sử đầy đủ về các sự kiện, hồi tưởng chi tiết và phân tích các quyết định trong quá khứ của tôi.
Tôi hy vọng rằng nó hữu ích và thú vị cho bạn khi tìm hiểu về con đường của chúng tôi. Bây giờ tôi phải đối mặt với sự lựa chọn mô tả phần nào của hệ thống Dodo IS trong bài viết tiếp theo: viết bình luận hoặc bình chọn.
Chỉ những người dùng đã đăng ký mới có thể tham gia khảo sát. , xin vui lòng.
Phần nào của Dodo IS mà bạn muốn biết trong bài viết tiếp theo?
-
24,1%Đá nguyên khối ban đầu ở Dodo IS (2011-2015)14
-
24,1%Những vấn đề đầu tiên và giải pháp (2015-2016)14
-
20,7%Lộ trình phía khách hàng: mặt đứng trên đế (2016-2017)12
-
36,2%Lịch sử của microservice thực tế (2018-2019)21
-
44,8%Hoàn thành cưa nguyên khối và ổn định kiến trúc26
-
29,3%Về các kế hoạch tiếp theo để phát triển hệ thống17
-
19,0%Tôi không muốn biết gì về Dodo IS11
58 người dùng bình chọn. 6 người dùng bỏ phiếu trắng.
Nguồn: www.habr.com