The page is temporarily unavailable
nginx error!
The page you are looking for is temporarily unavailable.
Please try again later.
Website Administrator
Something has triggered an error on your
This is the default error page for
nginx that is distributed with
It is located
/usr/share/nginx/html/50x.html
You should customize this error page for your own
site or edit the error_page directive in
the nginx configuration file
/etc/nginx/nginx.conf.他的最新文章
他的热门文章
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)The page is temporarily unavailable
nginx error!
The page you are looking for is temporarily unavailable.
Please try again later.
Website Administrator
Something has triggered an error on your
This is the default error page for
nginx that is distributed with
It is located
/usr/share/nginx/html/50x.html
You should customize this error page for your own
site or edit the error_page directive in
the nginx configuration file
/etc/nginx/nginx.conf.The page is temporarily unavailable
nginx error!
The page you are looking for is temporarily unavailable.
Please try again later.
Website Administrator
Something has triggered an error on your
This is the default error page for
nginx that is distributed with
It is located
/usr/share/nginx/html/50x.html
You should customize this error page for your own
site or edit the error_page directive in
the nginx configuration file
/etc/nginx/nginx.conf.OverviewArchitectureProvider: 暴露服务的服务提供方。Consumer: 调用远程服务的服务消费方。Registry: 服务注册与发现的注册中心。Monitor: 统计服务的调用次调和调用时间的监控中心。Container: 服务运行容器。Relations0. 服务容器负责启动，加载，运行服务提供者。1. 服务提供者在启动时，向注册中心注册自己提供的服务。2. 服务消费者在启动时，向注册中心订阅自己所需的服务。3. 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。4.&服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。5. 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。6. 注册中心，服务提供者，服务消费者三者之间均为长连接，监控中心除外7.&注册中心通过长连接感知服务提供者的存在，服务提供者宕机，注册中心将立即推送事件通知消费者8.&注册中心和监控中心全部宕机，不影响已运行的提供者和消费者，消费者在本地缓存了提供者列表Invoker Procedures !important0. 这里的Invoker是Provider的一个可调用Service的抽象，Invoker封装了Provider地址及Service接口信息。 1. Directory代表多个Invoker，可以把它看成List&Invoker&，但与List不同的是，它的值可能是动态变化的，比如注册中心推送变更。 2. Cluster将Directory中的多个Invoker伪装成一个Invoker，对上层透明，伪装过程包含了容错逻辑，调用失败后，重试另一个。 3. Router负责从多个Invoker中按路由规则选出子集，比如读写分离，应用隔离等。 4. LoadBalance负责从多个Invoker中选出具体的一个用于本次调用，选的过程包含了负载均衡算法，调用失败后，需要重选。
Configuration ProriotyService方法级优先，接口级次之，全局配置再次之。如果级别一样，则消费方优先，提供方次之。BasicJVM启动-D参数优先，这样可以使用户在部署和启动时进行参数重写，比如在启动时需改变协议的端口。XML次之，如果在XML中有配置，则dubbo.properties中的相应配置项无效。Properties最后，相当于缺省值，只有XML没有配置时，dubbo.properties的相应配置项才会生效，通常用于共享公共配置，比如应用名。FeaturesCheck on StartDubbo缺省会在启动时检查依赖的服务是否可用，不可用时会抛出异常，阻止Spring初始化完成，以便上线时，能及早发现问题，默认check=true。
#如果你的Spring容器是懒加载的，或者通过API编程延迟引用服务，请关闭check，否则服务临时不可用时， #会抛出异常，拿到null引用，如果check=false，总是会返回引用，当服务恢复时，能自动连上。
可以通过check="false"关闭检查，比如，测试时，有些服务不关心，或者出现了循环依赖，必须有一方先启动。
Fault ToleranceFailover Cluster # DEFAULT 失败自动切换，当出现失败，重试其它服务器。(缺省) 通常用于读操作，但重试会带来更长延迟。 可通过retries="2"来设置重试次数(不含第一次)。
Failfast Cluster 快速失败，只发起一次调用，失败立即报错。 通常用于非幂等性的写操作，比如新增记录。
Failsafe Cluster 失败安全，出现异常时，直接忽略。 通常用于写入审计日志等操作。
Failback Cluster 失败自动恢复，后台记录失败请求，定时重发。 通常用于消息通知操作。
Forking Cluster 并行调用多个服务器，只要一个成功即返回。 通常用于实时性要求较高的读操作，但需要浪费更多服务资源。 可通过forks="2"来设置最大并行数。
Broadcast Cluster 广播调用所有提供者，逐个调用，任意一台报错则报错。(2.1.0开始支持) 通常用于通知所有提供者更新缓存或日志等本地资源信息。
important&默认使用Failover，我们的系统使用这种方式，其实应该限定最大重试次数，比如两次（因为一般一台失败，其他的也会失败）#set max retry time 2 &dubbo:service retries="2" /& OR: &dubbo:reference retries="2" /& OR： &dubbo:reference&
&dubbo:method name="findFoo" retries="2" /& &/dubbo:reference&
Load Balancingimportant&基于软负载均衡算法Random LoadBalance 随机，按权重设置随机概率。 在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。
RoundRobin LoadBalance 轮循，按公约后的权重设置轮循比率。 存在慢的提供者累积请求问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。
LeastActive LoadBalance 最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。 使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。
ConsistentHash LoadBalance 一致性Hash，相同参数的请求总是发到同一提供者。 当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。 算法参见：http://en.wikipedia.org/wiki/Consistent_hashing。 缺省只对第一个参数Hash，如果要修改，请配置&dubbo:parameter key="hash.arguments" value="0,1" /& 缺省用160份虚拟节点，如果要修改，请配置&dubbo:parameter key="hash.nodes" value="320" /&
Thread Model事件处理线程说明0. 如果事件处理的逻辑能迅速完成，并且不会发起新的IO请求，比如只是在内存中记个标识，则直接在IO线程上处理更快，因为减少了线程池调度。 1. 但如果事件处理逻辑较慢，或者需要发起新的IO请求，比如需要查询数据库，则必须派发到线程池，否则IO线程阻塞，将导致不能接收其它请求。 2. 如果用IO线程处理事件，又在事件处理过程中发起新的IO请求，比如在连接事件中发起登录请求，会报“可能引发死锁”异常，但不会真死锁。
Dispatcher #all default0. all 所有消息都派发到线程池，包括请求，响应，连接事件，断开事件，心跳等。 1. direct 所有消息都不派发到线程池，全部在IO线程上直接执行。 2. message 只有请求响应消息派发到线程池，其它连接断开事件，心跳等消息，直接在IO线程上执行。 3. execution 只请求消息派发到线程池，不含响应，响应和其它连接断开事件，心跳等消息，直接在IO线程上执行。 4. connection 在IO线程上，将连接断开事件放入队列，有序逐个执行，其它消息派发到线程池。
ThreadPool #fixed default0. fixed 固定大小线程池，启动时建立线程，不关闭，一直持有。(缺省) 1. cached 缓存线程池，空闲一分钟自动删除，需要时重建。 2. limited 可伸缩线程池，但池中的线程数只会增长不会收缩。(为避免收缩时突然来了大流量引起的性能问题)。
E.G&dubbo:protocol name="dubbo" dispatcher="all" threadpool="fixed" threads="100" /&
参数说明iothread epoll模型，所以是CPU核数+1&dubbo:protocol& threads int 可选 100 性能调优 服务线程池大小(固定大小) 2.0.5以上版本&dubbo:protocol& iothreads int 可选 cpu个数+1 性能调优 io线程池大小(固定大小) 2.0.5以上版本Multi-protocol不同服务在性能上适用不同协议进行传输，比如大数据用短连接协议，小数据大并发用长连接协议。我们系统使用dubbo协议，基于长连接的协议（传输大小有限制）。如果是大文件可以使用RMIMulti-Registry,Multi-Group,Multi-Version，Group-Aggregation见手册，不过Group-Aggregation倒是很有意思&dubbo:reference interface="com.xxx.MenuService" group="*"&
&dubbo:method name="getMenuItems" merger="mymerge" /& &/dubbo:service&
#或：(指定合并方法，将调用返回结果的指定方法进行合并，合并方法的参数类型必须是返回结果类型本身)
&dubbo:reference interface="com.xxx.MenuService" group="*"&
&dubbo:method name="getMenuItems" merger=".addAll" /& &/dubbo:service&
JSR303 based validation#interface &dependency& &&&&&groupId&javax.validation&/groupId& &&&&&artifactId&validation-api&/artifactId& &&&&&version&1.0.0.GA&/version& &/dependency&
#implement &dependency& &&&&&groupId&org.hibernate&/groupId& &&&&&artifactId&hibernate-validator&/artifactId& &&&&&version&4.2.0.Final&/version& &/dependency&
E.G&dubbo:reference id="validationService" interface="com.alibaba.dubbo.examples.validation.api.ValidationService" validation="true" /& OR: &dubbo:service interface="com.alibaba.dubbo.examples.validation.api.ValidationService" ref="validationService" validation="true" /&
Cache结果缓存，用于加速热门数据的访问速度，Dubbo提供声明式缓存，以减少用户加缓存的工作量。&dubbo:reference interface="com.foo.BarService"&
&dubbo:method name="findBar" cache="lru" /& &/dubbo:reference&
泛话引用、泛话实现使用Map代替POJO回声测试所有服务自动实现EchoService接口，只需将任意服务引用强制转型为EchoService，即可使用。MemberService memberService = ctx.getBean("memberService"); // 远程服务引用
EchoService echoService = (EchoService) memberS // 强制转型为EchoService
String status = echoService.$echo("OK"); // 回声测试可用性
服务上下文与隐式传参，&基于这个实现架构所有配置信息都将转换为URL的参数，以字符串协议，类似于HTTP HEADER传送。RpcContext是一个ThreadLocal的临时状态记录器，当接收到RPC请求，或发起RPC请求时，RpcContext的状态都会变化。RpcContext.getContext()
异步调用，本地调用based on injvm流程图参数回调，本地存根参数回调方式与调用本地callback或listener相同，只需要在Spring的配置文件中声明哪个参数是callback类型即可，Dubbo将基于长连接生成反向代理，这样就可以从服务器端调用客户端逻辑。不是把代码传过去总的来说，没有想到应用的场景service: &bean id="callbackService" class="com.callback.impl.CallbackServiceImpl" /& &dubbo:service interface="com.callback.CallbackService" ref="callbackService" connections="1" callbacks="1000"&
&dubbo:method name="addListener"&
&dubbo:argument index="1" callback="true" /&
&!--也可以通过指定类型的方式--&
&!--&dubbo:argument type="com.demo.CallbackListener" callback="true" /&--&
&/dubbo:method& &/dubbo:service&
consumer: &dubbo:reference id="callbackService" interface="com.callback.CallbackService" /&
callbackService.addListener("http://10.20.160.198/wiki/display/dubbo/foo.bar", new CallbackListener(){
public void changed(String msg) {
System.out.println("callback1:" + msg);
延迟暴露关于暴露时间！important 在Spring解析到&dubbo:service /&时，就已经向外暴露了服务，而Spring还在接着初始化其它Bean。1. 强烈建议不要在服务的实现类中有applicationContext.getBean()的调用，全部采用IoC注入的方式使用Spring的Bean。 2. 如果实在要调getBean()，可以将Dubbo的配置放在Spring的最后加载。 3. 如果不想依赖配置顺序，可以使用&dubbo:provider deplay= /&，使Dubbo在Spring容器初始化完后，再暴露服务。 4. 如果大量使用getBean()，相当于已经把Spring退化为工厂模式在用，可以将Dubbo的服务隔离单独的Spring容器。
Shutdown服务提供方停止时，先标记为不接收新请求，新请求过来时直接报错，让客户端重试其它机器。然后，检测线程池中的线程是否正在运行，如果有，等待所有线程执行完成，除非超时，则强制关闭。服务消费方停止时，不再发起新的调用请求，所有新的调用在客户端即报错。然后，检测有没有请求的响应还没有返回，等待响应返回，除非超时，则强制关闭。Dubbo是通过JDK的ShutdownHook来完成优雅停机的，所以如果用户使用"kill -9 PID"等强制关闭指令，是不会执行优雅停机的，只有通过"kill PID"时，才会执行。我们的系统里面通过Kill -9 来执行Container服务容器是一个standalone的启动程序，因为后台服务不需要Tomcat或JBoss等Web容器的功能，如果硬要用Web容器去加载服务提供方，增加复杂性，也浪费资源。服务容器只是一个简单的Main方法，并加载一个简单的Spring容器，用于暴露服务Spring Container 自动加载META-INF/spring目录下的所有Spring配置。 配置：(配在java命令-D参数或者dubbo.properties中) dubbo.spring.config=classpath*:META-INF/spring/*.xml ----配置spring配置加载位置
Jetty Container 启动一个内嵌Jetty，用于汇报状态。 配置：(配在java命令-D参数或者dubbo.properties中) dubbo.jetty.port=8080 ----配置jetty启动端口 dubbo.jetty.directory=/foo/bar ----配置可通过jetty直接访问的目录，用于存放静态文件 dubbo.jetty.page=log,status,system ----配置显示的页面，缺省加载所有页面
Log4j Container 自动配置log4j的配置，在多进程启动时，自动给日志文件按进程分目录。 配置：(配在java命令-D参数或者dubbo.properties中) dubbo.log4j.file=/foo/bar.log ----配置日志文件路径 dubbo.log4j.level=WARN ----配置日志级别 dubbo.log4j.subdirectory=20880 ----配置日志子目录，用于多进程启动，避免冲突
阅读(...) 评论()