background

The company’s new business needs video on demand and live broadcasting. After comparative analysis, Tencent Cloud was finally selected as the video service provider.

There are the following arguments on how to access: 1. The central platform connects to the video service in a unified manner and encapsulates the unified external interface. If the video service provider needs to be changed later, the upper layer does not need to change it

Point of agreement: Unified encapsulation of external services Point of dispute: Whether to seamlessly switch video providers without affecting upper-layer services

2. General components are encapsulated on APP and WEB side based on Tencent video upload & Play SDk

Consensus: Unified encapsulation SDK Controversy: Whether the encapsulation granularity is strong or weak. That is, hide the internal implementation and expose only custom parameters; Or component parameters transparent transmission of Tencent SDk related parameters, only simple encapsulation of general business logic

For the above points of dispute, the meeting did not discuss the final conclusion. In my opinion, these two issues are actually a business architecture issue and a technical architecture issue. Only by clarifying these two issues can we make a clear judgment.

Business architecture

Business architecture: It’s really a matter of figuring out how the parties work, how they interact, and how they design.

There are two types of architecture for this scenario, one is central control and the other is parallel.

Control type

The central control type can be understood as a centralized unified control, and the general structure is shown as follows:

Core ideas:

Benefits:

  1. Video service switching has no impact on the business side and no extra development workload

Difficulties & Disadvantages:

  1. Video service gray switching problem
  2. Abstract video service in Taiwan is a common service with its own functions and interactive logic. Function intersection, can not use special video service unique highlights
  3. The middle-stage logic is complicated, the maintenance cost of compatibility is high, and it is not easy to iterate

The parallel type

Parallel design can be literally understood as parallel design. The two routes do not conflict, and the general structure is shown as follows:

Core idea: Parallel schemes are used to connect different video services without mutual influence

Benefits:

  1. Gray scale switch is convenient, the scope of influence can be controlled in a small business scope
  2. No compatibility processing, the code logic is clear, concise; After all switches, relevant codes can be abandoned as a whole
  3. Can make full use of all the functions of video service providers

Difficulties & Disadvantages:

  1. Switching video providers requires redesign and development, resulting in a huge amount of work

The technical architecture

Technical architecture: How to achieve high cohesion, low coupling, easy expansion, good version iteration and downward compatibility in technical implementation details depends on business architecture.

For argument 2, there are two technical architecture ideas, one for centralized compatible processing and the other for specific processing.

Centralized processing – strong encapsulation

For the SDK of each video service, centralized processing and unified external parameters, the general structure diagram is as follows:

Core idea: hide internal implementation logic, provide unified external exit

Benefits:

  1. Strong control, so that internal changes are not perceived by the outside

Difficulties & Disadvantages:

  1. Advance planning, strong abstractions, and restraint in providing minimal feature sets to avoid compatibility issues
  2. In the early stage, it is necessary to consider the problem of encapsulating different video services to ensure seamless subsequent switching, which is complicated to implement and heavy workload

Specific processing – weak encapsulation

For the specific processing of the SDK of each video service, different video services encapsulate different front-end components, and the general structure is shown as follows:

Core idea: the principle of minimum open and close, the second encapsulation of the video SDK is not necessary, the parameters can be passed through; Additional extension custom generic business encapsulation.

Benefits:

  1. You can get the full range of features from specific video service providers
  2. Component documentation does not need to be written separately, developers can refer to official documentation, encourage DIY, and troubleshoot problems themselves, rather than pushing them off to component providers
  3. No need to consider compatible with other video services, the code is simple, clear, strong maintenance

Disadvantages:

  1. To switch the video service, the corresponding component needs to be redesigned, and the top-level service needs to be adjusted according to the parameter specifications of the new component

Personal ideas

1. Be restrained and just right

This is actually a matter of balance and trade-offs. You can’t not think too far into the future, but you can’t think too far into the future. The problem with thinking too far is that a lot of work in the early stage may not be useful in the later stage.

2. Clean, neat and clear

When doing business architecture, individuals will pay more attention to what kind of architecture can make the technical architecture more concise, clear and easy to maintain. Try to avoid the framework design delimited box, resulting in technical implementation details complicated.

3. Low cost and high profit

For this problem, the total cost of doing one thing is relatively fixed. For the above problem, I prefer to use low cost in the early stage, and then invest additional cost when it really needs to be cut.

4. Start clear and firm, end clear and firm

Choose a structure should be consistent from top to bottom, do the best in one way, avoid half-hearted, this also want a little, that also want a little, the last few not like.

Finally, different choices have different costs; The difficulty of system architecture is not how to structure, but how to balance and make trade-offs. Every man has his hobbyhorse.

Author’s Official Account: