浅析项目架构-a

单元化,set集装箱,意思都差不多,一个set或单元服务一定量用户,根据用户位置转向就近机房为其服务,每个set或单元都有在其他机房的备份便于容灾

  • 一个请求可能经历的路径(目前使用手机的情况居多,以app为例)

    • 1.请求一个域名(httpDNS or GSLB获取就近服务器机房VIP-通过用户IP信息)
    • 2.lvs-fullnat负载均衡到一个real server(一般是nginx)
    • 3.nginx再负载均衡到backend server(一般是tomcat or jetty)
  • httpDNS or GSLB

    • 根据服务器域名 和 用户信息 获取 就近的机房VIP
  • 机房

    • 一般至少都有2-3个异地机房(如:北京,广州,华中等地)
  • DB

    假设机房a,b,c

    • 机房a: mysql master, mysql slave
    • 机房b: mysql slave
    • 机房c: mysql slave
  • 读写分离组件

    一般我们都使用Druid数据库连接池

    • 可以基于druid写一个读写分离的数据库组件,以jar包的形式,可以看成mysql-connector-j的plus版本
    • 读的时候再支持负载均衡
  • 服务化

    • 抽出核心的业务服务化,独立出来
    • 现有的rpc框架实现其服务化, dubbo(不跨语言,仅java)
  • 容灾

    • mysql 存储: 一主多从-多机房
    • 服务多机房部署
    • nginx-backend server
      • openresty(lua) 检测backend出问题时返回静态文件如json数据
      • 此json数据可以是task定时请求接口获取
  • 服务降级-保证核心业务正常使用

    • 自动降级
      • 非核心业务统计qps,达到阈值,断掉调用核心业务接口,避免核心业务受影响
    • 手动降级
      • 降级开关
        • 服务a调用存储api,打开降级开关,此调用被切断直接返回值
  • 降低mysql读压力

    • 这里可以添加一层redis,请求到redis获取数据,task刷数据到redis。调用很频繁的可以再加一层local cache,本机缓存,避免redis压力过大,也可以减少网络流量。
  • 限流

    • nginx限流
    • backend限流
    • 常见算法:令牌桶 漏桶
  • 监控及报警

  • 机器信息(cpu使用率,负载,内存使用,网络流量等)监控

  • 服务器监控nginx, tomcat or jetty, rpc server, mq

  • 服务调用次数:失败,成功,异常

  • 线上错误日志异常统计报警

  • 常见问题解决方案

  • cpu过高 top

    • 一般是jvm进程问题 dump线程堆栈看看线程都在干什么
    • 有可能是共享了一台物理机,受到其他业务的影响
  • 内存泄漏

    • dump内存 IBM memory analyzer分析 可疑泄漏点

你可能感兴趣的:(浅析项目架构-a)