哪些事情适合在 middleware 中做
以较流行的开源 golang 框架 chi 为例：

compress.go
  => 对 http 的 response body 进行压缩处理
heartbeat.go
  => 设置一个特殊的路由，例如 /ping，/healthcheck，用来给 load balancer 一类的前置服务进行探活
logger.go
  => 打印 request 处理日志，例如请求处理时间，请求路由
profiler.go
  => 挂载 pprof 需要的路由，如 /pprof、/pprof/trace 到系统中
realip.go
  => 从请求头中读取 X-Forwarded-For 和 X-Real-IP，将 http.Request 中的 RemoteAddr 修改为得到的 RealIP 
requestid.go
  => 为本次请求生成单独的 requestid，可一路透传，用来生成分布式调用链路，也可用于在日志中串连单次请求的所有逻辑
timeout.go
  => 用 context.Timeout 设置超时时间，并将其通过 http.Request 一路透传下去
throttler.go
  => 通过定长大小的 channel 存储 token，并通过这些 token 对接口进行限流

  ===================================================

  负载均衡算法效果验证
我们这里不考虑加权负载均衡的情况，既然名字是负载“均衡”。那么最重要的就是均衡。我们把开篇中的 shuffle 算法，和之后的 fisher yates 算法的结果进行简单地对比：

package main

import (
    "fmt"
    "math/rand"
    "time"
)

func init() {
    rand.Seed(time.Now().UnixNano())
}

func shuffle1(slice []int) {
    for i := 0; i < len(slice); i++ {
        a := rand.Intn(len(slice))
        b := rand.Intn(len(slice))
        slice[a], slice[b] = slice[b], slice[a]
    }
}

func shuffle2(indexes []int) {
    for i := len(indexes); i > 0; i-- {
        lastIdx := i - 1
        idx := rand.Intn(i)
        indexes[lastIdx], indexes[idx] = indexes[idx], indexes[lastIdx]
    }
}

func main() {
    var cnt1 = map[int]int{}
    for i := 0; i < 1000000; i++ {
        var sl = []int{0, 1, 2, 3, 4, 5, 6}
        shuffle1(sl)
        cnt1[sl[0]]++
    }

    var cnt2 = map[int]int{}
    for i := 0; i < 1000000; i++ {
        var sl = []int{0, 1, 2, 3, 4, 5, 6}
        shuffle2(sl)
        cnt2[sl[0]]++
    }

    fmt.Println(cnt1, "\n", cnt2)
}
  ===================================================


首先 配置菜单，创建菜单，但是没有对应的请求方式 <查看，增加，更新，删除>
然后 创建角色 然后配置角色和菜单的关系绑定

之后 配置角色 请求细节权限控制，如果没有配置的话，则可以访问可以操作，

最后 配置角色和用户之间的关系即可
---------------------------------------------------------------------------------

微服务架构梳理
通信常见的方式：
1.REST API
2.RPC 
3.发布/订阅 (同步)
4.发布/订阅 (异步)
多个服务之间的交互:
1.服务与服务之间使用的是发布/订阅
2.API Gateway和服务之间的交互使用的GraphQL
3.客户端和API Gateway之间的交互使用的是REST API
微服务中的事务：
Saga通过事件发布订阅来实现事务
发布订阅中的常见问题和解决方案：
重复发，重复执行，是否发布
解决方案
1.事务发件箱模式
2.事务日志拖尾模式
3.其他等
微服务中监控：
1.事件溯源
2.事件快照
3.流量监控
4.黑白名单
5.认证权限等等
微服务中的特殊数据查询问题可能会涉及到多个服务处理：
1.CQRS
2.ES | API组合等等
3.其他第三方工具
介绍一下CQRS，读写动作分离，通过发布/订阅来更新维护R的数据库
微服务中的原子性问题：
1.乐观锁
2.悲观锁
3.版本号
4.逻辑字段等等
微服务架构变化遵循的规则：
向后兼容问题

微服务中客户端到服务端交互模式：
1.APi Gateway 
2.API Gateway 的后端前置模式
设计到的第三方工具GraphQL 负责与服务端进行的交互

微服务中的测试问题：
测试分类
1.单元测试   负责业务逻辑
2.组件测试   负责交互通信
3.集成测试   负责领域测试
4.端对端测试  整体流程
配置桩和契约测试会高效的测试

关于中间设计到的一些技术问题
发布订阅/Kafka
模拟测试/Docker junit cucumber .....
网关路由分发/GraphQL
事件溯源/DynamoDB
....