在2016年6月接手公司项目，对事件库、积分奖扣（添加、修改与审核）、排名进行重写，与shine沟通之后，决定使用dubbo做为SOA治理，如此可以使新的模块脱离老系统的束缚，以便各个模块分而治之。
从dubbo到dobbox，从默认序列化到kryo，从dubbo协议到rest协议；现在介绍下参与其中13个模块：
第一个阶段：默认序列化：
- 事件库
- 积分奖扣
- 掘金报表
- 奖扣任务
- 任务大厅
- led（互联网化群控）
第二个阶段：：
开放平台、OAuth2、开放接口，这是一张架构图；
图一 架构图
图二 dubbox serialization="kryo"
图三 dubbox restful api 第三方访问接口
为什么我们要采用这样的架构？
对于系统内部需要更好的可伸缩性，于是内部系统基于最底层（图二dubbo协议）开发，第三方应用基于图三restful api开发；
我们应该使用那个版本？
首先说一个比较好玩的，dubbo（2.4.8）与dubbox（2.8.4）不兼容；我们继续我们的话题：
- 第一阶段：我们使用了dubbo
- 第二阶段：我们使用了dubbox
两者的区别：
dubbo是阿里开源，现已停止维护；dubbox是当当网二次开发后，维护的版本；
为什么切换至dubbox版本：
基于开放平台的开放接口，我们需要对restful的支持的框架；由于dubbox 支持restful协议，也一样可以继续实现分而治之的管理方式；dubbox底层引用的框架resteasy，当时很开心的是2年前已经使用过该框架；
希望此篇文章可以帮助大家，下一章我将基于dubbox开发的模块给予细致的讲解。
很高兴认识你，我们都一样，有过迷茫却从未放弃；害怕孤独可从不寂寞。
网友评论