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

Recall 发布于 2014/06/10 22:06
阅读 7K+
收藏 8

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

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

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

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

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

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

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

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

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

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

加载中
1
Grrrr
Grrrr

我来分享下我的经验。

起初,我的架构和你现在的差不多一样,用的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(缓存, 任务调度,消息容错)

Grrrr
Grrrr
回复 @采飞扬 : 反正已经用了redis了,而且reids有列队的结构,不想再引入别的了。最重要的是lua链接redis,mysql都很成熟了。如果用mq,得再找一个lua的脚本了。。。
采飞扬
采飞扬
回复 @Grrrr : 方法很妙呀,队列为什么不用专业的队列开源呢?如activemq
Grrrr
Grrrr
回复 @采飞扬 : 我没有用第三方插件,我读写分离作的很简单,更新缓存的时候向redis一个列队里面生成sql. 后台利用linux 的 crontab执行lua脚本链接redis取sql进行数据库更新,效果很好(话说lua真的很给力)。:-)
采飞扬
采飞扬
回复 @Grrrr : 数据库用的主从同步?读写分离?有没有用第三方的驱动呀?如mysql proxy
Grrrr
Grrrr
回复 @采飞扬 : 弓虽
下一页
1
g
goushijie
我们现在就是采用的分布式服务架构,服务可以任意扩展,爽呆了
0
harries
harries
哎,其实没有必要整怎么复杂,搞一个分布式hashmap存放服务的url就行了,各个客服端直接从hashmap里面拿,不过自己实现心跳,
0
Recall
Recall

引用来自“harries”的评论

哎,其实没有必要整怎么复杂,搞一个分布式hashmap存放服务的url就行了,各个客服端直接从hashmap里面拿,不过自己实现心跳,
本身要实现的并非是负载url这些简单的功能,这只是其中的一点,在分布式环境下的协调,使用zookeeper的特性来处理的,如果本身只要实现这一点是很简单,那么对分布式环境下处理不了一些问题,还有什么意义呢
0
harries
harries

引用来自“harries”的评论

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

引用来自“Recall”的评论

本身要实现的并非是负载url这些简单的功能,这只是其中的一点,在分布式环境下的协调,使用zookeeper的特性来处理的,如果本身只要实现这一点是很简单,那么对分布式环境下处理不了一些问题,还有什么意义呢
完全可以自己实现呀,写一个选举算法,自动推荐主
0
Recall
Recall

引用来自“harries”的评论

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

引用来自“Recall”的评论

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

引用来自“harries”的评论

完全可以自己实现呀,写一个选举算法,自动推荐主
那分布式锁,分布式配置文件统一,修改通知等,都自己去实现?????
0
linan
linan
dubbo挺好用的。
0
ForEleven
ForEleven
可以看看dubbo是否符合你的需求
0
ForEleven
ForEleven
或者看看akka,akka2.3的集群提供了分片集群以及状态持久化。非常简单的就可以实现服务的集群以及治理
0
中山野鬼
中山野鬼
哈,看到楼主这个帖子,我终于懂了另一篇,为什么还有“运维可做架构师”的观点存在。。。。系统的进步和演化,离不开应用中的问题,哈,不过架构如果都是这么整出来的,系统就太好设计了。。。。
Recall
Recall
回复 @中山野鬼 : 答案本身就不用你说,对于同一种需求,一千个公司有一千种实现方式,但大体思想不变,实现细节和对需求实现的转化,不光光是考虑技术层,谢谢,你的回答,但是请不要再回答了
中山野鬼
中山野鬼
回复 @Recall : 哈,需求和设计是等同的吗?客户的需求系统化的整理好,和从实现角度对这些需求进行实现,可以等同吗?答案不用我说,你自己判定咯。
Recall
Recall
你怎么知道架构就是这样整出来的, 你怎么知道,系统的进步和演化不是基于需求来推动,牛X大牛啊
Lyuans
Lyuans
运维可做架构师 这篇不是被人吐X死了嘛
返回顶部
顶部