Mùa xuân này chúng tôi thấy mình ở trong những điều kiện rất vui vẻ. Do đại dịch, rõ ràng là các hội nghị mùa hè của chúng tôi cần phải chuyển sang trực tuyến. Và để thực hiện chúng trực tuyến một cách hiệu quả, các giải pháp phần mềm làm sẵn không phù hợp với chúng tôi; chúng tôi cần phải viết ra giải pháp của riêng mình. Và chúng tôi có ba tháng để làm việc này.
Rõ ràng đó là ba tháng thú vị. Nhưng nhìn từ bên ngoài thì không hoàn toàn rõ ràng: nền tảng hội nghị trực tuyến là gì? Nó bao gồm những phần nào? Vì vậy, vào cuối hội nghị DevOops mùa hè, tôi đã hỏi những người chịu trách nhiệm về nhiệm vụ này:
- Nikolay Molchanov - giám đốc kỹ thuật Tập đoàn JUG Ru;
- Vladimir Krasilshchik là một lập trình viên Java thực dụng đang làm việc về phần phụ trợ (bạn cũng có thể xem các báo cáo của anh ấy tại các hội nghị Java của chúng tôi);
- Artyom Nikonov chịu trách nhiệm về toàn bộ hoạt động truyền phát video của chúng tôi.
Nhân tiện, tại hội nghị thu đông, chúng tôi sẽ sử dụng phiên bản cải tiến của cùng một nền tảng - rất nhiều độc giả habra vẫn sẽ là người dùng của nó.
Bức tranh lớn
– Thành phần của đội là gì?
Nikolay Molchanov: Chúng tôi có một nhà phân tích, một nhà thiết kế, một người thử nghiệm, ba người front-end và một back-end. Và tất nhiên là một chuyên gia hình chữ T!
- Nhìn chung quá trình đó diễn ra như thế nào?
Nikolai: Cho đến giữa tháng 15, chúng tôi chưa có gì sẵn sàng để trực tuyến cả. Và vào ngày XNUMX tháng XNUMX, toàn bộ băng chuyền trực tuyến bắt đầu quay. Chúng tôi thiết lập một số kho lưu trữ, lên kế hoạch, thảo luận về kiến trúc cơ bản và thực hiện mọi thứ trong ba tháng.
Tất nhiên, điều này đã trải qua các giai đoạn cổ điển về quy hoạch, kiến trúc, lựa chọn tính năng, bỏ phiếu cho các tính năng đó, chính sách cho các tính năng đó, thiết kế, phát triển, thử nghiệm chúng. Kết quả là vào ngày 6 tháng XNUMX, chúng tôi đã đưa mọi thứ vào sản xuất. . Có 90 ngày cho mọi thứ.
- Chúng ta có thực hiện được những gì mình đã cam kết không?
Nikolai: Vì chúng tôi hiện đang tham gia hội nghị DevOops trực tuyến nên điều đó có nghĩa là nó đã hoạt động. Cá nhân tôi đã cam kết điều chính: Tôi sẽ mang đến cho khách hàng một công cụ để họ có thể tổ chức hội nghị trực tuyến.
Thử thách là ở chỗ: cung cấp cho chúng tôi một công cụ để chúng tôi có thể phát sóng hội nghị của mình tới những người có vé.
Tất cả các kế hoạch được chia thành nhiều giai đoạn và tất cả các tính năng (khoảng 30 tính năng toàn cầu) được chia thành 4 loại:
- điều mà chúng tôi chắc chắn sẽ làm (chúng tôi không thể sống thiếu họ),
- việc mà chúng ta sẽ làm thứ hai,
- điều mà chúng ta sẽ không bao giờ làm,
- và điều mà chúng tôi sẽ không bao giờ làm.
Chúng tôi đã thực hiện tất cả các tính năng từ hai loại đầu tiên.
— Tôi biết rằng có tổng cộng 600 vấn đề JIRA đã được tạo ra. Trong ba tháng, bạn đã tạo ra 13 microservice và tôi nghi ngờ rằng chúng không chỉ được viết bằng Java. Bạn đã sử dụng các công nghệ khác nhau, bạn có hai cụm Kubernetes ở ba vùng khả dụng và 5 luồng RTMP trong Amazon.
Bây giờ chúng ta hãy xem xét từng thành phần của hệ thống một cách riêng biệt.
Truyền phát
— Hãy bắt đầu với khi chúng ta đã có một hình ảnh video và nó được truyền đến một số dịch vụ. Artyom, hãy cho chúng tôi biết việc phát sóng này diễn ra như thế nào?
Artyom Nikonov: Sơ đồ chung của chúng tôi trông như thế này: hình ảnh từ máy ảnh -> phòng điều khiển của chúng tôi -> máy chủ RTMP cục bộ -> Amazon -> trình phát video. Thêm chi tiết trên Habré vào tháng Sáu.
Nhìn chung, có hai cách toàn cầu để thực hiện việc này: trên phần cứng hoặc dựa trên các giải pháp phần mềm. Chúng tôi chọn con đường phần mềm vì nó dễ dàng hơn trong trường hợp loa từ xa. Không phải lúc nào cũng có thể mang phần cứng đến loa ở quốc gia khác, nhưng việc cung cấp phần mềm cho loa có vẻ dễ dàng và đáng tin cậy hơn.
Từ quan điểm phần cứng, chúng tôi có một số lượng máy ảnh nhất định (trong studio của chúng tôi và ở loa từ xa), một số điều khiển từ xa nhất định trong studio, đôi khi phải sửa chữa ngay dưới gầm bàn trong quá trình phát sóng.
Tín hiệu từ các thiết bị này đi vào máy tính bằng thẻ chụp, thẻ đầu vào/đầu ra và thẻ âm thanh. Ở đó các tín hiệu được trộn và tập hợp thành bố cục:
Ví dụ về cách bố trí 4 loa
Ví dụ về cách bố trí 4 loa
Hơn nữa, việc phát sóng liên tục được cung cấp với sự trợ giúp của ba máy tính: lần lượt có một máy chính và một cặp máy làm việc. Máy tính đầu tiên thu thập báo cáo đầu tiên, máy tính thứ hai - giờ nghỉ, máy tính đầu tiên - báo cáo tiếp theo, máy tính thứ hai - giờ nghỉ tiếp theo, v.v. Và máy chính trộn cái thứ nhất với cái thứ hai.
Điều này tạo ra một dạng tam giác và nếu bất kỳ nút nào trong số này bị lỗi, chúng tôi có thể tiếp tục cung cấp nội dung cho khách hàng một cách nhanh chóng mà không làm giảm chất lượng. Chúng tôi đã có một tình huống như vậy. Trong tuần đầu tiên của hội nghị, chúng tôi đã sửa một chiếc máy, bật/tắt nó. Mọi người có vẻ hài lòng với khả năng phục hồi của chúng tôi.
Tiếp theo, các luồng từ máy tính sẽ chuyển đến máy chủ cục bộ, máy chủ này có hai nhiệm vụ: định tuyến các luồng RTMP và sao lưu bản ghi. Vì vậy, chúng tôi có nhiều điểm ghi. Sau đó, các luồng video sẽ được gửi đến một phần hệ thống của chúng tôi được xây dựng trên các dịch vụ Amazon SaaS. Chúng tôi sử dụng ,S3,CloudFront.
Nikolai: Điều gì xảy ra ở đó trước khi video đến được với khán giả? Bạn phải cắt nó bằng cách nào đó, phải không?
Artyom: Chúng tôi nén video từ phía mình và gửi đến MediaLive. Chúng tôi khởi chạy bộ chuyển mã ở đó. Họ chuyển mã video theo thời gian thực thành nhiều độ phân giải để mọi người có thể xem chúng trên điện thoại của họ, thông qua mạng Internet kém ở trong nước, v.v. Sau đó các dòng này được cắt thành , đây là cách giao thức hoạt động . Chúng tôi gửi danh sách phát tới giao diện người dùng có chứa các con trỏ tới các phần này.
— Chúng ta có đang sử dụng độ phân giải 1080p không?
Artyom: Chiều rộng của video của chúng tôi bằng 1080p - 1920 pixel và chiều cao thấp hơn một chút, hình ảnh dài hơn - có nhiều lý do cho điều này.
Người chơi
— Artyom đã mô tả cách video được đưa vào luồng, cách video được phân phối thành các danh sách phát khác nhau cho các độ phân giải màn hình khác nhau, cắt thành nhiều đoạn và đưa vào trình phát. Kolya, bây giờ hãy cho tôi biết đây là loại trình phát gì, nó tiêu thụ luồng như thế nào, tại sao lại là HLS?
Nikolai: Chúng tôi có một trình phát mà tất cả người xem hội nghị đều có thể xem.
Về cơ bản, đây là một trình bao bọc xung quanh thư viện , trên đó có viết nhiều người chơi khác. Nhưng chúng tôi cần chức năng rất cụ thể: tua lại và đánh dấu vị trí của người đó, báo cáo mà người đó hiện đang xem. Chúng tôi cũng cần bố cục của riêng mình, tất cả các loại biểu tượng và mọi thứ khác được tích hợp sẵn với chúng tôi. Do đó, chúng tôi quyết định viết thư viện của riêng mình (một trình bao bọc trên HLS) và nhúng nó vào trang web.
Đây là chức năng gốc nên nó gần như được triển khai đầu tiên. Và rồi mọi thứ xung quanh nó phát triển.
Trên thực tế, thông qua ủy quyền, người chơi nhận được từ phần phụ trợ một danh sách phát có liên kết đến các phần tương ứng với thời gian và chất lượng, tải xuống những danh sách cần thiết và hiển thị chúng cho người dùng, thực hiện một số “ma thuật” trong quá trình thực hiện.
Ví dụ về dòng thời gian
— Một nút được tích hợp ngay trong trình phát để hiển thị dòng thời gian của tất cả các báo cáo...
Nikolai: Có, chúng tôi đã giải quyết ngay vấn đề điều hướng người dùng. Vào giữa tháng 4, chúng tôi quyết định sẽ không phát sóng từng hội nghị của mình trên một trang web riêng biệt mà sẽ kết hợp mọi thứ trên một trang web. Vì vậy, người dùng vé Full Pass có thể tự do chuyển đổi giữa các hội nghị khác nhau: cả chương trình phát sóng trực tiếp và bản ghi âm của những hội nghị trước đây.
Và để giúp người dùng điều hướng luồng hiện tại và chuyển đổi giữa các bản nhạc dễ dàng hơn, chúng tôi đã quyết định tạo nút “Phát toàn bộ” và thẻ báo cáo ngang để chuyển đổi giữa các bản nhạc và báo cáo. Có bàn phím điều khiển.
— Có bất kỳ khó khăn kỹ thuật nào với việc này không?
Nikolai: Họ có một thanh cuộn để đánh dấu điểm bắt đầu của các báo cáo khác nhau.
— Cuối cùng, bạn có triển khai những dấu này trên thanh cuộn trước khi YouTube làm điều gì đó tương tự không?
Artyom: Lúc đó họ đã có nó ở bản beta. Có vẻ như đây là một tính năng khá phức tạp vì họ đã thử nghiệm một phần với người dùng trong năm qua. Và bây giờ nó đã được bán.
Nikolai: Nhưng chúng tôi thực sự đã bán nó nhanh hơn. Thành thật mà nói, đằng sau tính năng đơn giản này có một lượng lớn phần phụ trợ, giao diện người dùng, tính toán và toán học bên trong trình phát.
giao diện người dùng
— Hãy tìm hiểu làm thế nào nội dung mà chúng tôi hiển thị (thẻ bài phát biểu, diễn giả, trang web, lịch trình) được đưa đến giao diện người dùng?
Vladimir Krasilshchik: Chúng tôi có một số hệ thống CNTT nội bộ. Có một hệ thống trong đó tất cả các báo cáo và tất cả các diễn giả đều được nhập vào. Có một quá trình mà một diễn giả tham gia vào một hội nghị. Người nói gửi đơn đăng ký, hệ thống sẽ ghi lại nó, sau đó sẽ có một quy trình nhất định để tạo ra báo cáo.
Đây là cách người nói nhìn thấy đường dẫn
Hệ thống này là sự phát triển nội bộ của chúng tôi.
Tiếp theo, bạn cần xây dựng lịch trình từ các báo cáo riêng lẻ. Như bạn đã biết, đây là một bài toán NP-khó, nhưng bằng cách nào đó chúng ta đã giải quyết được nó. Để thực hiện việc này, chúng tôi khởi chạy một thành phần khác có chức năng tạo lịch trình và tải lịch trình đó lên dịch vụ đám mây Contentful của bên thứ ba. Ở đó, mọi thứ trông giống như một cái bàn, trong đó có các ngày diễn ra hội nghị, trong các ngày có các khung thời gian và trong các khung có các báo cáo, thời gian nghỉ hoặc các hoạt động tài trợ. Vì vậy, nội dung chúng tôi thấy nằm trong dịch vụ của bên thứ ba. Và nhiệm vụ là truyền tải nó đến trang web.
Có vẻ như trang web chỉ là một trang có trình phát và không có gì phức tạp ở đây. Ngoại trừ nó không phải vậy. Phần phụ trợ đằng sau trang này chuyển đến Nội dung, lấy lịch trình từ đó, tạo một số đối tượng và gửi nó đến giao diện người dùng. Bằng cách sử dụng kết nối websocket mà mọi khách hàng trên nền tảng của chúng tôi đều tạo ra, chúng tôi gửi cho anh ấy bản cập nhật về lịch trình từ phần phụ trợ đến phần giao diện người dùng.
Trường hợp thực tế: diễn giả đã thay đổi công việc ngay trong buổi hội thảo. Chúng ta cần thay đổi huy hiệu công ty của anh ấy. Làm thế nào điều này xảy ra từ phần phụ trợ? Một bản cập nhật được gửi đến tất cả khách hàng thông qua websocket và sau đó giao diện người dùng sẽ tự vẽ lại dòng thời gian. Tất cả điều này xảy ra liền mạch. Sự kết hợp giữa dịch vụ đám mây và một số thành phần của chúng tôi mang đến cho chúng tôi cơ hội tạo ra tất cả nội dung này và cung cấp nó cho người dùng.
Nikolai: Điều quan trọng cần làm rõ ở đây là trang web của chúng tôi không phải là một ứng dụng SPA cổ điển. Đây vừa là một trang web được hiển thị, dựa trên bố cục vừa là một SPA. Google thực sự coi trang web này là HTML được hiển thị. Điều này tốt cho SEO và cung cấp nội dung cho người dùng. Nó không đợi 1,5 megabyte JavaScript tải trước khi xem trang, nó sẽ thấy ngay trang đã được hiển thị và bạn sẽ cảm nhận được điều đó mỗi khi chuyển báo cáo. Mọi thứ diễn ra trong nửa giây vì nội dung đã sẵn sàng và được đăng đúng nơi.
— Hãy vạch ra một ranh giới cho tất cả những điều trên bằng cách liệt kê các công nghệ. Tyoma cho biết chúng tôi có 5 luồng Amazon và chúng tôi cung cấp video và âm thanh ở đó. Chúng tôi có các tập lệnh bash ở đó, chúng tôi sử dụng chúng để khởi chạy và định cấu hình...
Artyom: Điều này xảy ra thông qua API AWS, có nhiều dịch vụ phụ kỹ thuật hơn ở đó. Chúng tôi phân chia trách nhiệm của mình để tôi giao hàng cho , và các nhà phát triển front-end và back-end bắt đầu từ đó. Chúng tôi có một số liên kết của riêng mình để đơn giản hóa bố cục nội dung, sau đó chúng tôi thực hiện ở 4K, v.v. Vì thời hạn rất gấp rút nên chúng tôi thực hiện gần như hoàn toàn trên AWS.
— Sau đó, tất cả điều này sẽ được đưa vào trình phát bằng hệ thống phụ trợ. Chúng tôi có TypeScript, React, Next.JS trong trình phát của mình. Và ở phần phụ trợ, chúng tôi có một số dịch vụ trong C#, Java, Spring Boot và Node.js. Tất cả đều được triển khai bằng Kubernetes bằng cơ sở hạ tầng Yandex.Cloud.
Tôi cũng muốn lưu ý rằng khi tôi cần làm quen với nền tảng, mọi việc trở nên dễ dàng: tất cả các kho lưu trữ đều có trên GitLab, mọi thứ đều được đặt tên rõ ràng, các bài kiểm tra được viết, có tài liệu. Tức là, ngay cả trong chế độ khẩn cấp, họ vẫn lo những việc như vậy.
Ràng buộc kinh doanh và phân tích
— Chúng tôi nhắm mục tiêu 10 người dùng dựa trên yêu cầu kinh doanh. Đã đến lúc nói về những hạn chế kinh doanh mà chúng tôi gặp phải. Chúng tôi phải đảm bảo khối lượng công việc cao, đảm bảo tuân thủ pháp luật về bảo quản dữ liệu cá nhân. Và những gì khác?
Nikolai: Ban đầu, chúng tôi bắt đầu từ các yêu cầu về video. Điều quan trọng nhất là lưu trữ video được phân phối trên toàn thế giới để phân phối nhanh chóng cho khách hàng. Các tính năng khác bao gồm độ phân giải 1080p cũng như tua lại, điều mà nhiều tính năng khác không triển khai ở chế độ trực tiếp. Sau đó, chúng tôi đã thêm khả năng kích hoạt tốc độ gấp đôi, với sự trợ giúp của nó, bạn có thể “bắt kịp” chương trình trực tiếp và tiếp tục theo dõi hội nghị trong thời gian thực. Và trên đường đi, chức năng đánh dấu dòng thời gian đã xuất hiện. Ngoài ra, chúng tôi phải có khả năng chịu lỗi và chịu được tải của 2 kết nối. Từ quan điểm phụ trợ, con số này là khoảng 10 kết nối nhân với 000 yêu cầu cho mỗi lần làm mới trang. Và đây đã là 10 RPS/giây. Một ít của.
— Có yêu cầu nào khác đối với một “triển lãm ảo” với gian hàng trực tuyến của các đối tác không?
Nikolai: Đúng, việc này phải được thực hiện khá nhanh chóng và phổ biến. Chúng tôi có tới 10 công ty đối tác cho mỗi hội nghị và tất cả đều phải hoàn thành trong một hoặc hai tuần. Tuy nhiên, nội dung của chúng hơi khác nhau về định dạng. Nhưng một công cụ mẫu nhất định đã được tạo ra để lắp ráp các trang này một cách nhanh chóng mà hầu như không có sự tham gia phát triển nào nữa.
— Cũng có các yêu cầu về phân tích lượt xem và số liệu thống kê theo thời gian thực. Tôi biết rằng chúng tôi sử dụng Prometheus cho việc này nhưng hãy cho chúng tôi biết chi tiết hơn: chúng tôi đáp ứng những yêu cầu nào đối với phân tích và việc này được triển khai như thế nào?
Nikolai: Ban đầu, chúng tôi có các yêu cầu tiếp thị về việc thu thập thông tin để thử nghiệm A/B và thu thập thông tin nhằm hiểu cách cung cấp đúng nội dung tốt nhất cho khách hàng trong tương lai. Ngoài ra còn có các yêu cầu đối với một số phân tích về hoạt động của đối tác và phân tích mà bạn thấy (truy cập quầy). Tất cả thông tin được thu thập trong thời gian thực.
Chúng tôi có thể cung cấp thông tin này ở dạng tổng hợp ngay cả với các diễn giả: có bao nhiêu người đang theo dõi bạn tại một thời điểm nhất định. Đồng thời, để tuân thủ Luật Liên bang 152, tài khoản cá nhân và dữ liệu cá nhân của bạn không bị theo dõi dưới bất kỳ hình thức nào.
Nền tảng này đã có các công cụ tiếp thị và số liệu của chúng tôi để đo lường hoạt động của người dùng trong thời gian thực (ai đã xem giây nào của báo cáo) để xây dựng biểu đồ về mức độ tham dự báo cáo. Dựa trên dữ liệu này, nghiên cứu đang được thực hiện nhằm giúp các hội nghị tiếp theo trở nên tốt hơn.
Gian lận
— Chúng ta có cơ chế chống gian lận không?
Nikolai: Do khung thời gian eo hẹp theo quan điểm kinh doanh, nhiệm vụ ban đầu không được đặt để chặn ngay các kết nối không cần thiết. Nếu hai người dùng đăng nhập bằng cùng một tài khoản, họ có thể xem nội dung. Nhưng chúng tôi biết có bao nhiêu lượt xem đồng thời từ một tài khoản. Và chúng tôi đã cấm một số người vi phạm đặc biệt ác ý.
Vladimir: Đáng khen ngợi là một trong những người dùng bị cấm đã hiểu tại sao điều này lại xảy ra. Anh ta đến, xin lỗi và hứa sẽ mua vé.
— Để tất cả những điều này xảy ra, bạn phải theo dõi đầy đủ tất cả người dùng từ lúc ra vào, luôn biết họ đang làm gì. Làm thế nào để hệ thống này hoạt động?
Vladimir: Tôi muốn nói về phân tích và số liệu thống kê, sau đó chúng tôi phân tích về sự thành công của báo cáo hoặc sau đó có thể cung cấp cho các đối tác. Tất cả các máy khách được kết nối thông qua kết nối websocket tới một cụm phụ trợ cụ thể. Nó đứng đó . Mỗi khách hàng tại mỗi khoảng thời gian sẽ gửi những gì anh ấy đang làm và bài hát anh ấy đang xem. Sau đó, thông tin này được tổng hợp bằng cách sử dụng các tác vụ Hazelcast nhanh và gửi lại cho tất cả những người xem các bản nhạc này. Chúng tôi nhìn thấy trong góc có bao nhiêu người đang ở cùng chúng tôi.
Thông tin tương tự được lưu trữ trong và đi tới hồ dữ liệu của chúng tôi, từ đó chúng tôi có cơ hội xây dựng một biểu đồ thú vị hơn. Câu hỏi đặt ra: có bao nhiêu người dùng duy nhất đã xem báo cáo này? Chúng tôi đến , có ping của tất cả những người truy cập theo id của báo cáo này. Chúng tôi đã thu thập, tổng hợp những cái độc đáo và bây giờ chúng tôi có thể hiểu được.
Nikolai: Nhưng đồng thời, chúng tôi cũng nhận được dữ liệu thời gian thực từ Prometheus. Nó được thiết lập chống lại tất cả các dịch vụ Kubernetes, chống lại chính Kubernetes. Nó thu thập tất cả mọi thứ và với Grafana, chúng tôi có thể xây dựng bất kỳ biểu đồ nào trong thời gian thực.
Vladimir: Một mặt, chúng tôi tải xuống phần này để xử lý OLAP thêm. Và đối với OLTP, ứng dụng tải toàn bộ nội dung xuống Prometheus, Grafana và các biểu đồ thậm chí còn hội tụ!
- Đây là trường hợp đồ thị hội tụ.
Thay đổi động
— Hãy cho chúng tôi biết các thay đổi linh hoạt được triển khai như thế nào: nếu báo cáo bị hủy 6 phút trước khi bắt đầu, chuỗi hành động sẽ như thế nào? Đường ống nào hoạt động?
Vladimir: Đường ống rất có điều kiện. Có một số khả năng. Đầu tiên là chương trình tạo lịch trình đã hoạt động và thay đổi lịch trình. Lịch trình sửa đổi được tải lên Contentful. Sau đó, phần phụ trợ hiểu rằng có những thay đổi đối với hội nghị này trong Contentful, tiếp nhận và xây dựng lại nó. Mọi thứ đều được thu thập và gửi qua websocket.
Khả năng thứ hai, khi mọi thứ diễn ra với tốc độ chóng mặt: người chỉnh sửa thay đổi thông tin trong Contentful theo cách thủ công (liên kết tới Telegram, bài thuyết trình của diễn giả, v.v.) và logic tương tự sẽ hoạt động như lần đầu tiên.
Nikolai: Mọi thứ diễn ra mà không cần làm mới trang. Tất cả các thay đổi diễn ra hoàn toàn liền mạch cho khách hàng. Điều tương tự cũng xảy ra với việc chuyển đổi báo cáo. Khi đến thời điểm, báo cáo và giao diện sẽ thay đổi.
Vladimir: Ngoài ra, còn có giới hạn thời gian để bắt đầu báo cáo trong dòng thời gian. Ngay từ đầu chẳng có gì cả. Và nếu bạn di chuột qua sọc đỏ, thì đến một lúc nào đó, nhờ đạo diễn phát sóng, các điểm cắt sẽ xuất hiện. Đạo diễn thiết lập thời điểm bắt đầu chương trình phát sóng chính xác, phần phụ trợ sẽ tiếp nhận thay đổi này, tính toán thời gian bắt đầu và kết thúc của toàn bộ bản trình bày theo lịch trình hội nghị, gửi cho khách hàng của chúng tôi và người chơi sẽ rút ra các điểm giới hạn. Bây giờ người dùng có thể dễ dàng điều hướng đến phần đầu và phần cuối của báo cáo. Đó là một yêu cầu kinh doanh nghiêm ngặt, rất thuận tiện và hữu ích. Bạn không lãng phí thời gian để tìm thời gian bắt đầu thực tế cho báo cáo. Và khi chúng tôi xem trước, nó sẽ hoàn toàn tuyệt vời.
Triển khai
- Tôi muốn hỏi về việc triển khai. Kolya và nhóm đã dành rất nhiều thời gian ngay từ đầu để thiết lập toàn bộ cơ sở hạ tầng nơi mọi thứ diễn ra với chúng tôi. Nói cho tôi biết, tất cả những thứ này được làm từ gì?
Nikolai: Từ quan điểm kỹ thuật, ban đầu chúng tôi yêu cầu sản phẩm phải càng trừu tượng càng tốt đối với bất kỳ nhà cung cấp nào. Hãy đến với AWS để tạo các tập lệnh Terraform cụ thể từ AWS hoặc cụ thể từ Yandex hoặc từ Azure, v.v. không thực sự phù hợp. Chúng tôi phải di chuyển đi đâu đó vào một thời điểm nào đó.
Trong ba tuần đầu tiên, chúng tôi không ngừng tìm cách để làm điều này tốt hơn. Kết quả là, chúng tôi đi đến kết luận rằng Kubernetes trong trường hợp này là tất cả của chúng tôi, bởi vì nó cho phép chúng tôi tạo các dịch vụ tự động mở rộng quy mô, tự động triển khai và sử dụng hầu hết tất cả các dịch vụ ngay lập tức. Đương nhiên, tất cả các dịch vụ đều phải được đào tạo để hoạt động với Kubernetes, Docker và nhóm cũng phải học hỏi.
Chúng tôi có hai cụm. Thử nghiệm và sản xuất. Chúng hoàn toàn giống nhau về phần cứng và cài đặt. Chúng tôi triển khai cơ sở hạ tầng dưới dạng mã. Tất cả các dịch vụ được tự động triển khai thành ba môi trường từ nhánh tính năng, nhánh chính, nhánh thử nghiệm và GitLab bằng cách sử dụng quy trình tự động. Điều này được tích hợp tối đa vào GitLab, tích hợp tối đa với Elastic, Prometheus.
Chúng tôi có cơ hội nhanh chóng (đối với phần phụ trợ trong vòng 10 phút, đối với giao diện người dùng trong vòng 5 phút) triển khai các thay đổi đối với bất kỳ môi trường nào bằng tất cả các thử nghiệm, tích hợp, chạy thử nghiệm chức năng, thử nghiệm tích hợp trên môi trường và cũng có thể thử nghiệm bằng thử nghiệm tải trên một môi trường thử nghiệm gần giống với thứ mà chúng tôi muốn có trong sản xuất.
Về các bài kiểm tra
— Bạn kiểm tra hầu hết mọi thứ, thật khó tin bạn đã viết mọi thứ như thế nào. Bạn có thể cho chúng tôi biết về các bài kiểm tra phụ trợ: mọi thứ được bao gồm bao nhiêu, những bài kiểm tra nào?
Vladimir: Hai loại bài kiểm tra đã được viết. Đầu tiên là các bài kiểm tra thành phần. Kiểm tra mức độ nâng của toàn bộ ứng dụng lò xo và chân đế trong . Đây là một thử nghiệm của các kịch bản kinh doanh cấp cao nhất. Tôi không kiểm tra chức năng. Chúng tôi chỉ thử nghiệm một số điều lớn. Ví dụ: ngay trong quá trình thử nghiệm, quy trình đăng nhập của người dùng được mô phỏng, yêu cầu của người dùng về vé đến nơi họ có thể đến và yêu cầu quyền truy cập để xem luồng. Kịch bản người dùng rất rõ ràng.
Điều tương tự cũng được thực hiện trong cái gọi là thử nghiệm tích hợp, thực sự chạy trên môi trường. Trên thực tế, khi lần triển khai tiếp theo trong sản xuất được triển khai, các kịch bản cơ bản thực tế cũng đang chạy trong sản xuất. Cùng một thông tin đăng nhập, yêu cầu vé, yêu cầu quyền truy cập vào CloudFront, kiểm tra xem luồng có thực sự kết nối với quyền của tôi hay không, kiểm tra giao diện của giám đốc.
Hiện tại tôi có khoảng 70 bài kiểm tra thành phần và khoảng 40 bài kiểm tra tích hợp. Độ che phủ rất gần 95%. Cái này dành cho những thành phần, ít hơn dành cho những cái tích hợp, đơn giản là không cần quá nhiều. Xem xét rằng dự án liên quan đến tất cả các loại tạo mã, đây là một chỉ báo rất tốt. Không có cách nào khác để làm những gì chúng tôi đã làm trong ba tháng. Bởi vì nếu chúng tôi kiểm tra thủ công, đưa ra các tính năng cho người kiểm tra của mình và cô ấy sẽ tìm ra lỗi và gửi lại cho chúng tôi để sửa chữa, thì chuyến đi khứ hồi để gỡ lỗi mã này sẽ rất dài và chúng tôi sẽ không đáp ứng được bất kỳ thời hạn nào.
Nikolai: Thông thường, để thực hiện hồi quy trên toàn bộ nền tảng khi thay đổi một số chức năng, bạn cần phải ngồi và tìm kiếm khắp nơi trong hai ngày.
Vladimir: Vì vậy, thật là một thành công lớn khi khi tôi ước tính một tính năng, tôi nói rằng tôi cần 4 ngày cho hai chiếc bút đơn giản và 1 ổ cắm web, Kolya cho phép điều đó. Anh ấy đã quen với việc 4 ngày này bao gồm 2 loại bài kiểm tra, và sau đó rất có thể nó sẽ thành công.
Nikolai: Tôi cũng có 140 bài kiểm tra được viết: thành phần + chức năng, thực hiện điều tương tự. Tất cả các kịch bản giống nhau đều được thử nghiệm trong sản xuất, trong thử nghiệm và trong sản xuất. Gần đây chúng tôi cũng đã thêm các bài kiểm tra giao diện người dùng cơ bản về chức năng. Bằng cách này, chúng tôi đề cập đến chức năng cơ bản nhất có thể bị hỏng.
Vladimir: Tất nhiên, cần phải nói về các bài kiểm tra tải. Cần phải kiểm tra nền tảng dưới tải gần với tải thực để hiểu mọi thứ diễn ra như thế nào, chuyện gì đang xảy ra với Rabbit, điều gì đang xảy ra với các JVM, thực tế cần bao nhiêu bộ nhớ.
— Tôi không biết chắc liệu chúng tôi có đang thử nghiệm bất cứ điều gì ở phía luồng hay không, nhưng tôi nhớ rằng đã xảy ra sự cố với bộ chuyển mã khi chúng tôi tổ chức các cuộc gặp mặt. Chúng tôi đã thử nghiệm các luồng chưa?
Artyom: Đã thử nghiệm lặp đi lặp lại. Tổ chức gặp mặt. Trong quá trình tổ chức các buổi gặp mặt đã có khoảng 2300 vé JIRA. Đây chỉ là những điều chung chung mà mọi người đã làm để tổ chức các buổi gặp mặt. Chúng tôi đã đưa các phần của nền tảng lên một trang riêng dành cho các buổi gặp mặt do Kirill Tolkachev điều hành ().
Thành thật mà nói thì không có vấn đề gì lớn cả. Theo nghĩa đen, một vài lần chúng tôi gặp phải lỗi bộ nhớ đệm trên CloudFront, chúng tôi đã giải quyết nó khá nhanh - chúng tôi chỉ cần cấu hình lại các chính sách. Có nhiều lỗi hơn đáng kể ở con người, trong hệ thống phát trực tuyến trên trang web.
Trong các hội nghị, tôi đã phải viết thêm một số nhà xuất khẩu để cung cấp thêm thiết bị và dịch vụ. Ở một số nơi, tôi phải tự làm xe đạp cho mình chỉ vì mục đích đo lường. Thế giới phần cứng AV (âm thanh-video) không mấy màu hồng - bạn có một số loại "API" của thiết bị mà bạn đơn giản là không thể tác động được. Và thực tế là bạn sẽ không thể có được thông tin mình cần. Các nhà cung cấp phần cứng thực sự rất chậm chạp và gần như không thể đạt được thứ bạn muốn từ họ. Tổng cộng có hơn 100 phần cứng, họ không trả lại những gì bạn cần và bạn viết những nhà xuất khẩu kỳ lạ và dư thừa, nhờ đó ít nhất bạn có thể gỡ lỗi hệ thống bằng cách nào đó.
Оборудование
— Tôi nhớ trước khi bắt đầu hội nghị, chúng tôi đã mua thêm một phần thiết bị.
Artyom: Chúng tôi đã mua máy tính, máy tính xách tay và bộ pin. Hiện tại chúng ta có thể sống mà không cần điện trong 40 phút. Vào tháng 40, ở St. Petersburg đã xảy ra giông bão dữ dội - vì vậy chúng tôi đã bị mất điện như vậy. Đồng thời, một số nhà cung cấp đến với chúng tôi bằng các liên kết quang từ các điểm khác nhau. Đây thực sự là XNUMX phút ngừng hoạt động của tòa nhà, trong thời gian đó chúng tôi sẽ bật đèn, âm thanh, camera, v.v.
– Chúng tôi có một câu chuyện tương tự với Internet. Trong văn phòng nơi đặt xưởng vẽ của chúng tôi, chúng tôi kéo một tấm lưới dày giữa các tầng.
Artyom: Chúng tôi có 20 Gbit sợi quang giữa các tầng. Xa hơn dọc theo các tầng, nơi nào đó có quang học, nơi nào đó không có quang học, nhưng vẫn có ít kênh hơn kênh gigabit - chúng tôi chạy video trên chúng giữa các kênh của hội nghị. Nhìn chung, việc làm việc trên cơ sở hạ tầng của riêng bạn rất thuận tiện, điều này hiếm khi có thể thực hiện được tại các hội nghị ngoại tuyến trên địa điểm.
— Trước khi làm việc tại JUG Ru Group, tôi đã thấy cách các phòng phần cứng tại các hội nghị ngoại tuyến được thiết lập chỉ sau một đêm, nơi có một màn hình lớn với tất cả các số liệu mà bạn xây dựng trong Grafana. Hiện tại còn có một phòng trụ sở chính để nhóm phát triển ngồi, nơi trong hội nghị sẽ sửa một số lỗi và phát triển các tính năng. Đồng thời có hệ thống giám sát được hiển thị trên màn hình lớn. Artyom, Kolya và những người khác ngồi xuống và đảm bảo rằng tất cả không bị rơi và hoạt động tốt.
Sự tò mò và vấn đề
— Bạn đã nói rất hay về việc chúng tôi phát trực tuyến với Amazon, có một trình phát trên web, mọi thứ đều được viết bằng các ngôn ngữ lập trình khác nhau, khả năng chịu lỗi và các yêu cầu kinh doanh khác đều được cung cấp, bao gồm cả tài khoản cá nhân được hỗ trợ cho các pháp nhân và cá nhân, và chúng tôi có thể tích hợp với ai đó bằng OAuth 2.0, có tính năng chống lừa đảo, chặn người dùng. Chúng tôi có thể triển khai các thay đổi một cách linh hoạt vì chúng tôi đã làm tốt và tất cả đều đã được thử nghiệm.
Tôi muốn biết những điều kỳ lạ nào liên quan đến việc bắt đầu một việc gì đó. Đã có tình huống kỳ lạ nào xảy ra khi bạn đang phát triển backend, frontend, bỗng nhiên có điều gì đó điên rồ xảy ra và bạn không biết phải làm gì với nó?
Vladimir: Đối với tôi, có vẻ như điều này chỉ xảy ra trong ba tháng qua. Hằng ngày. Như bạn có thể thấy, toàn bộ tóc của tôi đã bị nhổ ra.
Vladimir Krasilshchik sau 3 tháng, khi một loại trò chơi nào đó xuất hiện và không ai hiểu phải làm gì với nó
Ngày nào cũng có những chuyện như thế này, có lúc bạn lấy nó ra và bứt tóc, hoặc nhận ra rằng không còn ai khác, và chỉ có bạn mới có thể làm được điều đó. Sự kiện lớn đầu tiên của chúng tôi là TechTrain. Vào lúc 6 giờ sáng ngày 2 tháng 2.0, chúng tôi vẫn chưa triển khai môi trường sản xuất, Kolya đang triển khai nó. Và tài khoản cá nhân không hoạt động như một máy chủ ủy quyền bằng OAuth2.0. Chúng tôi đã biến nó thành nhà cung cấp OAuth18 để kết nối nền tảng với nó. Tôi đã làm việc có lẽ được XNUMX tiếng liền, tôi nhìn vào máy tính và không thấy gì cả, tôi không hiểu tại sao nó không hoạt động, còn Kolya thì xem mã của tôi từ xa, tìm lỗi trong cấu hình Spring , đã tìm thấy nó và LC đã hoạt động cũng như trong quá trình sản xuất .
Nikolai: Và một giờ trước khi TechTrain phát hành.
Rất nhiều ngôi sao đã được xếp thẳng hàng ở đây. Chúng tôi vô cùng may mắn vì chúng tôi có một đội ngũ tuyệt vời và mọi người đều được truyền cảm hứng từ ý tưởng thực hiện trực tuyến. Trong suốt ba tháng này, chúng tôi bị thúc đẩy bởi thực tế là chúng tôi đã “tạo ra YouTube”. Tôi không cho phép mình bứt tóc mà nói với mọi người rằng mọi chuyện sẽ ổn thôi, vì thực ra mọi chuyện đã được tính toán từ lâu rồi.
Về hiệu suất
— Bạn có thể cho tôi biết có bao nhiêu người đã có mặt trên địa điểm trên một đường đua không? Có vấn đề gì về hiệu suất không?
Nikolai: Không có vấn đề gì về hiệu suất như chúng tôi đã nói. Số người tham dự tối đa một báo cáo là 1300 người, đây là trên Heisenbug.
— Có vấn đề gì với việc xem cục bộ không? Và liệu có thể có một mô tả kỹ thuật với sơ đồ về cách thức hoạt động của tất cả không?
Nikolai: Chúng tôi sẽ viết một bài về điều này sau.
Bạn thậm chí có thể gỡ lỗi các luồng cục bộ. Khi các hội nghị bắt đầu, mọi việc càng trở nên dễ dàng hơn vì các luồng sản xuất xuất hiện mà chúng ta có thể xem mọi lúc.
Vladimir: Theo tôi hiểu, các nhà phát triển giao diện người dùng đã làm việc cục bộ với các bản mô phỏng và sau đó, vì thời gian triển khai cho các nhà phát triển ở phía trước cũng rất ngắn (5 phút), nên không có vấn đề gì khi kiểm tra xem điều gì đang xảy ra với chứng chỉ.
— Mọi thứ đều được kiểm tra và sửa lỗi, ngay cả ở địa phương. Điều này có nghĩa là chúng tôi sẽ viết một bài báo với tất cả các tính năng kỹ thuật, cho bạn xem, cho bạn biết mọi thứ bằng sơ đồ, nó như thế nào.
Vladimir: Bạn có thể lấy nó và lặp lại nó.
- Trong 3 tháng nữa.
Tổng
— Mọi thứ được mô tả cùng nhau nghe có vẻ hay, vì nó được thực hiện bởi một nhóm nhỏ trong ba tháng.
Nikolai: Một đội lớn sẽ không làm điều này. Nhưng một nhóm nhỏ những người giao tiếp khá chặt chẽ và tốt với nhau và có thể đi đến thống nhất thì có thể. Chúng không có bất kỳ mâu thuẫn nào, kiến trúc được phát minh trong hai ngày, được hoàn thiện và thực tế không có gì thay đổi. Có sự hỗ trợ rất nghiêm ngặt đối với các yêu cầu kinh doanh sắp tới về mặt chồng chất các yêu cầu và thay đổi tính năng.
— Danh sách nhiệm vụ tiếp theo của bạn là gì khi hội nghị mùa hè đã diễn ra?
Nikolai: Ví dụ: tín dụng. Dòng chữ bò trên video, pop-up ở một số vị trí trong video tùy theo nội dung hiển thị. Ví dụ: diễn giả muốn đặt một câu hỏi cho khán giả và một phiếu bầu sẽ xuất hiện trên màn hình, phiếu này sẽ quay trở lại mặt sau dựa trên kết quả biểu quyết của chính diễn giả. Một số loại hoạt động xã hội dưới dạng lượt thích, trái tim, xếp hạng của báo cáo trong khi trình bày, để bạn có thể điền phản hồi vào đúng thời điểm mà không bị phân tâm bởi các biểu mẫu phản hồi sau này. Ban đầu là như thế này.
Và cũng bổ sung thêm vào toàn bộ nền tảng, ngoại trừ phát trực tuyến và hội nghị, cũng là trạng thái sau hội nghị. Đây là các danh sách phát (bao gồm cả những danh sách do người dùng biên soạn), có thể là nội dung từ các hội nghị khác trước đây, được tích hợp, gắn nhãn, người dùng có thể truy cập và cũng có sẵn để xem trên trang web của chúng tôi ().
- Các bạn, cảm ơn rất nhiều vì câu trả lời của bạn!
Nếu trong số độc giả có những người đã tham dự hội nghị mùa hè của chúng tôi, vui lòng chia sẻ ấn tượng của bạn về người chơi và chương trình phát sóng. Điều gì thuận tiện, điều gì khiến bạn khó chịu, bạn muốn thấy điều gì trong tương lai?
Nếu bạn quan tâm đến nền tảng này và muốn xem nó “trong trận chiến”, chúng tôi sẽ sử dụng lại nền tảng này trên . Có rất nhiều loại trong số đó, vì vậy gần như chắc chắn có một loại phù hợp với bạn.
Nguồn: www.habr.com