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

With the development of the Internet, the scale of website applications continues to expand, the conventional vertical application architecture has been unable to cope with, distributed service architecture and mobile computing architecture are imperative, there is an urgent need for a governance system to ensure the orderly evolution of the architecture.

Single application architecture

◦ when the website traffic is very small, only one application is needed to deploy all the functions together to reduce the deployment nodes and costs.

◦ at this time, the data access framework (ORM), which is used to simplify the workload of additions, deletions, modifications and queries, is the key.

Vertical application architecture

◦ as the number of visits increases gradually, the acceleration caused by a single application to increase the machine becomes smaller and smaller, and the application is divided into several unrelated applications to improve efficiency.

◦ at this point, the Web framework (MVC) used to accelerate front-end page development is the key.

Distributed service architecture

◦ when there are more and more vertical applications, the interaction between applications is inevitable, the core business will be extracted, as an independent service, gradually form a stable service center, so that the front-end applications can respond to the ever-changing market demand more quickly.

◦ at this time, the distributed service framework (RPC) for improving business reuse and integration is the 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 cluster capacity in real time based on access pressure to improve cluster utilization.

◦ at this point, the Resource scheduling and Governance Center (SOA), which is used to improve machine utilization, is the key.

Before large-scale service, the application may simply expose and reference the remote service through tools such as RMI or Hessian, invoke it by configuring the URL address of the service, and load balance through hardware such as F5.

(1) when there are more and more services, the configuration management of service URL becomes very difficult, and the single point of pressure on F5 hardware load balancer is also increasing.

At this point, a service registry is needed to dynamically register and discover services to make the location of services transparent.

By obtaining the address list of service providers in the consumer, soft load balancing and Failover can be realized, which can reduce the dependence on F5 hardware load balancer and reduce part of the cost.

(2) when further development, the dependency relationship between services becomes complex, and even can not tell which application should be launched before which application, the architect can not fully describe the architectural relationship of the application. At this point, you need to automatically draw a dependency graph between applications to help the architect clean up the relationship.

(3) then, as the amount of service transfer becomes larger and larger, the problem of service capacity will be exposed. how many machines do this service need to support? When should I add the machine?

In order to solve these problems, the first step is to count the daily call volume and response time of the service as a reference index for capacity planning. Secondly, the weight can be adjusted dynamically, on-line, the weight of a machine is increased all the time, and the change of response time is recorded in the process of increasing, until the response time reaches the threshold, and the number of visits at this time is recorded. Then multiply the number of visits by the number of machines to deduce the total capacity.

These are the most basic requirements of Dubbo. For more service governance issues, please see:

Http://code.alibabatech.com/blog/experience_1402/service-governance-process.html

Node role description:

Provider: the provider of the exposed service.

Consumer: the service consumer that invokes the remote service.

Registry: the registry for service registration and discovery.

Monitor: the monitoring center that calculates the call time and call time of the service.

Container: the service running container.

Description of invocation relationship:

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

1. Upon startup, the service provider registers the services it provides with the registry.

2. Service consumers subscribe to the services they need from the registry when they start up.

3. The registry returns a list of service provider addresses to the consumer, and if there is a change, the registry will push the change data to the consumer based on the persistent connection.

4. The service consumer, from the provider address list, chooses one provider to call based on the soft load balancing algorithm, and then chooses another one if the call fails.

5. Service consumers and providers accumulate the number of calls and call time in memory and regularly send statistics to the monitoring center every minute.

(1) Connectivity:

The registry is responsible for the registration and search of the service address, which is equivalent to the directory service. Service providers and consumers only interact with the registry at startup, and the registry does not forward requests, so there is less pressure.

The monitoring center is responsible for counting the number and time of each service call. The statistics are first sent to the monitoring center server every minute after the memory is collected, and displayed in a report.

The service provider registers the services it provides with the registry and reports the call time to the monitoring center, which does not include network overhead

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

There is a long connection among the registry, the service provider and the service consumer, except the monitoring center.

The registry is aware of the existence of the service provider through a long connection, and the service provider is down, and the registry will immediately push the event to notify the consumer.

The registry and monitoring center are all down, and the running providers and consumers are not affected. Consumers cache the provider list locally.

Registries and monitoring centers are optional, and service consumers can connect directly to service providers

(2) fitness:

The downtime of the monitoring center does not affect the use, but only part of the sampled data is lost.

After the database is down, the registry can still query the list of services through the cache, but cannot register new services

The registry is a peer-to-peer cluster. When any one is down, it will automatically switch to the other.

After the registry is down, service providers and consumers can still communicate through the local cache.

The service provider is stateless, and its use will not be affected when any one of them goes down.

After all the service providers are down, the service consumer applications will be unavailable and will be reconnected indefinitely waiting for the service providers to resume.

(3) scalability:

The registry is a peer-to-peer cluster, which can dynamically add machine deployment instances, and 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.

(4) upgrading:

When the scale of the service cluster expands further, leading to the further upgrading of the IT governance structure, dynamic deployment and mobile computing are required. The existing distributed service architecture will not bring resistance:

Deployer: the local agent that automatically deploys the service.

Repository: the repository is used to store service application release packages.

Scheduler: the dispatch center automatically increases or decreases service providers based on access pressure.

Admin: unified management console.

Installation

1. Local services

1. Define the service interface: (this interface needs to be packaged separately and shared between the service provider and the consumer)

Public interface CustomerService {public String getName ();}

2. Implement the interface in the service provider: (hide the implementation from the service consumer)

Public class CustomerServiceImpl implements CustomerService {@ Override public String getName () {System.out.print ("I print"); return "print results";}}

3. Then introduce several packages of dubbo

Dubbo-2.5.3.jar

Log4j.jar

Netty-3.5.7.Final.jar

Slf4j.jar

Slf4j-log4j.jar

Zkclient.jar

Zookeeper.jar

4. Use Spring configuration declaration to expose the service:

Create a new applicationProvider.xml with the following configuration:

I expose the address of the server here to be managed by zookeeper. Users must first install zookeeper applications before they can use this function. For relevant installation steps, please see the relevant blog posts.

5. Load Spring configuration and invoke remote service: (you can also use IoC injection)

Public class DubooProvider {public static void main (String [] args) {ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext (new String [] {"applicationProvider.xml"}); context.start (); System.out.println ("Press any key to exit."); try {System.in.read ();} catch (IOException e) {/ / TODO Auto-generated catch block e.printStackTrace ();}

And start, make it enter the start state.

The above are the complete steps of the server provider, and the functional interfaces have been written, so let's start how to call remotely.

Second, serving consumers

1. Create a new configuration file applicationConsumer.xml, which contains the following contents:

For use in web, we configure in web.xml that the spring starts the read process

ContextConfigLocation/WEB-INF/application.xml / WEB-INF/applicationConsumer.xml

2. Call the API

The calling process is simple, first typing the interface file into a jar package, and then referencing it in this project.

The calling program in springmvc is as follows:

Autowired CustomerService demoService; @ RequestMapping (value= "duboo1") public void duboo1 () {demoService.getName ();}

It can be executed successfully.

III. The use of dubbo-admin

Download dubbo-admin-2.5.3.war

Put it under tomcat and configure dubbo.properties

Vi webapps/ROOT/WEB-INF/dubbo.propertiesdubbo.propertiesdubbo.registry.address=zookeeper://127.0.0.1:2181dubbo.admin.root.password=rootdubbo.admin.guest.password=guest

Modify the URL and port of zookeeper

Start:

. / bin/startup.sh

Open it and visit the home page directly as follows:

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.