Shulou(Shulou.com)06/02 Report--

I. Background

With the development of the Internet, the scale of website applications continues to expand, conventional vertical application architecture can no longer cope, distributed service architecture and mobile computing architecture are imperative, and a governance system is urgently needed to ensure the orderly evolution of the architecture. Below we use a diagram to illustrate the evolution of architecture and development framework in detail.

Single application architecture

When website traffic is low, just one app is needed, deploying all features together to reduce deployment nodes and costs. At this point, a data access framework (ORM) to simplify the workload of additions, deletions and corrections is key.

Vertical Application Architecture

As the number of visits gradually increases, the acceleration brought by a single application increasing machine becomes smaller and smaller, and the application is broken into several unrelated applications to improve efficiency. At this point, a Web Framework (MVC) for accelerating front-end page development is key.

Distributed Service Architecture

When vertical applications become more and more, interactions between applications are inevitable, and core services are extracted as independent services to gradually form a stable service center, enabling front-end applications to respond more quickly to changing market demands. At this point, a distributed services framework (RPC) to improve service reuse and integration is key.

mobile computing architecture

When there are more and more services, capacity evaluation, waste of small service resources and other problems gradually appear, at this time, it is necessary to add a scheduling center to manage the cluster capacity in real time based on access pressure and improve cluster utilization. At this point, resource scheduling and governance centers (SOAs) to improve machine utilization are key.

II. Demand for service governance

Microservice architecture is a hot topic on the Internet and an inevitable result of the development of Internet technology. It advocates dividing a monolithic application into a set of small services that coordinate and cooperate with each other to provide ultimate value to users.

When monolithic applications are broken down into microservices, service governance is key. So is there a good service governance program? The answer is yes, and a lot of people are using this framework, which is Dubbo. Dubbo is an RPC framework with service governance functions, providing a relatively complete set of service governance solutions, so if enterprises want to achieve service, Dubbo is a good choice. Here are a few basic requirements for Dubbo service governance.

Before large-scale service, applications may simply expose and reference remote services through tools such as RMI or Hessian, invoke them by configuring the URL address of the service, and perform Load Balancer through hardware such as F5.

As more services become available, service URL configuration management becomes very difficult and the F5 hardware Load Balancer becomes more and more stressed at a single point. A service registry is needed to dynamically register and discover services, making the location of services transparent. By obtaining the address list of service providers at the consumer side, soft Load Balancer and Failover are realized, dependence on F5 hardware Load Balancer is reduced, and part of cost can also be reduced.

As it evolves, service dependencies become so complex that it becomes impossible to tell which application should be launched before which, and architects cannot fully describe the architectural relationships of applications. At this point, dependency diagrams between applications need to be drawn automatically to help architects clarify relationships.

Then, as the number of calls to the service becomes larger and larger, the capacity problem of the service is exposed. How many machines do you need to support this service? When should I add machines? In order to solve these problems, the first step is to count the daily call volume and response time of the service as reference indicators for capacity planning. Secondly, it is necessary to dynamically adjust the weight. On the line, the weight of a certain machine is always increased, and the change of response time is recorded in the process of increasing, until the response time reaches the threshold, and the access amount at this time is recorded, and then the total capacity is calculated by multiplying the number of machines by the access amount.

These are the most basic requirements of Dubbo. Simply put, Dubbo is a framework for service invocation. If there is no distributed requirement, it is actually unnecessary to use it. Only when it is distributed, there is a requirement to use a distributed service framework such as Dubbo, and it is essentially a service invocation. Its core components include:

Telecommuting: Provides an abstract encapsulation of a variety of long connection-based NIO frameworks, including a variety of threading models, serialization, and request-response patterns for information exchange.

Cluster fault tolerance: It provides transparent remote procedure call based on interface method, including multi-protocol support and cluster support such as soft Load Balancer, failure fault tolerance, address routing and dynamic configuration.

Auto-discovery: Based on registry directory services, enables service consumers to dynamically look up ×× providers, makes addresses transparent, and enables service providers to smoothly add or remove machines.

III. Structure and characteristics of Dubbo

After finishing the background and requirements, let's talk about the overall architecture of Dubbo and the characteristics of Dubbo.

As shown in the figure above, the overall architecture design of Dubbo is divided into 10 layers, and the top Service layer is the interface layer reserved for developers who actually want to use Dubbo to develop distributed services to implement business logic. The interfaces used by the service consumer are shown on the light blue background on the left, the interfaces used by the service provider are shown on the light green background on the right, and the interfaces used by both parties are shown on the center axis.

Below, combined with Dubbo official documents, understand the design points of each level in the overall architecture hierarchy:

Service interface layer: This layer is related to actual service logic, and corresponding interfaces and implementations are designed according to the services of service providers and service consumers.

Configuration layer (Config): external configuration interface, centering on ServiceConfig and ReferenceConfig, can directly new configuration class, or can generate configuration class through Spring parsing configuration.

Proxy layer: Transparent proxy of service interface, generating client Stub and server skeleton of service, centering on ServiceProxy, extending interface to ProxyFactory.

Registry: Encapsulates the registration and discovery of service addresses, centering on service URLs and extending interfaces to RegistryFactory, Registry, and RegistryService. There may be no service registry, in which case the service provider directly exposes the service.

Cluster layer: Encapsulates routing and Load Balancer of multiple providers, bridges registry, centers on Invoker, and extends interfaces to Cluster, Directory, Router, and LoadBalance. Multiple service providers are combined into one service provider, which is transparent to service consumers and only needs to interact with one service provider.

Monitor layer: RPC call times and call time monitoring, centered on Statistics, extended interfaces are MonitorFactory, Monitor and MonitorService.

Protocol: Encapsulates RPC calls, centering on Invocationand Result, and extending interfaces to Protocol, Invoker, and Exporter. Protocol is the service domain, which is the main functional portal for Invoker exposure and reference, and is responsible for Invoker lifecycle management. Invoker is the entity domain, which is the core model of Dubbo, and other models rely on it or convert to it. It represents an executable entity to which invoke calls can be made. It could be a local implementation, a remote implementation, or a clustered implementation.

Exchange layer: Encapsulates request response mode, synchronous to asynchronous, centering on Request and Response, extending interfaces to Exchanger, ExchangeChannel, ExchangeClient and ExchangeServer.

Transport layer: abstract mina and netty for unified interface, with Message as the center, extended interface for Channel, Transporter, Client, Server and Codec.

Serialize: Reusable tools with extended interfaces Serialization, ObjectInput, ObjectOutput, and ThreadPool.

As can be seen from the above figure, Dubbo provides interfaces that need to be cared for and extended from the 10 layers of the framework for service providers and service consumers, respectively, to build the entire service ecosystem (service providers and service consumers themselves are service-centric).

The following figure is taken directly from Dubbo's official website. Take a look at the invocation relationship between service providers and service consumers based on RPC layer, as shown in the figure:

Node Role Description:

Call relationship description:

0: The service container is responsible for starting, loading, and running the service provider.

1: Service providers register their services with the registry at startup.

2: The service consumer subscribes to the registry for the services he needs at startup.

3: The registry returns the list of service provider addresses to the consumer, and if there are changes, the registry will push the change data to the consumer based on the long connection.

4. Service consumer: from the provider address list, based on the soft Load Balancer algorithm, select one provider to invoke, and if the invocation fails, select another provider to invoke.

5: Service consumers and providers accumulate the number of calls and call time in memory, and send statistical data to the monitoring center once a minute at regular intervals.

Dubbo architecture adopts a very simple model, either the provider provides services or the consumer consumes services, so based on this, two roles of service provider and service consumer can be abstracted. In addition, Dubbo architecture also has the following characteristics: connectivity, robustness, scalability, and scalability. The registry, protocol support, and service monitoring are also described in detail in the characteristics.

Connectivity (association of service consumers and service providers)

The registry is responsible for the registration and lookup of service addresses, which is equivalent to directory services. Service providers and consumers only interact with the registry at startup. The registry does not forward requests, so the pressure is small.

The monitoring center is responsible for counting the number of calls and call time of each service. The statistics are summarized in memory and sent to the monitoring center server once a minute, and displayed in reports.

Service providers register their services with the registry and report invocation times to the monitoring center, excluding network overhead.

The service consumer obtains the address list of service providers from the registry, directly invokes the providers according to the load algorithm, and reports the invocation time to the monitoring center, which includes network overhead.

The registry, service provider and service consumer are all long-term connections, except for the monitoring center.

The registry senses the presence of a service provider through a long connection, the service provider goes down, and the registry immediately pushes the event notification to the consumer.

Both the registry and monitoring center are down, not affecting the providers and consumers who are running, and the consumers cache the provider list locally.

Both the registry and monitoring center are optional, and service consumers can connect directly to service providers.

Robustness (services remain available after any node goes down)

Monitoring center down does not affect the use, just lost part of the sampling data.

After a database crash, the registry can still provide service list queries through the cache, but cannot register new services.

Registry peer-to-peer cluster, any one down, will automatically switch to another.

Service providers and service consumers can still communicate through the local cache after the registry is down.

Service providers are stateless, and any one of them fails without affecting usage.

After all service providers go down, the service consumer application becomes unusable and reconnects indefinitely waiting for the service provider to recover.

Scalability (nodes can be added automatically)

The registry is a peer-to-peer cluster, and machine deployment instances can be dynamically added. All clients will automatically discover the new registry.

The service provider is stateless and can dynamically add machine deployment instances. The registry will push new service provider information to consumers.

upgradability (smooth upgradeability)

When the scale of service clusters is further expanded and the IT governance structure is further upgraded, dynamic deployment and mobile computing need to be implemented without bringing resistance to the existing distributed service architecture. Here is a possible invocation architecture for the future:

Node Role Description:

IV. Summary

Dubbo is Alibaba's open source distributed services framework and is widely used by Internet companies. Dubbo only needs to be configured by Spring to complete the service, and there is no ** for the application. The maturity of the framework itself and the perfection of the documents can basically meet the business needs of various Internet companies.

If you need to use a configuration center, distributed tracking of these content will need to integrate yourself, there are some customization difficulties. Another open source distributed service framework Spring Cloud has developed to the present, considering almost all aspects of service governance, and it is very convenient and simple to develop. Therefore, enterprises need to choose the appropriate architecture to solve business problems according to their own R & D level and stage, whether it is Dubbo or Spring Cloud is an effective tool to implement microservices.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.