With the popularization of smart devices and the development of mobile Internet, mobile applications have gradually become a new entry for users, and their importance has become more and more prominent. However, enterprises generally have PC-side applications first, and then push APPs. Most of the functions of APP version 1.0 are translated from existing PC applications, and the APP architecture is not considered for the characteristics of mobile itself. As the APP becomes more and more complex, and the functional and non-functional requirements become higher and higher, the inherent deficiencies of the architecture have gradually become the bottleneck of large-scale APP upgrades.
Based on the landing practice of large-scale mobile applications, the author of this article explains how to upgrade and optimize from the perspective of server-side architecture design, so as to lay the architectural foundation for the subsequent APP to become bigger and stronger, for your reference.
The main contents of this article include:
- V1 Architecture
- problem analysis
- V2 Architecture
- Smart upgrade and upgrade
- Summarize
V1 Architecture
The APP is divided into a mobile terminal and a server. The mobile terminal is responsible for the UI, which is relatively simple. The server is responsible for providing data and business logic, which is relatively more critical. The server architecture of APP 1.0 is relatively simple. Generally, a wireless interface is added on the basis of the original PC-side Web application for APP to call, as shown in Figure 1.
On the one hand, the server system provides access to PC browsers in the form of web applications. On the other hand, in order to support mobile applications, some REST interfaces are added on the basis of web applications for direct APP access. Correspondingly, wireless interfaces and web applications are the same project. Development, as the same application deployment, this design idea is very direct and natural, you can quickly copy the PC-side functions to the APP.
problem analysis
The above design is to patch the existing web application, which reflects the wireless thinking of PC. The APP is simply used as a copy of the PC-side application, and the two are physically tied together, which brings a series of problems:
1. Tightly coupled
The wireless interface is tightly coupled with the web application. The modification on the web side will affect the wireless interface. The release on the web side will lead to the passive joint release of the wireless interface. The bug on the web side affects the availability of the wireless interface, and vice versa, any changes in the wireless interface will affect the web application.
2. Repeat development
In addition to providing business data to the APP, the wireless interface also needs to consider a series of non-functional factors, such as communication protocol and data format encapsulation, security control, logging, performance monitoring, etc., which are applicable to each wireless interface. If the APP and the back-end system are directly connected, it means that each back-end system needs to support these common functions, resulting in repeated development. Once these general requirements change (such as encryption enhancement of data transmission), all back-end systems must be modified and launched synchronously, which brings great challenges to project management.
3. Stability
The APP is directly connected to multiple back-end systems. As long as one system fails, it will affect the availability of the APP. The lack of fault isolation mechanism makes the APP very fragile.
These problems are essentially due to the lack of clear separation of Web applications and APPs, resulting in mutual influence and loss of both.
So how to achieve effective isolation? First of all, the two share the core business logic, so the core business logic must be independent and used for APP and Web calls in a consistent way; at the same time, the wireless interface serves the APP and has nothing to do with the Web front-end, so they need to be further stripped and separated. Maintenance and deployment, after splitting, the architecture is shown in Figure 2.
Figure 2 shows the system split
V2 Architecture
In addition to the splitting of APP and Web applications, the architectural transformation must also consider the characteristics of the APP itself. On the one hand, APP needs to obtain data from various systems on the server side, which is individual and business-oriented; on the other hand, all calls require non-functional general processing, which is common and has nothing to do with business. In terms of architecture, it is necessary to achieve the combination of unified and decentralized, unified treatment of common features, and decentralized treatment of individuality.
Finally, combined with the requirements of APP/Web splitting and the characteristics of the APP itself, the new APP architecture scheme is shown in Figure 3.
Figure 3 APP 2.0 Architecture
1. Peer isolation
The APP is actually equivalent to the PC-side browser. The PC-side application has a server, and the APP also needs its own independent server. Both servers need to be independently developed and deployed according to their own characteristics. The decoupling at the physical level completely gets rid of the wireless PC thinking from the architectural level.
2. Unified service
The core logic is separated from the Web application and transformed into a service. The service implementation does not distinguish between PC and wireless. Both APP and Web applications rely on these services, a set of interfaces, and multiple calls.
3. The unified gateway entry
provides a unified wireless gateway, and all APP calls point to this gateway. The gateway includes the general layer, the interface routing layer, and the adaptation layer.
-
System-level functions such as general-layer
communication protocol adaptation, data encapsulation, security, monitoring, and logging require the same logic for each interface call. These functions are pre-processed by the gateway to avoid repeated development. In the specific implementation, each general processing logic is encapsulated into an interceptor, which follows a unified filtering interface and is configurable. The gateway calls these interceptors in turn, which can support flexible expansion of general logic.
The interceptor interface is defined as follows:Object filter(Object input) throws Exception
-
After the interface route
is preprocessed by general logic, the wireless interface request will be further distributed to the backend processing (each Adapter). The URL and Adapter are mapped in the configuration file, and the distribution logic finds the corresponding Adapter according to the URL information in the request, and then passes the request to the Adapter for processing.
The configuration example is as follows:www.Website.com/search SearchAdapter
www.Website.com/detail DetailAdapter -
The input and output formats and communication protocols of the service adaptation
external wireless interface and internal SOA interface are likely to be different. For example, the former is often in HTTP+JSON format, and the latter may be in Hessian+binary format. Adapter is first used for wireless interfaces and internal SOA interfaces. In addition, the Adapter may aggregate multiple SOA services and provide coarse-grained data to the APP to reduce the number of remote network calls. In terms of implementation, generally each business system has an Adapter, which is responsible for the call adaptation of the wireless interface of the system.
The Adapter interface is defined as follows:Object adapter(Object input) throws Exception
Adapters are physically jar packages, which are provided by the R&D teams of various business lines and serve as the front end of the corresponding SOA services. In the end, all Adapters are centrally deployed on the gateway, and the gateway itself supports horizontal expansion.
Smart upgrade and upgrade
While the gateway supports centralized management and control, it also brings single-point problems. Suppose that a service interface in the background has serious performance problems for some reason, and the corresponding adapter processing is very slow, then the threads of the server where the gateway is located are quickly exhausted, resulting in a single interface dragging down the entire system. This kind of problem cannot be solved by simply adding machines and horizontally expanding the number of gateways. In practice, we introduce an intelligent upgrade and upgrade mechanism to quickly isolate the impact of a single interface, as shown in Figure 4:
Figure 4 Intelligent upgrade and upgrade
For a specific interface, if its timeout failure rate reaches a certain percentage (such as 2%) within a certain time interval (such as 5 seconds), the gateway will downgrade the interface and randomly discard some traffic, such as allowing only 50 % flow through. Re-evaluate in the next 5 seconds. If the failure rate has not improved, the allowable traffic will drop to 25%, and so on.
If the success rate improves, the gateway will upgrade the interface to increase the proportion of traffic passing through. In order to recover quickly, generally increase the traffic to 4 times the original traffic, and then evaluate whether to trigger the upgrade or upgrade in the next time period.
The whole process is fully automated and intelligently processed (to prevent misjudgment, manual intervention can be supported), so that a single interface problem will not affect the processing capability of the entire gateway.
Summarize
Through a series of splits and integrations, the APP server architecture not only optimizes the company's overall application architecture, but also lays a solid foundation for the APP to become bigger and stronger. The benefits it brings are comprehensive:
1. Realize the separation of PC-side applications and mobile-side applications, so that the two are completely decoupled and developed independently, and the APP has changed from a parasitic vine to a parallel lotus.
2. The underlying core SOA service provides logic and data based on unified business rules. The interface does not distinguish between PC, wireless or other channels (such as Open API), avoiding repeated development and business logic pollution. All the front-end siblings are born from the same root.
3. According to the characteristics of wireless itself, it supports centralized processing at the system level and decentralized processing at the business level. General logic supports plug-in expansion, which can be gradually supplemented as needed; Adapter realizes seamless conversion of internal and external interfaces, and can perform logical enhancements (such as service aggregation) for wireless scenarios. The master in the front leads the door, and the mothers in the back practice.
4. The mobile R&D team and each business line R&D team perform their own duties. Each team focuses on what it is good at. The mobile team is responsible for the general logic processing of the APP client and gateway, and each business line R&D team is responsible for the underlying SOA service and front-end Adapter adaptation. match. God's to God, Caesar's to Caesar.
If you use one word to describe the APP architecture, V1 is "claw", relying on each family when you are young; V2 is "ya", growing up and starting a family independently.
The new architecture, the coming-of-age ceremony of large-scale apps, are you "Y" ready?