基于Zookeeper的服务注册与发现

背景

大多数系统都是从一个单一系统开始起步的,随着公司业务的快速发展,这个单一系统变得越来越庞大,带来几个问题:

  1. 随着访问量的不断攀升,纯粹通过提升机器的性能来已经不能解决问题,系统无法进行有效的水平扩展
  2. 维护这个单一系统,变得越来越复杂
  3. 同时,随着业务场景的不同以及大研发的招兵买马带来了不同技术背景的工程师,在原有达达Python技术栈的基础上,引入了Java技术栈。

如何来解决这些问题?业务服务化是个有效的手段来解决大规模系统的性能瓶颈和复杂性。通过系统拆分将原有的单一庞大系统拆分成小系统,它带来了如下好处:

  1. 原来系统的压力得到很好的分流,有效地解决了原先系统的瓶颈,同时带来了更好的扩展性
  2. 独立的代码库,更少的业务逻辑,系统的维护性得到极大的增强

同时,也带来了一系列问题:

  • 随着系统服务的越来越多,如何来管理这些服务?
  • 如何分发请求到提供同一服务的多台主机上(负载均衡如何来做)
  • 如果提供服务的Endpoint发生变化,如何将这些信息通知服务的调用方?

最初的解决方案

Linkedin的创始人里德霍夫曼曾经说过:

成立一家初创公司就像把自己从悬崖上扔下来,在降落过程中去组装一架飞机。

这对于初创公司达达也是一样的,业务在以火箭般的速度发展着。技术在业务发展中作用就是保障业务的稳定运行,快速地“组装一架飞机”。所以,在业务服务化的早期,我们采用了Nginx+本地hosts文件的方式进行内部服务的注册与发现,架构图如下:


各系统组件角色如下:

  1. 服务消费者通过
  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值