APP technology selection and architecture design of the summit conference

On January 4th, I saw the news that Tiger Sniff pushed "Wang Sicong throws coins", and then began to scrutinize the technology behind it. It involves live streaming, real-time barrage, OAuth2.0 open authorization, SMS api, Push gateway, payment interface and other services. Its technical implementation is not complicated, so we will analyze it.

UI design

Enter image description

It can be said that the summit conference is to copy HQ's business logic, business logic and UI design. Presumably in the short term, there will be more knowledge quiz apps swarming. I will not comment too much on this, but only talk about the technical implementation behind it, not business.

Flutter

It can be said that I am a brainless fan of Google. According to rumors, Google's Fuchsia OS UI is designed with Flutter. Here, the adaptation of Android and IOS can be realized using Flutter. The specific design can completely imitate the HQ.

Business logic

The technical difficulties of the top conference APP are high concurrency and timeliness. To this end, we need to decouple the business, and separate the registration/login, live broadcast, barrage, Q&A, prize pool, push, and sharing. This will help business expansion, ensure high concurrency and follow-up maintenance issues.

Among them, the main business difficulties and focuses are live broadcast, barrage, and Q&A. Live broadcast and barrage are the main traffic outlets, and separating them helps ensure high concurrency and timeliness.

Enter image description

live streaming

Enter image description

Enterprises can build their own live broadcast services, and of course they can also purchase cloud services. Assume that Ali's live video service is selected here. In the live broadcast, the video stream is encoded, transmitted, transcoded, accelerated, and then pushed to the client.

Barrage

The barrage can be made into a simple request request method, or a message queue can be used. Of course, the message queue can also choose cloud services, but here we use kafka, which is deployed to the server cluster for load balancing. For users with low internet speed, we can turn off the barrage function by default to enhance the user experience. We will talk about high concurrency and timeliness later.

Q&A

The question and answer session is the most relevant business logic for users. We need to ensure that users receive messages in seconds. A little trick can be applied here, namely "synchronous push, asynchronous feedback". That is to say, after the host has said the question, a single server will push the question, but considering the different delays of the user's network condition, we can asynchronously receive the user's answer result. We can design the maximum time limit of asynchronous feedback to 10s, 15s.

Other business

Registration/Login: Call WeChat OAuth 2.0 to open authorization. For details, please refer to the WeChat open platform interface documentation, which will not be repeated here. Prize pool: After the question and answer session is over, it will be distributed uniformly. The business is simple and will not be repeated. Call the Alipay withdrawal interface. Push: You can use a push gateway, you can use http polling, or you can use cloud services. Share: You can call the sharing interface of each platform.

high load

I suggest the assumption of load balancing servers in Beijing, Shanghai, and Hong Kong respectively. Beijing serves northern users, Shanghai serves southern users, and Hong Kong serves Hong Kong, Macao, Taiwan and overseas users. Technically using hadoop, zookeeper, docker, nginx, etc.

Enter image description

For user IPs in different geographical locations, DNS resolution is required to automatically distribute and adapt traffic. We set up the sub-regional display of the barrage according to the user's geographical location. Accelerate with CDN.

Operation

It can be said that each live broadcast is an operation, because there is a "host" factor, so the question and answer push and answer results need to be "manually" controlled. The specific operation is to prepare the questions before the live broadcast, and enter the questions into the database or a certain configuration script. During the moderator's interaction, real-time question push is performed, and the answer results are fed back to the moderator.

finally

We exclude labor cost and bonus cost and calculate technical cost separately. A single Q&A live broadcast takes about 20 minutes. We try to calculate the peak traffic of 10G every day. The technical cost per day is about 10,000 yuan. Of course, this is after the number of users reaches a certain size. In the internet industry, this is not high. Therefore, in a short period of time, there will be a large number of knowledge quiz apps coming out.

This article only considers the technical implementation from an overall perspective, and does not involve too many details. But for some experienced companies, especially live broadcast companies, I would like to make this kind of APP, and it will not take more than a week. Let's wait and see.

This article welcomes reprints indicating the source, but for WeChat reprints, please contact the public account: caiyongji for authorized reprints.

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=325397682&siteId=291194637