本文讨论的主题是高性能,主要思路是围绕快展开,这么设计为什么会快?
架构设计:微服务架构
第一个设计是应用架构的设计,下图是单体架构与微服务架构的一个对比图。接下来的设计思路大家可以对比这个图来看
- **针对性的资源分配:**假设有10台服务器,单体架构下资源是共享的,每台服务器的资源是订单,会员,积分等模块共享的。我们知道订单模块是电商中的核心应用,完全可以把更多的资源倾斜给订单域,比如订单6机器,会员2机器,积分域2机器。获得的资源更多了,性能自然就会高。
- 模块化与独立性:这里我们用线程池来举例,只是举例哈,主要为了好理解。大家都知道线程池的线程数可能跟应用是CPU密集型还是IO密集型有关,假设订单是IO密集型,积分是CPU密集型,那么单体应用的话要么IO密集,要么CPU密集,但是微服务相对独立,可以但对针对订单优化成IO密集型应用,积分优化成CPU密集型。这里主要想表达的是,独立后可以针对性的优化,以达到每个模块最好的性能。
负载均衡
负载均衡的主要作用就是分发请求,那么均匀分发请求就很重要了。如下图,假设用户发起300请求,理想情况是3台机器,每台机器处理100请求。但是如果出现下面的情况请求是290,5,5分布的话就不能完全使用所有机器的全部性能。
因此负载均衡通过合理的分发请求,以达到资源的最大利用,从而可以提高性能。
数据一致性方案选择
这里很多人理解上有偏差,有人可能觉得数据一致性与高性能没有关系,实际这里是给系统中的一致性场景设计一种方案。设计方案的不同会导致系统应能的不同。简单说下强一致性跟最终一致性,只要能理解是如何影响性能的即可。
强一致性的实现方案比如分布式事务,需要任何时候数据都保证一致。ACID属性的保证通常需要更复杂的事务管理机制,这可能会增加延迟并影响性能。
最终一致性的方案允许短时间数据不一致,最终一致可以通过本地消息表等方案来实现,这可以更快响应请求,从而提高性能。
容错处理:双机互备
双机房是主流的容错方案。那么容错跟性能有什么关系呢?这里其实是间接影响了性能,当服务出现了问题,如果立即切换到另一个机房,缩短了服务不可用的时间,是否可以等同于提高了性能。
消息队列
在系统中引入消息队列,可以大大提高系统的性能,主要体现在以下几个方面
- 解耦系统中的不同组件,使得它们可以独立运行。
- 提供异步处理能力,从而提高系统的响应时间和吞吐量。
- 支持流量削峰,在高峰期吸收大量请求,平滑处理负载。
缓存
缓存是基于内存的,解决是数据库的IO耗时,常见的缓存有redis,也有本地缓存等。由于少了数据库IO的这部分消耗,所以使用缓存可以提高系统的性能。更详细的如下:
- 缓存减轻后端数据库的压力,提高数据读取速度。
- 通过存储频繁访问的数据副本来减少延迟。
- 常见的缓存技术包括Redis、Memcached等。
总结
以上对高性能的设计主要是架构设计与组件相关的选择。提高性能的方式可能还有很多,比如并发编程,增加索引等,但这些更偏向于对具体代码的设计。