\345\210\206\345\270\203\345\274\217\347\263\273\347\273\237\346\236\266\346\236\204\346\226\271\346\241\210\350\256\276\350\256\241\345\210\235\347\250\277.md
... ...
@@ -69,12 +69,16 @@
69 69
return new Tuple<>(false, null);
70 70
}
71 71
```
72
+#### 1.3 转发的路由问题
72 73
73
-#### 1.3 应用安装的复杂性
74
+已有的实现是将app和对应的路由关系保存在redis中，且不说redis可能丢失数据的问题，现有实现也没有一种类似路由存活的机制，比如某个业务app下线了，但路由信息还在，依然会将请求转发到这个容器中，造成不可访问。
75
+
76
+#### 1.4 应用安装的复杂性
74 77
75 78
在当前架构中，应用安装过程由引擎完成一份部分， Sidecar 完成另一部分，需要相互协调和等待回调。这种设计增加了复杂性和不确定性。理想情况下，应用的安装和卸载应该由一个组件独立完成。
76
-比如回调逻辑可能会因为异常出现死循环：
79
+比如回调逻辑可能会因为异常出现死循环.
77 80
81
+已有的实现边车和引擎没有相关关联，如果引擎由于oom导致容器重启（不是pod重启），但是对于边车来说是不知道引擎重启的，那么业务app就无法安装。
78 82
79 83
引擎端实现，判断请求是否exeMod为local来判断：
80 84
... ...
@@ -138,7 +142,7 @@ sidecar 回调，如果不成功会一直尝试：
138 142
}
139 143
```
140 144
141
-#### 1.4 内存同步遇到的问题
145
+#### 1.5 内存同步遇到的问题
142 146
143 147
- 一致性
144 148