支持者说性能成本可以忽略不计，这种权衡带来了可扩展性和正常运行时间等好处。我想知道的是，在真实的世界的场景中，什么时候容器编排是合理的，什么是最好的方法？如此高的流量最常见的问题是什么？（最好是一个技术堆栈的例子）我最近读到，Prime Video通过将架构的一部分改为整体风格，削减了90%的成本。这很难想象，因为我已经容器化了应用程序的一部分，这些应用程序在服务之间接收的请求数量远远不够--所以这更像是一个实践问题。谢谢
真的不是问题，想请教有实践经验的人。
支持者说性能成本可以忽略不计，这种权衡带来了可扩展性和正常运行时间等好处。我想知道的是，在真实的世界的场景中，什么时候容器编排是合理的，什么是最好的方法？如此高的流量最常见的问题是什么？（最好是一个技术堆栈的例子）我最近读到，Prime Video通过将架构的一部分改为整体风格，削减了90%的成本。这很难想象，因为我已经容器化了应用程序的一部分，这些应用程序在服务之间接收的请求数量远远不够--所以这更像是一个实践问题。谢谢
真的不是问题，想请教有实践经验的人。
1条答案
按热度按时间p1iqtdky1#
在应用程序世界中，一切都是一种权衡。系统设计的选择，无论是Monolith还是MicroService方式，都是一个非常特定于项目的决定。
你是正确的黄金视频部分，他们节省了吨美元切换回良好的旧巨石架构。被说成是那么容易吗？不是真的。想象一下，在设计一个能够满足团队所需的大部分关于规模和可用性的需求的单体时，付出了多少努力。
回答你的问题，我认为容器编排的使用/应用在两个主要场景中是合理的。首先，您的应用程序与容器编排必须提供的功能非常匹配。另一个也是最重要的一个是，你或你的团队能够理解和管理复杂的构建和基于编排的工具，比如说Kubernetes。我曾在两宗因缺乏正确认识而导致重大失误的个案中，清楚地提及原因。
最后，这里列出了一些由于容器化带来的开销/挑战：
1.主机和容器之间的抽象会带来额外的管理开销
1.正如Burak所指出的，容器有自己的网络IF。管理这一点比在主机本身上运行应用程序要多一点开销。
1.分布式日志记录，假设容器pod/docker示例根据负载要求打开和关闭。日志记录/日志存档是一项具有挑战性的任务。
希望这能帮上忙。