Talking about community PHP business development_PHP tutorial

In the current period of rapid development of Internet business, new products are springing up like mushrooms after a rain, and old product lines and new businesses are also constantly making breakthroughs and attempts. This puts forward higher requirements for rapid development iteration.

1. Basic operating environment
For the development of new products, it is necessary to be able to quickly build a LAMP architecture. Then it is nothing more than choosing a webserver, choosing a PHP version, choosing a MySQL version, then choosing a PHP development framework and choosing some PHP general extensions and basic libraries. Readers may think that this process is already very fast. Can it be faster?

The selection process requires R&D students to have a certain accumulation of relevant technical directions, weigh the pros and cons and priorities, and it is also a period of research and study. If there is a one-click installation program that provides automated installation of webserver, PHP, and MySQL, as well as a high-performance and flexible PHP development framework, and provides standardized, safe, and commonly used configuration files, it can greatly shorten the cost of product line LAMP system research and shorten the work cycle. .

Four steps for one-click installation: (1) download; (2) a small amount of configuration; (3) make install; (4) start; (of course there is end, a simple operation and maintenance tool), and the running environment is OK.

2. Business development framework
The community product lines are independent and have to develop their own business logic in a closed manner. In fact, there are many common business logic processes between various product lines, such as session verification, permission judgment, parameter verification, log printing, etc. For different product lines, all requests need to be processed. Can we not repeat the development? There are many differences between wireless business development and PC business logic, but there are also many commonalities between different product lines. Can we not repeat development?

The product line usually abstracts the processing of these general logic to a certain extent internally, and designs it in the form of ActionChain or through base class solutions. The framework will be more thorough: the common logic that must be processed by all requests is provided in the form of a business logic framework, and R&D students only need to focus on the logic processing specific to user requests.

The processing logic of a user request is as follows: the blue part is the controller framework processing flow, and the green part is combined with the controller framework to process the common business logic of all requests. The user who really needs the attention and development of R&D students requests proprietary business processing, that is, the yellow part (of course, one is not just an Action script, the processing of a request will be horizontally layered with MVC, which will be covered later.)

Business logic framework inheritance is provided in the one-click installer, which is easy to obtain.

The native PHP business and templates are deeply coupled without any layered design. The result is poor code reusability. Such original PHP systems are almost extinct now. The PHP development framework uniformly handles routing, rendering, AutoLoad, abstraction of general business logic and basic libraries, and proprietary business MVC layering, which has greatly accelerated the development of product line business logic. As shown below:

From top to bottom, they are the access layer (high-performance webserver), PHP development framework (routing, automatic loading, view engine, etc.), application and basic libraries, and storage engine.

3. General services
Community product lines have many common needs, such as log processing, configuration file processing, string processing, database interaction, network interaction, etc. These algorithms and tools are packaged into phplib and are relatively mature for use in product lines.

The business functions of community product lines have a lot of commonality, such as comment function, tag function, friend function, album, task system, etc. Many community product lines have similar new functions and new requirements, and they are designed and developed separately. ?

These requirements have personalized requirements on the UI of each product line, but the back-end implementation solutions are similar and have a certain degree of versatility. Functional servitization provides API interfaces for use by different product lines. The product lines only need to focus on the display logic and private data processing logic, and the services are operated and maintained in a unified manner to reduce the system complexity under the product.

4. Vertically split subsystems
As our business expands, the number of UIs and modules within a single application increases, and the interaction between Action and Logic (corresponding to the M layer in MVC, which can be further layered internally, will not be detailed this time) , the interaction between logic and logic is becoming more and more complex. Developers need to understand the logic of the entire application. To upgrade a certain logic, you need to check whether there are reverse dependencies on other UI or logic in the entire application. Under the requirements of rapid development, developers do not have a clear understanding of the coupling relationship between logic, which will inevitably cause more and more problems, affect the quality of the project, and make it difficult to start development.

As more and more problems are exposed in a single system, it’s time to split the system. How to dismantle? Split vertically by business logic. Separate functionally independent business logic into independent subsystems. At this time, we also need to consider the versatility of the business. Can it be service-oriented? Does the application already have a common service with the same needs? At this time, the general business logic is encapsulated into a general service or uses a general service, and the bypassed business logic is independently divided into subsystems. This reduces a lot of burden on the original single and huge system. After completing this stage of reconstruction, the system will become as follows:

A single system is split into multiple APPs (there is still a horizontal MVC layer inside the APP), and a large number of common services are reused. As a result, the R&D team has greatly improved its division of labor and parallel development.

5. Cross-system call framework
However, the actual situation is that dependencies between split subsystems cannot be completely eliminated. In order to solve the data dependency relationship between multiple subsystems, a unified solution is needed: API framework. Subsystems become independent applications (APPs), and there are mutual data dependencies between APPs, and these dependencies are provided externally in the form of APIs. As shown below:

When APP1 relies on the data of APP2 or APP3, APP2 and APP3 will provide part of the data interface in the form of API, the data will be packaged uniformly, and other APP calls within the product line will be provided through standard URLs. This form is very similar to a product's open API (open API to third parties, we call it openAPI, comply with a unified protocol, and undergo necessary permission verification), and the API interface that solves the data dependencies between internal subsystems can be further simplify.

The API provided by the APP provides interface description (input, output), processing API URL, and Logic forwarding implementation. API_LIB manages all API interfaces in a unified way and provides a unified API_Server::call interface for calling. Completely aligns with the internal forwarding and implementation details of the shield. Usually, in order to simplify and unify the operation and maintenance within the product line, all subsystems are deployed on the same machine. The API interface will bring additional network consumption and increase qps. Under this deployment premise, API_Server can be implemented through HTTP calls or optimized to direct PHPRequire. Advantages:

(1) Framework unification, interface convergence, and business decoupling;

(2) Improved performance, high ease of use, and high scalability;

6. UI split model
At this time, the independent subsystem can focus on its business logic, and the burden on the core system is also reduced. However, the core system has the highest frequency of upgrades and updates, and the business logic is also the most complex. After a certain period of time, the core system becomes bloated and difficult to maintain. At this time, some design patterns can be used to reduce the scalability and maintainability of the program. But even so, there is still a certain learning cost. Within an App, developers need to pay more or less attention to the code of other modules. As it gradually develops, upgrading will require troubleshooting many points. It’s time to further reduce the burden. What if the burden is reduced? Divided into two parts:

Step One: Asynchronous Model

Page rendering is divided into two stages: topic page data and other non-topic page data. Data is provided by different data sources based on different parts of the page. According to this logic, the app will be further divided vertically.

PHPService is composed of PHPmodule + a thin layer of UI to return formatted data.

Step 2: Synchronize the model

Module splitting, different business logic is split into different Modules, divided into multiple data sources, each providing different data content. After the unified UI schedules different data sources, the unified rendering page returns a response.

After such continuous load reduction, there will be more and more subsystems and modules within the product line, and it is necessary to maintain the unity of deployment and operation and maintenance. The division of labor among team members is very detailed, the business understanding is very focused and in-depth, and the efficiency of cooperation and parallelism will be higher, thus shortening the entire development cycle.

7. Summary
As business logic grows, if the business functions of each subsystem or module are too bloated, they need to be continuously reduced to keep them within a controllable scale. As the product develops, there will be more and more subsystems and modules within the product line, and deployment and operation and maintenance need to be unified and kept simple. The division of labor among team members is more detailed, the business understanding remains focused and in-depth, and the efficiency of cooperation and parallelism will be higher, thus shortening the entire development cycle.

by luhaixia

http://www.bkjia.com/PHPjc/485978.htmlwww.bkjia.comtruehttp: //www.bkjia.com/PHPjc/485978.htmlTechArticleIn the current period of rapid development of Internet business, new products are springing up like mushrooms after a rain, and new businesses in old product lines are also springing up. Constantly making breakthroughs and attempts. This raises the bar for rapid development iteration...