本文探讨如何使用大规格服务器+K8s方案简化新项目成本评估与部署，解决百万DAU社交App后端服务挑战。通过合理选择服务器规格，解决资源利用率低的问题，同时介绍微博在实施此方案时遇到的可用性问题和快速扩容策略，以及针对新挑战的优化措施，如绑核策略和调用链路优化。
近些年，各家公司都在不断推出各种新的 App，百万 DAU 成为各种 App 的最基本目标。本文将详解如何通过大规格服务器 +K8s 的方案简化这些新项目的成本评估、服务部署等管理工作，并在流量增长时进行快速扩容。同时，本文还介绍了微博核心业务采用此方案部署时遇到的问题以及对应的解决方案。
问题与挑战
以一个常见的社交 App 后端服务为例，如果采用主流微服务架构进行设计，通常会包含用户、关系、内容、提醒、消息等多个模块；每个模块又会分别包含各自的 Web 接口服务、内部 RPC 服务、队列处理机等几部分；同时为了保证高可用，通常每个模块还需要部署 2 个及以上的实例，算下来仅部署上述列出的应用服务就超过 30 多个实例。而对于依赖的数据库和缓存，甚至每个业务功能都需要部署独立的实例，若再考虑读写分离、预留分库分表等，则 App 上线前需要部署的数据库和缓存实例可能多达上百个。
（常见的社交 App 后端架构）
对于上述这样一个典型的 App，如果采用传统的部署模式，则需要使用至少数十台服务器才能满足部署数十个应用服务实例以及上百个数据库和缓存实
订阅专栏 解锁全文
扫一扫
818
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
