❶ bbo报错qos-server...Address already in use
报错日志如下：
问题原因是多个服务在该服务器内运行，两个服务的qos-server配置端口号一致，启动时提示被占用，修改其一端口号并重启。
qos是bbo的在线运维命令，bbo2.5.8新版本重构了telnet模块，提供了新的telnet命令支持，新版本的telnet端口与bbo协议的端口是不同的端口，默认为22222。
qos端口冲突并影响服务消费者消费服务，但是每次程序启动总是抛出端口冲突异常
❷ 关于升级 Dubbo 版本到 2.6.5 后启动失败的“坑”
Dubbo 从低版本升级到 2.6.5 版本后，启动失败，报错如下：
<b><font color='red'>上终极方案：使用 2.6.2 以下版本或者 2.7.0 以上版本的 bbo ；</font></b>
具体解决方式需要根据项目的情况解决，提供一些其他方案：
删除 web.xml 中如下的配置：
Spring Boot 工程没有特别好的解决方案，提供两个解决思路：
这个方案也没有绕过添加 web.xml 的命运，做法如下：
观察报错日志，报错位置很明显是 Spring 框架初始化时的报错，重点是： there is already a root application 。
这个错误抛出位置余汪返位于： Spring-web 包的 ContextLoader 类的 initWebApplicationContext 方法。
原因很明显， ContextLoader 被调用了至少两遍，第二遍报错导致项目初始化失败，其主要的“罪魁祸首”是 bbo 包下面的 web-fragment.xml 。
Servlet 3.0 是随着 Java EE 6 规范发布的，主要新增特性：
支持 Servlet 3.0 规范的容器，在启动后会扫描工程的 jar 包，找到符合规范的 添加了相关注解的类 和 web-fragment.xml 然后跟 web.xml 的配置合并作为整个项目的初始化配置。
上述问题的发生原因很明显了:
这个是 Servlet 3.0 提供的一个属性，等同一个开关，设置为 true 则表示 web.xml 已经提供了全部的配置信息，不需要容器再去各个 jar 包找配置了陵罩，换句话就是：关闭 可插特性 ；
这个属性是 注释里面提供的解决思路。这个属性可以理解为指定 web-fragment.xml 的加载顺序，和 ordering 标签的区别是， absolute-ordering 仅仅针对我们指定的 web-fragment.xml 做排序。
轻易升级一个基础框架不是一个好的做法竖饥，<b>升级基础框架还是应该关注下当前版本和目标升级版本，框架作者做了些什么事情，出现过什么BUG。</b>
当前的 Spring Boot 的解决方案并不让人满意，毕竟 Spring Boot 的无Xml的感觉还是很爽的，为了这个升级引入了 web.xml 会有一点点不爽。