Analyzing Distributed Service Framework

Technology is for the needs of the service, the same is true of distributed service frameworks, which are not born out of thin air, but also because of the need for such a distributed service framework to be born, in this blog to detailed analysis of the reasons for the birth of the Distributed service Framework (in fact, the need for a distributed service framework of the application scenario, The implication here is that not all applications need the distributed service framework, the feature that the distributed service framework needs to provide, and the optional technical solutions to implement these feature.

In fact, this blog should be written in the implementation of the Distributed Service Framework series blog before,:), no nonsense, to see why the need for distributed service framework, in a continuous development of large-scale applications, the system's business and functions continue to increase, while the technology in the continuous development of continuous changes in the team, It is easy to create the phenomenon: each subsystem, module implementation of a variety of technologies, deployment of the subsystems of different ways and requirements, the various subsystems of the interaction between the way and methods are not unified. The problem with this phenomenon is that the whole system is confused, but the technology is continuous development, so the specific implementation of subsystems, modules should be completely limited should not be possible, nor necessary, but would like the system to provide external functions can use a unified deployment and interactive methods, In this way, each subsystem can maintain its black box implementation, the other subsystems do not want to and do not need to care about its implementation, only need to be able to call the unified way to provide the functionality they can, this is the first need to appear.

At first the entire application is deployed on one machine, but as the system functions more and more, have to constantly increase the machine to reduce the pressure on the server, but soon there are bottlenecks, have to put the application layered deployment, so you can support a period of time, after a while to find the bottleneck again, So I want to be able to divide the system again, this time it becomes a hope to be able to deploy with very fine granularity, instead of deploying a bunch of functions on the same machine, the benefit is that the system reusability can be enhanced again, the server pressure can be effectively reduced, So that the system can continue to keep scable (like Google) at a lower cost, and this is also the evolution of ebay, you can go to see the famous ebay Architecture Evolution ppt, and a Chinese ebay is how to make.

As you can see from the description of the requirements scenario above, there is not a lot of scenarios that require a distributed service framework, and there is one scenario that is not mentioned, and that is that for a large enterprise, there is a need for a distributed service framework because of the variety of software that needs to be used. Because the way to meet that kind of scene can be simpler.

The application scenario of Distributed Service Framework is analyzed, and the Distributed service Framework has two main purposes:

1, the constraints need to provide external functions, to ensure that they are in a unified way to provide and access;

2, distributed deployment of fine-grained functionality.

After determining these two purposes, it is necessary to provide a detailed analysis of what feature is required to achieve these two objectives.

To constrain the function provided externally, to ensure the provision and acquisition in a unified manner, the first need to set the standard is the function in the end of what way to provide, here is the first birth of the service this very good image of the noun, the external function is actually to provide services for others, then the service in the end what is it? Interfaces are naturally preferred, so services are provided as interfaces, and there may be some meta information about services, such as the name of the service, description, dependencies, the machine, and so on, and then how to define the functions of each subsystem as a service. This requires a distributed service framework that provides a strong integration capability, such as a subsystem that is implemented in spring, that supports the ability to define a spring bean directly as a service, and that the solution to this problem is how other subsystems know that there are these services. Therefore, the need to provide a unified service registry, and the corresponding problem is how each service application to find these services, how to invoke these services, this is also a distributed service framework needs to be addressed, after the above feature, the first requirement can be basically achieved.

Distributed deployment of fine-grained functionality, this can be achieved directly in the case of the first requirement, because the Distributed service Framework has no requirement for the granularity of the service application and can be coarse and thin, but the distributed deployment of fine-grained functionality actually brings additional requirements, That is how to assemble these fine-grained services directly to meet the needs of the business, which is what the distributed Services framework should provide, and also to note that the stability and performance of the system can be compromised when it becomes a fine-grained distributed deployment scenario, These two points are important for large applications, and the distributed service framework needs to be considered.

....................................................... A cup of coffee, have a rest ..... ..... ...... ..... ..... ...... ..... ...... ...... ..... ...... ...