- kingsfighter
- 等级: 初级会员
- 性别:
- 文章: 32
- 积分: 50
- 来自: 南京
|
如题,该贴讨论企业内部繁多的子系统之间的交互方式及解决方案;
背景:公司正在处理一个项目,由于业务的需要分为N个子系统(都是内部子系统),子系统之间的交互很多,关系复杂;
-------------------------------我是华丽的分割线-----------------------------------------------------------
目前的解决方案:
我们暂定的实现方案是,通过jar包提供服务,jar中封装通信协议、以及报文的封装,保证了开发者的易开发性;
优点:
接口开发者、接口调用者均使用java代码(java类,参数有明确的类型,如XXXBean..),开发类似于本地调用,开发简单、方便;
缺点:
由于被调用接口的变更,需要变更参数,需要重新编译接口jar包,同步更新相关调用者的系统的jar包,维护麻烦;动态性差
大家可以发表自己的看法,以及相关的方案,谢谢!
声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
|
返回顶楼 |
|
|
- 天下有鹏
- 等级: 初级会员
- 性别:
- 文章: 25
- 积分: 90
- 来自: 北京
|
使用服务框架和消息中间件
|
返回顶楼 |
|
|
- bhdweb
- 等级: 初级会员
- 性别:
- 文章: 167
- 积分: 60
- 来自: 北京
|
我们用这个jersey
|
返回顶楼 |
|
|
- kingsfighter
- 等级: 初级会员
- 性别:
- 文章: 32
- 积分: 50
- 来自: 南京
|
天下有鹏 写道 使用服务框架和消息中间件
淘宝方案:但是淘宝没有使用ESB,而是用了自研的服务框架和消息中间件
可否具体一点讨论,谢谢
|
返回顶楼 |
|
|
- xushaomin1122
- 等级: 初级会员
- 性别:
- 文章: 9
- 积分: 30
- 来自: 深圳
|
发表时间:2013-07-08
最后修改:2013-07-08
用dubbo试试,阿里开放框架
|
返回顶楼 |
|
|
- 须等待
- 等级: 初级会员
- 性别:
- 文章: 102
- 积分: 70
- 来自: 深圳
|
服务化框架+1
服务化框架的核心功能:提供服务的发布和订阅、服务器地址动态路由和软负载均衡、至于客户端,不推荐用jar,维护起来太麻烦了
|
返回顶楼 |
|
|
- que1
- 等级: 初级会员
- 性别:
- 文章: 17
- 积分: 40
- 来自: 北京
|
用JAX-RS来实现,比如Apache CXF。
跟Web-services差不多。
|
返回顶楼 |
|
|
- kingsfighter
- 等级: 初级会员
- 性别:
- 文章: 32
- 积分: 50
- 来自: 南京
|
须等待 写道 服务化框架+1
服务化框架的核心功能:提供服务的发布和订阅、服务器地址动态路由和软负载均衡、至于客户端,不推荐用jar,维护起来太麻烦了
其实我也是赞同 服务化框架+1 的,目前我们也是按照这个模式去实现,只是实现的不够优雅;
客户端使用jar包的原因是规范客户端调用,避免由于开发人员不规范操作时造成的问题,但是现状确实是维护起来太麻烦了,频繁打jar包,打完jar包,调用段还得重启才能重新加载。
|
返回顶楼 |
|
|
- 须等待
- 等级: 初级会员
- 性别:
- 文章: 102
- 积分: 70
- 来自: 深圳
|
kingsfighter 写道 须等待 写道 服务化框架+1
服务化框架的核心功能:提供服务的发布和订阅、服务器地址动态路由和软负载均衡、至于客户端,不推荐用jar,维护起来太麻烦了
其实我也是赞同 服务化框架+1 的,目前我们也是按照这个模式去实现,只是实现的不够优雅;
客户端使用jar包的原因是规范客户端调用,避免由于开发人员不规范操作时造成的问题,但是现状确实是维护起来太麻烦了,频繁打jar包,打完jar包,调用段还得重启才能重新加载。
我认为如果使用了服务化以后客户端的调用还是使用jar的话,那么服务化的效果就太弱了,我们平台也是有这样的问题,发布一个服务要由服务端封装一个客户端jar,用的时候到处拷贝,且不说管理起来很麻烦,一旦协议有变化要升级什么的,简直是痛不欲生
个人觉得客户端这一块应该用更轻量级的协议模式:比如就直接用json来封装消息,你觉得这样可行么?
|
返回顶楼 |
|
|
- mike.liu
- 等级: 初级会员
- 性别:
- 文章: 22
- 积分: 30
- 来自: 深圳
|
如果是异步交互,建议消息中间件; 如果是同步交互,有两种风格: 1. RPC风格,包括Web Service,自定义RPC协议等; 2. RESTful风格,将所有服务抽象为资源;
第一种的缺点是,接口不容易改变,增减参数会影响服务端和客户端; 第二种的缺点是,可能需要更高的抽象能力,但是很多变化可以在资源内部进行,接口不受影响。
|
返回顶楼 |
|
|