Mikhail Salosin (sau đây gọi là – MS): - Chào mọi người! Tên tôi là michael. Tôi làm việc với tư cách là nhà phát triển phụ trợ tại MC2 Software và tôi sẽ nói về việc sử dụng Go trong phần phụ trợ của ứng dụng di động Look+.
Có ai ở đây thích khúc côn cầu không?
Sau đó, ứng dụng này là dành cho bạn. Nó dành cho Android và iOS và được sử dụng để xem các chương trình phát sóng trực tuyến và ghi lại các sự kiện thể thao khác nhau. Ứng dụng này cũng chứa nhiều số liệu thống kê, chương trình phát sóng văn bản, bảng dành cho hội nghị, giải đấu và các thông tin khác hữu ích cho người hâm mộ.
Ngoài ra, trong ứng dụng còn có những thứ như khoảnh khắc video, tức là bạn có thể xem những khoảnh khắc quan trọng nhất của trận đấu (bàn thắng, giao tranh, loạt luân lưu, v.v.). Nếu không muốn xem toàn bộ buổi phát sóng, bạn chỉ có thể xem những phần thú vị nhất.
Bạn đã sử dụng những gì trong quá trình phát triển?
Phần chính được viết bằng Go. API mà khách hàng di động giao tiếp được viết bằng Go. Dịch vụ gửi thông báo đẩy tới điện thoại di động cũng được viết bằng Go. Chúng tôi cũng phải viết ORM của riêng mình để một ngày nào đó chúng tôi có thể nói đến nó. Chà, một số dịch vụ nhỏ đã được viết bằng Go: thay đổi kích thước và tải hình ảnh cho người chỉnh sửa...
Chúng tôi đã sử dụng PostgreSQL làm cơ sở dữ liệu. Giao diện soạn thảo được viết bằng Ruby on Rails bằng gem ActiveAdmin. Nhập số liệu thống kê từ nhà cung cấp số liệu thống kê cũng được viết bằng Ruby.
Đối với các thử nghiệm API hệ thống, chúng tôi đã sử dụng Python unittest. Memcached được sử dụng để điều tiết các cuộc gọi thanh toán API, “Chef” được sử dụng để kiểm soát cấu hình, Zabbix được sử dụng để thu thập và giám sát số liệu thống kê hệ thống nội bộ. Graylog2 dùng để thu thập nhật ký, Slate là tài liệu API dành cho khách hàng.
Lựa chọn giao thức
Vấn đề đầu tiên chúng tôi gặp phải: chúng tôi cần chọn một giao thức tương tác giữa máy khách phụ trợ và máy khách di động, dựa trên các điểm sau...
- Yêu cầu quan trọng nhất: dữ liệu về khách hàng phải được cập nhật theo thời gian thực. Nghĩa là, tất cả những người hiện đang xem chương trình phát sóng sẽ nhận được thông tin cập nhật gần như ngay lập tức.
- Để đơn giản hóa mọi thứ, chúng tôi giả định rằng dữ liệu được đồng bộ hóa với máy khách sẽ không bị xóa mà bị ẩn bằng các cờ đặc biệt.
- Tất cả các loại yêu cầu hiếm gặp (chẳng hạn như số liệu thống kê, thành phần nhóm, số liệu thống kê nhóm) đều có thể nhận được bằng các yêu cầu GET thông thường.
- Thêm vào đó, hệ thống phải dễ dàng hỗ trợ 100 nghìn người dùng cùng lúc.
Dựa trên điều này, chúng tôi có hai tùy chọn giao thức:
- Ổ cắm web. Nhưng chúng tôi không cần các kênh từ máy khách đến máy chủ. Chúng tôi chỉ cần gửi các bản cập nhật từ máy chủ đến máy khách, vì vậy websocket là một lựa chọn dự phòng.
- Sự kiện do máy chủ gửi (SSE) đã xuất hiện đúng lúc! Nó khá đơn giản và về cơ bản đáp ứng mọi thứ chúng ta cần.
Sự kiện do máy chủ gửi
Một vài lời về cách thức hoạt động của thứ này...
Nó chạy trên kết nối http. Client gửi yêu cầu, server phản hồi với Content-Type: text/event-stream và không đóng kết nối với client mà tiếp tục ghi dữ liệu vào kết nối:
Dữ liệu có thể được gửi theo định dạng đã được thỏa thuận với khách hàng. Trong trường hợp của chúng tôi, chúng tôi đã gửi nó theo biểu mẫu sau: tên của cấu trúc đã thay đổi (người, người chơi) đã được gửi đến trường sự kiện và JSON với các trường mới, đã thay đổi cho trình phát đã được gửi đến trường dữ liệu.
Bây giờ hãy nói về cách hoạt động của sự tương tác.
- Điều đầu tiên máy khách làm là xác định lần cuối cùng thực hiện đồng bộ hóa với dịch vụ: nó xem xét cơ sở dữ liệu cục bộ và xác định ngày thay đổi cuối cùng được nó ghi lại.
- Nó gửi một yêu cầu với ngày này.
- Để đáp lại, chúng tôi gửi cho anh ấy tất cả các cập nhật đã xảy ra kể từ ngày đó.
- Sau đó, nó tạo kết nối với kênh trực tiếp và không đóng cho đến khi cần những cập nhật này:
Chúng tôi gửi cho anh ấy một danh sách các thay đổi: nếu ai đó ghi bàn, chúng tôi sẽ thay đổi tỷ số trận đấu, nếu anh ấy bị chấn thương, danh sách này cũng được gửi theo thời gian thực. Do đó, khách hàng ngay lập tức nhận được dữ liệu cập nhật trong nguồn cấp dữ liệu sự kiện trận đấu. Định kỳ, để khách hàng hiểu rằng máy chủ không chết, không có chuyện gì xảy ra với nó, chúng tôi gửi dấu thời gian 15 giây một lần - để khách hàng biết rằng mọi thứ đều ổn và không cần kết nối lại.
Kết nối trực tiếp được phục vụ như thế nào?
- Trước hết, chúng tôi tạo một kênh để nhận các bản cập nhật được lưu vào bộ đệm.
- Sau đó, chúng tôi đăng ký kênh này để nhận thông tin cập nhật.
- Chúng tôi đặt tiêu đề chính xác để khách hàng biết rằng mọi thứ đều ổn.
- Gửi ping đầu tiên. Chúng tôi chỉ cần ghi lại dấu thời gian kết nối hiện tại.
- Sau đó, chúng tôi đọc kênh theo vòng lặp cho đến khi kênh cập nhật đóng lại. Kênh định kỳ nhận được dấu thời gian hiện tại hoặc những thay đổi mà chúng tôi đã ghi vào các kết nối đang mở.
Vấn đề đầu tiên chúng tôi gặp phải là như sau: đối với mỗi kết nối được mở bằng máy khách, chúng tôi đã tạo một bộ đếm thời gian cứ sau 15 giây đánh dấu một lần - hóa ra là nếu chúng tôi có 6 nghìn kết nối được mở bằng một máy (với một máy chủ API), thì 6 hàng ngàn bộ tính giờ đã được tạo ra. Điều này dẫn tới việc máy không giữ được tải trọng cần thiết. Vấn đề không quá rõ ràng đối với chúng tôi nhưng chúng tôi đã nhận được một chút trợ giúp và đã khắc phục được nó.
Kết quả là bây giờ ping của chúng tôi đến từ cùng một kênh mà bản cập nhật đến.
Theo đó, chỉ có một đồng hồ bấm giờ cứ 15 giây lại tích tắc một lần.
Có một số chức năng phụ trợ ở đây - gửi tiêu đề, ping và chính cấu trúc. Tức là tên bảng (người, trận đấu, mùa giải) và thông tin về mục này được truyền tới đây:
Cơ chế gửi thông tin cập nhật
Bây giờ một chút về những thay đổi đến từ đâu. Chúng tôi có một số người, biên tập viên, xem chương trình phát sóng theo thời gian thực. Họ tạo ra tất cả các sự kiện: ai đó bị đuổi khỏi sân, ai đó bị thương, một người thay thế nào đó...
Sử dụng CMS, dữ liệu sẽ được đưa vào cơ sở dữ liệu. Sau đó, cơ sở dữ liệu sẽ thông báo cho máy chủ API về việc này bằng cơ chế Nghe/Thông báo. Máy chủ API đã gửi thông tin này cho khách hàng. Do đó, về cơ bản chúng tôi chỉ có một số máy chủ được kết nối với cơ sở dữ liệu và không có tải đặc biệt nào trên cơ sở dữ liệu, vì máy khách không tương tác trực tiếp với cơ sở dữ liệu theo bất kỳ cách nào:
PostgreSQL: Nghe/Thông báo
Cơ chế Nghe/Thông báo trong Postgres cho phép bạn thông báo cho người đăng ký sự kiện rằng một số sự kiện đã thay đổi - một số bản ghi đã được tạo trong cơ sở dữ liệu. Để làm điều này, chúng tôi đã viết một trình kích hoạt và hàm đơn giản:
Khi chèn hoặc thay đổi một bản ghi, chúng ta gọi hàm thông báo trên kênh data_updates, chuyển đến đó tên của bảng và mã định danh của bản ghi đã được thay đổi hoặc chèn vào.
Đối với tất cả các bảng phải được đồng bộ hóa với máy khách, chúng tôi xác định một trình kích hoạt, sau khi thay đổi / cập nhật bản ghi, sẽ gọi hàm được chỉ định trên trang trình bày bên dưới.
API đăng ký những thay đổi này như thế nào?
Cơ chế Fanout được tạo - nó sẽ gửi tin nhắn đến máy khách. Nó thu thập tất cả các kênh khách hàng và gửi các bản cập nhật nhận được thông qua các kênh này:
Ở đây thư viện pq tiêu chuẩn, kết nối với cơ sở dữ liệu và nói rằng nó muốn nghe kênh (data_updates), kiểm tra xem kết nối có mở không và mọi thứ đều ổn. Tôi đang bỏ qua việc kiểm tra lỗi để tiết kiệm dung lượng (không kiểm tra là nguy hiểm).
Tiếp theo, chúng tôi đặt Mã không đồng bộ, mã này sẽ gửi ping cứ sau 15 giây và bắt đầu nghe kênh mà chúng tôi đã đăng ký. Nếu chúng tôi nhận được ping, chúng tôi sẽ công bố ping này. Nếu chúng tôi nhận được một số loại mục nhập, thì chúng tôi sẽ xuất bản mục nhập này cho tất cả những người đăng ký Fanout này.
Fan-out hoạt động như thế nào?
Trong tiếng Nga, từ này được dịch là "bộ chia". Chúng tôi có một đối tượng đăng ký những người đăng ký muốn nhận một số cập nhật. Và ngay khi có bản cập nhật đến đối tượng này, nó sẽ phân phối bản cập nhật này cho tất cả những người đăng ký. Đủ đơn giản:
Cách nó được triển khai trong Go:
Có một cấu trúc, nó được đồng bộ hóa bằng Mutexes. Nó có một trường lưu trạng thái kết nối của Fanout với cơ sở dữ liệu, tức là nó hiện đang lắng nghe và sẽ nhận được các bản cập nhật, cũng như danh sách tất cả các kênh có sẵn - bản đồ, chìa khóa của nó là kênh và cấu trúc ở dạng các giá trị (về cơ bản nó không được sử dụng dưới bất kỳ hình thức nào).
Hai phương thức - Đã kết nối và Đã ngắt kết nối - cho phép chúng tôi thông báo cho Fanout rằng chúng tôi có kết nối với cơ sở, nó đã xuất hiện và kết nối với cơ sở đã bị hỏng. Trong trường hợp thứ hai, bạn cần ngắt kết nối tất cả các máy khách và nói với họ rằng họ không thể nghe bất cứ thứ gì nữa và họ sẽ kết nối lại vì kết nối với chúng đã bị đóng.
Ngoài ra còn có một phương thức Đăng ký để thêm kênh vào “người nghe”:
Có một phương thức Hủy đăng ký để xóa kênh khỏi người nghe nếu máy khách ngắt kết nối, cũng như phương thức Xuất bản, cho phép bạn gửi tin nhắn đến tất cả người đăng ký.
Câu hỏi: – Điều gì được truyền qua kênh này?
CÔ: – Model đã thay đổi hoặc ping được truyền đi (thực chất chỉ là số, số nguyên).
CÔ: – Bạn có thể gửi bất cứ thứ gì, gửi bất kỳ cấu trúc nào, xuất bản nó – nó chỉ chuyển thành JSON và thế là xong.
CÔ: – Chúng tôi nhận được thông báo từ Postgres – nó chứa tên bảng và mã định danh. Dựa trên tên bảng và mã định danh, chúng tôi nhận được bản ghi mình cần và sau đó chúng tôi gửi cấu trúc này để xuất bản.
cơ sở hạ tầng
Điều này trông như thế nào từ góc độ cơ sở hạ tầng? Chúng tôi có 7 máy chủ phần cứng: một trong số đó hoàn toàn dành riêng cho cơ sở dữ liệu, sáu máy chủ còn lại chạy máy ảo. Có 6 bản sao của API: mỗi máy ảo có API chạy trên một máy chủ phần cứng riêng biệt - điều này nhằm đảm bảo độ tin cậy.
Chúng tôi có hai giao diện người dùng được cài đặt Keepaliving để cải thiện khả năng truy cập để nếu có điều gì xảy ra, một giao diện người dùng có thể thay thế giao diện người dùng kia. Ngoài ra – hai bản sao của CMS.
Ngoài ra còn có một nhà nhập khẩu thống kê. Có một DB Slave để thực hiện sao lưu định kỳ. Có Pigeon Pusher, một ứng dụng gửi thông báo đẩy tới khách hàng, cũng như những thứ về cơ sở hạ tầng: Zabbix, Graylog2 và Chef.
Trên thực tế, cơ sở hạ tầng này là dư thừa vì 100 nghìn có thể được phục vụ với ít máy chủ hơn. Nhưng có sắt - chúng tôi đã sử dụng nó (chúng tôi được bảo rằng điều đó là có thể - tại sao không).
Ưu điểm của cờ vây
Sau khi chúng tôi làm việc trên ứng dụng này, những lợi thế rõ ràng của cờ vây đã xuất hiện.
- Thư viện http thú vị. Với nó, bạn có thể tạo ra khá nhiều thứ ngay lập tức.
- Ngoài ra, các kênh cho phép chúng tôi triển khai cơ chế gửi thông báo cho khách hàng một cách rất dễ dàng.
- Điều tuyệt vời Trình phát hiện cuộc đua cho phép chúng tôi loại bỏ một số lỗi nghiêm trọng (cơ sở hạ tầng dàn dựng). Mọi thứ hoạt động trên dàn dựng đều được khởi chạy, biên dịch bằng phím Race; và theo đó, chúng tôi có thể xem xét cơ sở hạ tầng dàn dựng để xem chúng tôi gặp phải những vấn đề tiềm ẩn nào.
- Sự tối giản và đơn giản của ngôn ngữ.
Chúng tôi đang tìm kiếm các nhà phát triển! Nếu có ai muốn thì xin vui lòng.
câu hỏi
Câu hỏi của khán giả (sau đây gọi là – B): – Đối với tôi, có vẻ như bạn đã bỏ sót một điểm quan trọng liên quan đến Fan-out. Tôi có đúng không khi hiểu rằng khi bạn gửi phản hồi cho khách hàng, bạn sẽ chặn nếu khách hàng không muốn đọc?
CÔ: - Không, chúng tôi không chặn. Đầu tiên, chúng tôi có tất cả những điều này đằng sau nginx, nghĩa là không có vấn đề gì với các máy khách chậm. Thứ hai, máy khách có một kênh với bộ đệm - trên thực tế, chúng tôi có thể đưa vào đó hàng trăm bản cập nhật... Nếu chúng tôi không thể ghi vào kênh thì kênh sẽ xóa kênh đó. Nếu chúng tôi thấy kênh bị chặn thì chúng tôi chỉ cần đóng kênh đó và thế là xong - khách hàng sẽ kết nối lại nếu có vấn đề gì phát sinh. Vì vậy, về nguyên tắc, không có sự ngăn chặn nào ở đây.
В: – Không thể gửi ngay bản ghi tới Nghe/Thông báo chứ không phải bảng định danh?
CÔ: – Nghe/Thông báo có giới hạn 8 nghìn byte trên tải trước mà nó gửi. Về nguyên tắc, có thể gửi nếu chúng tôi đang xử lý một lượng nhỏ dữ liệu, nhưng đối với tôi, có vẻ như cách này [cách chúng tôi thực hiện] đơn giản là đáng tin cậy hơn. Những hạn chế nằm ở chính Postgres.
В: – Khách hàng có nhận được thông tin cập nhật về những trận đấu mà họ không quan tâm không?
CÔ: - Nói chung là có. Theo quy định, có 2-3 trận đấu diễn ra song song và thậm chí khá hiếm khi xảy ra. Nếu một khách hàng đang xem thứ gì đó thì thường là anh ta đang xem trận đấu đang diễn ra. Sau đó, khách hàng có một cơ sở dữ liệu cục bộ trong đó tất cả các bản cập nhật này được thêm vào và ngay cả khi không có kết nối Internet, khách hàng vẫn có thể xem tất cả các kết quả trùng khớp trước đây mà mình có bản cập nhật. Về cơ bản, chúng tôi đồng bộ hóa cơ sở dữ liệu của mình trên máy chủ với cơ sở dữ liệu cục bộ của khách hàng để anh ta có thể làm việc ngoại tuyến.
В: – Tại sao bạn lại tạo ORM của riêng mình?
Alexey (một trong những nhà phát triển của Look+): – Vào thời điểm đó (cách đây một năm) có ít ORM hơn bây giờ, khi có khá nhiều. Điều tôi thích nhất về hầu hết các ORM hiện có là hầu hết chúng chạy trên các giao diện trống. Nghĩa là, các phương thức trong các ORM này sẵn sàng tiếp nhận mọi thứ: cấu trúc, con trỏ cấu trúc, số, thứ gì đó hoàn toàn không liên quan...
ORM của chúng tôi tạo ra các cấu trúc dựa trên mô hình dữ liệu. Riêng tôi. Và do đó tất cả các phương pháp đều cụ thể, không sử dụng sự phản chiếu, v.v. Họ chấp nhận các cấu trúc và mong muốn sử dụng những cấu trúc đó.
В: – Có bao nhiêu người tham gia?
CÔ: – Ở giai đoạn đầu, có hai người tham gia. Chúng tôi bắt đầu vào khoảng tháng XNUMX và đến tháng XNUMX, phần chính đã sẵn sàng (phiên bản đầu tiên). Đã có một bản phát hành vào tháng Chín.
В: – Nơi bạn mô tả SSE, bạn không sử dụng thời gian chờ. Tại sao vậy?
CÔ: – Thành thật mà nói thì SSE vẫn là giao thức html5: chuẩn SSE được thiết kế để giao tiếp với các trình duyệt, theo như tôi hiểu. Nó có các tính năng bổ sung để trình duyệt có thể kết nối lại (v.v.), nhưng chúng tôi không cần chúng vì chúng tôi có các ứng dụng khách có thể triển khai bất kỳ logic nào để kết nối và nhận thông tin. Chúng tôi không tạo ra SSE mà là một thứ tương tự như SSE. Bản thân đây không phải là giao thức.
Không cần. Theo tôi hiểu, khách hàng đã triển khai cơ chế kết nối gần như từ đầu. Họ không thực sự quan tâm.
В: – Bạn đã sử dụng thêm tiện ích gì?
CÔ: – Chúng tôi tích cực sử dụng govet và golint để thống nhất phong cách, cũng như gofmt. Không có gì khác được sử dụng.
В: – Bạn đã sử dụng gì để gỡ lỗi?
CÔ: – Việc gỡ lỗi phần lớn được thực hiện bằng cách sử dụng các bài kiểm tra. Chúng tôi không sử dụng bất kỳ trình gỡ lỗi hoặc GOP nào.
В: – Bạn có thể quay lại slide nơi chức năng Xuất bản được triển khai không? Tên biến gồm một chữ cái có làm bạn bối rối không?
CÔ: - KHÔNG. Họ có tầm nhìn khá “hẹp”. Chúng không được sử dụng ở bất kỳ nơi nào khác ngoại trừ ở đây (ngoại trừ phần bên trong của lớp này) và nó rất nhỏ gọn - chỉ mất 7 dòng.
В: – Không hiểu sao nó vẫn chưa trực quan…
CÔ: - Không, không, đây là mật mã thật! Đó không phải là về phong cách. Đó chỉ là một lớp rất nhỏ, tiện dụng - chỉ có 3 trường trong lớp...
CÔ: – Nhìn chung, tất cả dữ liệu được đồng bộ hóa với khách hàng (trận đấu trong mùa giải, cầu thủ) không thay đổi. Nói một cách đại khái, nếu chúng tôi tạo ra một môn thể thao khác mà chúng tôi cần thay đổi trận đấu, chúng tôi sẽ chỉ tính đến mọi thứ trong phiên bản mới của ứng dụng khách và các phiên bản cũ của ứng dụng khách sẽ bị cấm.
В: – Có gói quản lý phụ thuộc nào của bên thứ ba không?
CÔ: – Chúng tôi đã từng đi đẹp.
В: – Có nội dung gì đó về video trong chủ đề của báo cáo, nhưng trong báo cáo không có gì về video.
CÔ: – Không, tôi không có nội dung gì về chủ đề video. Nó có tên là “Look+” - đó là tên của ứng dụng.
В: – Bạn nói rằng nó được phát trực tuyến cho khách hàng?..
CÔ: – Chúng tôi không tham gia vào việc truyền phát video. Điều này hoàn toàn được thực hiện bởi Megafon. Vâng, tôi không nói rằng ứng dụng đó là MegaFon.
CÔ: – Go – để gửi tất cả dữ liệu – về tỷ số, về các sự kiện trận đấu, số liệu thống kê… Go là toàn bộ phần phụ trợ cho ứng dụng. Khách hàng phải biết từ đâu đó nên sử dụng liên kết nào cho người chơi để người dùng có thể xem trận đấu. Chúng tôi có liên kết đến video và luồng đã được chuẩn bị.
Một số quảng cáo 🙂
Cảm ơn bạn đã ở với chúng tôi. Bạn có thích bài viết của chúng tôi? Bạn muốn xem nội dung thú vị hơn? Hỗ trợ chúng tôi bằng cách đặt hàng hoặc giới thiệu cho bạn bè, , một dạng tương tự duy nhất của các máy chủ cấp đầu vào do chúng tôi phát minh ra dành cho bạn: (có sẵn với RAID1 và RAID10, tối đa 24 lõi và tối đa 40GB DDR4).
Dell R730xd rẻ hơn gấp 2 lần tại trung tâm dữ liệu Equinix Tier IV ở Amsterdam? Chỉ ở đây ở Hà Lan! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - từ $99! Đọc về
Nguồn: www.habr.com