dubbo之服务容器

服务容器是一个standalone的启动程序,因为后台服务不需要Tomcat或JBoss等Web容器的功能,如果硬要用Web容器去加载服务提供方,增加复杂性,也浪费资源。

服务容器只是一个简单的Main方法,并加载一个简单的Spring容器,用于暴露服务。

服务容器的加载内容可以扩展,内置了spring, jetty, log4j等加载,可通过Container扩展点进行扩展,参见:Container。配置配在java命令-D参数或者dubbo.properties中

Spring Container
  • 自动加载 META-INF/spring 目录下的所有 Spring 配置。
  • 配置spring配置加载位置:dubbo.spring.config=classpath*:META-INF/spring/*.xml
Jetty Container
  • 启动一个内嵌Jetty,用于汇报状态。
  • 配置:
    • dubbo.jetty.port=8080 ----配置jetty启动端口
    • dubbo.jetty.directory=/foo/bar ----配置可通过jetty直接访问的目录,用于存放静态文件
    • dubbo.jetty.page=log,status,system ----配置显示的页面,缺省加载所有页面
Log4j Container
  • 自动配置log4j的配置,在多进程启动时,自动给日志文件按进程分目录。
  • 配置:
    • dubbo.log4j.file=/foo/bar.log ----配置日志文件路径
    • dubbo.log4j.level=WARN ----配置日志级别
    • dubbo.log4j.subdirectory=20880 ----配置日志子目录,用于多进程启动,避免冲突
容器启动

如:(缺省只加载spring)

java com.alibaba.dubbo.container.Main

或:(通过main函数参数传入要加载的容器)

java com.alibaba.dubbo.container.Main spring jetty log4j

或:(通过JVM启动参数传入要加载的容器)

java com.alibaba.dubbo.container.Main -Ddubbo.container=spring,jetty,log4j

或:(通过classpath下的dubbo.properties配置传入要加载的容器)

dubbo.properties

dubbo.container=spring,jetty,log4j
时间: 2024-11-18 22:44:05

dubbo之服务容器的相关文章

Dubbo分布式服务框架入门

参考http://blog.csdn.net/u013142781/article/details/50387583 一.Dubbo概念介绍 1.1.Dubbo是什么? Dubbo是一个分布式服务框架,致力于提供高性能和透明化的RPC(Remote Procedure Call Protocol)远程服务调用方案,以及SOA(Service-Oriented Architecture,面向服务的体系结构)服务治理方案.简单的说,dubbo就是个服务框架,如果没有分布式的需求,其实是不需要用的,只

一篇文章带你深入了解Dubbo分布式服务框架

一.产生的背景 随着互联网的发展,网站应用的规模不断扩大,常规的垂直应用架构已无法应对,分布式服务架构以及流动计算架构势在必行,亟需一个治理系统确保架构有条不紊的演进.下面我们用一个图来具体说明架构和开发框架的演进过程.单一应用架构当网站流量很小时,只需一个应用,将所有功能都部署在一起,以减少部署节点和成本.此时,用于简化增删改查工作量的数据访问框架(ORM)是关键. 垂直应用架构当访问量逐渐增大,单一应用增加机器带来的加速度越来越小,将应用拆成互不相干的几个应用,以提升效率.此时,用于加速前端

Dubbo 微服务系列(03)服务注册

Dubbo 微服务系列(03)服务注册 [TOC] Spring Cloud Alibaba 系列目录 - Dubbo 篇 1. 背景介绍 图1 Dubbo经典架构图 注:本图来源 Dubbo官方架构图 表1 节点角色说明 节点 角色说明 Provider 暴露服务的服务提供方 Consumer 调用远程服务的服务消费方 Registry 服务注册与发现的注册中心 Monitor 统计服务的调用次数和调用时间的监控中心 Container 服务运行容器 在 Dubbo 微服务体系中,注册中心是其

关于dubbo的服务降级

一.dubbo降级服务     dubbo开发中,可能由于服务没有启动或者网络不通,调用中会出现RpcException,也就是远程调用失败.如果是服务启动顺序的问题,可能加工check="false"的配置可以得到很好的解决.但是,如果是服务宕掉或者并发数太高导致的RpcException该如何处理? 经过过12306抢票的人应该经常会遇到这个问题:在抢票高峰的时候,明明票还有,但是查询出来的列表却是为空的(如果没票列表也应该会呈现):等高峰过后再查询,列表又恢复正常.个人猜测应该是

laravel框架总结(四) -- 服务容器

1.依赖 我们定义两个类:class Supperman 和 class Power,现在我们要使用Supperman ,而Supperman 依赖了Power class Supperman { private $power; public function __construct(){ $this->power = new Power; } } 一旦Power发生了变化,Supperman 不得不修改,这种就叫耦合程度太高,所以面临的问题是解耦,就需要用到控制反转. 2.依赖注入 只要不是由

Minor【 PHP框架】4.服务容器与服务提供者

4.1 服务提供者 关于服务容器可以参考我的另外一篇文章:http://www.cnblogs.com/orlion/p/4797422.html Minor使用IoC(Inversion of Control,控制倒转,这是一个设计模式,可以先查看下百科)容器这个强有力的工具管理类依赖.依赖注入(也是一种设计模式,一般用于实现IoC)是 一个不用编写固定代码来处理类之间依赖的方法,相反的,这些依赖是在运行时注入的,这样允许处理依赖时具有更大的灵活性. 服务提供者是服务容器中的单元,是一个普通的

Laravel 服务容器 IoC(控制反转) 和 DI(依赖注入)

Laravel 服务容器 IoC(控制反转) 和 DI(依赖注入) IoC 容器, laravel 的核心 Laravel 的核心就是一个 IoC 容器,根据文档,称其为“服务容器”,顾名思义,该容器提供了整个框架中需要的一系列服务.作为初学者,很多人会在这一个概念上犯难,因此,我打算从一些基础的内容开始讲解,通过理解面向对象开发中依赖的产生和解决方法,来逐渐揭开“依赖注入”的面纱,逐渐理解这一神奇的设计理念. 本文一大半内容都是通过举例来让读者去理解什么是 IoC(控制反转) 和 DI(依赖注

Dubbo分布式服务子系统的划分

一.划分子系统的策略 按照系统的业务模块的独立性划分 二.划分时服务子系统的数量的控制 过多:可能划分过细,破坏业务子系统的独立性,部署维护工作量大,独立进程占用内存多 过少:没能很好的解耦,开发维护不好分工,升级维护影响面大 三.服务子系统划分要注意的地方 3.1 不要出现A服务中的SQL需要链接查询到B服务中的表等情况,这样在A服务与B服务进行垂直拆库时就会出错       eg:服务虽然拆分了,但是还是用的同一个数据库 3.2  服务子系统间避免出现环状的依赖调用        eg:A服

服务容器

1.依赖 我们定义两个类:class Supperman 和 class Power,现在我们要使用Supperman ,而Supperman 依赖了Power class Supperman { private $power; public function __construct(){ $this->power = new Power; } } 一旦Power发生了变化,Supperman 不得不修改,这种就叫耦合程度太高,所以面临的问题是解耦,就需要用到控制反转. 2.依赖注入 只要不是由