服务端从零到千万日活架构演变2018.04.17 11:48
1.互联网公司业务发展初期，没有较大流量，每日新增用户较少，技术团队核心点还是放在快速版本迭代，调研市场，开发新功能，以及配合一些活动、推广吸引新用户。所以业务初期，技术选型也比较简单。
对APP或WEB端来说，流量直接打到1台或多台ECS对应API，基于不同的业务场景，API会请求对应Nosql/缓存，或直接落到DB。
2.随着公司业务不断成型，用户的一步步累计，日活已经打到几十万甚至百万级别，初期的技术选型已经无法满足需求，ES及后端资源可能会频繁报警，这个时候就需要对已有的业务模型升级改造，由单机过渡到集群。
前端机会有SLB下的一组或多组ECS构成，SLB负责均衡外部流量，打到后端不同机器。对应的后端资源也会是主从集群模式，均衡单台CPU或内存过高而造成服务器无法响应。
除了资源的集群化，对应的业务也需要进行梳理改造，比如DB慢查，缓存、NoSQL滥用等等。
除此之外还要建立API及资源的安全化，比如API签名、加密，存储资源的有效期等等。
此阶段的主要任务是资源的合理化，减少对容易造成系统瓶颈资源的依赖，优化原有业务并制定新的开发规范，完善资源监控等等。
3.等到公司业务已经相对成熟，日活达到千万级别，市场良性循环建立，用户留存及新增用户都比较可观，这个时候架构升级就会偏向各个模块稳定性，后端各个模块会服务化，即微服务架构。
每个微服务模块相对隔离，有自己独立的一套资源（SLB, NOSQL, DB等）,各个模块之间不会有过多耦合，最上层API会依据对应业务场景，组装或调用不同微服务模块。
此阶段的主要任务是保障可控，可监控、可扩展，减少模块之间相互依赖（包括逻辑依赖与资源依赖）。
各个微服务模块相对稳定之后，架构就要考虑平台化，比如账户体系，已经不单单是针对单一应用，要考虑SSO，OAuth等。媒资库也要考虑多端资源聚合等。
没有一成不变的架构，只有不断探索、优化，适当尝试新技术，才能打造一个稳定可靠的平台。
相关文章
<< 上一篇 LNMP知识结构 后端资源常见的使用优化 下一篇 >>
- 正在加载用户留言，请稍后~