将调用服务发现的操作重构为Batch操作；对于多LDC且大批量Pod的流量变更任务，实现自动拆单，避免变更流量时由于服务发现限频导致的卡单

变更Pod小于5000不会卡；变更Pod超过5000要拆单【有多LDC（地区机房）的情况，灰度策略可能会拆出100步灰度步骤（13个不同地区的机房）】

服务状态发现服务【司南，限频10分钟内100次，Batch操作批量一次可以请求50个Pod的状态】

建立一个流量变更任务单，需要按灰度策略计算出每一批灰度的行为，这个需要把本变更单的所有Pod的状态都查出来【判断是上线、下线、流量调权，这样才能选择对应的灰度策略】，所以太多Pod的时候只能拆单【优先按照LDC（地区机房）拆单，这样逻辑比较顺；还是不行的话按照 Pod 和 物理机 拆；再不行的话手动按照命名空间拆分】

灰度策略见notion笔记：https://app.notion.com/p/389be42d0e85809b8985f3cb3d2689de

正向灰度、回退、强制关单的逻辑，对应的锁是咋加的？

正向灰度、回退、强制关单的逻辑见notion笔记【总设计】：https://app.notion.com/p/38abe42d0e85800b8830ffabc53e1182

加锁策略见notion笔记：https://app.notion.com/p/38abe42d0e8580f1802dcb1b08f85322

自己看代码中的老流控如何加锁见notion笔记：https://app.notion.com/p/38ebe42d0e85806b90ded2e0527e0bf6

自己看代码中的新流控如何加锁见notion笔记：https://app.notion.com/p/38ebe42d0e8580bfb8a2c6934534cbbd

自己看代码中的正向灰度、回退、强制关单的逻辑见notion笔记：https://app.notion.com/p/38ebe42d0e8580609e6bc093029e6710

实现变更各阶段（建单前置、执行前置、执行后异步检查）的风险防控检查项、级别（阻塞/提示）、适用场景（上线、下线、流量调权）以及具体方案

风险防控措施见notion笔记：https://app.notion.com/p/389be42d0e858066ba5cd8722e4ead68

前端建单时建单前置的风险检查，前端每个环节一次请求调用，一个检查项一次请求，这样返回的快，用户可以更好的感知进度

后台变更，脚本自动在后台调用的时候就走设置好的风险检查策略链，一次调用全部检查完后一次返回

后台脚本自动变更和前端手动变更风险检查的检查项是不一样的

根据用户反馈优化系统前端的展示与操作逻辑

建单时要填的所有东西要在一页里面，页面太长就在右边加上可跳转导航。填完确认和风险检查的页面单独一页。

默认的一般不需要改的地方就折叠仅展示仅可读不可改，要改的话点击修改才让改并具体展开详细的值与说明

权重不可以小于0，但可以大于100【历史遗留，且可以方便SRE同学精细流量变更】

批量上线、批量下线、批量设置权重

同一个流量变更单中流量变更的方向需要相同

保留去除填入的IP、不知到服务名时通过 IP+端口号 找出对应POD【等方便的查询功能】