垂直服务化拆分-分布式服务架构

来源：互联网发布：如何申请开淘宝网店编辑：程序博客网时间：2024/04/29 07:18

转载自：

http://www.oschina.net/question/260548_158110?nocache=1491549674568

这是我加入公司后，公司架构的演变，但本身也有些问题想听听大家的想法。

加入这家公司后，在公司业务发展的同时，技术架构也逐渐在发生变化，垂直应用架构无法应对，所以我们进行了垂直服务化拆分。

最初我们跟很多公司一样，将核心业务拆分出多个服务应对多个垂直应用。起初，只是简单的暴露接口使用Hessian，通过配置服务的url调用。

但随着服务越来越多，没有一个统一的注册中心对这些服务管理，单个服务的压力越大，想将各个服务做集群。

最近看到zookeeper，可以做一些分布式文件配置，心跳检测，所以想使用zookeeper的节点来做注册中心，每个服务的提供方提供一个客户端，进行注册服务，zookeeper本身可以做心跳检测，一旦一个服务挂了后，可以将这个服务的注册信息提剔除，新增的服务在启动时会注册到zookeeper。

消费端，从注册中心订阅服务，可以从注册中心获取服务列表，本地缓存服务列表，及时服务中心宕机也不会影响使用，zookeeper更改服务列表信息也可以通知到消费端进行本地修改。

淘宝的dubbo本身做的很棒，但是本身系统复杂，部署麻烦，zookeeper节点存储的是每个接口的方法，基本都是Invoker思想。

我本身喜欢简单，目前架构进行修改后，可以支持未来一段时间应用，让我们可以腾出手做别的事情。

我的想法是，zookeeper每个节点存储，服务的地址，消费端有自己实现负载均衡获取地址后，进行访问服务。集群的配置文件放入zookeeper内。

不知道大家有什么想法，或者说类似的案例。想听听多些思路。

哎，其实没有必要整怎么复杂，搞一个分布式hashmap存放服务的url就行了，各个客服端直接从hashmap里面拿,不过自己实现心跳，评论(0) 引用此评论举报

harries

3年前

引用来自“harries”的评论

哎，其实没有必要整怎么复杂，搞一个分布式hashmap存放服务的url就行了，各个客服端直接从hashmap里面拿,不过自己实现心跳，

本身要实现的并非是负载url这些简单的功能，这只是其中的一点，在分布式环境下的协调，使用zookeeper的特性来处理的，如果本身只要实现这一点是很简单，那么对分布式环境下处理不了一些问题，还有什么意义呢评论(0) 引用此评论举报

Recall

3年前

引用来自“harries”的评论

哎，其实没有必要整怎么复杂，搞一个分布式hashmap存放服务的url就行了，各个客服端直接从hashmap里面拿,不过自己实现心跳，

引用来自“Recall”的评论

本身要实现的并非是负载url这些简单的功能，这只是其中的一点，在分布式环境下的协调，使用zookeeper的特性来处理的，如果本身只要实现这一点是很简单，那么对分布式环境下处理不了一些问题，还有什么意义呢

完全可以自己实现呀，写一个选举算法，自动推荐主评论(0) 引用此评论举报

harries

3年前

引用来自“harries”的评论

哎，其实没有必要整怎么复杂，搞一个分布式hashmap存放服务的url就行了，各个客服端直接从hashmap里面拿,不过自己实现心跳，

引用来自“Recall”的评论

引用来自“harries”的评论

完全可以自己实现呀，写一个选举算法，自动推荐主

那分布式锁，分布式配置文件统一，修改通知等，都自己去实现？？？？？评论(0)引用此评论举报

Recall

3年前

dubbo挺好用的。评论(0) 引用此评论举报

linan

3年前

我来分享下我的经验。

起初，我的架构和你现在的差不多一样，用的zookeeper.这个东西刚开始接触的时候感觉太好了。基于node和watcher可以快速构建出符合分布式标准的架构。比如做横向扩展，只需在某服务的节点下注册下server host&port. Master的负载均衡器就能快速感知。Master的单点故障也能通过竞争唯一node来解决。分布式锁，任务调度，消息容错，简直随手捏来。（当然这些代码都需要自己写，zookeeper只是提供给你了些基本的api.）

测试的时候什么都很好，等部署到生产后发现问题还是很多的。首先最要命的就是watcher通知滞后。（这也是我最终放弃zk的原因）肯定能收到通知，但是大多时候都很滞后（我用的java客户端，代码都是直接参考官方的，也可能是我代码太差），对于那些及时响应的应用影响很大，甚至会产生错误导向。还有一些小问题，差不多也忘了。。。囧。。

如果你还是要坚持用zookeeper，那么我建议你先掌握一个算法：CAS - compare and set. 这个算法是开发zookeeper经常用到的。就是用来解决race condition的。zk为每一个node提供了一个version number. 结合CAS就可以做原子操作了。

我现在的分布式架构缩减了很多，Master(nginx+lua) + Slave[tomcat(restful api)] + redis（缓存, 任务调度，消息容错）

--- 共有 9 条评论 ---

Grrrr：回复 @采飞扬 : 反正已经用了redis了，而且reids有列队的结构，不想再引入别的了。最重要的是lua链接redis,mysql都很成熟了。如果用mq,得再找一个lua的脚本了。。。3年前

采飞扬：回复 @Grrrr : 方法很妙呀，队列为什么不用专业的队列开源呢？如activemq 3年前

Grrrr：回复 @采飞扬 : 我没有用第三方插件，我读写分离作的很简单，更新缓存的时候向redis一个列队里面生成sql. 后台利用linux 的 crontab执行lua脚本链接redis取sql进行数据库更新，效果很好(话说lua真的很给力)。:-)3年前

采飞扬：回复 @Grrrr : 数据库用的主从同步？读写分离？有没有用第三方的驱动呀？如mysql proxy 3年前

Grrrr：回复 @采飞扬 : 弓虽 3年前

Grrrr

3年前