Oracle ESB - 中间件皇冠上的明珠

背景

今年至少已经有3个人问了我同样的问题osb很无聊，不能写代码，没有写代码的快感，他们的疑惑我也是能理解，作为一个程序员，做开发不写代码就像厨师炒菜不用锅铲一样，很容易产生来自灵魂的拷问，“我是谁，我在哪，我在干嘛”。先说结论，osb是我从业以来最喜欢的产品，也是我觉得做的最牛逼的产品，这个想法至今没有改变过。我疑惑的是，为什么我们当初学osb的时候没有人有这疑问？

国庆期间陪老婆去散步，看到一排竹子，我跟老婆说，小时候我们很喜欢用竹做枪，野果做子弹，现在已经没人玩了，老婆说，现在小孩有手机，有平板，有电脑，谁还会去玩这个。这个有点像我们当年做开发，没有容器，没有微服务，没有spring boot，所有的开发都得从最基础的做起，很多接口都是直接用servlet开发，要是有人跟我们说有个东西能够不用写代码就可以写接口，肯定是不信的，但osb就是这么个东西，所以当年对osb格外的喜欢。现在程序员，不管前端还是后端都有各种各样的框架支持，一句话，都是给惯的。

那么osb过时了吗？并没有。

ps：在百度上找到了竹枪的图片，现在已经没有小孩玩了

osb是个什么东西

osb是Oracle Service Bus的简称，Service Bus中文翻译为服务总线，服务总线是干嘛的呢？我们假设有一个企业内部有100套系统，每个系统有自己的接口，现在该企业要做一个移动门户，需要获取各个系统的数据，拍脑袋列举了以下需求：

• 要求有个统一的调用地址
• 一个接口可能部分数据来源于A系统，部分数据来源于B系统，比如订单信息可能来源于订单系统，客户信息来源于CRM系统
• 不同系统接口数据格式不一样，可能有些系统是webservice+soap，有些是restful+json，有些就是自定义
• 不同系统接口协议可能也不一样，有些是jms，有些是http，有些是基于tcp
• 系统必须支持集群高可用
• 系统集成最好可视化，方便管理和问题排查
• 有完善的日志，可以追踪到每一次调用
• 可以对服务进行搜索
• ....

随便想想就能想到很多的需求，如果你一上来就是spring boot+nginx，那么谁也不会否认，整个项目最终会到不可维护的地步。所以服务总线就是解决以上问题的解决方案，服务总线规定了涉及到系统集成各个方面的解决方案，Oracle Service Bus就是一套成熟的服务总线产品。

如果你了解一些微服务，就会发现上面这些问题也是微服务要解决的问题，很多同学觉得微服务牛逼，不学点微服务都不好意思跟人打招呼了，那么我们对比下osb的解决方案和微服务的解决方案到底有什么区别。我们就以spring cloud的解决方案为例，spring cloud应该是目前最火的微服务解决方案。

osb VS spring cloud

统一接口调用地址

• spring cloud解决方案

这个方案可以很多种，你可以用nginx做反向代理，可以将所有的接口都代理到统一的地址上，好处是简单方便，nginx性能也不错，坏处是可视化差，而且随着接口数量增长，配置将变得复杂难以管理。当然你也可以选择spring cloud gateway产品，具体效果嘛，看下官方start的代码自行体会

• oracle osb解决方案

借助统一平台的优势，接口地址可以直接在osb上配置，就是这么直接

服务聚合

• spring cloud解决方案

服务聚合是微服务的概念，在spring cloud中，你可以通过Feign在代码层面做聚合，作为一个程序员你可能觉得这个很合理，但是如果聚合的服务一多，你怎么直观的看接口里聚合了多少服务？要去翻代码吗？下面是官网教程中的聚合例子

@FeignClient("stores")
public interface StoreClient {
    @RequestMapping(method = RequestMethod.GET, value = "/stores")
    List<Store> getStores();

    @RequestMapping(method = RequestMethod.GET, value = "/stores")
    Page<Store> getStores(Pageable pageable);

    @RequestMapping(method = RequestMethod.POST, value = "/stores/{storeId}", consumes = "application/json")
    Store update(@PathVariable("storeId") Long storeId, Store store);
}

用法很简单，一看就懂，但终归是代码层面上的东西，写时一时爽，排查泪两横。

• oracle osb解决方案

2008年，中国举办奥运会，那是我还是只会用ie的电脑白痴，那时候的音乐播放器是千千静听，那时候的手机是诺基亚，但那时候的osb已经有了在线版，已经可以可以在线开发接口，已经做到了可视化接口开发

• 服务编排

• 服务调用

数据格式转化

• spring cloud解决方案

数据格式转化在spring cloud中都不是问题，并没有解决方案，需要开发者在代码层面上自行进行转换，这个在互联网产品中可能没什么问题，大家用的格式都是json，但在企业中，单单一个xml转json就能搞死很多人。

• osb解决方案

可视化！还是可视化

不同协议

• spring cloud解决方案

spring cloud接口是通过spring boot进行开发，spring boot有众多的starter支持不同协议，比如MQ有spring-boot-starter-activemq，基本所有的协议都有相应的starer，就算没有，因为是基于java开发的，可以直接引用sdk

• osb解决方案

osb中business service（简称bs）对不同协议的接口进行了抽象，经过bs封装后的服务对上层都是一样的，bs也是可视化，可配置

日志

• spring cloud解决方案

微服务日志的收集分为，程序内部日志，接口调用日志，内部日志可以通过ELK等分布式日志系统进行收集，接口调用日志有个好听的名字，分布式跟踪系统，目前比较流行的有skywalking和zipkin，spring cloud据我所知是不包含日志系统的，如果表述有错请指正。

skywaling界面

zipkin界面

因为是外部第三方系统，所以在osb中也是可以用的。

• osb解决方案

osb早期版本对日志支持较弱，12c后与soa结合可以在em中查看详细的审计线索

osb的问题

osb本身也存在一些问题，让人想爱也爱不起来

• 爹是oracle，实际上osb亲爹是bea公司，就是那个创造出weblogic的公司，bea被oracle收购后osb就成了oracle中间件的一员，oracle的产品有个弊端，界面能多难看就多难看，操作能多复杂就多复杂，所以这么多年过去了，osb的界面还是没什么变化，有些操作还是那么难用
• 商业产品，不开源，oracle是不可能开源的，永远也不可能开源的
• 和oracle相关产品绑定的太紧，可以说，要想把osb用好，soa，weblogic等组件是必不可少的

其实从上面的对比可以看出，虽然osb在可视化方面完胜spring cloud，但是spring cloud相对osb，更加的开放和包容，这个可以从她强大的社区和数量庞大的组件库可以看出，而osb永远只有oracle自己在玩，但为什么我还是觉得osb是最牛逼的产品呢，因为：

我觉得osb的思路是对的

不管osb有多难看，有多难用，有多落后，但是osb对系统集成，对微服务的思考是对的，如果没有接触osb只接触spring cloud，你可能会觉得在代码里调用其他服务处理数据转换是对的，为了一个日志搭建一套ELK是对的，为了跟踪调用路径上一套skywalking是对的，如果你的团队够大，大到大厂那种级别，这些方案都是没问题，但如果你的团队只有两三个人，还要负责开发，你上这么多系统就是给自己挖坑。osb把整个解决方案打包在一套系统中，可视化界面进行展示，这个思路我一直觉得是对的，所以我至今都觉得osb是最牛逼的产品。

微服务目前还处于摸索阶段，真正成功的案例屈指可数，我个人觉得，osb就是未来微服务的方向，所有的组件会统一到一个平台上，代码会越来越少，可视化会越来越多。

该如何看待osb

写了这么多，终于要引出终极问题，osb这么好，到底是好事还是坏事？这个问题有点像，现在日子好了，天天有肉吃，都吃腻了，那么日子好了到底是好事还是坏事？我继承了千万家产，但是终日无所事事，到底是好事还是坏事？我觉得这个问题已经超出技术的范围，是一个哲学问题了。我说下我自己的想法。

我已经不做osb开发很久了，久到我现在都不的如何创建一个osb工程，但是osb那些概念是完全消化吸收，在学微服务时，心里经常就会冒出一句，“这个osb里不是早就有了吗，而且做的比这个好多了”，所以微服务的那些概念很快就能接受，并且能够知道微服务的解决方案存在什么问题。微服务存在很多问题，osb也存在很多问题，各有所长，既然你既懂osb也懂微服务，为什么不两者结合下？

所以，如果你会微服务，应该去看下osb，如果你会osb，应该去看下微服务，如果你两者都会了，是否想过如何结合，osb是不用写代码，但是osb也存在很多方面的问题，就像上面提到的那样，那么你是否能够思考下，如何解决那些问题

• 如何让osb变得更好用
• 如何让osb更好的跟java结合
• 如何实现osb自动部署
• 是否能够自动生成特定osb接口
• ...

甚至，是否我可以写一个更好用的osb。比如下面这个（截图来自Paragon)

总结

在oracle中间件大家族中，osb毫无争议是皇冠上的明珠，超前的设计理念，超低的资源要求，超稳定的服务，也许是太过超前的设计理念和目前流行的开源组件方向不一致，导致很多人认为学习osb没什么用，如果只是当作一个工具去学，确实没啥用，如果你明白里osb的设计理念，明白了osb的解决方案，对以后的技术架构能力是非常有帮助的。当你明白了osb的设计理念，你又有想法，恭喜你，你可能创造出一个新的osb。