首先，这是关于我的学校论文的问题。我对此做过一些研究，似乎还没有解决的问题（可能不常见）。
在深入研究问题之前，我将简要介绍一下我的用例。
我有多个包含微服务的命名空间，具体取决于状态X.为了管理这个，微服务被放在以状态命名的命名空间中。 （所以命名空间state_A，state_B，...）
重要的是要知道每个微服务在启动服务时都需要这种状态。它会根据状态下载必要的文件......当使用状态A版本1启动它时，状态很可能每个月都会更新。当发生这种情况时，重要的是让所有依赖于状态A的微服务升级（数据库，内存状态，......）。
我目前解决此问题的方法只是使用事件，当状态更改可以订阅事件并相应地迁移/升级时需要更新的微服务。我面临的唯一问题是，虽然服务正在升级，但它应该仍然有效。所以不知怎的，我应该首先复制服务，让重复升级，当升级成功时，关闭原始服务。因此，使用的业务流程服务必须能够创建重复项（包括复制状态）。
我的问题是，我的问题是否有解决方案（如果是的话，哪些问题）？我已经研究过Netflix Conductor（它的工作流和事件似乎很有前景），Amazon SWF，Marathon和Kubernetes，但它们都没有解决我的问题。
最重要的是，现有解决方案不应绑定到特定平台（Azure，GCE，...）。
答案 0 :(得分：1)
对于不间断的升级，您应该使用提供服务的节点集群并执行滚动更新，一次取出一个节点，升级它，剩下的节点继续进行维护。我建议查看虚拟服务的概念（例如在kubernetes）和rolling updates。
对于诱导状态，我建议查看容器初始化机制。例如，在docker中，您可以使用entrypoint scripts或在kubernetes中使用init containers的概念。您应该注意到，今天存在将服务和状态分离的趋势，这意味着状态保存在与服务部署分离的DB中，允许将服务视为无状态组件，可以在不丢失状态的情况下进行替换（给定服务和所需状态之间的接口没有改变）。这在服务变更频繁且数据库设计频率较低的情况下很好。
另一个注意事项 - 我不确定在命名空间中表示状态是个好主意。通常，命名空间是用于组织（代码，服务等）的静态构造，旨在实现稳定性。