Discussion on community PHP business development to improve efficiency and shorten development cycle

In the current rapid development of the Internet business, new products springing up, the old product line new business is constantly breaking and trying. This puts a higher demand on rapid development iterations.

First, the basic operating environment

For new product development, must be able to quickly build a lamp structure. Then there is nothing to choose a webserver, select a php version, choose a MySQL version, then select a PHP development framework and select some PHP universal extensions and base libraries. The reader may feel that the process is fast, can it be faster?

The selection process requires the development of students to the relevant technical direction has a certain accumulation, weigh the pros and cons and priorities, but also a survey and learning. If you have a key installer, provide automated installation webserver,php,mysql, and carry a high-performance flexible PHP development Framework, and provide standardized, secure, common configuration files, you can greatly shorten the product line lamp system research costs, shorten the work cycle.

One-click installation Four steps: (1) Download, (2) A small amount of configuration, (3) make install; (4) Start; (Of course, there is the end, simple operation tools), the operating environment OK.

Second, the Business Development framework

The Community product line is fragmented, closed to develop their own business logic. In fact, there are many common business logic processing among each product line, such as session verification, authority judgment, parameter verification, log printing and so on. Different product lines, all requests need to do these processing, can not repeat development? There are many differences between the wireless business development and the business logic on the PC, but there is a lot of commonality between the different product lines. Can not repeat development?

Product lines in the internal usually to the processing of these general logic to do a certain degree of abstraction, designed as a actionchain form or through the base class of the scheme. The framework will be more thorough: the common logic for all of these requests is provided in the form of a business logic framework, and the students only need to focus on the logical processing of the user's request.

The processing logic of a user request is as follows: The blue part is the Controller framework processing process, the green part and the controller framework are combined to handle all the request common business logic. And the real need for research and development of the students concerned and developed the user request proprietary business processing, that is, the yellow part (of course, one is not just an action script, a request processing will be horizontal MVC hierarchy, this piece of follow-up will be involved.) )

The business logic framework is provided in one-click Installer and is simply available.

Native PHP business and template coupling is very deep, did not do any layered design, the result is code reusability is poor. Such a primitive PHP system is now almost extinct. The PHP development Framework unifies the routing, the rendering, the autoload, the common business logic abstraction and the base storehouse abstraction, the proprietary business MVC stratification, has greatly accelerated the product line business logic development. As shown in the following illustration:

From the top down, are the access layer (high-performance webserver), PHP development Framework (routing, automatic loading, view engine, etc.), application and basic library, storage engine.

Third, the General Service

The Community product line has many common needs, such as log processing, configuration file processing, string processing, database interaction, network interaction and so on. These algorithms and tools are packaged into Phplib for product line use has been more mature.

Community product line business functions exist a lot of versatility, such as comment function, tag function, friend function, Atlas, task system, etc., in many community product lines have similar new features and new requirements, their respective design and development?

These requirements have personalized requirements on the UI of each product line, but the backend implementations are similar and have certain versatility. function service, provide API interface to different product line use, product line only need to pay attention to display logic and private data processing logic can, and service unified operation dimension, reduce the system complexity under the product.

Four, vertical split subsystem

So as our business expands, the number of UI and module within a single application is increasing, and the interaction between action and logic (the M layer in MVC, which can be further layered, not detailed), logic and logic is becoming more and more complex. Development students need to understand the entire application of the logic, a logic upgrade, you need to troubleshoot the entire application of the existence of other UI or logic reverse dependencies. In the rapid development of the request, the development of students in the logic of the mutual coupling between the comb is not clear, is bound to cause more and more problems, affecting the quality of the project, difficult to start development.

The problem of a single system is exposed more and more, it is time to split the system. How to split? Split vertically by business logic. Separate the function of the business logic out of the independent subsystem. This time also need to consider the commonality of the business, whether can be serviced? apply a generic service that already has the same requirements? At this point, the generic business logic is packaged into a generic service or a generic service is used, and the bypass business logic is independent of the subsystem, thus reducing the original single, large system. After completing this phase of refactoring, the system joins into the following

A single system is split into multiple apps (there are still horizontal MVC hierarchies within the app), and a large number of general-purpose services are reused. In this way, the development team has been greatly improved in the parallel development of the Staff Division.

V. Cross-system call framework

However, the real status quo, in the split between the subsystems can not completely eliminate dependence. In order to solve the relationship of data dependency among multiple subsystems, a unified solution is needed: API framework. Subsystems become independent applications (apps), and there are mutual data dependencies between apps, which are provided externally in the form of APIs. The following figure

When APP1 relies on APP2 or APP3 data, APP2 and APP3 provide part of the data interface in the form of an API, data is packaged uniformly, and other app calls within the product line are provided through the URL of the standard specification. This form is very similar to a product opening API (for third party open APIs, which we call Openapi, adheres to a unified protocol and validated by the necessary permissions), and the API interface to resolve data dependencies between internal subsystems can be further simplified.

The API solution provided by app provides interface description (input, output), url,logic forwarding implementation of the processing API. Api_lib Unified to manage all API interfaces and provide a unified Api_server::call interface for invocation. Complete the forwarding and implementation details on the inside of the shield. Usually within the product line in order to achieve the simplification and unification of operational dimensions, all subsystems are deployed by the same machine, the API interface will bring additional network consumption, and increase QPS. Under this deployment, the implementation of Api_server can be implemented directly phprequire via HTTP invocation or optimization. Advantage:

(1) Framework unification, interface convergence, business decoupling, (2) performance improvement, ease of use, high scalability;

Vi. UI Split Model

At this time the independent subsystem can focus on its business logic, the core of the system also get the burden. But the core system upgrades the frequency is highest, the business logic is also the most complex. At a certain time, the core system became bloated and difficult to maintain. Some design patterns can be used to reduce the scalability and maintainability of the program. But even so, there is a certain cost of learning, in an app, the development of students more or less need to pay attention to other modules of the code, gradually developed to upgrade a little need to troubleshoot a lot of points. It's time to lighten the burden again. If the burden is divided into two parts:

First step: Asynchronous model

Page rendering is divided into two stages: Subject page data and other non topic page data. Data is provided by different data sources depending on the different parts of the page. Follow this logic to further vertically split the app.

Phpservice is a thin, phpmodule+ UI that returns formatted data.

Step Two: Synchronize the model

module to split, different business logic split into different module, differentiated into multiple data sources, respectively, providing different data content, by the unified UI scheduling different data sources, unified rendering page return response.

After such a continuous burden, the product line within the subsystem and modules will be more and more, the need to maintain the deployment and operation of the unification. The division of the team members is very fine, business understanding is very focused and in-depth, cooperation, parallel efficiency will be higher, so that the whole development cycle shortened.

Vii. Summary

As the business logic grows, the business functions of each subsystem or module need to be continuously reduced to maintain a manageable size if they are too bloated. So along with the product development, the product line internal subsystem and the module will be more and more, needs to maintain the deployment and the Operation dimension unification, maintains is simple. The division of the team members of a finer, business understanding to remain focused and in-depth, cooperation, parallel efficiency will be higher, so that the entire development cycle shortened.