Lịch sử của Kiến trúc Dodo IS: Nguyên khối ban đầu

Hoặc mọi công ty không hài lòng với một khối nguyên khối đều không hạnh phúc theo cách riêng của mình.

Sự phát triển của hệ thống Dodo IS bắt đầu ngay lập tức, giống như việc kinh doanh Dodo Pizza, vào năm 2011. Nó dựa trên ý tưởng số hóa hoàn toàn và toàn bộ các quy trình kinh doanh và một mình, mà thậm chí vào năm 2011 đã gây ra rất nhiều câu hỏi và sự hoài nghi. Nhưng trong 9 năm nay, chúng tôi đã đi theo con đường này - với sự phát triển của chính chúng tôi, bắt đầu bằng một khối đá nguyên khối.

Bài viết này là “câu trả lời” cho câu hỏi “Tại sao phải viết lại kiến ​​trúc và thực hiện những thay đổi quy mô lớn và dài hạn như vậy?” quay lại bài viết trước "Lịch sử kiến ​​trúc Dodo IS: Con đường của Back Office". Tôi sẽ bắt đầu với việc quá trình phát triển Dodo IS bắt đầu như thế nào, kiến ​​trúc ban đầu trông như thế nào, các mô-đun mới xuất hiện như thế nào và vì những vấn đề gì mà những thay đổi quy mô lớn phải được thực hiện.

Series bài viết "Dodo IS là gì?" kể về:

1. Đá nguyên khối ban đầu ở Dodo IS (2011-2015). (bạn đang ở đây)

2. Con đường Back Office: Cơ sở và xe buýt riêng biệt.

3. Con đường phía khách hàng: mặt tiền trên cơ sở (2016-2017). (Trong tiến trình...)

4. Lịch sử của microservice thực sự. (2018-2019). (Trong tiến trình...)

5. Đã cưa xong khối đá nguyên khối và ổn định kiến ​​trúc. (Trong tiến trình...)

kiến trúc ban đầu

Vào năm 2011, kiến ​​trúc Dodo IS trông như thế này:

Mô-đun đầu tiên trong kiến ​​trúc là chấp nhận đơn đặt hàng. Quá trình kinh doanh là:

• khách hàng gọi tiệm bánh pizza;

• người quản lý nhấc máy;

• chấp nhận một đơn đặt hàng qua điện thoại;

• điền nó song song trong giao diện chấp nhận đơn hàng: thông tin về khách hàng, dữ liệu về chi tiết đơn hàng, địa chỉ giao hàng được tính đến. 

Giao diện của hệ thống thông tin trông như thế này ...

Phiên bản đầu tiên từ tháng 2011 năm XNUMX:

Cải thiện đôi chút vào tháng 2012 năm XNUMX

Hệ thống thông tin Dodo Pizza Giao hàng Nhà hàng Pizza

Nguồn lực để phát triển mô-đun lấy đơn hàng đầu tiên bị hạn chế. Chúng tôi phải làm rất nhiều, nhanh chóng và với một nhóm nhỏ. Một nhóm nhỏ là 2 nhà phát triển đặt nền móng cho toàn bộ hệ thống trong tương lai.

Quyết định đầu tiên của họ quyết định số phận của kho công nghệ:

• Backend trên ASP.NET MVC, ngôn ngữ C#. Các nhà phát triển là dotnetchiki, ngăn xếp này quen thuộc và dễ chịu với họ.

• Giao diện người dùng trên Bootstrap và JQuery: giao diện người dùng trên các kiểu và tập lệnh tự viết. 

• Cơ sở dữ liệu MySQL: không tốn giấy phép, dễ sử dụng.

• Máy chủ trên Windows Server, vì .NET sau đó chỉ có thể dưới Windows (chúng tôi sẽ không thảo luận về Mono).

Về mặt vật lý, tất cả những điều này đã được thể hiện trong “sự cống hiến cho người dẫn chương trình”. 

Kiến trúc ứng dụng nhận đơn đặt hàng

Sau đó, mọi người đã nói về microservice và SOA đã được sử dụng trong các dự án lớn trong 5 năm, chẳng hạn như WCF đã được phát hành vào năm 2006. Nhưng sau đó họ đã chọn một giải pháp đáng tin cậy và đã được chứng minh.

Nó đây.

Asp.Net MVC là Razor, theo yêu cầu từ biểu mẫu hoặc từ máy khách, hiển thị trang HTML với kết xuất máy chủ. Trên máy khách, các tập lệnh CSS và JS đã hiển thị thông tin và nếu cần, thực hiện các yêu cầu AJAX thông qua JQuery.

Các yêu cầu trên máy chủ kết thúc trong các lớp * Trình điều khiển, nơi xử lý và tạo trang HTML cuối cùng diễn ra trong phương thức. Bộ điều khiển đưa ra yêu cầu đối với một lớp logic được gọi là *Dịch vụ. Mỗi dịch vụ tương ứng với một số khía cạnh của doanh nghiệp:

• Ví dụ, DepartmentStructureService cung cấp thông tin về tiệm bánh pizza, về các phòng ban. Một bộ phận là một nhóm các cửa hàng bánh pizza được điều hành bởi một bên nhận quyền duy nhất.

• ReceiveOrdersService đã chấp nhận và tính toán thành phần của đơn đặt hàng.

• Và SmsService đã gửi SMS bằng cách gọi các dịch vụ API để gửi SMS.

Dịch vụ xử lý dữ liệu từ cơ sở dữ liệu, lưu trữ logic nghiệp vụ. Mỗi dịch vụ có một hoặc nhiều *Kho lưu trữ với tên thích hợp. Chúng đã chứa các truy vấn tới các thủ tục được lưu trữ trong cơ sở dữ liệu và một lớp trình ánh xạ. Có logic kinh doanh trong các kho lưu trữ, đặc biệt là rất nhiều trong những kho đã phát hành dữ liệu báo cáo. ORM không được sử dụng, mọi người đều dựa vào sql viết tay. 

Ngoài ra còn có một lớp của mô hình miền và các lớp trợ giúp phổ biến, chẳng hạn như lớp Order lưu trữ đơn hàng. Ở cùng một nơi, trong lớp, có một trình trợ giúp để chuyển đổi văn bản hiển thị theo đơn vị tiền tệ đã chọn.

Tất cả điều này có thể được đại diện bởi một mô hình như vậy:

Cách đặt hàng

Hãy xem xét một cách ban đầu đơn giản hóa để tạo một đơn đặt hàng như vậy.

Ban đầu, trang web là tĩnh. Nó có giá trên đó, và trên cùng - một số điện thoại và dòng chữ "Nếu bạn muốn ăn pizza - hãy gọi số này và đặt hàng." Để đặt hàng, chúng ta cần thực hiện một quy trình đơn giản: 

• Khách hàng truy cập một trang web tĩnh với giá cả, chọn sản phẩm và gọi đến số được liệt kê trên trang web.

• Khách hàng đặt tên cho các sản phẩm họ muốn thêm vào đơn đặt hàng.

• Cung cấp địa chỉ và tên của mình.

• Nhà điều hành chấp nhận đơn đặt hàng.

• Đơn hàng được hiển thị trong giao diện đơn hàng được chấp nhận.

Tất cả bắt đầu với việc hiển thị menu. Người điều hành người dùng đã đăng nhập chỉ chấp nhận một đơn đặt hàng tại một thời điểm. Do đó, giỏ hàng nháp có thể được lưu trữ trong phiên của anh ấy (phiên của người dùng được lưu trong bộ nhớ). Có đối tượng Cart chứa sản phẩm và thông tin khách hàng.

Khách hàng đặt tên sản phẩm, nhân viên vận hành click vào + bên cạnh sản phẩm và yêu cầu được gửi đến máy chủ. Thông tin về sản phẩm được lấy ra từ cơ sở dữ liệu và thông tin về sản phẩm được thêm vào giỏ hàng.

Ghi. Có, ở đây bạn không thể lấy sản phẩm từ cơ sở dữ liệu mà chuyển sản phẩm từ giao diện người dùng. Nhưng để rõ ràng, tôi đã chỉ ra chính xác đường dẫn từ cơ sở dữ liệu. 

Tiếp theo, nhập địa chỉ và tên của khách hàng. 

Khi bạn nhấp vào "Tạo đơn hàng":

• Yêu cầu được gửi đến OrderController.SaveOrder().

• Chúng tôi lấy Giỏ hàng từ phiên, có những sản phẩm với số lượng chúng tôi cần.

• Chúng tôi bổ sung Cart với thông tin về khách hàng và chuyển nó đến phương thức AddOrder của lớp ReceiveOrderService, nơi nó được lưu vào cơ sở dữ liệu. 

• Cơ sở dữ liệu có các bảng với đơn đặt hàng, thành phần của đơn đặt hàng, khách hàng và tất cả chúng đều được kết nối.

• Giao diện hiển thị đơn đặt hàng đi và kéo ra các đơn đặt hàng mới nhất và hiển thị chúng.

mô-đun mới

Nhận đơn đặt hàng là quan trọng và cần thiết. Bạn không thể kinh doanh bánh pizza nếu bạn không có đơn hàng bán. Do đó, hệ thống bắt đầu có được chức năng - khoảng từ năm 2012 đến 2015. Trong thời gian này, nhiều khối khác nhau của hệ thống đã xuất hiện mà tôi sẽ gọi là mô-đun, trái ngược với khái niệm dịch vụ hoặc sản phẩm. 

Mô-đun là một tập hợp các chức năng được thống nhất bởi một số mục tiêu kinh doanh chung. Đồng thời, chúng ở trong cùng một ứng dụng.

Các mô-đun có thể được gọi là các khối hệ thống. Ví dụ: đây là mô-đun báo cáo, giao diện quản trị, theo dõi thực phẩm trong nhà bếp, ủy quyền. Đây là tất cả các giao diện người dùng khác nhau, một số thậm chí có các kiểu trực quan khác nhau. Đồng thời, mọi thứ đều nằm trong khuôn khổ của một ứng dụng, một quy trình đang chạy. 

Về mặt kỹ thuật, các mô-đun được thiết kế thành Khu vực (ý tưởng như vậy thậm chí còn tồn tại trong lõi asp.net). Có các tệp riêng biệt cho giao diện người dùng, mô hình cũng như các lớp trình điều khiển của riêng chúng. Kết quả là, hệ thống đã được chuyển đổi từ ...

... vào đây:

Một số mô-đun được thực hiện bởi các trang web riêng biệt (dự án thực thi), do chức năng hoàn toàn riêng biệt và một phần do sự phát triển hơi riêng biệt, tập trung hơn. Cái này:

• Chỗ - phiên bản đầu tiên trang dodopizza.ru.

• Xuất khẩu: tải lên các báo cáo từ Dodo IS cho 1C. 

• Cá nhân - tài khoản cá nhân của nhân viên. Nó được phát triển riêng biệt và có điểm vào riêng và thiết kế riêng biệt.

• fs — một dự án lưu trữ số liệu thống kê. Sau đó, chúng tôi rời xa nó, chuyển tất cả các số liệu thống kê sang Akamai CDN. 

Phần còn lại của các khối nằm trong ứng dụng BackOffice. 

Giải thích tên:

• Cashier - Thu ngân nhà hàng.

• ShiftManager - giao diện cho vai trò "Trình quản lý ca": thống kê hoạt động về doanh số bán bánh pizza, khả năng đưa sản phẩm vào danh sách dừng, thay đổi thứ tự.

• OfficeManager - giao diện cho các vai trò "Người quản lý tiệm bánh" và "Người được nhượng quyền". Dưới đây là các chức năng được thu thập để thiết lập một tiệm bánh pizza, các chương trình khuyến mãi tiền thưởng, tiếp nhận và làm việc với nhân viên, các báo cáo.

• PublicScreens - giao diện cho TV và máy tính bảng treo trong tiệm bánh pizza. Tivi hiển thị menu, thông tin quảng cáo, tình trạng đơn hàng khi giao hàng. 

Họ đã sử dụng một lớp dịch vụ chung, một khối lớp miền Dodo.Core chung và một cơ sở chung. Đôi khi họ vẫn có thể dẫn dắt các quá trình chuyển đổi cho nhau. Bao gồm các trang web riêng lẻ, chẳng hạn như dodopizza.ru hoặc personal.dodopizza.ru, đã chuyển sang các dịch vụ chung.

Khi các mô-đun mới xuất hiện, chúng tôi đã cố gắng sử dụng lại mã dịch vụ đã tạo, các thủ tục được lưu trữ và các bảng trong cơ sở dữ liệu ở mức tối đa. 

Để hiểu rõ hơn về quy mô của các mô-đun được tạo trong hệ thống, đây là sơ đồ từ năm 2012 với các kế hoạch phát triển:

Đến năm 2015, mọi thứ đã có trên bản đồ và thậm chí nhiều thứ khác đã được sản xuất.

• Chấp nhận đơn đặt hàng đã phát triển thành một khối riêng biệt của Trung tâm liên hệ, nơi đơn đặt hàng được chấp nhận bởi nhà điều hành.

• Có những màn hình công cộng với thực đơn và thông tin được treo trong tiệm bánh pizza.

• Bếp có module tự động phát tin nhắn thoại “Pizza mới” khi có đơn hàng mới, đồng thời in hóa đơn cho nhân viên chuyển phát nhanh. Điều này giúp đơn giản hóa đáng kể các quy trình trong nhà bếp, cho phép nhân viên không bị phân tâm bởi một số lượng lớn các thao tác đơn giản.

• Đơn vị giao hàng đã trở thành một Checkout giao hàng riêng biệt, nơi đơn đặt hàng được phát hành cho người chuyển phát nhanh đã thực hiện ca làm việc trước đó. Thời gian làm việc của anh đã được tính vào để tính lương. 

Đồng thời, từ năm 2012 đến năm 2015, hơn 10 nhà phát triển đã xuất hiện, 35 tiệm bánh pizza được mở, triển khai hệ thống tới Romania và chuẩn bị cho việc mở các cửa hàng tại Hoa Kỳ. Các nhà phát triển không còn xử lý tất cả các nhiệm vụ nữa mà được chia thành các nhóm. mỗi chuyên môn hóa trong phần riêng của mình trong hệ thống. 

Vấn đề

Bao gồm cả vì kiến ​​trúc (nhưng không chỉ).

Hỗn loạn trong căn cứ

Một cơ sở là thuận tiện. Tính nhất quán có thể đạt được trong đó và phải trả giá bằng các công cụ được tích hợp trong cơ sở dữ liệu quan hệ. Làm việc với nó rất quen thuộc và thuận tiện, đặc biệt nếu có ít bảng và ít dữ liệu.

Nhưng qua 4 năm phát triển, cơ sở dữ liệu hóa ra có khoảng 600 bảng, 1500 thủ tục lưu trữ, nhiều thủ tục cũng có logic. Than ôi, các thủ tục được lưu trữ không mang lại nhiều lợi thế khi làm việc với MySQL. Chúng không được cơ sở lưu trữ trong bộ đệm và việc lưu trữ logic trong chúng làm phức tạp quá trình phát triển và gỡ lỗi. Tái sử dụng mã cũng khó khăn.

Nhiều bảng không có chỉ mục phù hợp, ở đâu đó, ngược lại, có rất nhiều chỉ mục gây khó khăn cho việc chèn. Cần phải sửa đổi khoảng 20 bảng - giao dịch để tạo đơn hàng có thể mất khoảng 3-5 giây. 

Dữ liệu trong các bảng không phải lúc nào cũng ở dạng phù hợp nhất. Ở đâu đó nó là cần thiết để làm không chuẩn hóa. Một phần của dữ liệu nhận được thường xuyên nằm trong một cột ở dạng cấu trúc XML, điều này làm tăng thời gian thực hiện, kéo dài các truy vấn và làm phức tạp quá trình phát triển.

Để cùng một bảng đã được sản xuất rất yêu cầu không đồng nhất. Các bảng phổ biến bị ảnh hưởng đặc biệt, như bảng được đề cập ở trên. đơn đặt hàng hoặc bảng tiệm pizza. Chúng được sử dụng để hiển thị các giao diện hoạt động trong nhà bếp, phân tích. Một trang web khác đã liên hệ với họ (dodopizza.ru), tại bất kỳ thời điểm nào, rất nhiều yêu cầu có thể bất ngờ đến. 

Dữ liệu không được tổng hợp và nhiều tính toán đã diễn ra nhanh chóng bằng cách sử dụng cơ sở. Điều này tạo ra các tính toán không cần thiết và tải bổ sung. 

Thường thì mã được chuyển đến cơ sở dữ liệu khi nó không thể làm như vậy. Ở đâu đó không có đủ hoạt động hàng loạt, ở đâu đó cần phải phân chia một yêu cầu thành nhiều yêu cầu thông qua mã để tăng tốc và tăng độ tin cậy. 

Sự gắn kết và che giấu trong mã

Các mô-đun được cho là chịu trách nhiệm về phần kinh doanh của họ đã không làm điều đó một cách trung thực. Một số trong số chúng có chức năng trùng lặp cho các vai trò. Ví dụ: một nhà tiếp thị địa phương chịu trách nhiệm về hoạt động tiếp thị của mạng trong thành phố của mình phải sử dụng cả giao diện "Quản trị viên" (để tạo quảng cáo) và giao diện "Trình quản lý văn phòng" (để xem tác động của quảng cáo đối với doanh nghiệp). Tất nhiên, bên trong cả hai mô-đun đều sử dụng cùng một dịch vụ hoạt động với các chương trình khuyến mãi tiền thưởng.

Các dịch vụ (các lớp trong một dự án lớn nguyên khối) có thể gọi lẫn nhau để làm giàu dữ liệu của chúng.

Với chính các lớp mô hình lưu trữ dữ liệu, công việc trong mã được thực hiện khác nhau. Ở đâu đó có các nhà xây dựng thông qua đó có thể chỉ định các trường bắt buộc. Ở đâu đó điều này đã được thực hiện thông qua tài sản công cộng. Tất nhiên, việc lấy và chuyển đổi dữ liệu từ cơ sở dữ liệu rất đa dạng. 

Logic nằm trong bộ điều khiển hoặc trong các lớp dịch vụ. 

Đây có vẻ là những vấn đề nhỏ, nhưng chúng làm chậm quá trình phát triển và giảm chất lượng, dẫn đến sự không ổn định và lỗi. 

Sự phức tạp của một sự phát triển lớn

Khó khăn phát sinh trong chính sự phát triển. Cần phải tạo các khối khác nhau của hệ thống và song song. Việc sắp xếp nhu cầu của từng thành phần vào một mã duy nhất ngày càng trở nên khó khăn. Không dễ để đồng ý và làm hài lòng tất cả các thành phần cùng một lúc. Thêm vào đó là những hạn chế về công nghệ, đặc biệt là liên quan đến cơ sở và giao diện người dùng. Cần phải từ bỏ jQuery để hướng tới các khung cấp cao, đặc biệt là về dịch vụ khách hàng (trang web).

Trong một số phần của hệ thống, cơ sở dữ liệu phù hợp hơn cho việc này có thể được sử dụng.. Ví dụ: sau này chúng tôi có trường hợp sử dụng chuyển từ Redis sang CosmosDB để lưu trữ một giỏ đơn hàng. 

Các nhóm và nhà phát triển tham gia vào lĩnh vực của họ rõ ràng muốn có nhiều quyền tự chủ hơn cho các dịch vụ của họ, cả về phát triển và triển khai. Hợp nhất các xung đột, giải phóng các vấn đề. Nếu đối với 5 nhà phát triển thì vấn đề này không đáng kể, thì với 10 nhà phát triển và thậm chí hơn thế nữa với sự tăng trưởng theo kế hoạch, mọi thứ sẽ trở nên nghiêm trọng hơn. Và phía trước là sự phát triển của một ứng dụng di động (nó bắt đầu vào năm 2017 và năm 2018 là mùa thu lớn). 

Các phần khác nhau của hệ thống yêu cầu mức độ ổn định khác nhau, nhưng do khả năng kết nối của hệ thống quá mạnh nên chúng tôi không thể cung cấp dịch vụ này. Rất có thể đã xảy ra lỗi trong quá trình phát triển chức năng mới trong bảng quản trị khi chấp nhận đơn đặt hàng trên trang web, vì mã là phổ biến và có thể tái sử dụng, cơ sở dữ liệu và dữ liệu cũng giống nhau.

Có thể tránh được những lỗi và sự cố này trong khuôn khổ của kiến ​​trúc nguyên khối-mô-đun như vậy: phân chia trách nhiệm, cấu trúc lại cả mã và cơ sở dữ liệu, tách biệt rõ ràng các lớp với nhau, theo dõi chất lượng hàng ngày. Nhưng các giải pháp kiến ​​trúc đã chọn và việc tập trung vào việc mở rộng nhanh chức năng của hệ thống đã dẫn đến các vấn đề về tính ổn định.

Blog Power of the Mind đặt máy tính tiền trong nhà hàng như thế nào

Nếu sự phát triển của mạng lưới tiệm bánh pizza (và tải) tiếp tục với tốc độ như cũ, thì sau một thời gian, sự sụt giảm sẽ khiến hệ thống không thể tăng lên. Minh họa rõ ràng những vấn đề mà chúng ta bắt đầu gặp phải vào năm 2015, đây là một câu chuyện như vậy. 

Trong blog "Sức mạnh ý chí” là một tiện ích hiển thị dữ liệu về doanh thu trong năm của toàn bộ mạng. Tiện ích đã truy cập API công khai Dodo cung cấp dữ liệu này. Thống kê này hiện có tại http://dodopizzastory.com/. Tiện ích được hiển thị trên mọi trang và thực hiện các yêu cầu trên bộ hẹn giờ cứ sau 20 giây. Yêu cầu được chuyển đến api.dodopizza.ru và yêu cầu:

• số lượng tiệm bánh pizza trong mạng lưới;

• tổng doanh thu toàn mạng từ đầu năm;

• doanh thu cho ngày hôm nay.

Yêu cầu thống kê về doanh thu được chuyển thẳng đến cơ sở dữ liệu và bắt đầu yêu cầu dữ liệu về đơn đặt hàng, tổng hợp dữ liệu nhanh chóng và đưa ra số tiền. 

Bàn tính tiền trong các nhà hàng chuyển đến cùng một bảng đơn đặt hàng, dỡ danh sách các đơn đặt hàng đã nhận cho ngày hôm nay và các đơn đặt hàng mới được thêm vào đó. Máy tính tiền thực hiện các yêu cầu của họ cứ sau 5 giây hoặc khi làm mới trang.

Sơ đồ trông như thế này:

Một mùa thu nọ, Fyodor Ovchinnikov viết một bài báo dài và nổi tiếng trên blog của mình. Rất nhiều người đã đến blog và bắt đầu đọc mọi thứ một cách cẩn thận. Trong khi mỗi người đến đều đang đọc bài viết, tiện ích con doanh thu hoạt động bình thường và yêu cầu API cứ sau 20 giây.

API đã gọi một thủ tục được lưu trữ để tính tổng tất cả các đơn đặt hàng kể từ đầu năm cho tất cả các tiệm bánh pizza trong chuỗi. Việc tổng hợp dựa trên bảng đơn đặt hàng, rất phổ biến. Tất cả các bàn thu ngân của tất cả các nhà hàng mở vào thời điểm đó đều đến đó. Bàn thu ngân ngừng phản hồi, đơn đặt hàng không được chấp nhận. Chúng cũng không được chấp nhận từ trang web, không xuất hiện trên trình theo dõi, người quản lý ca không thể nhìn thấy chúng trong giao diện của anh ta. 

Đây không phải là câu chuyện duy nhất. Vào mùa thu năm 2015, tải trọng trên hệ thống vào thứ Sáu hàng tuần là rất lớn. Nhiều lần chúng tôi đã tắt API công khai và một lần, chúng tôi thậm chí phải tắt trang web vì không có tác dụng gì. Thậm chí còn có một danh sách các dịch vụ có lệnh tắt máy khi tải nặng.

Kể từ bây giờ, cuộc đấu tranh của chúng tôi với tải và ổn định hệ thống bắt đầu (từ mùa thu năm 2015 đến mùa thu năm 2018). Đó là khi nó xảy ra"mùa thu tuyệt vời“. Hơn nữa, những thất bại đôi khi cũng xảy ra, một số rất nhạy cảm, nhưng thời kỳ bất ổn chung hiện có thể được coi là đã qua.

Tăng trưởng kinh doanh nhanh chóng

Tại sao nó không thể được thực hiện ngay lập tức? Chỉ cần nhìn vào các biểu đồ sau đây.

Cũng trong năm 2014-2015 đã có một buổi khai trương ở Romania và một buổi khai trương ở Hoa Kỳ đang được chuẩn bị.

Mạng lưới phát triển rất nhanh, các quốc gia mới được mở ra, các dạng bánh pizza mới xuất hiện, chẳng hạn như một tiệm bánh pizza được mở tại khu ẩm thực. Tất cả điều này đòi hỏi sự chú ý đặc biệt đến việc mở rộng các chức năng của Dodo IS. Nếu không có tất cả các chức năng này, không theo dõi trong nhà bếp, tính toán sản phẩm và thất thoát trong hệ thống, hiển thị việc ban hành đơn đặt hàng trong khu ăn uống, chúng ta sẽ khó nói về kiến ​​trúc “đúng” và cách tiếp cận “đúng” đối với phát triển bây giờ.

Một trở ngại khác đối với việc sửa đổi kiến ​​trúc kịp thời và nói chung là chú ý đến các vấn đề kỹ thuật là cuộc khủng hoảng năm 2014. Những điều như thế này ảnh hưởng rất nhiều đến cơ hội phát triển của các nhóm, đặc biệt là đối với một doanh nghiệp trẻ như Dodo Pizza.

Giải pháp nhanh đã giúp

Các vấn đề cần giải pháp. Thông thường, các giải pháp có thể được chia thành 2 nhóm:

• Những người nhanh chóng dập tắt ngọn lửa và mang lại một biên độ an toàn nhỏ và giúp chúng ta có thời gian để thay đổi.

• Có hệ thống và, do đó, lâu dài. Tái cấu trúc một số mô-đun, phân chia kiến ​​​​trúc nguyên khối thành các dịch vụ riêng biệt (hầu hết chúng hoàn toàn không phải là dịch vụ vi mô, mà là dịch vụ vĩ mô, và có điều gì đó về nó Báo cáo của Andrey Morevskiy). 

Danh sách khô của những thay đổi nhanh chóng như sau:

Mở rộng quy mô tổng thể cơ sở

Tất nhiên, điều đầu tiên được thực hiện để xử lý tải là tăng dung lượng của máy chủ. Điều này đã được thực hiện cho cơ sở dữ liệu chủ và cho các máy chủ web. Than ôi, điều này chỉ có thể đến một giới hạn nhất định, sau đó nó trở nên quá đắt.

Kể từ năm 2014, chúng tôi đã chuyển sang Azure, chúng tôi cũng đã viết về chủ đề này vào thời điểm đó trong bài báo “Cách Dodo Pizza cung cấp bánh pizza bằng đám mây Microsoft Azure“. Nhưng sau một loạt các đợt tăng máy chủ cho cơ sở, họ đã phải đối mặt với chi phí. 

Bản sao cơ sở để đọc

Hai bản sao đã được thực hiện cho cơ sở:

ĐọcBản sao cho các yêu cầu tham khảo. Nó được sử dụng để đọc các thư mục, loại, thành phố, đường phố, tiệm bánh pizza, sản phẩm (miền thay đổi chậm) và trong những giao diện có thể chấp nhận độ trễ nhỏ. Có 2 trong số các bản sao này, chúng tôi đảm bảo tính khả dụng của chúng giống như các bản chính.

ReadReplica cho các yêu cầu báo cáo. Cơ sở dữ liệu này có tính khả dụng thấp hơn, nhưng tất cả các báo cáo đều được chuyển đến nó. Hãy để họ có nhiều yêu cầu tính toán lại dữ liệu khổng lồ, nhưng chúng không ảnh hưởng đến cơ sở dữ liệu chính và giao diện hoạt động. 

Bộ nhớ cache trong mã

Không có bộ đệm nào ở bất kỳ đâu trong mã (hoàn toàn). Điều này dẫn đến các yêu cầu bổ sung, không phải lúc nào cũng cần thiết đối với cơ sở dữ liệu đã tải. Bộ nhớ cache lần đầu tiên có cả trong bộ nhớ và trên dịch vụ bộ nhớ cache bên ngoài, đó là Redis. Mọi thứ đã bị vô hiệu hóa theo thời gian, các cài đặt đã được chỉ định trong mã.

Nhiều máy chủ phụ trợ

Phần phụ trợ của ứng dụng cũng cần phải được thu nhỏ để xử lý khối lượng công việc gia tăng. Cần phải tạo một cụm từ một máy chủ iis. Chúng tôi đã lên lịch lại phiên ứng dụng từ bộ nhớ sang RedisCache, điều này giúp có thể tạo một số máy chủ phía sau bộ cân bằng tải đơn giản với luân chuyển vòng tròn. Lúc đầu, cùng một Redis được sử dụng cho bộ đệm, sau đó nó được chia thành nhiều phần. 

Kết quả là, kiến ​​trúc đã trở nên phức tạp hơn ...

… nhưng một số căng thẳng đã được loại bỏ.

Và sau đó, cần phải làm lại các thành phần đã tải mà chúng tôi đã đảm nhận. Chúng ta sẽ nói về điều này trong phần tiếp theo.

Nguồn: www.habr.com