一、内容分析
4.1 硬件的扩展+微服务的拆分
在互联网早期的时候，单体架构就足以支撑起日常的业务需求，大家的所有业务服务都在一个项目里，部署在一台物理机器上。
所有的业务包括你的交易系统、会员信息、库存、商品等等都夹杂在一起，当流量一旦起来之后，单体架构的问题就暴露出来了，机器挂了所有的业务全部无法使用了。
于是，集群架构的架构开始出现，单机无法抗住的压力，最简单的办法就是水平拓展横向扩容了，
这样，通过负载均衡把压力流量分摊到不同的机器上，暂时是解决了单点导致服务不可用的问题。
但是随着业务的发展，在一个项目里维护所有的业务场景使开发和代码维护变得越来越困难，
一个简单的需求改动都需要发布整个服务，代码的合并冲突也会变得越来越频繁，同时线上故障出现的可能性越大。微服务的架构模式就诞生了。
把每个独立的业务拆分开独立部署，开发和维护的成本降低，集群能承受的压力也提高了，再也不会出现一个小小的改动点需要牵一发而动全身了。
以上的点从高并发的角度而言，似乎都可以归类为通过服务拆分和集群物理机器的扩展提高了整体的系统抗压能力，那么，随之拆分而带来的问题也就是高并发系统需要解决的问题。
4.2 高性能 RPC
微服务化的拆分带来的好处和便利性是显而易见的，但是与此同时各个微服务之间的通信就需要考虑了。
传统HTTP的通信方式性能首先并不太好，大量的请求头之类无效的信息是对性能的浪费，这时候就需要引入诸如Dubbo类的RPC框架
。
有小伙伴进行对比测试，Dubbo RPC的性能，是Feign RPC的性能10倍。
我们假设原来来自客户端的QPS是9000的话，那么通过负载均衡策略分散到每台机器就是3000，而Feign HTTP RPC 改为 Dubbo RPC 之后，接口的耗时缩短了，单体服务和整体的QPS就提升了。
而RPC框架本身一般都自带负载均衡、熔断降级的机制，可以更好的维护整个系统的高可用性。
那么说完RPC，作为基本上国内普遍的选择Dubbo的一些基本原理就是接下来的问题。
4.3 消息队列消峰解耦
对于MQ的作用大家都应该很了解了，主要功能：
- 削峰填谷、解耦。
- 同步转异步的方式，可以降低微服务之间的耦合。
对于一些不需要同步执行的接口，可以通过引入消息队列的方式异步执行以提高接口响应时间。在交易完成之后需要扣库存，然后可能需要给会员发放积分，本质上，发积分的动作应该属于履约服务，对实时性的要求也不高，我们只要保证最终一致性也就是能履约成功就行了。
对于这种同类性质的请求就可以走MQ异步，也就提高了系统抗压能力了。
4.4 三级缓存架构
缓存作为高性能的代表，在某些特殊业务可能承担90%以上的热点流量。
对于一些活动比如秒杀这种并发QPS可能几十万的场景，引入缓存事先预热可以大幅降低对数据库的压力，10万的QPS对于单机的数据库来说可能就挂了，但是对于如redis这样的缓存来说就完全不是问题。
以秒杀系统举例，活动预热商品信息可以提前缓存提供查询服务，库存数据可以提前缓存，下单流程可以完全走缓存扣减，秒杀结束后再异步写入数据库，数据库承担的压力就小的太多了。
4.5 数据库分库分表
对于整个系统而言，最终所有的流量的查询和写入都落在数据库上，数据库是支撑系统高并发能力的核心。
怎么降低数据库的压力，提升数据库的性能是支撑高并发的基石。主要的方式就是通过读写分离和分库分表来解决这个问题。
对于整个系统而言，流量应该是一个漏斗的形式。比如我们的日活用户DAU有20万，实际可能每天来到提单页的用户只有3万QPS，最终转化到下单支付成功的QPS只有1万。
那么对于系统来说读是大于写的，这时候可以通过读写分离的方式来降低数据库的压力。
读写分离也就相当于数据库集群的方式降低了单节点的压力。而面对数据的急剧增长，原来的单库单表的存储方式已经无法支撑整个业务的发展，这时候就需要对数据库进行分库分表了。
针对微服务而言垂直的分库本身已经是做过的，剩下大部分都是分表的方案了。
二、粉丝福利
- 我根据我从小白到架构师多年的学习经验整理出来了一份50W字面试解析文档、简历模板、学习路线图、java必看学习书籍 、 需要的小伙伴斯我一下，或者评论区扣“求分享”
扫一扫
529
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
