System component architecture design

content

1. Componentization and the construction of "big, middle and Taiwan"

2. "Componentization" and "Microservice" of projects

3. "Componentization" and "Front-end"

4. Project "componentization" transformation case

foreword

Recently, I was working on a project. The name of the project included the word "componentization". The goal of the project was to integrate business logic, adjust the system architecture, and finally realize a set of codes for multi-country reuse and reduce maintenance costs. From the perspective of this project goal, it has nothing to do with "componentization" at all. To be precise, this project should be called an "internationalization" transformation project.

The result of "componentization" is to deploy the system as a "component" and provide external services. The "componentization" of the system I understand is actually another name for the "serviceization " or "microservice" of the system. . The difference is that "components" are external "services", and some "services" are private and cannot be external.

A component named "Component 1 " is encapsulated here, including 3 sub-service systems, of which A service is open to the outside world, and B and C services exist to support the external A service, but are not open to the outside world. The idea of "microservices" is adopted here to split "component 1 " into three subsystems, which are somewhat similar to public methods and private methods in java . System A corresponds to public methods and can provide external services, while systems B and C correspond to private methods only. Called inside "Component 1 ". The so-called services here are all subsystems built through the RPC framework. In essence, whether to provide external services is realized through the authority verification system of the RPC framework (such as Taobao's Dubbo ).

1. Componentization and the construction of "big, middle and Taiwan"

Now some major Internet companies are promoting the "separation of the former, middle and Taiwan" and vigorously promoting the "construction of the middle and Taiwan system". This section mainly talks about the relationship between China-Taiwan construction and componentization. The following are all personal opinions.

"Middle-office system" (personal understanding): It is composed of countless general "components", and these general "components" provide services for the "front-end system". The so-called "building blocks"

"Front-end system" (personal understanding): It is the business system corresponding to each specific business line. These systems will call the services provided by each "component" in the "middle-office system" according to specific business needs. A simple diagram is as follows:

From this figure, it can be seen that: adding a "front-end business", as long as the "middle-office system" is strong enough, the new business can quickly complete a new business by calling various public "components" in a way similar to "building blocks" System Development. This should be the theoretical basis of Ali's so-called "small front desk" and "big and middle stage".

The advantages are quick launch and quick trial and error. The "front-end system" only needs to invest a small amount of labor cost to quickly complete the development and launch of new products, and make adjustments according to the market's response. In recent days, the big guys discussing Amazon's "flywheel theory" + "two pizzas" probably means this.

2. "Componentization" and "Microservice" of projects

The construction of the "front-middle-office system" mentioned above is divided at the level of the company's organizational structure. I personally think that in their respective project teams, they can also use this "componentization" idea to split subsystems, and they have their own "front-middle-stage" subsystems in the project team, regardless of whether the project is in the organizational structure or not. Whether it is "front stage" or "back stage". The splitting of the "front-middle-office" subsystem within a specific project is actually somewhat similar to the "microservice" split:

This picture is quoted from another blog " Microservices - Fusing and Isolation "

Each sub-project in the " jsf service sub-project set" in the above figure can be regarded as a "component" (only this component has only 1 project, but each project can continue to be modularized and split according to business needs), belonging to "Central System".

The " web service sub-project set" in the above figure actually corresponds to various business systems, which are accumulated by calling various basic services, and belong to a lightweight "front-end" system. As long as the "componentization" in the " jsf service sub-project set" is strong enough, we can maximize the reuse of these common components in the project team, reduce human input, and quickly realize business development.

From the above explanation, three conclusions can be drawn:

1. The organizational structure adjustment of the "front and middle office" at the company level is the "front and middle office" in a broad sense. The "front office" system is more business-oriented, and the "middle office" system is more general-purpose "componentization". Internal ( or external) attached energy.

2. Specific to the project team, the idea of "micro-service" can also be used to split the system into its own "front-middle-stage" system, and establish its own "large-middle-stage" subsystem (corresponding to multiple components) that belongs to the project. , it can also attach energy internally (or externally).

3. The "front-end system" within the project team prefers to use external public "components" (saving money for the company), if not, create its own "components" in the internal "middle-office system", and when the time is ripe, you can use this "component" component" external service.

3. "Componentization" and "Front-end"

The above explanations are all based on the "back-end". In fact, the development of front-end js and css can also be split according to the idea of "componentization" and deployed independently for multiple reuse. The development of front-end development is roughly divided into three stages (from the perspective of the back-end):

1. Coupling stage: The front-end and back-end codes are coupled in the same code project, and the deployment is also merged and deployed together. The development mode is generally that the front-end R&D first builds static pages, and the back-end R&D then integrates these built static pages into page templates (such as velocity , freemaker and other templates). The disadvantage is obvious. The same page needs to be developed twice, and the front-end builds the back-end template once.

2. The front-end and back-end separation stage: the front-end independently develops and deploys pages, js , css , etc., and the back-end only provides data interfaces. The advantage of this is that all page development has front-end control, and the back-end only needs to focus on business logic. But the disadvantage is also obvious, the front-end workload increases sharply. In addition, because the data is acquired asynchronously from the back end, the front-end rendering page will flash. Some pages can be rendered in the back-end according to the situation, but the rendering requires js and css , which are obtained from an independent static server.

3. Front-end "componentization" stage: In the second stage, we have deployed the front-end related code independently, but this undoubtedly greatly increases the front-end workload. At this time, we need to "componentize" the front-end construction, and build a series of our own front-end components within the team. Other systems can use these components directly without the need to develop and deploy them again. As shown below:

At this point, you may have noticed that the so-called "componentization", "microservices", and "large and medium-sized platform construction" all have similar aspects, but the level of application is different. This idea of improving reusability can be found in implemented at all levels.

Fourth, the project "component" architecture case

Here is an example of a non-real project (similar to a project that the author has recently done). Before the "componentization" of this project, the system was divided into pc shops, pc activities, m shops, and m activities. The system is divided as follows:

You may have already discovered the problem. The four business systems here are very similar, but developers need to maintain a set of code independently for each system: front-end, decoration, rendering, and browsing. The disadvantages are obvious:

1. A lot of R&D resources are invested, new functions are developed or modified, and the workload is X4 ;

2. 4 sets of similar or identical logic maintenance , without any reusability;

3. Tired of various business processing, there is no more R&D resources to invest in new project development and project performance optimization;

4. If you need to add a new business one day, you need to develop another set from beginning to end. . . . ;

Next, we use the idea of componentization to transform the system architecture, extract the front and back ends by "componentization", and extract the common functional modules as "components" for separate deployment. The specific business system calls these public components to achieve the purpose of reuse. The modified system architecture is as follows:

After the transformation of the technical architecture shown above, some general "components" (both front and back ends) will be extracted in the project. At the same time, the business system is more lightweight, and complex and general logic processing can be realized by directly calling general "components". Let's take a look at the advantages of "componentization":

1. Only one set of general "components" needs to be developed, which can reduce R&D investment;

2. Common "components" can be reused by multiple services, reducing maintenance costs;

3. The saved R&D resources can be invested in the deep optimization of components and new business development, entering a virtuous circle (Amazon "flywheel theory");

4. If you want to add a new business, you only need to develop a small amount of private logic, and other general logic can be reused directly.

The theoretical analysis of the system componentized architecture design is here. The above only represents personal opinions. If you have different opinions, please leave a message for discussion, thank you!

Please indicate the source of the correction:

System component architecture design

http://moon-walker.iteye.com/blog/2393310

Guess you like