Có vẻ như lĩnh vực quảng cáo trực tuyến nên có công nghệ tiên tiến và tự động hóa nhất có thể. Tất nhiên, bởi vì những người khổng lồ và chuyên gia trong lĩnh vực của họ như Yandex, Mail.Ru, Google và Facebook đều làm việc ở đó. Tuy nhiên, hóa ra, không có giới hạn nào cho sự hoàn hảo và luôn có thứ gì đó để tự động hóa.
Nhóm truyền thông Mạng lưới Dentsu Aegis Nga là công ty lớn nhất trong thị trường quảng cáo kỹ thuật số và đang tích cực đầu tư vào công nghệ, cố gắng tối ưu hóa và tự động hóa quy trình kinh doanh của mình. Một trong những bài toán chưa có lời giải của thị trường quảng cáo trực tuyến là nhiệm vụ thu thập số liệu thống kê về các chiến dịch quảng cáo từ các nền tảng Internet khác nhau. Giải pháp cho vấn đề này cuối cùng dẫn đến việc tạo ra một sản phẩm D1.Kỹ thuật số (đọc là DiVan), quá trình phát triển mà chúng tôi muốn nói đến.
Tại sao?
1. Vào thời điểm bắt đầu dự án, chưa có một sản phẩm làm sẵn nào trên thị trường giải quyết được vấn đề tự động hóa việc thu thập số liệu thống kê về các chiến dịch quảng cáo. Điều này có nghĩa là không ai ngoại trừ chính chúng ta sẽ đáp ứng được nhu cầu của chúng ta.
Các dịch vụ như Improvado, Roistat, Supermetrics, SegmentStream cung cấp khả năng tích hợp với các nền tảng, mạng xã hội và Google Analitycs, đồng thời giúp xây dựng bảng điều khiển phân tích để phân tích và kiểm soát các chiến dịch quảng cáo một cách thuận tiện. Trước khi bắt đầu phát triển sản phẩm của mình, chúng tôi đã cố gắng sử dụng một số hệ thống này để thu thập dữ liệu từ các trang web, nhưng thật không may, chúng không thể giải quyết được vấn đề của chúng tôi.
Vấn đề chính là các sản phẩm được thử nghiệm dựa trên nguồn dữ liệu, hiển thị số liệu thống kê vị trí theo trang web và không cung cấp khả năng tổng hợp số liệu thống kê về các chiến dịch quảng cáo. Cách tiếp cận này không cho phép chúng tôi xem số liệu thống kê từ các trang web khác nhau ở một nơi và phân tích toàn bộ trạng thái của chiến dịch.
Một yếu tố khác là ở giai đoạn đầu, sản phẩm nhắm đến thị trường phương Tây và không hỗ trợ tích hợp với các trang web của Nga. Và đối với những trang web đã triển khai tích hợp, tất cả các số liệu cần thiết không phải lúc nào cũng được tải xuống với đầy đủ chi tiết và việc tích hợp không phải lúc nào cũng thuận tiện và minh bạch, đặc biệt là khi cần lấy thứ gì đó không có trong giao diện hệ thống.
Nói chung, chúng tôi quyết định không thích ứng với các sản phẩm của bên thứ ba mà bắt đầu phát triển...
2. Thị trường quảng cáo trực tuyến đang phát triển qua từng năm và năm 2018, xét về ngân sách quảng cáo, nó đã vượt qua thị trường quảng cáo truyền hình lớn nhất truyền thống. Vì vậy có một thang đo.
3. Không giống như thị trường quảng cáo truyền hình, nơi việc bán quảng cáo thương mại được độc quyền, có rất nhiều chủ sở hữu cá nhân của khoảng không quảng cáo với nhiều quy mô khác nhau hoạt động trên Internet bằng tài khoản quảng cáo của riêng họ. Vì chiến dịch quảng cáo, theo quy luật, chạy trên nhiều trang web cùng một lúc, nên để hiểu trạng thái của chiến dịch quảng cáo, cần phải thu thập báo cáo từ tất cả các trang web và kết hợp chúng thành một báo cáo lớn sẽ hiển thị toàn bộ bức tranh. Điều này có nghĩa là có tiềm năng tối ưu hóa.
4. Đối với chúng tôi, có vẻ như chủ sở hữu khoảng không quảng cáo trên Internet đã có cơ sở hạ tầng để thu thập số liệu thống kê và hiển thị chúng trong tài khoản quảng cáo và họ sẽ có thể cung cấp API cho dữ liệu này. Điều này có nghĩa là về mặt kỹ thuật có thể thực hiện được nó. Hãy nói ngay rằng mọi chuyện hóa ra không đơn giản như vậy.
Nhìn chung, tất cả các điều kiện tiên quyết để thực hiện dự án đều rõ ràng đối với chúng tôi và chúng tôi chạy đua để đưa dự án vào cuộc sống...
Kế hoạch lớn
Để bắt đầu, chúng tôi đã hình thành tầm nhìn về một hệ thống lý tưởng:
- Các chiến dịch quảng cáo từ hệ thống công ty 1C sẽ được tự động tải vào đó cùng với tên, giai đoạn, ngân sách và vị trí của chúng trên nhiều nền tảng khác nhau.
- Đối với mỗi vị trí trong chiến dịch quảng cáo, tất cả số liệu thống kê có thể có sẽ được tự động tải xuống từ các trang web nơi vị trí diễn ra, chẳng hạn như số lần hiển thị, số lần nhấp chuột, số lượt xem, v.v.
- Một số chiến dịch quảng cáo được theo dõi bằng cách sử dụng sự giám sát của bên thứ ba bởi các hệ thống được gọi là quảng cáo như Adriver, Weborama, DCM, v.v. Ngoài ra còn có máy đo Internet công nghiệp ở Nga - công ty Mediascope. Theo kế hoạch của chúng tôi, dữ liệu từ giám sát độc lập và giám sát công nghiệp cũng sẽ được tải tự động vào các chiến dịch quảng cáo tương ứng.
- Hầu hết các chiến dịch quảng cáo trên Internet đều nhắm đến các hành động mục tiêu nhất định (mua hàng, gọi điện, đăng ký lái thử, v.v.), được theo dõi bằng Google Analytics và số liệu thống kê cũng rất quan trọng để hiểu trạng thái của chiến dịch và nên được tải vào công cụ của chúng tôi.
Bánh đầu tiên là sần
Với cam kết của chúng tôi về các nguyên tắc phát triển phần mềm linh hoạt (linh hoạt, tất cả mọi thứ), trước tiên chúng tôi quyết định phát triển MVP và sau đó lặp đi lặp lại hướng tới mục tiêu đã định.
Chúng tôi quyết định xây dựng MVP dựa trên sản phẩm của mình DANBo (Bảng mạng Dentsu Aegis), là một ứng dụng web có thông tin chung về các chiến dịch quảng cáo của khách hàng của chúng tôi.
Đối với MVP, dự án đã được đơn giản hóa hết mức có thể về mặt thực hiện. Chúng tôi đã chọn một danh sách giới hạn các nền tảng để tích hợp. Đây là những nền tảng chính, chẳng hạn như Yandex.Direct, Yandex.Display, RB.Mail, MyTarget, Adwords, DBM, VK, FB và các hệ thống quảng cáo chính Adriver và Weborama.
Để truy cập số liệu thống kê trên các trang web thông qua API, chúng tôi đã sử dụng một tài khoản. Người quản lý nhóm khách hàng muốn sử dụng tính năng thu thập số liệu thống kê tự động về chiến dịch quảng cáo trước tiên phải ủy quyền quyền truy cập vào các chiến dịch quảng cáo cần thiết trên trang web cho tài khoản nền tảng.
Tiếp theo là người dùng hệ thống DANBo phải tải một tệp có định dạng nhất định lên hệ thống Excel, tệp này chứa tất cả thông tin về vị trí (chiến dịch quảng cáo, nền tảng, định dạng, thời gian thực hiện, các chỉ số theo kế hoạch, ngân sách, v.v.) và số nhận dạng của các chiến dịch quảng cáo tương ứng trên các trang web và quầy trong hệ thống quảng cáo.
Thành thật mà nói, nó trông thật đáng sợ:
Dữ liệu đã tải xuống được lưu vào cơ sở dữ liệu, sau đó tách các dịch vụ thu thập số nhận dạng chiến dịch trên các trang web khỏi chúng và tải xuống số liệu thống kê về chúng.
Đối với mỗi trang web, một dịch vụ windows riêng biệt đã được viết, mỗi ngày một lần thuộc một tài khoản dịch vụ trong API của trang web và tải xuống số liệu thống kê cho các ID chiến dịch được chỉ định. Điều tương tự cũng xảy ra với hệ thống quảng cáo.
Dữ liệu đã tải xuống được hiển thị trên giao diện dưới dạng bảng điều khiển tùy chỉnh nhỏ:
Thật bất ngờ cho chúng tôi, MVP đã bắt đầu hoạt động và bắt đầu tải xuống số liệu thống kê hiện tại về các chiến dịch quảng cáo trên Internet. Chúng tôi đã triển khai hệ thống trên một số khách hàng, nhưng khi cố gắng mở rộng quy mô, chúng tôi đã gặp phải các vấn đề nghiêm trọng:
- Vấn đề chính là sự phức tạp trong việc chuẩn bị dữ liệu để tải vào hệ thống. Ngoài ra, dữ liệu vị trí phải được chuyển đổi sang định dạng cố định nghiêm ngặt trước khi tải. Cần phải đưa số nhận dạng thực thể từ các trang web khác nhau vào tệp tải xuống. Chúng tôi phải đối mặt với thực tế là những người dùng chưa được đào tạo về mặt kỹ thuật rất khó giải thích nơi tìm thấy những số nhận dạng này trên trang web và nơi chúng cần được nhập trong tệp. Xem xét số lượng nhân viên trong các bộ phận đang thực hiện các chiến dịch trên các trang web và doanh thu, điều này dẫn đến lượng hỗ trợ rất lớn từ phía chúng tôi, điều mà chúng tôi hoàn toàn không hài lòng.
- Một vấn đề khác là không phải nền tảng quảng cáo nào cũng có cơ chế ủy quyền truy cập chiến dịch quảng cáo cho các tài khoản khác. Nhưng ngay cả khi có cơ chế ủy quyền, không phải tất cả các nhà quảng cáo đều sẵn sàng cấp quyền truy cập vào chiến dịch của họ cho tài khoản bên thứ ba.
- Một yếu tố quan trọng là sự phẫn nộ đã làm dấy lên sự phẫn nộ của người dùng bởi thực tế là tất cả các chỉ số theo kế hoạch và chi tiết vị trí mà họ đã nhập vào hệ thống kế toán 1C của chúng tôi, họ phải nhập lại vào DANBo.
Điều này cho chúng tôi ý tưởng rằng nguồn thông tin chính về vị trí phải là hệ thống 1C của chúng tôi, trong đó tất cả dữ liệu được nhập chính xác và đúng thời gian (vấn đề ở đây là hóa đơn được tạo dựa trên dữ liệu 1C, vì vậy hãy nhập dữ liệu chính xác vào 1C là ưu tiên của mọi người KPI). Đây là cách một khái niệm mới về hệ thống xuất hiện...
Khái niệm
Điều đầu tiên chúng tôi quyết định làm là tách hệ thống thu thập số liệu thống kê về các chiến dịch quảng cáo trên Internet thành một sản phẩm riêng - D1.Kỹ thuật số.
Trong khái niệm mới, chúng tôi quyết định tải vào D1.Kỹ thuật số thông tin về các chiến dịch quảng cáo và vị trí trong đó từ 1C, sau đó lấy số liệu thống kê từ các trang web và hệ thống Phân phát quảng cáo tới các vị trí này. Điều này được cho là sẽ đơn giản hóa đáng kể cuộc sống của người dùng (và như thường lệ, thêm nhiều công việc hơn cho các nhà phát triển) và giảm lượng hỗ trợ.
Vấn đề đầu tiên chúng tôi gặp phải là về bản chất tổ chức và liên quan đến thực tế là chúng tôi không thể tìm thấy khóa hoặc dấu hiệu để chúng tôi có thể so sánh các thực thể từ các hệ thống khác nhau với các chiến dịch và vị trí từ 1C. Thực tế là quy trình ở công ty chúng tôi được thiết kế theo cách mà các chiến dịch quảng cáo được những người khác nhau (người lập kế hoạch truyền thông, người mua, v.v.) nhập vào các hệ thống khác nhau.
Để giải quyết vấn đề này, chúng tôi phải phát minh ra một khóa băm duy nhất, DANBoID, có thể liên kết các thực thể trong các hệ thống khác nhau với nhau và có thể được xác định khá dễ dàng và duy nhất trong các tập dữ liệu đã tải xuống. Mã nhận dạng này được tạo trong hệ thống 1C nội bộ cho từng vị trí riêng lẻ và được chuyển đến các chiến dịch, vị trí và bộ đếm trên tất cả các trang web cũng như trong tất cả các hệ thống Phân phát quảng cáo. Việc triển khai thực tiễn đưa DANBoID vào tất cả các vị trí mất một thời gian, nhưng chúng tôi đã làm được :)
Sau đó, chúng tôi phát hiện ra rằng không phải tất cả các trang web đều có API để tự động thu thập số liệu thống kê và ngay cả những trang có API cũng không trả về tất cả dữ liệu cần thiết.
Ở giai đoạn này, chúng tôi quyết định giảm đáng kể danh sách các nền tảng để tích hợp và tập trung vào các nền tảng chính tham gia vào phần lớn các chiến dịch quảng cáo. Danh sách này bao gồm tất cả những người chơi lớn nhất trong thị trường quảng cáo (Google, Yandex, Mail.ru), mạng xã hội (VK, Facebook, Twitter), hệ thống phân tích và phân tích quảng cáo chính (DCM, Adriver, Weborama, Google Analytics) và các nền tảng khác.
Phần lớn các trang web chúng tôi chọn đều có API cung cấp số liệu chúng tôi cần. Trong trường hợp không có API hoặc không chứa dữ liệu cần thiết, chúng tôi đã sử dụng các báo cáo được gửi hàng ngày tới email văn phòng của chúng tôi để tải dữ liệu (trong một số hệ thống có thể định cấu hình các báo cáo đó, trong các hệ thống khác, chúng tôi đã đồng ý phát triển các báo cáo đó cho chúng tôi).
Khi phân tích dữ liệu từ các trang web khác nhau, chúng tôi phát hiện ra rằng hệ thống phân cấp của các thực thể không giống nhau trong các hệ thống khác nhau. Hơn nữa, thông tin cần được tải xuống với các chi tiết khác nhau từ các hệ thống khác nhau.
Để giải quyết vấn đề này, khái niệm SubDANBoID đã được phát triển. Ý tưởng về SubDANBoID khá đơn giản, chúng tôi đánh dấu thực thể chính của chiến dịch trên trang web bằng DANBoID được tạo và chúng tôi tải lên tất cả các thực thể lồng nhau bằng mã định danh trang web duy nhất và tạo thành SubDANBoID theo nguyên tắc DANBoID + mã định danh của cấp độ đầu tiên thực thể lồng nhau + mã định danh của thực thể lồng nhau cấp thứ hai +... Cách tiếp cận này cho phép chúng tôi kết nối các chiến dịch quảng cáo trong các hệ thống khác nhau và tải xuống số liệu thống kê chi tiết về chúng.
Chúng tôi cũng phải giải quyết vấn đề truy cập vào các chiến dịch trên các nền tảng khác nhau. Như chúng tôi đã viết ở trên, cơ chế ủy quyền truy cập vào chiến dịch vào một tài khoản kỹ thuật riêng biệt không phải lúc nào cũng được áp dụng. Do đó, chúng tôi phải phát triển cơ sở hạ tầng để ủy quyền tự động thông qua OAuth bằng cách sử dụng mã thông báo và cơ chế cập nhật các mã thông báo này.
Ở phần sau của bài viết, chúng tôi sẽ cố gắng mô tả chi tiết hơn về kiến trúc của giải pháp và các chi tiết kỹ thuật của việc triển khai.
Kiến trúc giải pháp 1.0
Khi bắt đầu triển khai một sản phẩm mới, chúng tôi hiểu rằng ngay lập tức chúng tôi cần cung cấp khả năng kết nối các trang web mới, vì vậy chúng tôi quyết định đi theo con đường kiến trúc vi dịch vụ.
Khi thiết kế kiến trúc, chúng tôi đã tách các đầu nối với tất cả các hệ thống bên ngoài - 1C, nền tảng quảng cáo và hệ thống quảng cáo - thành các dịch vụ riêng biệt.
Ý tưởng chính là tất cả các trình kết nối đến các trang web đều có cùng một API và là các bộ điều hợp mang API của trang web đến một giao diện thuận tiện cho chúng ta.
Trọng tâm của sản phẩm của chúng tôi là một ứng dụng web, là một khối nguyên khối được thiết kế sao cho có thể dễ dàng tách rời thành các dịch vụ. Ứng dụng này chịu trách nhiệm xử lý dữ liệu đã tải xuống, đối chiếu số liệu thống kê từ các hệ thống khác nhau và hiển thị chúng cho người dùng hệ thống.
Để liên lạc giữa các trình kết nối và ứng dụng web, chúng tôi phải tạo một dịch vụ bổ sung mà chúng tôi gọi là Proxy kết nối. Nó thực hiện các chức năng của Service Discovery và Task Scheduler. Dịch vụ này chạy các tác vụ thu thập dữ liệu cho mỗi trình kết nối hàng đêm. Viết một lớp dịch vụ dễ dàng hơn việc kết nối một nhà môi giới tin nhắn và đối với chúng tôi, điều quan trọng là phải nhận được kết quả nhanh nhất có thể.
Để đơn giản và tốc độ phát triển, chúng tôi cũng quyết định rằng tất cả các dịch vụ sẽ là API Web. Điều này giúp có thể nhanh chóng lắp ráp bằng chứng khái niệm và xác minh rằng toàn bộ thiết kế hoạt động.
Một nhiệm vụ riêng biệt, khá phức tạp là thiết lập quyền truy cập để thu thập dữ liệu từ các tài khoản khác nhau, như chúng tôi đã quyết định, việc này sẽ được người dùng thực hiện thông qua giao diện web. Nó bao gồm hai bước riêng biệt: đầu tiên, người dùng thêm mã thông báo để truy cập tài khoản qua OAuth, sau đó định cấu hình việc thu thập dữ liệu cho khách hàng từ một tài khoản cụ thể. Việc nhận mã thông báo qua OAuth là cần thiết vì như chúng tôi đã viết, không phải lúc nào cũng có thể ủy quyền quyền truy cập vào tài khoản mong muốn trên trang web.
Để tạo cơ chế chung cho việc chọn tài khoản từ các trang web, chúng tôi phải thêm một phương thức vào API trình kết nối trả về Lược đồ JSON, được hiển thị thành một biểu mẫu bằng cách sử dụng thành phần JSONEditor đã sửa đổi. Bằng cách này, người dùng có thể chọn tài khoản để tải xuống dữ liệu.
Để tuân thủ các giới hạn yêu cầu tồn tại trên các trang web, chúng tôi kết hợp các yêu cầu cài đặt trong một mã thông báo nhưng chúng tôi có thể xử lý song song các mã thông báo khác nhau.
Chúng tôi đã chọn MongoDB làm nơi lưu trữ dữ liệu đã tải cho cả ứng dụng web và trình kết nối, điều này cho phép chúng tôi không phải lo lắng quá nhiều về cấu trúc dữ liệu ở giai đoạn phát triển ban đầu, khi mô hình đối tượng của ứng dụng thay đổi hàng ngày.
Chúng tôi sớm phát hiện ra rằng không phải tất cả dữ liệu đều phù hợp với MongoDB và chẳng hạn như việc lưu trữ số liệu thống kê hàng ngày trong cơ sở dữ liệu quan hệ sẽ thuận tiện hơn. Do đó, đối với các trình kết nối có cấu trúc dữ liệu phù hợp hơn với cơ sở dữ liệu quan hệ, chúng tôi đã bắt đầu sử dụng PostgreSQL hoặc MS SQL Server làm bộ lưu trữ.
Kiến trúc và công nghệ đã chọn cho phép chúng tôi xây dựng và ra mắt sản phẩm D1.Digital tương đối nhanh chóng. Trong hơn hai năm phát triển sản phẩm, chúng tôi đã phát triển 23 trình kết nối tới các trang web, thu được kinh nghiệm quý giá khi làm việc với API của bên thứ ba, học cách tránh những cạm bẫy của các trang web khác nhau, mỗi trang đều có những cạm bẫy riêng, góp phần phát triển API của ít nhất 3 các trang web, tự động tải xuống thông tin về gần 15 chiến dịch và hơn 000 vị trí, đã thu thập rất nhiều phản hồi từ người dùng về hoạt động của sản phẩm và tìm cách thay đổi quy trình chính của sản phẩm nhiều lần, dựa trên phản hồi này.
Kiến trúc giải pháp 2.0
Đã hai năm trôi qua kể từ khi bắt đầu phát triển D1.Kỹ thuật số. Tải trọng hệ thống tăng liên tục và sự xuất hiện ngày càng nhiều nguồn dữ liệu mới dần bộc lộ những vấn đề trong kiến trúc giải pháp hiện có.
Vấn đề đầu tiên liên quan đến lượng dữ liệu được tải xuống từ các trang web. Chúng tôi phải đối mặt với thực tế là việc thu thập và cập nhật tất cả dữ liệu cần thiết từ các trang web lớn nhất bắt đầu mất quá nhiều thời gian. Ví dụ: việc thu thập dữ liệu từ hệ thống phân phối quảng cáo AdRiver, hệ thống mà chúng tôi theo dõi số liệu thống kê cho hầu hết các vị trí, mất khoảng 12 giờ.
Để giải quyết vấn đề này, chúng tôi bắt đầu sử dụng tất cả các loại báo cáo để tải xuống dữ liệu từ các trang web, chúng tôi đang cố gắng phát triển API của chúng cùng với các trang web để tốc độ hoạt động của nó đáp ứng nhu cầu của chúng tôi và song song hóa việc tải xuống dữ liệu nhiều nhất có thể.
Một vấn đề khác liên quan đến việc xử lý dữ liệu đã tải xuống. Giờ đây, khi có số liệu thống kê vị trí mới, quy trình tính toán lại số liệu gồm nhiều giai đoạn sẽ được triển khai, bao gồm tải dữ liệu thô, tính toán số liệu tổng hợp cho từng trang web, so sánh dữ liệu từ các nguồn khác nhau và tính toán số liệu tóm tắt cho chiến dịch. Điều này gây ra rất nhiều tải cho ứng dụng web thực hiện tất cả các phép tính. Nhiều lần, trong quá trình tính toán lại, ứng dụng đã tiêu tốn hết bộ nhớ trên máy chủ, khoảng 10-15 GB, điều này ảnh hưởng bất lợi nhất đến hoạt động của người dùng với hệ thống.
Các vấn đề đã được xác định và các kế hoạch đầy tham vọng để phát triển hơn nữa sản phẩm đã khiến chúng tôi cần phải xem xét lại kiến trúc ứng dụng.
Chúng tôi bắt đầu với các đầu nối.
Chúng tôi nhận thấy rằng tất cả các trình kết nối đều hoạt động theo cùng một mô hình, vì vậy chúng tôi đã xây dựng một khung quy trình để tạo một trình kết nối, bạn chỉ cần lập trình logic của các bước, phần còn lại là phổ biến. Nếu một số trình kết nối yêu cầu cải tiến thì chúng tôi sẽ ngay lập tức chuyển nó sang một khung mới cùng lúc với trình kết nối đang được cải tiến.
Đồng thời, chúng tôi bắt đầu triển khai các trình kết nối với Docker và Kubernetes.
Chúng tôi đã lên kế hoạch chuyển sang Kubernetes từ khá lâu, thử nghiệm cài đặt CI/CD, nhưng chỉ bắt đầu chuyển khi một trình kết nối, do lỗi, bắt đầu ngốn hơn 20 GB bộ nhớ trên máy chủ, gần như giết chết các quy trình khác . Trong quá trình điều tra, trình kết nối đã được chuyển đến cụm Kubernetes, nơi cuối cùng nó vẫn được giữ nguyên, ngay cả sau khi lỗi đã được khắc phục.
Rất nhanh chóng, chúng tôi nhận ra rằng Kubernetes rất tiện lợi và trong vòng sáu tháng, chúng tôi đã chuyển 7 trình kết nối và Proxy trình kết nối vốn tiêu tốn nhiều tài nguyên nhất sang cụm sản xuất.
Theo các trình kết nối, chúng tôi quyết định thay đổi kiến trúc của phần còn lại của ứng dụng.
Vấn đề chính là dữ liệu đến từ các trình kết nối đến proxy theo lô lớn, sau đó truy cập DANBoID và được gửi đến ứng dụng web trung tâm để xử lý. Do số lượng tính toán lại số liệu lớn nên ứng dụng phải chịu tải lớn.
Việc theo dõi trạng thái của từng công việc thu thập dữ liệu riêng lẻ và báo cáo lỗi xảy ra trong các trình kết nối với ứng dụng web trung tâm cũng tỏ ra khá khó khăn để người dùng có thể biết điều gì đang xảy ra và tại sao dữ liệu không được thu thập.
Để giải quyết những vấn đề này, chúng tôi đã phát triển kiến trúc 2.0.
Sự khác biệt chính giữa phiên bản mới của kiến trúc là thay vì API Web, chúng tôi sử dụng RabbitMQ và thư viện MassTransit để trao đổi tin nhắn giữa các dịch vụ. Để làm được điều này, chúng tôi đã phải viết lại gần như hoàn toàn Proxy của Connectors, biến nó thành Connectors Hub. Tên đã được thay đổi vì vai trò chính của dịch vụ không còn là chuyển tiếp yêu cầu đến trình kết nối và quay lại nữa mà là quản lý việc thu thập số liệu từ trình kết nối.
Từ ứng dụng web trung tâm, chúng tôi đã tách thông tin về vị trí và số liệu thống kê từ các trang web thành các dịch vụ riêng biệt, điều này giúp loại bỏ các tính toán lại không cần thiết và chỉ lưu trữ số liệu thống kê đã được tính toán và tổng hợp ở cấp độ vị trí. Chúng tôi cũng viết lại và tối ưu hóa logic để tính toán số liệu thống kê cơ bản dựa trên dữ liệu thô.
Đồng thời, chúng tôi đang di chuyển tất cả các dịch vụ và ứng dụng sang Docker và Kubernetes để giúp giải pháp dễ dàng mở rộng quy mô và quản lý thuận tiện hơn.
Chúng ta đang ở đâu
Sản phẩm kiến trúc chứng minh khái niệm 2.0 D1.Kỹ thuật số sẵn sàng và hoạt động trong môi trường thử nghiệm với một số đầu nối hạn chế. Tất cả những gì còn lại cần làm là viết lại 20 trình kết nối khác sang nền tảng mới, kiểm tra xem dữ liệu có được tải chính xác không và tất cả các chỉ số đều được tính toán chính xác, đồng thời triển khai toàn bộ thiết kế vào sản xuất.
Trên thực tế, quá trình này sẽ diễn ra dần dần và chúng ta sẽ phải loại bỏ khả năng tương thích ngược với các API cũ để mọi thứ vẫn hoạt động.
Kế hoạch trước mắt của chúng tôi bao gồm phát triển các trình kết nối mới, tích hợp với các hệ thống mới và thêm các số liệu bổ sung vào tập hợp dữ liệu được tải xuống từ các trang web được kết nối và hệ thống quảng cáo.
Chúng tôi cũng có kế hoạch chuyển tất cả các ứng dụng, bao gồm cả ứng dụng web trung tâm, sang Docker và Kubernetes. Kết hợp với kiến trúc mới, điều này sẽ đơn giản hóa đáng kể việc triển khai, giám sát và kiểm soát các tài nguyên đã tiêu thụ.
Một ý tưởng khác là thử nghiệm lựa chọn cơ sở dữ liệu để lưu trữ số liệu thống kê, hiện được lưu trữ trong MongoDB. Chúng tôi đã chuyển một số trình kết nối mới sang cơ sở dữ liệu SQL, nhưng sự khác biệt ở đó hầu như không được chú ý và đối với số liệu thống kê tổng hợp theo ngày, có thể được yêu cầu trong một khoảng thời gian tùy ý, mức tăng có thể khá nghiêm trọng.
Nói chung kế hoạch hoành tráng quá, đi tiếp thôi :)
Tác giả bài viết R&D Dentsu Aegis Network Russia: Georgy Ostapenko (), Mikhail Kotsik ()
Nguồn: www.habr.com