想把DB部分单独做成服务，各项目通过HttpClient进行通信，是否可行

netwild
2016-11-13 12:06

架构示意图：

QQ截图20161113113419.jpg

整体类似于SOAP

核心数据服务，由DB IO Service担任，基于JFinal框架，主要有两个工作：

1、数据库端，维护连接池，并利用JFinal的ARP对各数据库进行操作

2、输出端，开放主要的Controller，用于对DB的各种CURD操作，同时对数据进行缓存处理

至于各项目，只需通过JAR包方式引用DB插件，即可通过插件中封装的HttpClient方法与DB Service进行通信，完成数据交换。

上面说的各项目，其实就是模块，只是这样一来，就可以实现有针对性的单独部署

整体思路还是很明确的，下面是几个担心：

1、各项目中，底层是通过HttpClient解析服务端的JSON来获取数据的，这种方式的运行效率是否理想，心里没底

2、如果项目中的并发数据需求量较大，HttpClient能否应付过来

3、相比直接与DB Server通信，这种方式增加了网络层面（HTTP）的开销，对速度肯定会有所影响，能否超出忍耐范围

这种模式是我需要的，目前还停留在前期的分析阶段

不清楚是否可行，提交到这里，也是想得到波总以及各位朋友的指点

项目：JFinal

评论区

JFinal

2016-11-13 13:36

有人这么做过，效果极好，在你现在的架构图上只需要做一点点改动：将 DB IO Service 与 Controller 这部分做成多实例部署，也就是说弄成集群，如果 DB IO Service 这部分有不同的实例，那就成了一个分布式系统

淘宝、新浪都是这么做的，当并发需求很大时，先是多实例部署，然后加一个负载均衡来分发请求到不同的实例，这就属于集群的范畴

当集群的性能还满足不了需求时，再将大项目拆分成小项目，这就属于分布式的范畴，然后分布式中的热点小项目再多实例部署，这就属于分布式 + 集群混合的范畴

JFinal

2016-11-13 13:39

你的这个架构设计，总体上是极好的，如果性能出现瓶颈，先做集群，将 DB IO Service 与 Controller 这部分多实例部署

如果做了分布式，那么各分布式结点可能需要通信，一般情况下仍然用 http 走 json 就可以，如果是极大的性能要求，可以用 netty 走 socket 通道，我估计你很长时间都用不上，这都是巨型公司才要用的

JFinal

2016-11-13 13:44

再针对后面具体的问题做个简要回答：
1：Json 无论是转换性能，还是传输体积都是很好的方案，类似于腾迅开放平台、微信公众号这类巨型系统，都是走的 json 以及 xml，不会有问题。json 转换使用 FastJson 确保高性能，阿里巴巴内部都用的这个东东

2：HttpClient 是一个比较老的项目，很久没有关注过它的性能了，可以尝试一些比较轻量级的新的 http 工具包，例如 okhttp，比较下性能，选择最好的

3：http 的开销比 socket 确实是大了点，不过好在开销的消耗集中在每次请求都有三次握手，所以，一定要注意要开启 http 的 keep alive，并用心跳请求保持住长连接，这样可以让 http 建立长连接，不用每次请求都再重新建立连接

netwild

2016-11-13 14:18

@JFinal 万分感谢波总的耐心回复！也坚定了我对这套架构的信心
下面的工作就是逐一尝试了，对于FastJson还是挺熟悉的，okhttp头次听说
以后在具体实现时可能还会有更多的问题要麻烦波总
如果最后可以成功投入应用，也计划像JFinal一样开源，让更多人参与进来，握手~

JFinal

2016-11-13 14:28

@netwild 下个月上 jfinal 2.3 ，确保四年冠，多多关注社区动态，感谢支持社区发展

海哥

2016-11-13 17:43

这种设计很好，其实已经有很多的公司都在用，性能通过横向扩展完全不是问题。不过其中最重要的问题是权限问题，DB IO Service 是否对外暴露？如何对DB Plugin jar进行权限控制及安全保证？这是作者应该思考的。

顺便第一句，不建议用HttpClient，太重，性能也不好，可以直接手写httpUrlConnection都可以。同时对于DB IO Service 的暴露，也可以用netty作为server，通过netty暴露出来。

netwild

2016-11-13 21:36

@海哥权限控制确实是个问题，我目前的想法是按照微信公众平台的模式，应用层面通过AppID和token与DB Service进行授权校验，但肯定不会像微信那么复杂，否则就违背了简单易用的初衷。
感谢 @海哥提出用netty作为server容器的意见，以前没接触过，正好学习一下~

Dreamlu

2016-11-15 09:22

这种事务一致性是最大的问题。敏感数据注意写日志

JFinal

2016-11-15 09:49

@Dreamlu 在划分服务的时候保障一下不要跨数据源事务，每个小型服务通常使用一个数据源就好，多个服务再协同工作

海哥

2016-11-19 09:42

@Dreamlu @JFinal 其实这种解决方案，个人建议还是不要自己再造轮子了好，zookeeper已经很好的解决了分布式事务的问题，而dubbo很好的解决了 service的暴露以及远程调用。目前我所知道的亿及用户的产品，使用zookeeper + dubbo已经很好的支撑了。

JFinal

2016-11-19 14:16

@海哥少说了一点，服务治理用 dubbo 这类东东，并且对具体项目是透明的，具体项目使用 jfinal 做功能即可

netwild

2017-12-17 17:52

@海哥你的JBoot看起来就是我要的啊！

热门反馈

扫码入社