RPC服务框架 -- Dubbo
一、模式比较
我们知道Dubbo和SpringCloud是分布式RPC框架，那么先了解传统开发模式和分布式开发模式的一点知识。
MVC设计模式：Model View Controller 模型-视图-控制器，首先区分MVC和三层架构区别，MVC是一种设计模式，不是分层结构，最典型的例子就是：JavaBean - JSP - Servlet，JavaBean作为数据库访问和操作解决业务逻辑实现，JSP作为系统向用户的展示包括HTML，Servlet负责用户界面和业务逻辑的通信控制。SpringMVC中的Controller其实也就是采用MVC模式也就是三个和一为一个Controller
三层架构：数据访问层 - 业务逻辑层 - 表示层 也就是开发分包经常分的Dao - Service - Controller，其中数据访问层的ORM框架，表示层的web框架，业务逻辑层的业务框架等等。这是一种最传统的单机开发架构
SOA：面向服务的架构，也就是分为服务层和表现层，也就是将原来的三层架构前两个数据访问层和业务逻辑层合为一个服务层。表现层只需要处理页面的交互，业务逻辑都是调用服务层的服务来实现的。主要针对类似银行业务，比较重量级使用XML格式，企业级EJB服务
微服务架构：在soa的基础上在进行细分，这也是分布式架构。将项目中的每一个项目模块在进行细分为类似于用户模块，订单模块，支付模块等等，每个模块服务之间独立运行全部模块服务组成一个整体项目。内部采用http协议+restful+json格式更加轻量级，使用RPC服务治理管理整个模块服务。主流框架：Dubbo And SpringCloud
二、Dubbo的使用
1.简介及原理参照其他博文，首先假设电脑已经安装好了JDK，Zookeeper注册中心和Dubbo环境搭建。那么怎么使用Dubbo搭建一个微服务架构？
首先一个需求：用户下单，调用查询用户地址。开始分服务模块，Member - Order - API_Interface
引入Dubbo_Mermber：
//引入dubbo
com.alibaba
dubbo
2.6.2
com.101tec
zkclient
0.10
org.apache.curator
curator-framework
2.12.0
//配置提供者
ARI_interface模块：
//定义UserBean
public class UserAddress implements Serializable{
private Integer id;
private String userAddress;
private String userId;
private String consignee;
private String phoneNum;
private String isDefault;
}
//定义用户查询地址接口
public Interface UserService{
public List getUserAddressList(String userId);
} Member模块：
//首先引入服务接口
com.jxau.dubbo
API_interface
0.0.1-SNAPSHOT
//实现服务接口
public class UserServiceImpl implements UserService {
@Override
public List getUserAddressList(String userId) {
// TODO Auto-generated method stub
return userAddressDao.getUserAddressById(userId);
}
}
order模块：
//引入API
com.jxau.dubbo
API_interface
0.0.1-SNAPSHOT
//调用服务接口
public class OrderService {
UserService userService;
/**
* 初始化订单，查询用户的所有地址并返回
* @param userId
* @return
*/
public List initOrder(String userId){
return userService.getUserAddressList(userId);
}
}
引入Dubbo_order：
//引入dubbo
com.alibaba
dubbo
2.6.2
com.101tec
zkclient
0.10
org.apache.curator
curator-framework
2.12.0
//配置消费者信息
Dubbo实现高可用和高并发。
1.ZK实现集群下dubbo配置
Random LoadBalance
随机，按权重设置随机概率。
在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。
RoundRobin LoadBalance
轮循，按公约后的权重设置轮循比率。
存在慢的提供者累积请求的问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。
LeastActive LoadBalance
最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。
使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。
ConsistentHash LoadBalance
一致性 Hash，相同参数的请求总是发到同一提供者。
当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。算法参见：http://en.wikipedia.org/wiki/Consistent_hashing
缺省只对第一个参数 Hash，如果要修改，请配置 集群容错：
Failover Cluster
失败自动切换，当出现失败，重试其它服务器。通常用于读操作，但重试会带来更长延迟。可通过 retries="2" 来设置重试次数(不含第一次)。
重试次数配置如下：
Failfast Cluster
快速失败，只发起一次调用，失败立即报错。通常用于非幂等性的写操作，比如新增记录。
Failsafe Cluster
失败安全，出现异常时，直接忽略。通常用于写入审计日志等操作。
Failback Cluster
失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作。
Forking Cluster
并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源。可通过 forks="2" 来设置最大并行数。
Broadcast Cluster
广播调用所有提供者，逐个调用，任意一台报错则报错 [2]。通常用于通知所有提供者更新缓存或日志等本地资源信息。
集群模式配置
按照以下示例在服务提供方和消费方配置集群模式
服务治理：熔断，限流等使用Hystrix
生产者：
@Service(version = "1.0.0")
public class HelloServiceImpl implements HelloService {
@HystrixCommand(commandProperties = {
@HystrixProperty(name = "circuitBreaker.requestVolumeThreshold", value = "10"),
@HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "2000") })
@Override
public String sayHello(String name) {
// System.out.println("async provider received: " + name);
// return "annotation: hello, " + name;
throw new RuntimeException("Exception to show hystrix enabled.");
}
}
消费者：
@Reference(version = "1.0.0")
private HelloService demoService;
@HystrixCommand(fallbackMethod = "reliable")
public String doSayHello(String name) {
return demoService.sayHello(name);
}
public String reliable(String name) {
return "hystrix fallback value";
}