亿级流量架构,服务器如何扩容?写得太好了

简介: 亿级流量架构,服务器如何扩容?写得太好了

为什么要扩容

说人话就是, 无论如何优化性能,能达到的最大值是一定的,对于一个用户量大的应用,可以对服务器进行各种优化,诸如限流、资源隔离,但是上限还是在那里,这时候就应该改变我们的硬件,例如使用更强的CPU、更大的内存,在前文中举了一个学生食堂打饭的例子,如果学生多了,可以通过令牌桶算法优先给高三学生令牌打饭,但是如果高三的学生还是很多呢?那就只有增加窗口或者食堂的数量,也就是硬件上的扩容。


扩容策略

扩容策略可以分为两种, 一种是对单机整体扩容,也就是机器内部包含CPU、内存、存储设备等,另一种是扩容对应的组件,例如扩内存、扩磁盘、扩CPU。


整机硬件

整机扩容的好处是,有很多专业的服务器硬件供应商,例如IBM、浪潮、DELL、HP等,专业的硬件供应商,他们组装以及搭配方面可能经验更加丰富,另外有些公司会对组件进行一些优化,从而服务器更加稳定,可以类比为买电脑,有的人可能选择买淘宝卖家已经组装好的台式,有的人可能自己买各种硬件自己回家组装,对于一般人而言,选择前者是较为靠谱的选择,因为你即使懂硬件的一些参数,也难保自己搭配的机器是否能发挥各个部件最大性能。


组件

对于一些技术能力强悍的公司,更多的是自己买各种组件组装,这样成本更低,因为节省了组装等费用,并且可以根据业务个性化定制,例如有的公司是计算密集型的,那么主要是更换更强的CPU,有的IO密集型,那么扩容的应该是内存等,有的公司需要存储大量的数据,那么可能扩容的是硬盘等存储设备。


组件包含:

cpu

Intel、Amd ,参考频率、线程数等

网卡

百兆->千兆 -> 万兆

内存

ECC校验

磁盘

SCSI HDD(机械)、HHD(混合)、SATA SSD、PCI-e SSD、 MVMe SSD


AKF拆分原则

对于一个应用,如果单机不足以支撑服务请求,那么可以建立诸如主主、主从等模式的集群:

image.png

这个叫AKF原则X轴扩展,目的是将请求分流在多台机器上,但是多台机器中间要解决数据同步性的问题,越多的机器数据不同步的可能性越大,这也就意味着没法无限整体复制扩容。所以可以整理搜集服务器内热点的业务请求,将业务分离出来,只对热点业务进行扩容,这就是AKF原则的Y轴拆分:

image.png

对业务拆分之后,某个业务还可能太热点,也就是Y轴拆分后水平复制还是不足以支撑数据请求,那么可以将业务的数据进行拆分, 具体来说就是,某个业务的数据,可以放在多个地方,例如在湖北、北京、上海部署机房,各地的人们需要请求数据时,由离得近的服务器提供服务。


拆分扩容后存在的问题

随着业务的增长,系统变得越来越庞大, 根据系统功能拆分成独立而又互通的项目, 比如交易系统、财务系统、生产流程系统、物流系统、网站系统等等,但是分布式结构会存在很多问题。对于这些问题每一个都值得深入探讨,这儿简单的提一下,后面再开篇幅。


  1. 数据共享问题 所有的服务之间数据如何共享同步,这是一个需要考虑的问题,微服务架构中,数据不可能只有一份,没法避免机器损坏等原因造成的数据丢失,多份数据之间如何同步?目前可供参考的解决思路是建立数据中心、搭建数据库集群。


  1. 接口调用问题 不同的服务器之间进行调用遵循远程调用协议RPC


   JAVA RMI:Java远程方法调用,即Java RMI(Java Remote Method Invocation)是Java编程语言里,一种用于实现远程过程调用的应用程序编程接口。 它使客户机上运行的程序可以调用远程服务器上的对象。


   dubbo:提供了面向接口代理的高性能RPC调用


  1. 持久化数据雪崩问题 数据库分库分表 资源隔离 缓存设定数据持久化策略


  1. 高并发问题


缓存:诸如缓存击穿、穿透、雪崩等


数据闭环:为了便于理解,举个例子,对于淘宝而言,有网页版、IOS版、安卓版、还有什么一淘等等,虽然客户端不一样,但是展示的商品信息是相同的,也就是一件商品,无论是哪个端用的数据是一样的,需要一套方案来解决并发下根据相同数据在不同端进行不同展示的问题,这就叫数据闭环。


  1. 数据一致性问题
    这是一个难点,大意就是多个服务器之间数据如何保证一致性,同样的商品在不同客户端服务端端价格应该是一样的, 通常使用分布式锁。



数据库扩容:集群

先简单说一下分布式与集群的区别,这两个词儿经常一起出现,但是意义却有所不同,分布式会缩短单个任务的执行时间来提升工作效率,而集群强调的是提高单位时间内执行操作数的增加来提高效率。更简单的来说,分布式是将步骤分到每台电脑上,不考虑依赖关系,集群方案是指几个任务同时在处理。


单一数据库存储难以满足业务需求时,采取集群的方式,将数据存储在不同的服务器,这可以是主主或者主从,主从中主负责写,从负责读,将与数据库有关的压力进行分解到多台机器上。



相关文章
|
10天前
|
存储 负载均衡 网络协议
杨老师课堂之JavaWeb项目架构之NFS文件服务器
杨老师课堂之JavaWeb项目架构之NFS文件服务器
19 0
|
9天前
|
分布式计算 资源调度 Hadoop
分布式系统详解--架构(Hadoop-克隆服务器)
分布式系统详解--架构(Hadoop-克隆服务器)
19 1
|
10天前
|
监控 安全 网络安全
蓝易云 - 服务器遭受攻击,CPU升高,流量升高,你一般如何处理
以上步骤可以帮助你处理服务器遭受攻击的情况,但具体的方法可能会根据你的网络环境和攻击类型有所不同。
16 2
|
1天前
|
Cloud Native 安全 开发者
云原生架构的演进与实践:从微服务到无服务器计算
本文深入探讨了云原生技术的最新进展,特别关注微服务和无服务器计算模型。通过分析相关研究数据和行业案例,文章揭示了云原生架构如何推动现代应用开发,提升运维效率,并实现资源的最优化配置。文中详细讨论了云原生生态系统中的关键组成部分,包括容器化、自动化管理工具和服务网格,以及它们如何共同促进敏捷性和可扩展性。此外,文章还分析了云原生安全策略的重要性,以及如何在保障安全的同时,保持系统的灵活性和高效性。
|
2天前
|
网络协议 安全 分布式数据库
技术分享:分布式数据库DNS服务器的架构思路
技术分享:分布式数据库DNS服务器的架构思路
7 0
|
29天前
|
资源调度 运维 Cloud Native
云原生架构技术之无服务器技术
当这些BaaS云服务日趋完善时,无服务器技术(Serverless)因为屏蔽了服务器的各种运维复杂度,让开发人员可以将更多精力用于业务逻辑设计与实现,而逐渐成为云原生主流技术之一。
38 5
|
12天前
|
负载均衡 网络协议 安全
|
28天前
|
Serverless 持续交付 测试技术
无服务器应用架构转型
【6月更文挑战第2天】Serverless架构虽新,但其软件生命周期仍遵循传统模式,需确保交付质量。
|
1天前
|
弹性计算 安全 Shell
阿里云ECS安全加固:从访问控制到数据保护的全方位策略
【6月更文挑战第29天】阿里云ECS安全聚焦访问控制、系统加固及数据保护。安全组限定IP和端口访问,密钥对增强SSH登录安全;定期更新补丁,使用防病毒工具;数据备份与加密确保数据安全。多维度策略保障业务安全。
23 15
|
1天前
|
弹性计算
阿里云ECS使用体验
在申请高校学生免费体验阿里云ECS云服务器后的一些使用体验和感受。