1.dubbo是个什么东西
Dubbo是阿里开源的一个分布式服务框架, 可以实现远程通信，自动容错，服务发现，主要特点是可以很好的进行服务的治理和服务器的监控
我们采用的是zk（文件系统加通知机制）作为dubbo的注册中心。
[服务化的改造]
是一个分布式的服务框架
SOA (面向服务的体系结构，是一个组件模型)
使用http做后台端服务的弊端：
1.为了增加项目的并发量，后端的服务可以使用nginx做负载或者F5硬件做负载，这样做的弊端是
不能实现服务的动态添加和剔除，（每一次去增加机器都需要在nginx上做配置），而且会增加负载均衡服务器的单点压力
2.不能完成服务的容量测算和服务的监控和治理
dubbo是可以完成这些功能的
服务的监控（监控中心）：1.可以完成动态完成机器的容量测算 2. 自动画出应用间的依赖关系图
服务的治理（管控台）：1.动态的调整服务调用关系的权重 2.方便定位服务的负责人 3.集群容错
重启zk
2.你们项目中是如何使用的
我们的电商项目，分为商品模块，购物车模块，订单模块，用户模块，促销模块，库存模块，支付模块，风控系统 生产系统
促销模块（服务的消费者）：----->商品模块（服务的提供者）
（服务提供者） 订单，购车（服务的消费者）
最佳实践
3.它可以解决什么问题
1.rpc调用问题
2.负载均衡算法
3.服务的监控
4.服务的治理
1）如果项目中要使用dubbo.,那么需要引入dubbo的依赖
2）我们当时在做项目配置dubbo:application的owner时候，不识别@，修改成-
3）在创建maven项目依赖的时候，只找jar, 我以前有一个同事。。。。。war的事情
4）在使用zk 做注册中心的时候需要加上zk的依赖
5）在导入zk的依赖的时候发现jar冲突，log4j冲突，我们使用exclusions 排除依赖
6）电商中的少买问题，比如下单成功需要调用库存系统占用库存，我们当时没有注意dubbo的消费者调用提供者会有一个重试机制，由于网络原因
有可能调用成功但是没有响应，这样消费者重复扣减库存，就出现了少买，之后看了dubbo的官方文档，发现有一个dubbo:reference中 有一个reties的属性用来控制是否重试 将retries设置为0就不会重试了
4.和其他的类似的rpc框架比较
Webservice
rmi
这些框架基本都是提供了rpc的远程调用，但是对于调用关系复杂的系统，则不适合使用，因为他是没有服务治理和监控功能。
5.dubbo的原理
0. 服务容器负责启动，加载，运行服务提供者。
1. 服务提供者在启动时，向注册中心注册自己提供的服务。
2. 服务消费者在启动时，向注册中心订阅自己所需的服务。
3. 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
4. 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
5. 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。
未完待续。。。。将不定时更新
