构建大型网站:分布式改造

声明:本文仅限用于学术交流,引用或转载本文时请注明出处!

最近阅读许令波的《大型网站技术架构演进与性能优化》,记录部分笔记,

分布式改造需要解决的问题

  • 第一,应用需要微服务化。将粗粒度的应用逻辑拆小
  • 第二,必须先建立分布式服务框架。
  • 第三,必须解决状态一致性问题。

典型的分布式架构

  • 横向扩展:主要用来解决应用架构的容量问题
  • 纵向扩展:主要是解决业务的扩展问题
    b587d10523211cd36325ac5133b9a53f.jpeg@w=300h=200

分布式中间件

应用层:负载均衡系统
服务层:RPC框架、异步调度的分布式消息框架、解决静态配置信息分布式框架
数据层:屏蔽不同数据库的差异性,屏蔽应用层代码对数据分布的感知

服务化和分布式化

服务化:将业务做更细粒度的功能拆分
分布式化:从系统架构层面的角度

分布式配置框架

两种管理方式

  • 拉取模式:典型的c/s模型,缺点是configserve没法主动及时更新配置信息
  • 推送模式:主动把配置信息推送给每个client

实际应用场景

推送模式:配置下发延时率比较敏感,client数据不是特别大。zookeeper
拉取模式:client数据在万级以上

面临问题

  • configserve网卡成为瓶颈
  • 保证配置下发的到达率

分布式RPC框架

60bd9315193e599a19c831b71126d93d.jpeg@w=300h=200

  • 服务注册:服务被发现,必须先注册
  • 服务发现: 吧服务和提供服务的对应机器解耦。服务调用方只需要关心服务名,不用关心该服务有谁提供
  • 服务调度和负载均衡:摘除故障节点和负载均衡
  • 统一的sdk封装

分布式消息框架

实时消息

  • 异步解耦:分开调用者和被调用者的处理逻辑
  • 多消费端:单一事情触发的场景中

延时消息

分布式数据层

  • 分库分表:需要解析用户的sql
  • 主备切换
  • 读写分离
wechat
欢迎您扫一扫上面的微信公众号,订阅我的博客!

当前网速较慢或者你使用的浏览器不支持博客特定功能,请尝试刷新或换用Chrome、Firefox等现代浏览器