JAVA 牛牛

架构framework

framework

项目架构基本思路

  • 减少io
  • 提升相应速度
  • 最终一致性
  • 移动端的开发需要考虑 移动端和服务器的时间问题
  • 价格可以用分来计算
  • 程序员的高效率来自明确的需求
    • 需求不明确，项目我们不接
    • 项目接了，需求不能改，只能放在下一个版本
  • 减少io或者合并io
    • 比如数据库的读取，放在一起调用，一次commit
    • 比如服务间的请求，放在一起调用
  • 设计系统考虑下：原料和流程
  • 微服务要考虑服务的无状态（每次调用，微服务是对调用前后状态无感知的）
  • 识别系统的变化点
  • 升级发布
    • 蓝绿发布（需要两倍的服务器）费钱
    • 滚动发布（新版本和老版本会在一段时间内同时在线，容易出现问题）
    • 灰度发布-金丝雀发布（）
      • 网关到服务
        • 通过在网关配置不同的参数做区分，路由到不同的地址 使用RibboFilterContextHolder
      • 服务到服务
        • 自定义ribbo的rule的规则
      • 可以支持A/B测试
        • 制定灰度测试规则，区分哪些用户走哪些服务（ 规则都写到数据库里面，boss后台录入规则，这样测试的时候就不用重启机器了）
      • 使用ribbon 或者一起框架路由到对应的微服务
    • 允许失败，允许适度浪费，鼓励内部良性竞争
  • zuul（网关可以做什么）
    • 分发服务
    • 身份认证
    • 过滤请求
    • 监控
    • 路由
    • 限流
  • 当你有拷贝欲望的时候 就该考虑设计的合理性
  • 最小知道原则，安全规则
  • 过滤器的执行顺序，节省计算的资源
  • 网关接口容错
    • 创建一个对象实现 FallbackProvider
  • 生产中小技巧
    • db中存储：过滤器开关
      • 配合 spring-boot-starter-actuator 更清爽

项目中遇到的问题

  • 使用zuul cookie 和token 不能向后传递的问题

    • 通过在yml里面配置下 ，把敏感信息制成空

      zuul:
#    以下配置，表示忽略下面的值向微服务传播，以下配置为空表示：所有请求头都透传到后面微服务。
#  sensitive-headers:
  routes:
    # 此处名字随便取
    custom-zuul-name:
      path: /zuul-custom-name/**
      service-id: service-sms

  • 老项目改造中路由问题

    • 方式一 yml配置
    RibbonXXXFilter 路由到其他服务
SimpleHostRoultFilter 路由到其他url
SendForewordFilter 路由到自己的路径
zuul:
  routes:
    xxx:
      path: /forword1/**
      url: forward:/myController
  
  
#    # 配合 风雨冷人
#    xxxx: /zuul-api-driver/**
##     此处名字随便取
#    custom-zuul-name:
#      path: /zuul-api-driver/**
#      url: http://localhost:8003/

    • 方式二，使用zuul的Filter

      1.过滤器 route
2.获取请求过来的url（请求）
3.url（请求） = url（目的地）映射
4.设置RequestContext中的 serviceid url
====
开发之前，想清楚步骤
技术和业务做选择和取舍。（100种方法，你去其中一种，出问题自己扛）

  • 动态路由（根据不同的用户路由到不同的服务）

    • 路由到服务
    • 路由到具体地址

  • 微服务404的原因

    • url是从哪里拿到的
      • 从eureka中拿到
      • 从配置文件中拿到

  • 2核4G 并发量可以达到1000qps

实际开发中的技巧

  • 做IP次数限制，
    • 结合redis 一起使用 将key设置为ip，value设置为请求次数，并设置过期时间
  • 网关限流和服务限流
    • 结合gavaca 使用
  • currentContext.setSendZuulResponse(false)
    • 系统中默认的route post error过滤器不会执行，因为源码中有对应的判断
    • 自定义的 route post error 还是会走，需要做对应的判断，可以再根据自己的业务做判断
    • 表示本过滤器（比如pre）不向后面的route post error过滤器转发，但是所有的pre过滤还是会挨个执行
    • 所以 在shouldFilter() 方法中 将返回值设置为 currentContext.getSendZuulResponse() 可以将其他的pre也过滤掉，不再向下执行

接口管理

  • yapi
  • 小幺鸡

缓存

  • map
  • gavage
  • redis
  • memcache

项目中优化的点

  • 开发时用快照版本 生产环境不能用快照版本

  • 通过将数据从堆移到栈中提升效率
  • 常用不变的用缓存，不要用db（把内存用起来减少io ，io是瓶颈，比如网络io，磁盘io）
  • 提高QPS
    • 提高并发数
      • 能用多线程就使用多线程
      • 增加各种连接数，tomcat，mysql，redis等等
      • 服务无状态：便于横向扩展，扩机器
      • 让服务能力怼等（serviceUrl，打乱顺序）
    • 减少相应时间
      • 异步（最终一致性）
      • 缓存
      • 数据库优化
      • 多的数据，分批次返回
      • 减少 调用链（但是通常会被共用工具类打破）
      • 能用长连接不用轮询，能不用长连接也不用

简历

  • 传统项目改成微服务
    • 兼容老的url，zuul，过滤器
    • 根据用户做动态路由
Search