最近从一个项目组调到了另外一个项目组，开发的项目也从以前单点(mvc+jsp+other)的情况转变到了现在分布式(dubbo+other)的情况，工作的职责改变，要处理的事情也更多了。
先来说说目前工作的情况吧，现在一个基础的项目可以分为api包（定义接口与BEAN），provider包（对API里的接口进行实现），web项目（调用api包，与页面交互）。web项目只引入API包，provider包与web项目分别独立部署，web项目通过dubbo调用provider包的服务。
如图：
这其实也是一个分布式系统的基础结构，对于以前的单点系统来说，他把业务逻辑更加细分，使得每个人都能负责自己那一部分。
以上是理想情况，接下来我说说这种架构开发我所遇到的问题。
第一个，也是最严重的问题。“API包内接口的定义”，这个问题实在是太突出了，举个例子，现在项目赶工，需要并行开发，那么一个人如果需要另一个人把接口后才能开发的话，就完全做不到并行，会耽误工期。这其实就和前后端分离一样，只有定义好了接口，才能做到真正的前后端分离，可是实际开发过程中，接口的定义是边做边制定的，这就很麻烦。
第二个，“接口改动”，因为上面说的，接口的定义是边做边制定的，这就需要频繁的更新JAR包，虽然说现在是使用maven管理，但是目前市面上的编辑器，对maven的改动简直有毒，经常会出现找不到包，或者拉不下来，然后缺包，编译出错的情况。有时候一定小小的改动又不会更改版本号，这就导致了要删除本地的包然后重新拉取。然后就有可能出现上面说的问题。PS：实在找不到或者出错的情况下可以关闭项目，到本地MAVEN仓库删除JAR包，到项目里面删除IDEA的配置文件，然后在重新打开项目。
第三个，“文档文档文档”，重要的事情说三遍，现在我的开发流程是这样的，找人要API包版本号，要调用哪个方法，那个方法有那些参数，参数有什么意义，返回值的意义是啥开发一个接口就得问一遍，目前对接的其实也没多少东西，但是我已近把公司的同事都差不多问了个遍。所以，如果要使用这种开发模式，文档是非常非常非常重要的。
第四个，“假数据，模拟数据”，即使API定义好了，provider不能正常提供的情况下，模拟数据怎么定义，是提供方定义还是调用方定义，是否需要验证方法，还是说直接创建方法返回结果对象测试，如果需要并行开发，调用API因该有返回结果，即使是假的，这些结果怎么创建，怎么管理。使用mock会不会太过冗余。这个答案我也不知道，求解答。
第五个，“服务地址管理”，provider目前注册到了不同的zookeeper地址,以我目前来说，一个服务就注册一个地址，这些地址有可能相同也有可能不同，都写在了dubbo的XML配置里面，这些地址应该怎么管理，上线后应该怎么调整，变更后项目怎么变更，这也是个难题。
最后，其实技术迭代产品更新是好事，遇到问题其实也挺正常的，如果到时候我学到了好的解决方法我就更新这篇博客。谢谢您的观看，共勉。
