问题描述
在开发一个桌面应用程序时遇到了一个问题。他们的应用程序允许用户从多个平台下载在线数据，并将其集中存储在一个地方。用户的数据非常重要，因此隐私保护是他们的首要考虑因素。为了解决用户的需求，他们决定提供两种选择：桌面应用程序和Web应用程序。然而，将如此大量的数据（每个用户约50GB到1TB）转移到云端的共享数据库是一项繁琐的任务，涉及到服务器的复制、分片、缓存等，以及与大规模数据相关的成本和复杂性。他们考虑使用Docker容器为每个用户维护数据，并将数据存储在AWS的弹性文件系统（EFS）上。每个用户的数据在EFS上以加密形式存储，并在用户成功登录后才解密。每个用户的Docker容器将具有一个小型的SQLite数据库，用于使数据可搜索和索引。未来，容器还可以拥有自己的Elasticsearch数据库以及其他NoSQL或SQL数据库。用户的身份可以使用AWS Cognito或任何分散式身份系统进行管理。另一种方法是为每个用户保留不同的加密SQLite数据库文件，但这样做会带来问题，因为SQLite不支持多线程，无法同时打开同一个SQLite数据库的不同实例。相比之下，使用Docker容器，我们只需要在用户登录时启动Docker容器，这样我们就可以确保只有一个SQLite实例被访问。然而，他们仍然担心这种方法可能存在的漏洞，希望我们能够帮助他们识别出来。
解决方案
请注意以下操作注意版本差异及修改前做好备份。
方案1
根据您的描述，您的问题实际上是一个数据分区问题，您需要在每个客户之间保持一定的隔离性，同时将服务集中托管。您提出了为每个客户实例化一个Docker容器的想法，但我认为这种方法存在一些问题：
1. 容器通常是短暂的，您可以使用Kubernetes中的一些概念来创建每个客户的单例，但是：
– 如果Pod、节点或集群发生故障，可用性可能会受到影响，需要重新调度该Pod。
– 成本可能会相当高，因为每个容器都会消耗一些资源，无论它们是否被使用。
2. 根据您的客户数量，您可能会遇到太多的容器问题：
– 诸如Kubernetes、Docker Swarm和Mesosphere之类的编排器通常设计用于支持大量容器，但是预期的是大量相同的工作负载，而不是大量不同的工作负载。Kubernetes过去曾在部署大量ConfigMaps、Pods和CustomResourceDefinitions时出现过性能下降的情况。
– 尽管每个容器都很轻量级，但它们将消耗系统资源，不仅是内存、CPU，还有TCP/IP池的耗尽。
3. 隔离性 – 容器是隔离工作负载的一种好方法，但并不是绝对可靠的 – 请阅读《容器不是虚拟机》。
如果我要解决您的问题，我倾向于使用Kubernetes作为微服务平台，在多个ReplicaSet上托管您的应用程序，然后在AWS中通过DynamoDB和EFS实现数据存储级别的分区。您已经对数据进行了加密，因此可以确保隔离性。
方案2
另一种方法是使用不同的加密SQLite数据库文件来为不同的用户保留数据。然而，这样做会带来一些问题，因为SQLite不支持多线程，无法同时打开同一个SQLite数据库的不同实例。相比之下，使用Docker容器，我们只需要在用户登录时启动Docker容器，这样我们就可以确保只有一个SQLite实例被访问。
方案3
您还可以考虑使用AWS的其他服务来解决您的问题。例如，您可以使用AWS的ElastiCache来缓存您的数据，以提高性能。您还可以使用AWS的RDS服务来托管您的数据库，并使用AWS的Identity and Access Management（IAM）来管理用户的访问权限。这些服务可以帮助您更好地管理和扩展您的应用程序。
请注意，以上解决方案仅供参考，具体实施方式可能因您的具体需求和环境而有所不同。建议您在实施之前仔细评估和测试这些解决方案，以确保其适用性和可行性。