dubbo+zookeeper builds a highly available distributed cluster

(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, soft load balancing and failover can be realized, the dependence on the F5 hardware load balancer can be reduced, and some costs can also be reduced.
(2) With 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.
To solve these problems, what Dubbo did for us:
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, it registers the service it provides with the registry.
2. When the service consumer starts, it subscribes to the registration center for the services it needs.
3. The registry returns the service provider address list to the consumer. 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, selects a provider to call based on the soft load balancing algorithm, and if the call fails, select another provider to call.
5. Service consumers and providers accumulate the number of calls and call times in memory, and regularly send statistical data to the monitoring center every minute.

Third: Dubbo integrates with Zookeeper and SpringMVC

Step 1: Install Zookeeper on Linux
Zookeeper is the registration center of the Dubbo service. Dubbo's original database-based registration center did not use Zookeeper. Zookeeper is a distributed service framework. It is a tree-type directory service data storage, which can manage data in clusters. It can be very good here. As the registry of the Dubbo service, Dubbo can be deployed in clusters with Zookeeper. When the provider experiences abnormal shutdowns such as power failure, the Zookeeper registry can automatically delete the provider information, and when the provider restarts, it can automatically restore the registration data, and Subscription request. We first install Zookeeper on linux. We install the simplest single point, and the cluster is more troublesome.

You need to install JdK first, download it from Oracle's Java website, the installation is very simple, so I won't go into details.
Standalone mode
Stand-alone installation is very simple, just get the Zookeeper compressed package and extract it to a directory such as: d:/zookeeper-3.4.5/, the startup script of Zookeeper is in the bin directory, and the startup script under Windows is zkServer.cmd.
Before you execute the startup script, there are several basic configuration items that need to be configured. The Zookeeper configuration file is in the conf directory, which contains zoo_sample.cfg and log4j.properties. All you need to do is to rename zoo_sample.cfg It is zoo.cfg, because Zookeeper will look for this file as the default configuration file when it starts. The following is a detailed introduction to the meaning of each configuration item in this configuration file.

tickTime: This time is used as the time interval for maintaining heartbeats between Zookeeper servers or between clients and servers, that is, a heartbeat will be sent every tickTime.
dataDir: As the name suggests, it is the directory where Zookeeper saves data. By default, Zookeeper also saves log files for writing data in this directory.
dataLogDir: As the name suggests, it is the directory where Zookeeper saves log files
clientPort: This port is the port where the client connects to the Zookeeper server. Zookeeper will listen to this port and accept the client's access request.
When these configuration items are configured, you can start Zookeeper now. After startup, you need to check whether Zookeeper is already in service. You can use the netstat –ano command to check whether the clientPort port number you configured is listening for the service.

The command operation of the Zookeeper client is ls/ to view the current operation command. Create node create /zk mydata
Set the node data set /key value form delete /zk node. under windows. To configure a pseudo-cluster, first create a mid file in the datadir path directory to specify the server to be read from the file configuration. tickTime=2000
Server 1 :
initLimit = 10
syncLimit=5
dataDir=/tmp/zookeeper/server001/data
clientPort=2183
server.3=127.0.0.1:2888:3888 If it is 3, write 3, the file can not specify the format. Notepad also works.
Server 2:
tickTime=2000
initLimit = 10
syncLimit=5
dataDir=/tmp/zookeeper/server002/data
clientPort=2182
server.2=127.0.0.1:2889:3889
Server 3:
tickTime=2000
initLimit = 10
syncLimit=5
dataDir=/tmp/zookeeper/server002/data
clientPort=2181
server.2=127.0.0.1:2881:3881

Then open the distributed server server respectively. Just run ./zkServer.sh start under linux bin. Open the client, switch the server through the command in help, and view the server information.
Description of some attributes of the dubbo:registry tag:
1) Whether register registers the service with this registry center, if it is set to false, it will only subscribe, not register.
2) Check whether an error is reported when the registration center does not exist.
3) Whether subscribe subscribes services to this registry center, if it is set to false, it will only register, not subscribe.
4) timeout registration center request timeout time (milliseconds).
5) The address can be configured in the Zookeeper cluster, and multiple addresses can be separated by commas, etc.
Some attribute descriptions of the dubbo:service tag:
1) The path of the interface service interface
2) ref refers to the ID of the bean of the corresponding implementation class
3) The registry registers with the specified registry and is used in multiple registries. The value is the id attribute of <dubbo:registry>. Multiple registry IDs are separated by commas. If you do not want to register the service to any registry, you can set the value set to N/A
4) register defaults to true, whether the service of this protocol is registered to the registry.
Description of some properties of dubbo:reference:
1) Service interface called by interface
2) check checks whether the provider exists when starting, true reports an error, false ignores
3) registry obtains the service list from the specified registry registration, used in multiple registries, the value is the id attribute of <dubbo:registry>, and multiple registry IDs are separated by commas
4) loadbalance Load balancing strategy, optional values: random, roundrobin, leastactive, respectively: random, round-robin, least active calls

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:dubbo="http://code.alibabatech.com/schema/dubbo"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-3.1.xsd
http://code.alibabatech.com/schema/dubbo
http://code.alibabatech.com/schema/dubbo/dubbo.xsd">
<bean id="propertyConfigurer" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="order" value="1" />
<property name="ignoreUnresolvablePlaceholders" value="true" />
<property name="locations">
<list>
<value>classpath:demo-provider-module.properties</value>
</list>
</property>
</bean>

<dubbo:application name="${app.name}" owner="${app.owner.name}" organization="${app.organization.name}" />

<dubbo:registry id="activity-service-registry" protocol="${registry.protocol}" address="${registry.address}" timeout="5000" />
<dubbo:protocol name="${service.protocol}" port="${service.port}" accesslog="/usr/local/misc_apps/demo-provider/logs/access/demo-provider-dubbo.log" />
<dubbo:monitor protocol="registry" />
<dubbo:reference id="merchandiseRemoteService" registry="activity-service-registry" timeout="2000" check="false" interface="demo.dcn.DubboService" version="1.0.0" />
</beans>

dubbo+zookeeper builds a highly available distributed cluster

Guess you like