|
锁定老帖子 主题：企业内部子系统交互方案
精华帖 (0) :: 良好帖 (1) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2013-07-09
mike.liu 写道 如果是异步交互，建议消息中间件；
如果是同步交互，有两种风格： 1. RPC风格，包括Web Service，自定义RPC协议等； 2. RESTful风格，将所有服务抽象为资源； 第一种的缺点是，接口不容易改变，增减参数会影响服务端和客户端； 第二种的缺点是，可能需要更高的抽象能力，但是很多变化可以在资源内部进行，接口不受影响。 我觉得接口不变是一个很大的优势啊，有没有具体的案例？ |
| 返回顶楼 | |
|
发表时间：2013-07-09
须等待 写道 mike.liu 写道 如果是异步交互，建议消息中间件；
如果是同步交互，有两种风格： 1. RPC风格，包括Web Service，自定义RPC协议等； 2. RESTful风格，将所有服务抽象为资源； 第一种的缺点是，接口不容易改变，增减参数会影响服务端和客户端； 第二种的缺点是，可能需要更高的抽象能力，但是很多变化可以在资源内部进行，接口不受影响。 我觉得接口不变是一个很大的优势啊，有没有具体的案例？ 没有具体案例，有一篇关于REST思想的文章供参考： http://blog.csdn.net/besfanfei/article/details/7978030 |
| 返回顶楼 | |
|
发表时间：2013-07-09
用 XML 也不错,
要求通过 wsdl 验证才行.比 json 格式上更谨慎. 比接口 jar 更方便,把 wsdl 发布到调用端可以访问的地方. 调用端写一个验证程序就知道 xml 报文是否符合规则. ----------------------------------- 接口jar 包方式: dubbo, 在有多个服务者的时候可以用,并且: 引用 Dubbo的设计目的是为了满足高并发小数据量的rpc调用，在大数据量下的性能表现并不好，建议使用rmi或http协议. 如果只有一个服务者,用 hessian 就可以了. -------------------------------------- json 这个技术上没什么说的,更多是接口文档沟通,管理上的.内部可以用这个方式. -------------------------------------- XML 对外的接口还是用这个吧. 到时候把 wsdl 一发布, 每个使用者都必须看这个. |
| 返回顶楼 | |
|
发表时间：2013-07-09
mike.liu 写道 如果是异步交互，建议消息中间件；
如果是同步交互，有两种风格： 1. RPC风格，包括Web Service，自定义RPC协议等； 2. RESTful风格，将所有服务抽象为资源； 第一种的缺点是，接口不容易改变，增减参数会影响服务端和客户端； 第二种的缺点是，可能需要更高的抽象能力，但是很多变化可以在资源内部进行，接口不受影响。 我们是同步交互，个人比较赞成第二种，更高的抽象能力； |
| 返回顶楼 | |
|
发表时间：2013-07-09
须等待 写道 kingsfighter 写道 须等待 写道 服务化框架+1
服务化框架的核心功能：提供服务的发布和订阅、服务器地址动态路由和软负载均衡、至于客户端，不推荐用jar，维护起来太麻烦了 其实我也是赞同 服务化框架+1 的，目前我们也是按照这个模式去实现，只是实现的不够优雅； 客户端使用jar包的原因是规范客户端调用，避免由于开发人员不规范操作时造成的问题，但是现状确实是维护起来太麻烦了，频繁打jar包，打完jar包，调用段还得重启才能重新加载。 我认为如果使用了服务化以后客户端的调用还是使用jar的话，那么服务化的效果就太弱了，我们平台也是有这样的问题，发布一个服务要由服务端封装一个客户端jar，用的时候到处拷贝，且不说管理起来很麻烦，一旦协议有变化要升级什么的，简直是痛不欲生 个人觉得客户端这一块应该用更轻量级的协议模式：比如就直接用json来封装消息，你觉得这样可行么？ 我个人是比较赞成客户端轻量级，直接 http + json 的，但是json ，对于客户端来说，没有强类型化，开发人员容易犯错误，开发、调试的成本会大一点点，我们采用jar包模式，也是为了开发人员方便，提高开发效率，但是维护上却成了劣势。 |
| 返回顶楼 | |
|
发表时间：2013-07-09
内部帖子，里边有淘宝的子应用交互方案，大家可以看看
http://www.iteye.com/topic/1131120 |
| 返回顶楼 | |
|
发表时间：2013-07-19
我觉得楼主即然是远程交互, 肯定是基于某种远程通迅方式, 这个是重点. 没有说出来.
至于客户端是否要统一成JAR包, 简化各个客户端的开发. 这个也可以肯定. 是有好处的. 至于JAR包如何管理.可以使用依赖管理工具.如MAVEN, ANT. |
| 返回顶楼 | |
|
发表时间：2013-07-19
这个应该具体看你们内部几个项目是什么架构模式，restful是很方便，但是如果你内部几个系统就不是用rest风格架构的话也没法用，webservice个人觉得用于内部系统有点大材小用了，内部系统用的最多的还是使用jar包依赖。如果有变动打个jar包重新发布下也不是很麻烦的事儿。
|
| 返回顶楼 | |
|
发表时间：2013-07-20
我认为，对于内部系统的交互而言，楼主这种方案很合适。
JAVA接口的远程调用虽然比XML、JSON这类通用格式调用丧失了异构系统间的交互能力，但是这并不是这种场景所需要的。 另一方面，得到的好处就是显而易见的。调用远程服务和调用本地服务一样，这无疑大大减低了开发难度，也降低了出问题的几率。 楼主面临的接口变更的问题，解决方案是寻求一种更好的jar包管理的方式。可以使用MAVEN来管理JAR包。将各个子系统的接口JAR包部署到中央仓库。这样其他子系统可以从中央仓库直接取这个jar包。当更新了接口，打新的JAR包部署到中央仓库。调用再次取jar包的时候就能取到最新的jar包。 |
| 返回顶楼 | |
|
发表时间：2013-07-22
内部调用还是dubbo效率高一些
|
| 返回顶楼 | |
