Updated 分布式系统架构方案设计初稿.md (markdown)

当前架构中（引擎 --> sidecar(修改url中的域名) --> dapr --> app服务），引擎通过 Sidecar 进行URL 域名修改后，再转发到 Dapr。这种设计导致了两次不必要的网络转发，增加了延迟和复杂性，同时这些转发对应用并不透明，比如对stream流的支持。

```java

}

```

引擎的转发逻辑是：如果目标app在本地容器中，则直接处理；如果不在本地容器中，则转发请求。

然而，如果访问一个不存在的应用，则会导致死循环（业务中反馈的出现 loop call 问题），因为每个节点都觉得不在本容器内就转发，没有停止的条件。一般来说，路由应该是确定性的，如果app存在则访问，否则直接报错不存在。

}

```

在当前架构中，应用安装过程由引擎完成一份部分， Sidecar 完成另一部分，需要相互协调和等待回调。这种设计增加了复杂性和不确定性。理想情况下，应用的安装和卸载应该由一个组件独立完成。

比如回调逻辑可能会因为异常出现死循环：

}

```

- 一致性

以上问题当确定网关也就是master节点的地位以后，就变得非常简单了。简单来说master节点永远是主节点，其他业务节点只是从节点，而且内存同步的发起方永远是master，那么master节点只需要把需要操作的内存信息以http请求方式广播给所有的从节点就可以了，http本身是同步且待ack确认的。

网关服务可以通过固定的 service 名称（如 `master`）来实现统一管理，确保先启动并完成所有内置应用的表结构初始化、种子数据初始化等只需要一个容器一次性初始化任务。这些任务只需要一个容器执行，无需在所有容器中重复执行。

这里应该插入架构图的，但是不知道咋插入 ₍ᐢ..ᐢ₎ todo

在 MySQL 中维护app和其所在容器服务的关系。每个 Pod 中可在进程内缓存这些关系，并设置有效期（如 5 分钟）。如果缓存未过期但访问失败，则强制从 MySQL 读取，以确保数据的正确性。

```

通过 watch 服务变化，及时主动更新内存中的 service 和应用对应关系，确保数据的一致性和实时性。

安装和卸载功能可以由一个独立的内置app管理和创建容器。为了确保一致性，可以采用以下策略：

可能有人会感觉容器的管理和维护，应该是属于运维层面的事情，不应该放到业务中来处理，确实是的，其实最佳做法还是按照业界的做法，编写operator来完成所有的容器操作，而且这个操作是一致的，尤其是再涉及到多个资源的情况，比如有service、deployment、configmap、pvc、secret等，如何保证创建、删除和修改这些资源的一致性呢？

k8s已经给出了答案，通过operaotr即可做到 https://kubernetes.io/zh-cn/docs/concepts/extend-kubernetes/operator/ 以及如何管理依赖和引用：https://kubernetes.io/docs/concepts/overview/working-with-objects/owners-dependents/

通过上述改进方案，可以解决当前架构中的多个问题：