Talking about Zookeeper+dubbo distributed service

Zookeeper+dubbo was used in the last project.

Let's just say our current system architecture
HTTP access to the server to go through the content: some of Ali's security mechanisms will not say "use of Ali server"
Just say nginx-tomcat–db.
Nginx is a load balance around, another interview asked me Nginx the reverse agent, now think about what the interviewer should ask is the domain name of the reverse proxy
is to use a domain name to specify a port, specifically

http://blog.csdn.net/hzw2312/article/details/60757808

Such a proxy
As for load balancing, yes, please. http can not be divided into different tomcat to slow down the tomcat pressure

And then again, Tomcat generally develops services that are aggregated services
The project is very big, the project module develops, basically all is such son
For example, user module, separate out to do a service, put under a tomcat, then commodity module, order module, payment module, and so on, such as separate deployment, the first can reduce Tomcat pressure, second: User module may be used more, a tomcat is not enough, I can add one, Simple and convenient, without the need to join other modules,

Then to the late development: A module is also very large, such as the Order module,
There is a distributed service, separating the service layer, using the Dubbo remote call
This time to see the role of Dubbo, the book says that invoking remote services is like invoking a local service, developers do not need to focus on the service layer logic implementation, directly to you a document to tell you what I am the service is used, and then find some outsourcing, junior staff, Specialized in developing controller, that thing, no brains,

So the question is Dubbo how to do it.
I do not know: The beginning of everything is difficult, and will be used first to study how to use the not.
I'll just say Dubbo how to use it.
Plain Text Description:
Create a Spring-dubbo.xml under the resource folder
Add the project to Spirng.xml and start loading the code for this Dubbo file
And then again, the Dubbo configuration.
Dubbo has a provider and consumer two kinds of files.

General Service side of the question is Spirng-dubbo-provider.xml

Provider is the service provider that is configured to write services,
Configured to be

<dubbo id= "Demoservice"  bean= "Com.csdn.demo.service.DemoService" ...>

... Representatives also have some other configuration
This will load this Dubbo file when this tomcat is started Dubbo will load this service into Dubbo

And then what? In the service of writing controller, you also need to join Spring-dubbo-consumer.xml this configuration file
The content has some configuration "you can check it yourself, I also just study"
Content is also this file

<dubbo id= "Demoservice"  bean= "Com.csdn.demo.service.DemoService" ...>

In this file we indicate which service to invoke the Dubbo service
In the consumer service, we just need to write a service that maps to this bean.
You can then call the inside method directly, just like invoking a local service, invoking a remote service,

And then say something about the role of zookeeper in this
What about zookeeper? Typically placed in a Dubbo configuration file to indicate the Dubbo service port
The use of zookeeper distributed, one hang, another replace the role of the main node, to ensure the stability of services, relevant and other, Hadoop also used the zookeeper distributed, technology is used together, which is the stability of which we use which

Normally we will deploy three zookeeper service nodes
One outage and two services available.

To continue the development of distributed today
Got a lot of information and learned something new.
The next node is Spingsource proposed Springcloud
Springcloud is based on Springboot.
Relatively Dubbo a bit is to develop concise support restful development
Another springcloud update is much faster than the Dubbo update.
But now domestic still use Dubbo more, have Chinese document, technology more mature
Foreign use of springcloud than more
Springcloud integrates a large number of third-party components, but the advantage is springboot automation configuration
Dubbo provides RPC calls, Springcloud supports restful calls:
Two kinds of difference.

Service provider and caller interface dependencies are too strong: we define our own service abstraction interfaces for each micro service, and through continuous integration to the private warehouse, the caller application has strong dependencies on the abstract interfaces provided by the Micro service, so that the development, testing, and integration environments require strict management versioning dependencies , will not appear the service side and the caller's inconsistency causes the application not to compile the success and so on a series of problems, and this also can directly affect the local development the environment request, often one relies on many services the upper application, each day must update many code and install later can carry on the follow-up development. Such dependencies can be a big nightmare for the development team without a strict version management system or the development of some automated tools. While the rest interface is lighter than RPC, the service provider and the caller depend on only a piece of paper contract, there is no code-level strong reliance, of course, the rest interface also has pain point, because the interface definition is too light, it can easily cause the definition of the document and the actual implementation of inconsistent results in the integration of services, but the problem , you need to integrate swagger with each service, so that the code of each service can be integrated with the document to resolve. So in a distributed environment, the rest-way service dependencies are more flexible than the RPC-mode dependencies.
services are sensitive to platforms and are difficult to reuse: usually when we provide external services, we provide them in rest, so that the cross-platform features can be achieved, and the callers of any language can be implemented according to the interface definition. So when we provide the rest interface in Dubbo, we have to implement a layer of proxies to transform the RPC interface into a rest interface for external release. If we have each service itself as a rest interface, when to provide services, mainly in the API Gateway configuration mapping relationship and access control can realize the reuse of services.
It is also believed that these pain points are one of the reasons why Dangdang has added rest support to the Dubbox (Dubbo Open Source extension).

Reference documentation
http://blog.csdn.net/shuijieshuijie/article/details/53133082