深入理解微服务中的高并发、高性能、高可用及处理方式
作者：yuhuofei2021
前言
首先要明确的一个概念是： 高并发是根因，而高性能和高可用是结果。
通俗点来说，就是指为了解决高并发这一现象，怎么做，才能保证系统的高性能和高可用？
系统在巨大的流量洪峰（即指高并发场景）冲击下，依然能高效、稳定、正常地（即指高性能、高可用）对外提供服务，这是系统设计的主要目标之一。
具体的指标定义，如：高并发方面要求 QPS（Queries Per Second，每秒查询率） 大于 10 万，高性能方面要求请求延迟小于 100 ms，高可用方面要高于 99.99%。
1. 高并发
高并发问题：如果百万级别、千万级别甚至上亿级别的访问请求同时到来，系统怎么快速处理这些请求且能保证系统不崩溃？
基于上面的问题，从请求入口开始分析处理一个请求要用到哪些策略或者技术、方式。
1.1 负载均衡
当请求到来时，给到哪个服务去处理？这里涉及到请求的分发问题，采用负载均衡的方式处理，那么其对应的应用部署方式就得是集群化部署了。
1.2 池化技术
处理请求，由于请求多，做阻塞式处理肯定不行，因此采用多线程处理。
而多线程处理时如果涉及顺序问题或者一致性问题，要考虑对资源加锁处理。
线程的创建，需要消耗时间、消耗内存、消耗 CPU ，总结就是有开销，特别是大量创建线程时，开销更大；因此为了解决这个问题，用到池化技术。
池化技术包括：线程池、连接池、内存池、对象池、协程池、进程池等
1.3 流量过滤
做好前置校验，对于非法的、不符合要求的请求，设计好过滤器进行过滤，在进行真正的业务逻辑处理之前，先对流量过滤一轮，减少并发压力。
过滤器：设计一套自己的规则，对过来的请求进行校验（如校验IP、校验请求参数是否合法等），如果不符合要求，直接拒绝，不进行后面的处理。
2. 高性能
系统性能不好，直接导致的问题就是处理请求耗时长，用户等待时间长，用户体验差。
系统性能影响的因素：
- 用户网络环境
- 请求/响应的数据包大小
- 业务系统 CPU、内存、磁盘等性能
- 业务链路的长度
- 关系方系统的性能
- 处理逻辑的代码实现是否高效… 等等
怎么提高系统的性能？
2.1 使用缓存
高并发场景下，对于查询操作，每次都去查数据库，会给数据库造成很大压力，导致性能下降，严重的直接就宕机了，所以这是要避免的，需要引入缓存，比如用 Redis 、MemCache去做缓存处理。
查询的时候，先去缓存中读，如果有结果就直接返回，没有再去数据库查，减少直接访问数据库的次数，并且读缓存的效率是比读数据库要高的。
2.2 磁盘问题处理
实际开发中，我们经常会在一些关键的地方，写上日志的打印语句，方便定位并排查问题。
不打日志的人，不是好人，绝非善类，十有八九是个坑爹的货，机智的你要知道速速远离。
我们打印出来的日志，最终还是会写到磁盘上保存起来，这里就涉及到了磁盘的 IO 读写问题。
不仅仅是写日志，包括其它涉及直接读或者写磁盘上文件的操作，都会有相同的问题。
磁盘读写的效率肯定是低于 CPU 或者 内存的处理效率的，而且磁盘本身也是有性能的问题存在。
所以可以这么处理：
- 磁盘升级，选用读写性能更好的磁盘，这里是硬件层次的处理
- 在写文件到磁盘上时，可以考虑先写到内存上，给内存设定一个阈值，当达到阈值时再批量将内存上的文件，写到磁盘上
3. 高可用
系统的高可用，更多的是从架构和部署方式去着手解决。
例如一个单体系统，所有业务模块都放到同一个系统中，当某一个模块坏掉，会导致整个系统坏掉，无法对外提供正常的服务，这就是不可用。
如果是微服务系统，每个模块都是独立的小系统，所有小系统共同组成一个微服务系统对外提供服务，一个小系统坏掉，并不会影响到其它小系统正常运行，而整体依旧可以对外提供服务，可用性比单体的更高。
保证系统可用性的策略或者方式，大致有下面这么些：
3.1 采用微服务架构
利用微服务架构，分散能力，使得各个模块独立成为一个小系统，降低系统间的耦合性，提高系统对外提供正常服务的能力。
3.2 采用分布式+集群部署
在高并发场景下，一个服务的部署，不应该只部署在一台服务器上，起码 3 台以上，这样，一台服务器宕机了，还有另外的服务器能正常使用并对外服务，这样就用到了集群的部署方式。
而采用微服务架构，也不应该把每个独立的小系统都部署在同一台服务器上，一个小系统就是一台服务器，这就使用了分布式部署。
将上面的两种部署方式结合起来用，先做分布式部署再为每个小系统拓展成为一个集群，就产生了分布式+集群部署。
3.3 同城双活、异地多活
这里是做灾备考虑，例如当前放置服务器的机房，由于温度过高，着火了，所有服务器都被烧掉，面对这样的情况，前面的架构设计得再好也无济于事。
基于上面可能存在的情况，就要考虑做同城双活或者异地多活了。
简单来说，就是多建几个同样的机房，并且这些机房分布在不同的地理位置，这样一个机房被烧掉了，另外的还能用，依旧保证了可用性。
3.4 主从切换
对于需要存储数据的应用，例如 Redis 、Mysql 等，做好主从复制，做好一主多从的设计和考虑，当主节点出问题时，从节点自动升级为新的主节点，对外服务。
3.5 熔断限流
熔断与限流，二者的目的都是提供过载保护，保证系统不至于崩溃，无法使用。
这里的过载保护，是指负载超过系统的承载能力时，系统需要自动采取保护措施，确保自身不被压垮、崩溃。
熔断：在系统濒临崩溃时，立即中断服务，停止所有请求的处理，保障系统稳定避免崩溃。类似于电器中的“保险丝”，当电流过大的时候，“保险丝”会先被烧掉，断开电流，以免电路过热烧毁电器引起火灾。
限流：原理跟熔断有点类似，都是通过判断某个条件来确定是否执行某个策略。
熔断与限流的区别：熔断，触发过载保护，该节点会暂停服务，直到恢复；限流，只处理自己能力范围之内的请求，超出范围的请求会被限流，并不会暂停服务。
到此这篇关于深入理解Java中的高并发、高性能、高可用及处理方式的文章就介绍到这了,更多相关Java高并发、高性能、高可用内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！