我暂时还没用上tiproxy 但是看了下官网文档，感觉很抽象，tidb 前面加 tiproxy ,tiproxy 前面再加vip
我知道在tiproxy上做了一些带策略的故障转移，策略发现等功能
但是我觉得 tidb tiproxy vip ,后两者是完全可以做到tidb 里面的
就像web 应用那样，每个节点入口都是nginx ,和应用容器整合到一起，然后再均衡流量到server 层
从真实使用场景来看，其实牺牲的只是初始化建联的时间，长连接的相应不受影响
1 个赞
难道是从项目管理角度出发，tidb 作为独立项目，就不把这些直接做进去吗？
1 个赞
感觉这个是有意分开的，分层设计，可扩展性高一些
感觉架构一点冗余了，可以从低耦合的角度考虑 但是实际上 tiproxy 和 tidb 的定位都是唯一的，直接内聚到一起就行了
tidb + pd + tikv … 就能跑了
tiproxy 是为了解决特殊的场景和问题诞生的，因为还有其他可选的解决方案。
如果从组件的角度来看呢，单一职责对于迭代而言，会更容易了。
tidb 加上 tiproxy 的功能，我觉得一点问题都没有
嗯，你说的对
那要内核实现，成本有点高
另外 不需要这个功能的人，也会觉得我们 tidb 的架构也会变得冗余
我觉得存在即合理
组件角色分离考虑，这样的部署形态更灵活
有些架构代理层是可以和应用层放一起的
我也是觉得既然存在,肯定有它的应用场景,毕竟tidb很成熟了
是的，不好因需要功能就把架构搞的冗余 。
thanks for sharing