基于容器的云开发状态

大多数应用程序都是有状态的。状态状态是指流媒体服务记住了电影中您离开的地方，即使您切换设备或移动应用程序存储用户的首选项或最近打开的文件。对于应用程序级别的情况，它具有从会话中断中恢复的功能，可以将用户放回到他们离开的地方，而不会丢失数据。
我们来自一个有状态的世界。有状态的应用程序会记住有关状态的信息，这在会话之间是持久的。状态数据存储在某种非易失性机制中，例如物理存储，包括数据库。
输入容器，面临有关国家保留的新挑战和机遇。在容器世界中，我们被教导为无状态的。在容器设计中，包括我曾教过的课程，其思想是使容器作为实例出现，执行其编程要执行的操作，并在不保持状态的情况下消失。
如果确实可以处理来自某些外部来源的数据，则将其交给另一个进程或服务处理，然后将其返回到另一个进程，然后再从内存中删除。尽管如此，仍未保持任何状态。 核心问题是，就像几年前发明的那样，容器无法保存状态信息。
没有持久存储的概念，因此无法维护状态。早期我们被告知容器是用于不需要状态保留的操作。 有些人仍然认为在构建基于容器的应用程序时需要无状态，认为这是最干净的方法，而认为有状态意味着以过时的方式进行思考。
但是，对于使用容器的大多数企业开发人员来说，这可能是不可接受的。传统应用程序不是为容器而专门设计的。例如，为容器重构的应用程序通常是有状态的，并且取决于状态数据。
尝试使这些应用程序变为无状态通常是一项艰巨的努力。这就增加了成本和风险，以至于“为什么要把它们搬到集装箱上呢？”此外，即使是针对容器的从头开始构建的容器应用程序也可能会发现，维持状态是一项基本功能，基于业务需求他们无法避免。确实，使应用程序保持应状态的无状态解决方案实际上并不是最干净的方法。
可以说基于容器的应用程序需要支持两个状态模型。好事Kubernetes和其他技术提供了有状态的机制。实际上，考虑到许多基于容器的系统将被联合/分布式的事实，有状态是这些体系结构的核心要求。
我对此有何看法？所有应用程序，包括基于容器的应用程序，都需要为开发人员提供有状态和无状态选择。当大多数开发人员知道现实世界中的情况并非如此时，说无状态应用程序是唯一有效的方法就太局限了。