With the development of the Internet, the scale of website applications continues to expand, and the conventional vertical application architecture can no longer cope. Distributed service architecture and mobile computing architecture are imperative, and a governance system is needed to ensure the orderly evolution of the architecture.
Single Application Architecture
When the website traffic is very small, only one application is needed, and all functions are deployed together to reduce deployment nodes and costs.
At this point, a data access framework (ORM) that simplifies the CRUD workload is key.
Vertical application architecture
When the number of visits gradually increases, the acceleration brought by the addition of a single application to the machine becomes smaller and smaller, and the application is divided into several applications that are not related to each other to improve efficiency.
At this point, a web framework (MVC) for accelerating front-end page development is key.
Distributed service architecture
When there are more and more vertical applications, the interaction between applications is inevitable. The core business is extracted as an independent service, and a stable service center is gradually formed, so that front-end applications can respond more quickly to changing market demands. .
At this time, the distributed service framework (RPC) for improving business reuse and integration is the key.
When there are more and more services in the mobile computing architecture (Dubbo)
, problems such as capacity evaluation and waste of small service resources gradually appear. At this time, a dispatch center needs to be added to manage the cluster capacity in real time based on the access pressure and improve the cluster utilization rate.
At this point, a Resource Scheduling and Governance Center (SOA) for improving machine utilization is key.
2. Before the large-scale service of the Dubbo architecture
, applications may simply expose and reference remote services through tools such as RMI or Hessian, call them by configuring the URL address of the service, and perform load balancing through hardware such as F5.
(1) When there are more and more services, service URL configuration management becomes very difficult, and the single point pressure of F5 hardware load balancer is also increasing.
At this time, a service registry is needed to dynamically register and discover services, so that the location of the service is transparent.
And by obtaining the address list of service providers on the consumer side to achieve soft load balancing and failover, reduce the dependence on the F5 hardware load balancer, and also reduce part of the cost.
(2) When further development, the dependencies between services become complicated and misunderstood, and it is not even clear which application should be started before which application, and architects cannot fully describe the architectural relationship of the application.
At this time, it is necessary to automatically draw a dependency relationship diagram between applications to help architects clean up the relationship.
(3) Then, the call volume of the service is increasing, and the capacity problem of the service is exposed. How many machines does this service need? When should the machine be added?
In order to solve these problems, the first step is to count the current daily call volume and response time of the service as a reference indicator for capacity planning.
Secondly, it is necessary to dynamically adjust the weight. Online, increase the weight of a certain machine all the time, and record the change of the response time in the process of increasing, until the response time reaches the threshold, record the number of visits at this time, and then use This number of visits is multiplied by the number of machines to invert the total capacity.
The SOA of the Dubbo architecture can solve the above problems.
Node role description
Provider : The service provider that exposes the service.
Consumer : The service consumer that invokes the remote service.
Registry : A registry for service registration and discovery.
Monitor : The monitoring center that counts the invocation times and invocation time of the service.
Container : The service runs the container.
Description of the calling relationship
0. The service container is responsible for starting, loading, and running the service provider.
1. When the service provider starts up, it registers the service it provides with the registry.
2. When the service consumer starts, subscribe to the registration center for the services they need.
3. The registration center returns the service provider address list to the consumer. If there is a change, the registration center will push the change data to the consumer based on the long connection.
4. For service consumers, from the provider address list, based on the soft load balancing algorithm, select a provider to call, and if the call fails, select another provider to call.
5. For service consumers and providers, the number of calls and the calling time are accumulated in the memory, and statistics are sent to the monitoring center every minute.
Advantages
Connectivity
The registration center is responsible for the registration and search of service addresses, which is equivalent to a directory service. Service providers and consumers only interact with the registration center at startup, and the registration center does not forward requests, so the pressure is less
The monitoring center is responsible for statistics of each service The number of invocations, invocation time, etc., the statistics are first aggregated in memory and sent to the monitoring center server once a minute, and displayed in a report.
The service provider registers the services it provides with the registration center, and reports the invocation time to the monitoring center. Including network overhead
The service consumer obtains the address list of service providers from the registration center, and directly calls the provider according to the load algorithm, and reports the calling time to the monitoring center at the same time, this time includes network overhead
Registration center, service provider, service consumer All three are long-term connections, except for the monitoring center
The registration center senses the existence of the service provider through the long-term connection, and the service provider is down, and the registration center will immediately push the event to notify the consumer
The registration center and the monitoring center are all down, Does not affect the running providers and consumers, the consumer caches the provider list locally
Registration center and monitoring center are optional, service consumers can directly connect to service providers
Robustness
The failure of the monitoring center does not affect the use, but only loses some sampled data
After the database is down, the registry can still provide service list query through the cache, but cannot register new services
For the peer-to-peer cluster of the registry, after any one goes down, Will automatically switch to another
After all the registration centers are down, the service provider and the service consumer can still communicate through the local cache
The service provider is stateless, after any one goes down, it will not affect the use
of all service providers After it goes down, the service consumer application will be unavailable, and will reconnect indefinitely and wait for the service provider to recover.
Scalability
The registry is a peer-to-peer cluster, which can dynamically increase machine deployment instances, and all clients will automatically discover the new registry
Service providers are stateless and can dynamically increase machine deployment instances, and the registry will push new service provider information to consumers.
Upgradability
When the scale of the service cluster is further expanded, the IT governance structure is further upgraded, and it is necessary to realize dynamic deployment and flow Calculation
The next article explains how to use it, and a demo will be uploaded.