在线实时数据清洗架构(2)——server选型 Dubbo
2017-07-01 11:23
459 查看
对于我这种菜鸟,第一个问题就是为什么不选择tomcat?
根据我的反思和对项目的理解,原因如下:
1,这是一个纯后台项目,在整个公司的定位是中间层组件的概念,一个用户的请求会跳到公司各种系统里,例如
用户申请——>web站点——>后台业务站点——>我们站点
其主要调用逻辑控制在后台业务站点,在这期间可能
后台业务站点——>我们站点A
后台业务站点——>站点B
后台业务站点——>站点C
…
Tomcat内有很大一部分是servlet container,一般需要用到jsp或web-后台耦合时,用到的多。
所以纯粹的通信就可以满足需要,这个时候我想到了RMI。
关于RMI
http://haolloyin.blog.51cto.com/1177454/332426/
可是使用RMI有以下几个问题:
1,集群怎么办?
2,怎么控制负载均衡?
想想还是头皮发麻,rmi太过原始,使用起来会有大量的开发量,也很考验程序员的开发功底,稍有不慎会埋下很多隐患。
主角登场——dubbo
关于dubbo的一篇文章
http://www.importnew.com/19732.html
因为dubbo其底层通信采用的是nio,(为什么nio比传统io好?文章内有答案)所以贴出关于nio的一篇文章
http://www.importnew.com/22623.html
dubbo的注册中心一般采用zookeeper管理,为什么用zookeeper管理好,我理解是zookeeper有很好的容灾机制和很好的分布式锁机制(可以解决多台并发注册时产生的问题),具体博客:
http://www.importnew.com/24411.html
面试中问到:你对dubbo调优有什么了解?
上面关于dubbo的文章内提到
“如服务的调用量越来越大,服务的容量问题就暴露出来,这个服务需要多少机器支撑?什么时候该加机器?为了解决这个问题,第一步,要将服务现在每天的调用量,响应时间,都统计出来,作为容量规划的参考指标。其次,要可以动态调整权重,在线上,将某台机器的权重一直加大,并在加大的过程中记录响应时间的变化,直到响应时间到达阀值,记录此时的访问量,再以此访问量乘以机器数反推总容量“
具体操作:
http://blog.csdn.net/tototuzuoquan/article/details/72765540
在看看dubbo的核心内容
“其核心部分包含:
1》远程通讯: 提供对多种基于长连接的NIO框架抽象封装,包括多种线程模型,序列化,以及“请求-响应”模式的信息交换方式。
2》集群容错: 提供基于接口方法的透明远程过程调用,包括多协议支持,以及软负载均衡,失败容错,地址路由,动态配置等集群支持。
3》自动发现: 基于注册中心目录服务,使服务消费方能动态的查找服务提供方,使地址透明,使服务提供方可以平滑增加或减少机器。“
完美
一句话总结dubbo:
Provider服务提供者,注册到注册中心(zookeeper),Consumer消费者也把要调用的接口注册到注册中心,当消费者调用某A方法的接口时,dubbo监听到,并去注册中心找配置,找到后 底层rpc调用到生产者相应方法接口,调用方法实例返回数据给消费者。其中,monitor控制调用生产者的负载。
根据我的反思和对项目的理解,原因如下:
1,这是一个纯后台项目,在整个公司的定位是中间层组件的概念,一个用户的请求会跳到公司各种系统里,例如
用户申请——>web站点——>后台业务站点——>我们站点
其主要调用逻辑控制在后台业务站点,在这期间可能
后台业务站点——>我们站点A
后台业务站点——>站点B
后台业务站点——>站点C
…
Tomcat内有很大一部分是servlet container,一般需要用到jsp或web-后台耦合时,用到的多。
所以纯粹的通信就可以满足需要,这个时候我想到了RMI。
关于RMI
http://haolloyin.blog.51cto.com/1177454/332426/
可是使用RMI有以下几个问题:
1,集群怎么办?
2,怎么控制负载均衡?
想想还是头皮发麻,rmi太过原始,使用起来会有大量的开发量,也很考验程序员的开发功底,稍有不慎会埋下很多隐患。
主角登场——dubbo
关于dubbo的一篇文章
http://www.importnew.com/19732.html
因为dubbo其底层通信采用的是nio,(为什么nio比传统io好?文章内有答案)所以贴出关于nio的一篇文章
http://www.importnew.com/22623.html
dubbo的注册中心一般采用zookeeper管理,为什么用zookeeper管理好,我理解是zookeeper有很好的容灾机制和很好的分布式锁机制(可以解决多台并发注册时产生的问题),具体博客:
http://www.importnew.com/24411.html
面试中问到:你对dubbo调优有什么了解?
上面关于dubbo的文章内提到
“如服务的调用量越来越大,服务的容量问题就暴露出来,这个服务需要多少机器支撑?什么时候该加机器?为了解决这个问题,第一步,要将服务现在每天的调用量,响应时间,都统计出来,作为容量规划的参考指标。其次,要可以动态调整权重,在线上,将某台机器的权重一直加大,并在加大的过程中记录响应时间的变化,直到响应时间到达阀值,记录此时的访问量,再以此访问量乘以机器数反推总容量“
具体操作:
http://blog.csdn.net/tototuzuoquan/article/details/72765540
在看看dubbo的核心内容
“其核心部分包含:
1》远程通讯: 提供对多种基于长连接的NIO框架抽象封装,包括多种线程模型,序列化,以及“请求-响应”模式的信息交换方式。
2》集群容错: 提供基于接口方法的透明远程过程调用,包括多协议支持,以及软负载均衡,失败容错,地址路由,动态配置等集群支持。
3》自动发现: 基于注册中心目录服务,使服务消费方能动态的查找服务提供方,使地址透明,使服务提供方可以平滑增加或减少机器。“
完美
一句话总结dubbo:
Provider服务提供者,注册到注册中心(zookeeper),Consumer消费者也把要调用的接口注册到注册中心,当消费者调用某A方法的接口时,dubbo监听到,并去注册中心找配置,找到后 底层rpc调用到生产者相应方法接口,调用方法实例返回数据给消费者。其中,monitor控制调用生产者的负载。
相关文章推荐
- 在线实时数据清洗架构(3)—— 缓存选型 Redis
- 在线实时数据清洗架构(1)——风控系统业务梳理
- 在线支付之风控系统架构选型
- 日处理20亿数据,实时用户行为服务系统架构实践
- 大数据架构:flume-ng+Kafka+Storm+HDFS 实时系统组合
- Sybase在线课堂报名:深度剖析——Sybase ASE 15.5的实时数据处理(11月17日 周三)
- SQLServer可更新订阅数据在线架构更改(增加字段)方案
- 大数据架构:flume-ng+Kafka+Storm+HDFS 实时系统组合
- 大数据实时处理:百分点实时计算架构和算法
- Code-First 在SQLServer Compact 4.0 中的应用(二),使用Migrations更改数据库架构并保留历史数据
- 用于实时大数据处理的Lambda架构
- 调研----小米架构师:亿级大数据实时分析与工具选型
- 【阿里在线技术峰会】李金波:企业大数据平台仓库架构建设思路
- CAD图形在线发布及行业实时数据、动画在图形上的展示
- 大数据架构:flume-ng+Kafka+Storm+HDFS 实时系统组合
- 大数据架构:flume-ng+Kafka+Storm+HDFS 实时系统组合
- 日处理20亿数据,实时用户行为服务系统架构实践
- [网络广播] SQL Server 主数据管理结合 BizTalk Server SOA 架构实现保险行业 ECIF 解决方案
- 大数据实时处理:百分点实时计算架构和算法