初学者遇到的dubbo设计架构问题及解决方法总结

1.传输字节流限制：

代码质量不过关导致超出dubbo支持的最大传输字节，导致服务崩溃而关闭：

在项目中遇到使用 dubbo 进行服务间调用（provider-consumer），由于系统需要传输文件，于是使用字节流在provider 和 consumer间通信，但是在

使用 dubbo时，收到报错，提示 payload 过大，查阅资料发现，provider 和 consumer 之间的传输 有效载荷 不得大于 8兆  payload=88388608(=8M)

，而这个属性是可选属性，所以可以自己在配置文件中配置

2.分布式事务：

本地事务放在最先 ，远程事务按其本地事务一层层往下封装业务。

原先垂直式的业务调用，事务是基于本地内存管理的，因此要对其进行服务拆分，异常回滚能够保证事务的原子性。

3.序列化：

远程传输的数据模型（实体等）必须实现序列化

旧业务代码，以前是本地内存创建的实体对象，在做分布式网络拆分后，TCP/IP协议是基于二进制流的，因此原先这些实体必须实现序列化。

4.多点部署：

一个服务多服务器同个zk注册，多个zk注册（一个服务注册到多个注册中心，可只在其中一个中心订阅）

5.zk端口冲突：

按照ip+端口决定唯一性，开发阶段经常会遇到在一台机器启动同一个端口的服务，原来问题出在这。

6.服务失败请求3次机制：

dubbo遇到服务调用失败默认会共调用3次请求，如开发过程中遇到某一事务没控制好，会导致3次脏数据的入库

7.启动时检查

在刚进行拆分重构时建议关闭这个启动时检查，以方便开发，可以无序的启动相关服务。

缺省会在启动时检查依赖的服务是否可用，不可用时会抛出异常，阻止Spring初始化完成，以便上线时，能及早发现问题，默认check=true。
关闭所有服务的启动时检查：(没有提供者时报错)
   
关闭某个服务的启动时检查：(没有提供者时报错)