【架构师从入门到进阶】第二章:系统衡量指标——第一节:伸缩性、扩展性、安全性

【架构师从入门到进阶】第二章:系统衡量指标------第一节:伸缩性、扩展性、安全性

伸缩性

什么是伸缩性

大型的网站需要面对大量的用户的高并发访问和海量的存储要求,或者说我们的系统从开始用户量很少的情况下到后面用户越来越多,一边是用户的访问量会增大,二是存储的数据量也会增大。这个时候系统就有扩容的需求,所谓的这种伸缩性呢就是指不断的向集群中加入服务器的手段来缓解不断上升的用户访问,和不断增长的数据需求。

什么意思呢?就是说我这个系统扛不住这么多的用户请求,也扛不住这么多的数据的存储,那么我就需要进行扩容了。扩容就需要用到伸缩性,为什么叫伸缩性呢?原来只是一个系统现在多了一个系统,就是说我的这个系统能伸开,某一天流量没有那么高时我的系统要进行缩减,这就是我们的伸缩性

衡量架构伸缩性的主要标准

衡量架构伸缩性的主要标准就是:

  • 是否可以用多台服务器构建集群
  • 是否容易向集群中添加新的服务器
  • 加入新的服务器后是否可以提供和原来的服务器无差别的服务
  • 集群中可容纳的总的服务器的数量是否有限制

伸缩性举例

应用服务器

首先是应用服务器,对应用服务器来说,只要服务器上不保存数据,包括内存里的session都没有(也就是所谓的无状态),那么所有的服务器都是对等的,只跑代码,我们通过使用合适的负载均衡设备就可以向集群中不断的加入机器。

缓存服务器

接下来我们看一下缓存服务器,缓存服务器主要就是当用户来请求的时候减少数据库的压力,给用户提供更快的响应速度。

新加入缓存服务器有可能会使缓存命中失效。比如说,我们原来有一个缓存服务器,所有的用户都在这里面能取到数据,我新加一个缓存服务器之后,这个缓存服务器里是空的,如果某一个请求被分到我这个服务器上,因为里面是空的,什么都没有,那么这时候就会去数据库去取,加了一个缓存服务器反而在这种情况下让用户的响应速度变慢了。

如何让缓存服务器具备伸缩性呢?就是提前加载缓存数据 ,我加服务器的时候要把数据给你加载上;或者做好路由分发的策略

什么意思呢?就是说两种方式:

  • 原来一个缓存服务器里面有数据,我加一个缓存服务器,提前把数据准备好。
  • 还有一种策略就是原来有一个缓存服务器,我新加一个缓存服务器,但是我并不是让所有的请求无差别的到我的这个服务器上,而是一部分一部分的放过来,慢慢的等这边的缓存数据慢慢的预热起来,这样的话系统就能平稳的过渡。

数据库服务器

还有就是数据库服务器。

比如我们拿MySQL举例子,可能有的同学会说MySQL它原生就支持数据复制呀!比如说,主从模式,配个slave of,直接配置它就扩容了。但是这样的话,大家想一想它是扩容吗?它只是做了一个备份而已,并没有对伸缩性的提升。因为扩了一个一模一样的数据库,并且这个数据库还是存储一模一样的数据,那他相当于做了个备份。

如何让数据库也相当于做伸缩了呢?这个时候就需要让数据库存储不一样的数据。既然我扩了一台数据库,那么这台数据库就应该存新的东西。这样的话才能存更多的数据。或者是增量的,就是新的数据库存的是增量的数据。或者是通过某些方法进行分库分表,比如说原来一个大的数据库里有用户数据、订单数据、支付数据、积分数据,然后我加了一台服务器之后,我通过某些方式将用户和订单的数据放在新库里,将支付和积分的数据还在老库进行保留。或者说新开一个业务,新业务的数据都在新库里,不再往老库里去添加,这样的话也算是做了伸缩性。

NoSql数据库

数据库除了关系型数据库之外,还有一些NoSql数据库。由于好多这种NoSql数据库天生就是为了海量数据而生的,因此好多这种NoSql类型的数据库对伸缩性的支持都非常好,可以在人工少参与的情况下做到集群规模的线性伸缩。

扩展性

下一步我们聊扩展性。

什么是扩展性

关于扩展性,不同于其他架构要素关注的这种非功能性需求。什么是非功能性需求呢?就是说TPS、QPS、吞吐量、响应时间这些。网站的扩展性直接关注网站的功能性需求,就是它是针对网站功能的

随着网站的快速发展,功能不断完善,功能不断扩展,如何设计网站的架构使其能够快速响应需求的变化,是网站架构可扩展性的主要目的。就是说我的网站,设计好了这个架构,你在新加功能的时候,我只需要不改动或者少改动 ,就能达到在已有业务的功能上增加新的功能。还有就是各个网站之间是否很少偶合,或者说一个产品的改动,在我的整个架构里,某一个功能模块的改动是否对其他产品产生影响呢,这个也归于扩展性的内容。

如何实现网站的扩展性

那么我们应该如何去做呢?网站的扩展性主要是通过事件驱动架构和分布式架构来实现的。

事件驱动式的架构

事件驱动式的架构,在网站系统中通常会引入消息队列,一个系统模块完成了自己的处理后,如果其他模块还有后续操作,那么封装成消息,把它发布到消息队列当中。消息的处理者也就是消息的消费者,从消息队列中获取消息并进行处理。通过这种方式将消息的生产者和消息的消费者分离开来,可以透明的增加消息的生产者和消息的消费者,这样就实现了扩展性。当我需要实现在原有功能上加一个功能的时候,我不在那上面进行改动,我把一些要素放在消息队列里,然后我加的功能去订阅这个消息,他接着往下做他的业务就可以了。

分布式架构

第二个就是分布式架构。

分布式架构是将业务和可复用的服务分离开来。就是说我们的系统经过长时间的发展,有些业务已经渐渐独立了。比如说订单、用户,这些很成熟的业务独立开发测试部署。比如说最开始是一个特别大的系统,里面包括了用户、订单、积分等等,后来我们想扩展一些功能,这些功能也会用到订单服务,这个时候我们可以将原来的系统进行拆分。系统发展到某一个阶段的时候,我们可以将这个用户拿出来成做成一个用户系统,然后将订单拿出来做成一个订单系统,当我们在扩展新功能的时候它直接调用订单系统就可以,并且这两个系统不需要进行更改,它们之间完全通过api接口进行通信。

安全性

接下来就是安全性。

互联网是开放的,任何人在任何地方都可以访问,我们网站的安全性方面考虑的就是保证网站不受恶意的攻击和访问,保护网站的重要数据不被窃取。衡量网站的安全性主要是看对现存的和潜在的各种攻击与窃取手段是否有可靠的应对策略。

那么我们的应对策略有哪些呢?比如说系统和系统之间api的调用是否安全;还有就是系统的认证体系是否有bug;怎么保证token的敏感信息不外传;怎么正确的验证token;怎么把token发出去之后在我们的后端的服务还能控制token;还有就是我们的系统会不会被爬虫恶意的爬取数据等等。

相关推荐
guoji77882 小时前
Gemini 3.1 Pro 原生多模态架构深度拆解:统一表示、交叉注意力与联合训练
架构
一叶飘零_sweeeet2 小时前
击穿 Kafka 高可用核心:分区副本、ISR 机制与底层原理全链路拆解
分布式·架构·kafka
希望永不加班2 小时前
SpringBoot 核心配置文件:application.yml 与 application.properties
java·spring boot·后端·spring
一叶飘零_sweeeet2 小时前
高可用架构核心:限流熔断降级全解,Sentinel 与 Resilience4j 原理 + 落地实战
架构·sentinel
散峰而望2 小时前
【基础算法】从入门到实战:递归型枚举与回溯剪枝,暴力搜索的初级优化指南
数据结构·c++·后端·算法·机器学习·github·剪枝
小程故事多_802 小时前
抛弃昂贵MCP,拥抱技能+CLI,AI Agent架构的成本革命与性能突围
人工智能·架构·aigc
前端付豪3 小时前
Memory V1:让 AI 记住你的关键信息
前端·后端·llm
毛骗导演3 小时前
@tencent-weixin/openclaw-weixin 插件深度解析(三):CDN 媒体服务深度解析
前端·架构
编码忘我3 小时前
RokcetMq的顺序消费、防丢失、去重
后端