Dubbo

服务器两次被入侵，导致我一切推倒重来，在重新配置的过程，总结下安装经验 如果需要安装包，可以留言，这次重新安装配置后都有存下来 数据库的配置 tomcat及JDK的配置 zookeeper的配置及dubbo可视化界面（未更新） fastDfs分布式文件系统服务器（用于上传配置） 在Storage上安装nginx配置图片服务虚拟主机(用于下载) redis缓存服务器安装及jedis集成使用（未更新） solr搜索应用服务器安装配置及集成使用（未更新） 来源： CSDN 作者： 陈晨* 链接： https://blog.csdn.net/weixin_41998993/article/details/104626212

Dubbo 架构 节点角色说明 Provider：暴露服务的服务提供方 Consummer:调用远程服务的服务消费方 Registry:服务注册与发现的注册中心 Monitor：统计服务调用次数和调用时间的监控中心 Container：服务运行容器 调用关系说明 服务容器负责启动，加载，运行服务提供者。 服务提供者在启动时，向注册中心注册自己提供的服务。 服务消费者在启动时，向注册中心订阅自己所需的服务。 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。 Dubbo特性 联通性 健壮性 伸缩性 向未来架构升级i性 连通性 注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小 监控中心负责统计各服务调用次数，调用时间等，统计先在内存汇总后每分钟一次发送到监控中心服务器，并以报表展示 服务提供者向注册中心注册其提供的服务，并汇报调用时间到监控中心，此时间不包含网络开销 服务消费者向注册中心获取服务提供者地址列表，并根据负载算法直接调用提供者，同时汇报调用时间到监控中心

作者：Longofo@知道创宇404实验室 时间：2020年2月20日 原文地址： https://paper.seebug.org/1131/#_2 前不久有一个关于Apache Dubbo Http反序列化的漏洞，本来是一个正常功能（通过正常调用抓包即可验证确实是正常功能而不是非预期的Post），通过Post传输序列化数据进行远程调用，但是如果Post传递恶意的序列化数据就能进行恶意利用。Apache Dubbo还支持很多协议，例如Dubbo（Dubbo Hessian2）、Hessian（包括Hessian与Hessian2，这里的Hessian2与Dubbo Hessian2不是同一个）、Rmi、Http等。Apache Dubbo是远程调用框架，既然Http方式的远程调用传输了序列化的数据，那么其他协议也可能存在类似问题，例如Rmi、Hessian等。@pyn3rd师傅之前在twiter发了关于Apache Dubbo Hessian协议的反序列化利用，Apache Dubbo Hessian反序列化问题之前也被提到过， 这篇文章 里面讲到了Apache Dubbo Hessian存在反序列化被利用的问题，类似的还有Apache Dubbo Rmi反序列化问题。之前也没比较完整的去分析过一个反序列化组件处理流程，刚好趁这个机会看看Hessian序列化、反序列化过程，以及

Dubbo简介 官网：http://dubbo.apache.org/zh-cn Apache Dubbo (incubating) |ˈdʌbəʊ| 是一款高性能、轻量级的开源 Java RPC 分布式服务框架。 Dubbo 提供了三大核心能力： 面向接口的远程方法调用， 智能容错和负载均衡， 以及服务自动注册和发现。（Dubbo调用Zookeeper） 她最大的特点是按照分层的方式来架构，使用这种方式可以使各个层之间解耦合（或者最大限度地松耦合）。 从服务模型的角度来看，Dubbo 采用的是一种非常简单的模型，要么是提供方提供服务，要么是消费方消费服务，所以基于这一点可以抽象出服务提供方（Provider）和服务消费方（Consumer）两个角色。 来源： CSDN 作者： 子 ★ 诚 链接： https://blog.csdn.net/qq_40634246/article/details/104612175

1、Dubbo的定义 Dubbo是阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的RPC实现服务的输出和输入功能，可以和Spring框架无缝集成。 Dubbo框架，是基于容器运行的，容器是Spring 2、Dubbo的作用？ 1.透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。 2.软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。 3. 服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。 Dubbo采用全spring配置方式，透明化接入应用，对应用没有任何API侵入，只需用Spring加载Dubbo的配置即可，Dubbo基于Spring的Schema扩展进行加载。 来源： CSDN 作者： 菜鸟和大白谁厉害 链接： https://blog.csdn.net/weixin_42976139/article/details/104608288

此文档针对初学者。 废话不多说，先上源码： http://git.oschina.net/alexgaoyh/Dubbo-parent http://git.oschina.net/alexgaoyh/Dubbo-parent/attach_files Maven项目，只需要注意下图中红色箭头标注的三个模块即可； Dubbo-api： API接口，被 Dubbo-test-provider(服务提供者)，Dubbo-test-consumer（服务消费者）依赖； Dubbo-api 模块没什么多说的，只是需要的interface接口和实体类……； Dubbo-test-consumer 模块同样没有什么多说的，讲服务提供者发布的接口依赖到项目中即可，注意 consumerAll.xml 即可。 Dubbo-test-provider: 服务提供者，Dubbo整合mybatis spring druid，实现事务控制，druid监控数据的log4j日志记录（sql输出）； 下图中，需要注意两个单元测试的文件， DemoTest.java 文件是用来本地进行单元测试使用的，确保对外发布的服务接口都通过单元测试； DemoDubboTest.java 文件是直接对外发布dubbo服务接口的，相关的方法通过单元测试整合，即可对外发布接口，发布接口之后，服务消费者即可进行相关业务操作； PS

摘自： https://www.cnblogs.com/mrhelloworld/p/12388859.html 技术架构演变 　　 　　 　　随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，亟需一个治理系统确保架构有条不紊的演进。 　　 　　 单一应用架构 当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。 此时，用于简化增删改查工作量的 数据访问框架(ORM) 是关键。 缺点：随着应用功能的增多，代码量越来越大，越来越难维护，那怎么解决代码一体化的问题？ 垂直应用架构 当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。 此时，用于加速前端页面开发的 Web框架(MVC) 是关键。 缺点：垂直架构中相同逻辑代码需要不断的复制，不能复用。每个垂直模块都相当于一个独立的系统。 分布式服务架构 当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。 此时，用于提高业务复用及整合的 分布式服务框架(RPC) 是关键。 缺点：服务越来越多，需要管理每个服务的地址，调用关系错综复杂，难以理清依赖关系，服务状态难以管理，无法根据服务情况动态管理。 流动计算架构

一、先了解一下情况 Dubbox是什么？ 现在 微服务 很火，而 Dubbox 就是一个支持微服务的一个框架 SpringBoot又是什么？ 我们先来讨论一个问题，我们在使用 Spring 的时候，是不是要进行大量的配置，甚至部署的时候还要重新配置发布环境，重新打包，部署………… 是不是觉得太麻烦了？而 SpringBoot 就是干这个的，它的 Profiles 功能简直就是专门用来治里各种配置问题的。 二、SpringBoot中的Profiles Profiles可以说就是指定配置环境的一个功能。 在 SpringBoot 中，如果不指定 Profile ，则默认会读取 application.properties 配置文件，如果指定 Profile ，则会去读取 application-{Profile}.properties 配置文件，例如： # Profile指定为development application-development.properties 如果指定 Profile 呢？我们只需要在 SpringBoot 的启动参数中加入以下参数即可： -Dspring.profiles.active=develpment 整体为： $ java -Dspring.profiles.active=development -jar provider.jar 好了，讲了

官方ISSUE参考 https://github.com/alibaba/dubbo/issues 注册中心ZookeeperRegistry.doSaveProperties warn 2014-10-1419:56:51WARN [com.alibaba.dubbo.registry.zookeeper.ZookeeperRegistry.doSaveProperties(221)] [DUBBO] Failed to save registry store file, cause: Can not loc k the registry cache file /homearch/.dubbo/dubbo-registry-192.168.1.109.cache, ignore and retry later, maybe multi java process use the file, please config: dubbo.re gistry.file=xxx.properties, dubbo version:2.5.3, current host:192.168.1.22 java.io.IOException: Can not lock the registry cache file /homearch/.dubbo/dubbo-registry-192.168.1

技术架构演变 随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，亟需一个治理系统确保架构有条不紊的演进。 单一应用架构 当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。 此时，用于简化增删改查工作量的 数据访问框架(ORM) 是关键。 缺点：随着应用功能的增多，代码量越来越大，越来越难维护，那怎么解决代码一体化的问题？ 垂直应用架构 当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。 此时，用于加速前端页面开发的 Web框架(MVC) 是关键。 缺点：垂直架构中相同逻辑代码需要不断的复制，不能复用。每个垂直模块都相当于一个独立的系统。 分布式服务架构 当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。 此时，用于提高业务复用及整合的 分布式服务框架(RPC) 是关键。 缺点：服务越来越多，需要管理每个服务的地址，调用关系错综复杂，难以理清依赖关系，服务状态难以管理，无法根据服务情况动态管理。 流动计算架构 当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。 此时