Deep understanding of large app architecture upgrades from a server-side architecture design perspective

With the popularization of smart devices and the development of mobile Internet, mobile application has become a new portal for users, and the importance is becoming more and more prominent. But enterprises are generally the first PC-side applications, and then push App,app 1.0 version of the features are mostly from existing PC applications to translate, there is no mobile features to consider the app architecture. As apps become more complex, functional and non-functional requirements become more and more high, the inherent weaknesses of the architecture are becoming a bottleneck for large app upgrades.

Based on the practice of large mobile application, this paper expounds how to optimize the upgrade from the point of view of service-side architecture design, and lays the foundation for the future app to be bigger and stronger for reference.

The main contents of this paper include:

• V1 Architecture
• Problem analysis
• V2 Architecture
• Intelligent Lifting Grade
• Summarize

V1 Architecture

The app is mobile and server-side, the mobile phone is responsible for the UI, relatively simple, the service side is responsible for providing data and business logic, relatively more critical. APP1.0 version of the service-side architecture is relatively simple, generally in the original PC-side Web application based on the addition of wireless interface, for the app to call, as shown in.

Server-side system on the one hand in the form of Web applications to the PC-side browser access, on the other hand to support mobile, on the basis of Web applications to add some rest interface directly to the app access, corresponding to the wireless interface and Web applications as the same project development, as the same application deployment, This design idea is straightforward and natural, and can quickly copy PC-side functions to the app.

Problem analysis

The above design is in the existing Web application patching, reflects the PC thinking wireless, the app is simple as a copy of the PC-side application, and the two are physically bundled together, bringing a series of problems:

1. Tight coupling

Wireless interface and Web applications tightly coupled, web-side modification will affect the wireless interface, web-side publishing causes the wireless interface passive publishing, web-side bugs affect the availability of wireless interfaces, in turn, any changes in the wireless interface will affect the Web application.

2. Repeat Development

In addition to providing business data to the app, wireless interfaces also need to consider a range of non-functional factors such as protocol and data format encapsulation, security controls, logging, performance monitoring, and so on for each wireless interface. If the app and backend systems are connected directly, it means that each backend system needs to support these common functions, leading to repetitive development. Once these general requirements change (such as the encryption enhancement of data transfer), all back-end systems are forced to synchronize the modification and on-line, which poses a great challenge to project management.

3. Stability

Apps and multiple back-end systems are connected directly, so long as one system goes wrong, the usability of the app is affected, and the lack of a fault isolation mechanism makes the app very vulnerable.

These problems are essentially caused by the lack of clear isolation of web applications and apps, resulting in mutual impact and loss.

So how to achieve effective isolation? First, the two share the core business logic, so the core business logic to be independent, in a consistent way for the app and the Web call, while the wireless interface services to the app, and the Web front-end has no relationship, need to further peel them, separately maintained and deployed, after the split of the schema two is shown.

Figure II System split schematic V2 Architecture

In addition to app and web App splits, architectural transformation must also take into account the features of the app itself. On the one hand, the app needs to get data from each system on the server, which is personal, business oriented, and all calls require non-functional generic processing, which is generic and irrelevant to the business. The architecture needs to be integrated, unified processing, and personalized decentralized processing.

Finally, combined with App/web split requirements and app features, the new app architecture scenario is shown in three.

Figure Three APP 2.0 architecture

1. Peer Isolation

The app is actually equivalent to the PC-side browser, the PC-side application has a service side, the app also needs its own independent server, two service sides need to target their own characteristics, independent development, independent deployment, at the same time to achieve the logical and physical decoupling, from the architectural level to completely get rid of PC thinking wireless.

2. Unified Services

The core logic is stripped out of the Web application and transformed by service, the service is realized without distinguishing between PC and wireless, and the app and Web application all depend on these services, a set of interfaces, multiparty calls.

3. Unified Gateway Portal
Provides a unified wireless gateway, all app calls point to this gateway, the gateway includes a universal layer, interface routing layer, adaptation layer.

• Universal Layer
  Communication protocol adaptation, data encapsulation, security, monitoring, logging these system-level functions, each interface call requires the same logic, these functions are unified by the gateway pre-processing, avoid duplication of development. When implemented, each generic processing logic is encapsulated as an interceptor, follows a unified filtering interface, and is configurable, and the gateway calls these interceptors in turn to support the flexible expansion of common logic.
  The Interceptor interface is defined as follows:

  Object filter (Object input) throws Exception

• Interface Routing
  After the general logic preprocessing, the wireless interface request is 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 based on the URL information in the request, and then gives the request to adapter processing.
  The configuration examples are as follows:

  Www.Website.com/search Searchadapter
  Www.Website.com/detail Detailadapter

• Service adaptation
  The input and output formats of the external wireless interface and the internal SOA interface, as well as the communication protocol, are likely to be different, such as the former is often the Http+json format, which may be the hessian+ binary format, adapter first for the wireless interface and the internal SOA interface adaptation, in addition, Adapter may also aggregate multiple SOA services, providing coarse-grained data to the app to reduce the number of remote network calls. In general, each business system has a 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

Adapter is physically a jar package, provided by the various line-of-business development teams, as the predecessor of the corresponding SOA service, and eventually all adapter centrally deployed in the gateway, which natively supports horizontal scaling.

Intelligent Lifting Grade

The gateway supports centralized control while also bringing a single point of issue. Assuming a service interface in the background, for some reason, the performance of a serious problem, the corresponding adapter processing is slow, the gateway is located on the server's thread is quickly exhausted, resulting in a single interface to bring down the entire system. This kind of problem, simply by adding the machine, horizontal expansion of the gateway number is not solved, in practice, we introduce the intelligent lifting level mechanism to quickly isolate the impact of a single interface, as shown in four:

Figure Four Intelligent Lifting stage

For a particular interface, if within a certain time interval (for example, 5 seconds), its time-out failure rate to a certain percentage (such as 2%), the gateway will be degraded processing of the interface, randomly discard some of the traffic, such as only allow 50% traffic pass. Next 5 seconds, if the failure rate has not improved, allow traffic to pass down to 25%, and so on.

If the success rate improves, the gateway to the interface to do upgrade processing, increase the traffic ratio, in order to recover quickly, generally up to 4 times times the original traffic, and then in the next time period to evaluate whether to trigger the lifting level.

The whole process of automatic intelligent processing (in order to prevent false positives, can support manual intervention), so that the single interface problems, will not affect the entire gateway processing power.

Summarize

The app service-side architecture, through a series of splits and integrations, both optimizes the overall application architecture of the company and lays a good foundation for the app to be bigger and stronger, and the benefits are all-out:

1. Achieve PC-side application and mobile application separation, so that the two completely decoupled, their independent development, the app from the parasitic vines into Bingdilian.

2. The underlying core SOA service provides logic and data based on unified business rules that do not differentiate between PCs, wireless, or other channels (such as the Open API), avoid duplication of development, and prevent the business logic from being contaminated. All the front-end of a mother, Ben is born.

3. Support centralized processing at the system level and decentralized processing at the operational level, depending on the nature of the wireless. Universal logic supports plug-in extensions that can be incrementally supplemented as needed, and adapter enables seamless conversion of internal and external interfaces, enabling logical enhancements (such as service aggregation) for wireless scenarios. In front of the master to lead the door, behind the practice of mother.

4. The mobile research and development team and the line of business research and development teams do their part, each team focuses on their own parts, the mobile team is responsible for the app client and gateway General logic processing, the line of Business development team responsible for the underlying SOA services and front-end adapter adaptation. God's God, Caesar's return to Caesar.

If you use a word to describe the app architecture, V1 is "claw", young relying on each family, V2 is "ya", grow up independent married.

New architecture, big app Mitzvah, are you ready for "Y"?

Deep understanding of large app architecture upgrades from a server-side architecture design perspective