软件架构-企业级dubbo应用（上）

上次说了dubbo的历史，介绍，了解了cosumber ，proivder，registry 他们之间的调用管理。提供的源码是cosumber 和 proivder 在一个项目里面，在实际的企业开发中他们两者之间都是在不同的项目下的。这次主要说说分布式开发和联调，其实这个坑很大，比技术的坑要大，要深！每次查看生产和消费者 直接这样口头或者文档的形式是不是很low，其实可以搭建dubbo控制台，对于注册中心上次使用了小广播的形式，对于实际生产环境应该选择哪种注册中心这里也会说到。

（一）分布式项目开发与联调

• 接口暴露与引用

在一个RPC场景中 ，调用方是通过接口来调用服务端，传入参数并获得返回结果。这样服务端的接口和模型必须暴露给调用方项目。服务端如何暴露呢？客户端如何引用呢？

1.接口信息
2.模型信息
3.异常

暴露接口的通常做法是 接口与实现分离，服务端将 接口、模型、异常 等统一放置于一个模块，实现置于另一个模块。调用方通过Maven进行引用。

记得当初刚开始使用RPC框架的dubbo的时候，服务端打一个jar包，通过qq的方式扔给客户端的项目，然后他在放到maven的仓库中。每次更新需要重复的进行qq的jar包发送，坚持了1个礼拜，太费劲了，开发的工程中，互相的扯皮，说jar包邮问题，他说没问题只能反编译看jar包。直接拷贝发送jar包的方式也是可以的，一个两个项目还是可以的，如果项目达到一定的量，你来回这样发送就有点SB了，老铁。

• 自动化构建与协作

当项目越来越多，服务依赖关系越发复杂的时候，为了提高协作效率，必须采用自动化工具 完成 接口从编写到构建成JAR包，最后到引用的整个过程。

流程描述：

1.服务提供者项目发人员编写Client 接口
2.push 至远程仓库
3.jenkins 构建指定版本
4.jenkins Deploye 至私服仓库 nexus
5.服务消费者项目开发人员基于maven 从私服务仓库下载

• 接口平滑升级

在项目迭代过程当中， 经常会有多个项目依懒同一个接口，项目B、C都依懒了项目A当中的接口1，此时项目B业务需要，需要接口1多增加一个参数，升级完成后。项目B能正确构建上线，项目C却不行。

之前的项目就存在过这个问题，如果接口变了，依赖的所有项目都要发生改变，当时项目为了解决这个问题。

解决办法与原则

为什么有紧急版本，为什么要加班，很多时候就是这些细节没控制好。

1.接口要做到向下兼容：接口参数尽量以对象形式进行封装。Model属性只增不删，如果需要作废，可以添加@Deprecated 标识。
2.接口参数尽量不要用Map格式，Map不容易让人读懂，解析的时候也麻烦，有点互相伤害的意思，生产者也要伤害，消费者也要伤害，大小写等等吧，主要map可读性太差了。
3.如果出现了不可兼容的变更，则必须通知调用方整改，并制定上线计划。
4.千万不要尝试版本号这种方式，项目B升级成了新版本，项目C还是老版本，有的项目在新版本上，有的在老版本上，很容易混乱。

• 开发联调

在项目开发过程当中，一个开发或测试环境的注册中心很有可能会同时承载着多个服务，如果两组服务正在联调，如何保证调用的是目标服务呢？

1.基于临时分组联调

group 分组在reference 和server 当中采用相同的临时组 ,通过group 进行设置，设置配置文件properties中配置个 名称=value 然后 service的group={value}

2.直连提供者：

在reference 中指定提供者的url即可做到直连

<dubbo:reference url="dubbo://127.0.0.1:20880" id="demoService"
timeout="2000"
interface="com.tuling.teach.service.DemoService" check="false"/>

3.只注册：
一个项目有可能同是为即是服务提供者又消费者，在测试时需要调用某一服务同时又不希望正在开发的服务影响到其它订阅者如何实现？
通过修改 register=false 即可实现

<dubbo:registry address="multicast://224.5.6.7:1234" register="false"/>

PS：这次就说这么多，源码还是参考我的连接，很多技术学都直接看官方的api更清楚，最想说的注意的一些技巧。下次说说dubbo阿里的后台管理工具dubbo-admin。