GitHub地址:https://github.com/polarismesh/femas
    Femas介绍:https://www.infoq.cn/article/KksAEfXidiM2iwZMvZ0q
    体验环境:http://106.53.107.83:8080/femas/guide
    用户名:admin密码:123456

    问：我有这种场景，同一种服务有多种注册中心，femas有这种归集的功能吗（指，我getServices）可以拿到各个中心的instance。
    答：CompositeServiceRegistry 代码里有一些相关的类，不过还没有开放实现。
    场景：各个医院上我公司的系统用的是不一样的注册中心。医院现在某些业务要实现互联互通，就需要这种场景，还是registry-sync， 把各个注册中心地址簿实时同步，不需要应用同步注册，proxy代理同步心跳。

    问：dubbo3完全兼容grpc那么SpringCloudGateway是否可以改造为Dubbo网关呢？
    答：k8s的Ingress云网关上兼容微服务网关，springcloudgateway就没存在的必要了，SpringCloudGateway跟dubbo不是一个体系，外国人写scg的时候不会考虑去支持dubbo，肯定需要增强，把协议打通，dubbo不是支持grpc协议吗，SpringCloudGateway也支持grpc呀，运维网关和业务网关合并，统一管理南北流量和东西流量，是目前网关的主流，确实没有springcloudgateway的必要了。

    问：sc新的webflux协议，比servlet协议快？
    答：不一定，webFlux虽然是基于netty的但是 tomcat也支持nio,webflux更像一个封装的网络库。react，epoll这种是解决计算机C10k问题的，对业务代码的latency没有什么帮助。

    问：一个业务查询1s，走epoll和走servlet RT差别会大吗？
    答：它们的并发编程模型是为了解决网络并发问题，并不是为了解决业务快慢
    答：TP999 我们要求80ms以内

    问：美团用的啥，Pigeon？
    答：thrift，femas压测sc的治理逻辑，基本上是20ms左右。
    答：就是走数据库 然后还有好几个RPC调用。

    问：美团不是有个部门专门研究quick协议的吗？

    问：这边还是以定制thrift协议，还是mtthrift为主？
    答：字节也是thrift，eign性能优化tomcat换undertow 默认的httpurlconnect换httpclient 性能也没多大提升啊 压测能扛200 请求也200ms左右 做到80这是要多狠。
    答：三次RPC 两次读数据库

    问： 三次RPC 两次读数据库优化方向？
    答：优化的方向就是 两次数据库并行查询 一个主线程查询 一个扔到线程池查询 RPC优化的方向就是 减少RPC调用 + backuprequest + RPC并行调用
    答：并行调用的结果 最后取个交集就行 没什么依赖关系

    问：域网关？
    答：通用网关，测试都妥妥的，netty写的，真实流量一上去，傻眼了。搞得一个大部门一个网关
    答：一个大部门一个网关，其实也有合理性，很多BU不喜欢吃大锅饭

    问：我们现在的瓶颈在数据库 分了100张表 单表规模5000万 单表增长太快了
    答：顶不住，流量太大，提升太难，直接拆分
    答：先负载均衡 在网关 这样分开要好些吧
    答：分布式数据库
    答：中间件一般是自己搞sdk存储，etcd，TIDB基本都是 boltdb或者rocksdb，femas的存储也是rocksdb

    问：分库分表不也需要proxy去对业务屏蔽细节吗？
    答：读写分开历史数据也难
    答：100张物理表，对业务来说就是一张逻辑表
    答：是的 业务开发无感 都是proxy自动路由的 不过有一些场景还是需要 自己写hint路由。

    问：分表前期没规划好？溢出了？ 可以这么理解
    答：所以现在在做拆库拆表 100拆1000
    答：历史数据倒还好 做好冷热分离

    问：mysql单表应该800万左右正常吧 用hash均匀分布0-800 800-1600这样吗 ？
    答：userID % 100 改为 %1000 取模

    问：老数据呢，规则改了，老数据查询就混乱了？
    答：老数据问题不大 切库后走新的路由规则即可 以前是十个用户的数据在一个表 现在是 十个用户拆到了十个表， 我们的业务场景 不会有 userIdList 这种查询 都是单个用户，我们会将老数据迁移 将原来的单张表数据清洗到10张表里。

    问：停机停服迁徙？
    答：嗯 停服迁移

    问：分库分表要是前期规划的的话，应该怎么搞啊。要是主从的话，感觉异步延迟也是问题，主库业务停摆这个应该不允许。先把新的入了，旧的通过脚本搞么？

    问：数据分片跟主从是两个东西？
    答：主从主要是从库分担主库读压力，分片是数据分片存储。

    经验： 前期规划分表的时候 胆子大点 人有多大胆 地有多大产 一年数据增长可能就1000万的业务 按1年一个亿来估 都说的过去 资源浪费 总比最后冷热分离都解决不了的容量问题要好 当然如果你想刷KPI当我没说

    问：迁移时的同步 从库不也要同步吗？
    答：迁移同步我们不是整个迁移阶段都停服，腾讯有我有不停服迁徙的方案。
    答：我们可以做到不停服迁移 但是成本比较大 综合评估 停服一分钟 问题不大。

    问：数据是最终一致 还是实时一致？
    答：实时一致

    问：不需要停服，这方案很贵吧？
    答：嗯，贵，看他们老板诚意

    问：分库分表扩容
    答：扩的库表多了，还要考虑对应的canal也得扩，es集群等也得扩，还有很多小细节。要不停服，用户无感知，还要考虑成本等。

    数据迁移：有现成的数据迁移工具 对业务无入侵 只不过没法对数据一致性进行check 对我们黑盒 所以我们需要停服check数据的一致性 预计也就一两分钟把 某天半夜切下库就行了，我们不是服务下线哈 我们是把写库场景降级 验证数据一致之后就切库 然后恢复降级即可。先白名单验证 没问题就停服一把梭。
    数据迁移：弄个代理层无感知切换新旧dao 开起双写 先用脚本将存量挪到新库 停读旧表改新表还是要保持双写 观察观察 停掉旧表。
    停服迁移看业务：看影不影响线上成交了，如果是头条这种内容的，停一分钟可能还好吧，我有次一个定时刷的任务，重启。刚好那个时间重启，直接10w个告警出来。线上业务都是蓝绿这么玩了。
    数据迁移：femas的灰度路由。

    问：nepxion玩法吗？
    答: 不是，泳道的玩法
    答：com.tencent.tsf.femas.adaptor.paas.governance.lane.FemasLaneFilter 这个代码你可以看看，泳道的部分逻辑