With the increasing complexity of business systems, there are more and more calls between systems. In the process of microservice splitting and iteration, is it constantly splitting new independent services or encapsulating independent components to The way we rely on the jar package to provide services is a problem that we often need to face. This article will discuss in detail the differences between these two different ways, their respective advantages and disadvantages, and applicable scenarios, hoping to inspire everyone.
1. Componentization & Service Definition
With the rapid development of the company's Internet business, the complexity of the system is getting higher and higher, and there are more and more calls between systems. In the process of splitting and iterating microservices, two scenarios are often encountered:
In what form does some public function modules in your own system provide services, whether to encapsulate all the logic and methods and provide them in the form of jar packages, or to split out a service independently and provide it through an interface;
Involving calls to external system services, there may be many services inside the system that need to call external services, but the calling logic is the same, then the interface calling logic and method for the external system is encapsulated into a jar package for the internal services to rely on Call, or separate the interface call logic and method of the external system into one service independently, and then the internal services call the external system service by calling this independently split service.
For the above two scenarios, we can conclude summarized as component-based and service of two different services provided in the form of:
Component definition: encapsulate some public function modules in the system or some logic methods called to external systems into an independent jar package, and the system in need directly depends on the jar package to use the corresponding service, which we call here Componentization
An example of componentization of public function modules in the system, service A, B, and C all rely on component D to use related functions.
Componentized example of external system service interface calling, service A, B, C all use component D to call external service E
Service-oriented definition: That is, some public function modules in the system or some logical methods called to the external system are independently divided into a service, and the service exposes a unified interface for all the services in need to call, here we call it It is servitization.
The example of servicing public function modules in the system corresponds to the independent splitting of component D in Figure 1 into service D, and service D provides interfaces for services A, B, and C to call.
The external system service interface calls the service-oriented example, which corresponds to the independent splitting of the component D in the example Figure 2 into the service D, and the services A, B, and C call the external system service E by calling the service D.
So in actual work, in the face of different scenarios and problems, which method should we choose? Whether it is a relevant reference standard, and what issues need our special attention and consideration. Next, we will introduce in detail the advantages and disadvantages of componentization and serviceization and applicable scenarios.
2. Advantages and disadvantages of componentization and applicable scenarios
What are the advantages and disadvantages of componentization to call third-party services through jar dependence?
2.1 Advantages of componentization
The service call performance is high , because the third-party services are directly transferred by calling the methods in the jar package, and the performance loss is less. Using this method for scenarios with higher performance requirements will have certain advantages;
Save the cost of server machines , because you do not need to deploy services independently, you can save server resources, especially in scenarios where a large amount of server requests are high and a large number of server resources need to be deployed, the more server resources can be saved.
2.2 Disadvantages of componentization
The maintainability is poor . Once the logic method of calling other services needs to be changed, or the jar package provided by a third party needs to be upgraded, in addition to the maintenance and upgrade of the component itself, the services that rely on this component in our own system need to be upgraded together. , As time goes by, it will be troublesome to sort and maintain;
The cost of component upgrade is high and the risk is relatively high . If there are many services that rely on the component inside the system, the upgrade cost will be high. The cost here includes the cost of development, maintenance and upgrade of various services, the cost of testing and verification, and the cost of operation and maintenance release. , The more services that need to be upgraded and maintained, the higher the cost and the greater the corresponding risk.
2.3 Scenarios for componentization
So which specific scenarios are suitable for deployment in a componentized way? According to our experience, it is recommended to use a componentized approach that meets the characteristics of the following scenarios:
Some public function processing scenarios in the own system do not involve the connection and call of the database resource level, which is suitable for componentization;
For external system service invocation scenarios, the large amount of service concurrency requires high service performance, mainly some to C services, which require high performance and low latency, and need to minimize service invocation links. This situation is more suitable for external System call logic and methods are provided in a componentized manner. If the business itself has extremely high performance requirements, in many cases performance issues will be prioritized and some disadvantages caused by componentization will be tolerated;
Companies have stricter requirements for server resource cost control and try to reduce costs as much as possible. This situation is more common for start-up companies or projects, often requiring low-cost, fast trial and error.
2.4 Cases of using componentization
Case 1
App store has 240 million monthly active users and 60 million daily active users. It has very high requirements on the performance of the store server. Many services in the store involve a large number of external system service calls, such as CPD, games, DMP, etc., in the user experience and Under the premise of giving priority to performance, we all integrate calls to external systems through componentization, and tolerate some inconveniences in maintenance and upgrades.
2.5 Negative case of componentization
Case 2
again shares a negative case of a store using a component approach. Many service modules in the store involve the management of some operational resources. Many services need to deliver some operational resource materials to the client, which was not sufficient at the beginning. Considering various scenarios, the most obvious thing is that the acquisition of these resource materials involves the connection and invocation of database resources. After using componentization, it will lead to high development and maintenance costs and low iteration efficiency.
3. The advantages and disadvantages of servitization and applicable scenarios
3.1 Advantages of servicing
After being serviced, resources can be isolated without affecting each other, internal details can be hidden from the caller, development and deployment can be carried out independently, and development efficiency can be improved;
Compared with componentization, maintainability is better. After serviceization, each module service is decoupled. Whether it is the logic method of calling other services needs to be changed, or the jar package provided by a third party needs to be upgraded, only the service is needed. You can upgrade itself, as long as the interface protocol does not change, other services that call the service do not need to be changed, which is very convenient to maintain;
The service upgrade cost is low and the risk is controllable. No matter how many systems rely on the service, we only need to handle the upgrade of this service. The cost of development and maintenance upgrades, testing and verification costs, and operation and maintenance costs are all relative to componentization. Greatly reduced, the risk is also small, in the current situation where various jar package security problems frequently need to be upgraded and repaired in time, the advantages of servicing become more obvious.
3.2 Disadvantages of servicing
Service performance is relatively poor compared to componentization. The more servicing is split, the more complex the mutual calls between services and the longer the call link. The more network request calls between services, the worse the performance ；
Multi-service and multi-node deployment after servicing will bring some inherent problems in natural distributed systems, such as consistency, distributed transaction processing, etc. In addition, the overall stability of the service brought by more nodes and longer service links Descent problems, etc.;
After servicing, more server resource costs will be increased. For each independent deployment of a service on the service call link, in order to ensure service performance, the corresponding number of machine resources corresponding to the original service will be increased or more, and the service will be split. The more detailed the higher the cost;
3.3 Scenarios applicable to servicing
So which scenarios are suitable for deployment in a service-oriented way? It is recommended to use a service-based approach that meets the characteristics of the following scenarios:
For some public function modules in your own system, if it involves resource calls at the database level, it is recommended to provide them in a service-oriented way to avoid all services that rely on this public function module have to configure and maintain the corresponding database resource information, which will be maintained later. Very painful, such as database changes, computer room migration, etc.;
For external system service calls, if there are many internal systems that rely on external services, but the service concurrency is small, the performance requirements are not high, and the service call link lengthening has little effect, and the concurrency and performance requirements are not high. The business is smooth and does not require too many server resources. In this case, it is recommended to encapsulate the external system interface call into an independent service. When the external system call logic changes or the related jar package is upgraded, we only need to upgrade this one. Service, you do not need to upgrade all related services within your own system.
3.4 Service-oriented use cases
Case 1: The
service-oriented case of public function modules in the system. Each module of the application store often has some public filtering logic before returning information to the client. The processing of these public filtering logic also involves interaction with mysql and redis, so These public filtering logics are directly and independently split into an independent service. At present, the service not only provides services within the project, but also is used by many other departments in the company.
Some students may have questions. For services with a large number of users and high service concurrency and performance requirements, splitting one more service solves the problem of data resource isolation, but how to solve the problem of performance degradation caused by a long service call link For example, the negative case of componentization of operational resources mentioned above (Figure 6). For this kind of problem, we can increase the cache on the caller to solve the performance problem, because this business scenario has real-time data The requirements are not high.
Some students may have questions. For services with a large number of users and high service concurrency and performance requirements, splitting one more service solves the problem of data resource isolation, but how to solve the problem of performance degradation caused by a long service call link For example, the negative case of componentization of operational resources mentioned above (Figure 6). For this kind of problem, we can increase the cache on the caller to solve the performance problem, because this business scenario has real-time data The requirements are not high.
Case 2:
Service call of external system service. We have an open platform system, which mainly serves developers and does not require high system performance. One of the requirements involves the call of external system services, and the open platform system There are multiple projects that need to call the external system service. In order to facilitate subsequent service maintenance and upgrades, the call logic of the external system service is unified encapsulated into an internal service dedicated to external system calls, and then through the internal service To call an external system.
Four, summary
Summarize the advantages and disadvantages of componentization and serviceization:
_ |
Componentization |
Servicing |
Development efficiency |
low |
high |
Call performance |
high |
low |
Maintainability |
low |
high |
Maintenance cost |
high |
low |
Machine cost |
low |
high |
Service as a whole stability |
high |
low |
Applicable scene |
Does not involve database resources, large service concurrency and high performance requirements |
Involving database resources, small service concurrency, low performance requirements |
To sum up, there is no absolute good or bad between componentization and serviceization. Each has its own advantages and disadvantages. Which method should be used is related to our real problem scenarios. You can refer to the above analysis and combine yourself. The actual project situation to choose the way that suits oneself, the technology is ultimately to serve the business, in most cases there is no perfect solution, only the most suitable solution.
Author: vivo Internet server team -Yao Wenyu