海量用户同时进行高频拜访对任何平台都是难题，也是行业乐此不疲的钻研方向。但值得庆幸的是，尽管业务场景不同，设计和优化的思维却是万变不离宗。本文将联合业务与高并发零碎设计的核心技术点，对系统架构调优计划进行深度分析。
文章依据 Authing 身份云高级工程师罗杰林，在又拍云 Open Talk 技术沙龙北京站所作主题演讲《亿级流量零碎架构演进之路》整顿而成，现场视频及 PPT 可点击浏览原文查看。
置信大家都批准，互联网发展势头的逐步厉害扭转了咱们很多的生存形式。比方网购、银行转账等业务，不再须要咱们必须线下办理，这极大不便了咱们的生存。这背地当然也对身为互联网从业人员的咱们来说，面临的考验也越来越大，在零碎架构降级上也会倾泻更大的心血。
意识高并发零碎
高并发零碎领有高并发、高性能、高可用，分布式、集群化，安全性等个性。
咱们首先来看一下高并发、高性能、高可用，也就是咱们常常提到的三高零碎。当咱们流量十分大的状况下，咱们肯定要保障这三高。这其中高并发是指要反对很多并发用户，高性能是在高并发的前提下保障优良的性能，高可用则是保证系统在某一节点呈现问题时不会整体宕机且持续继续提供服务。由此可见三高的次要个性则是分布式和集群化，而咱们次要要解决的问题则是安全性。
上图是一些常见的与咱们生存非亲非故的高并发场景。左上电商秒杀是最常见的场景了，去年疫情期间口罩紧缺抢口罩就是这个场景，很多人在一个对立的工夫去点击同一个页面，这个的并发数是特地高的。右上则是抢票，这个大家也很相熟了，特地是春节须要回家的在当地工作的敌人们，必定都是开个抢票软件始终刷给本人抢票的，这种的并发流量特地大。左下则是银行交易系统，咱们所有的线上、线下扫码其实都须要通过银行零碎，这就让它的日交易量极大。最初是 Authing 身份证，咱们次要是给用户做整套的身份认证和用户管理体系，这个体系让开发者防止了反复构建身份的操作，缩小了开发者编写的代码，进步他们的效率。以下图作为例子：
图中展现的是咱们的外围组件，外表上看是一个简略的登录框，也就是用户认证界面，然而其背地有一个宏大的由用户体系、管理体系、认证体系等一系列服务组成的后盾撑持。只管用户只是进行了用户名和明码的输出，然而咱们要思考到的不仅仅是用户的平安认证、多种登录形式，还有很多用户同时认证时要如何解决等等多种事项。除此之外，咱们还须要思考到如何让包含私有化用户在内的多种类型的客户实现高可用和疾速部署，实现疾速集成。
如果有做高并发的敌人，对于 CAP 实践肯定不生疏。它的次要观点是分布式系统无奈同时满足三个，只可能满足其中两个。即分布式系统要么满足 CA，要么满足 CP，但无奈同时满足 CAP。其中的意思是说如果满足了可用性和分区的容错性，那可能意味着要就义一致性，进而达到最终的数据一致性。它是通知咱们要作出取舍。
从单体利用架构说起
上图中示意的单体利用构架是晚期罕用的模式。晚期因为人手紧缺通常会将 Web 和 Server 一起开发再一起部署，之后和数据库连在一起就能够失常提供服务。这么做的长处是保护简略，然而迭代比拟麻烦。
当初前后端拆散后，咱们通常把 Web 和 Server 离开为两个服务部署，为疾速迭代提供了便当。如果咱们有一个 Server 须要修复，咱们能够独自对这个服务进行代码批改和部署，而后疾速上线服务。然而它的毛病是随着业务的增多，Server 蕴含的内容也越来越多，这会让它耦合很深进而导致服务变慢。这一点我深有体会，多年前我有个敌人架构出了问题，有段时间每到周末他会买一袋瓜子来我家一起推敲。为什么要买一袋瓜子呢？因为耦合的太深了，服务启动要 5 分钟，改一个货色又要等 5 分钟重启，所以咱们嗑着瓜子聊天期待。
相似下面提到的依赖简单、臃肿繁冗是单体利用会遇到的一个问题，除此之外单体利用还有以下问题：
- 单点瓶颈
- 稳固差
- 扩展性差
- 业务模型缺失
- 新业务扩大差
- 业务流程根底能力不足
- 前后端耦合重大
- API 芜杂难保护
既然痛点如此显著，那么如何去优化就很重要。不过在谈这个问题之前须要思考一个新问题——CPU 越多性能就会越好吗？
大多数状况是这样的，因为 CPU 能够进步运算速度。但这不是相对的，如果咱们的程序里有很多锁的概念，那就无奈体现出多线程的多核性。那可能 CPU 的多少就不会有显著效果。个别遇到这种状况，许多公司会思考把服务拆开。这就波及到老本问题，也就是说减少 CPU 并不是最优解，咱们还是须要思考如何去优化锁。不过思考具体优化前咱们能够先理解下池化技术。
上图是池化技术的抽象概念，个别获取连贯以及线程用完后都会放入资源池资源池。同时咱们还须要有以下四个概念：连接池、线程池、常量池、内存池。
个别用连接池较多，因为零碎之间的调用、申请内部服务时都会通过申请连贯来进行。已经咱们应用的是短连贯，然而因为 HTTP 的每次连贯都须要反复建设和敞开连贯的过程，十分耗时，所以当初开始应用连接池。它每次申请完后创立的连贯都是反复可用的，十分有助于节俭开销。同时咱们的工作最初都是须要拆出来的，而那些拆出来的异步工作则都搁置在线程池内进行。常量池和内存池的概念是想通的，咱们会申请一块大的内存复用。
理解池化技术后，咱们回到具体优化。
利用架构优化
Web Server 优化
首先来看一下 Web Server 的优化，它次要通过代码优化、热点缓存、算法优化等等步骤实现。
第一步是代码优化，将不合理的代码进行优化。比方查问接口通常都会查问很多内容，使得运算迟缓，这就须要优先进行优化。
第二步是热点缓存，将全副的热点数据进行缓存从而尽可能减少数据库的操作。比方 Authing 身份认证在拿到 token 后不可能每次进行数据库运算，这样 QPS 会十分慢，咱们能够通过将热点数据全副缓存来进步 QPS。
第三步是算法优化，因为咱们的业务通常都非常复杂，所以这个概念十分宽泛。比方查问一个列表，是须要一次性列出全副列表还是在内存中计算结束后将后果返回给前端呢？这就须要针对不同的业务场景进行优化，从而进步性能。
独自部署
实现单体利用优化后，如果这些服务都部署在同一台服务器上，那可能会呈现 CPU 和内存被占用的状况。这时候咱们能够把 Web、以及加载完缓存的应用程序拎进去别离部署到一个独自服务器上。同时将动态资源全副存储在 CDN 上，通过就近拜访放慢页面加载速度。通过这些形式，让咱们的 Auting 达到了 50 毫秒内响应的需要。独自部署的形式也非常适合零碎之间的需要，无论你是什么业务场景，如果须要晋升响应速度，那大家能够思考这个形式。
垂直拆分
之后咱们须要对业务进行拆分。业务拆分有以下三种形式：
- 依照业务场景拆分，比方将用户、订单、账务进拆分。
- 依照业务是同步还是异步进拆分，这样做的益处是能够很好管制异步流量，不让它影响咱们的外围服务运行。
- 依照模型拆分，因为业务拆分次要是为了解决零碎之间耦合重大依懒性问题，为了前期尽量减少零碎间的以来，所以后期的模型肯定要尽可能的建设好。
在实现零碎拆分后，咱们须要评判优化后的零碎能承载多少业务量，优化了多少。那么我就须要对它进行一次压测。压测会波及到大家都有所理解的木桶实践，咱们将零碎比作一个木桶，那么木桶可能承载多少水量取决于最低的那块木板。所以压测时咱们不须要关注那些占用资源少的局部，咱们要关怀那些高的曾经达到了零碎瓶颈的局部。通过这部分来查找咱们零碎的潜在问题点。
横向拆分
在咱们将服务进行垂直拆分后，随着申请量逐步增多可能还是无奈满足需要。这时候咱们能够将零碎进行程度拆分，而后进行程度扩容，一个不够就减少两个甚至更多。同时通过负载平衡的服务器将申请量平均分给这些程度节点。通常咱们会抉择应用 NG 来作负载平衡服务器。
上图是咱们的负载平衡服务器。负载平衡上面会有很多网关零碎，咱们看到两头有一个 Nginx 集群。咱们都晓得 Nginx 可能接受的并发量十分大，所以流量小的时候不须要这个集群，须要它的时候肯定是并发量十分大的状况。当你的并发量极大，到 Nginx 集群都无奈接受的时候，咱们最好不要在它的集群后面再放一层 Nginx，因为成果并不显著。同时我集体也不太倡议大家抉择 F5，因为 F5 是一个硬件，它的老本比拟大。我集体倡议大家抉择 LVS，它是 Linux 上面的一个虚构服务，如果配置的好，它的性能齐全比得上 F5。
说完了负载平衡，咱们回到程度拆分。
在进行程度拆分时咱们不能疏忽缓存问题。在单机模式下缓存都是本地缓存，而当咱们成为分布式后，如果有一个服务器拿到 token 并存到本地，另一个服务器就会因为没有拿到而无奈通信。因而咱们引入分布式缓存，比方将缓存放到 Redis 这种分布式缓存里，让所有利用都申请 Redis 拿缓存。
当咱们程度拆分后，还须要关注分布式 ID。因为单体时候生成 ID 的办法可能不适用于分布式服务。以工夫戳举例，以前在单体时有，申请咱们就生成一个 ID，这是有唯一性的。在分布式状况下多个服务器收到申请可能会生成反复 ID，做不到唯一性。所以咱们须要独自做一个 ID 服务来生成 ID。
配置核心
在咱们把服务进行了程度和垂直的拆分后，如何让配置对立同步的配置到每一个服务就成了问题。最好的方法就是当咱们批改配置后，让所有服务都同时感知到这个更改，而后本人利用并配置。因而咱们引入了配置核心。
上图是配置核心的大体流程，目前比拟风行的配置核心计划有两个是，一个是阿里开源的 Nacos，另一个是 Spring Cloud 组建的 Spring Cloud config，感兴趣的敌人们能够理解一下。
接下来咱们具体看一下上图。这其中 Server 是寄存咱们配置的控制台。个别开发者会在控制台通过 API 批改配置，批改后的配置能够长久搁置在 Mysql 或其余数据库内。Client 蕴含了咱们所有的利用，在它外面会有一个监听 Server 内是否有配置更改的监听，当有配置更改时则去获取这个配置，这样所有的利用就能够在前端更新后及时更新了。同时为了避免 App 在获取更新时因为网络问题而获取失败的状况，咱们会在本地做一个快照，当网络呈现问题时，App 能够降级到本地获取文件。
数据库拆分
咱们实现了零碎的拆分，做好了负载平衡，并实现了配置核心。在申请量不太大的状况下，咱们其实曾经实现了零碎的优化。等到前期业务持续扩张时，咱们遇到的瓶颈就不再是零碎，而是数据库了。那么要如何解决这个问题呢？
第一种形式是主从复制与读写拆散。读写拆散能够解决数据读写全都在一个库上的问题，通过将主从库拆分为 master 和 slave，让写这一环节全副由 master 来解决，将写的压力摊派从而进步数据库性能。之后随着业务量的持续增大，独自的主从复制曾经无奈满足咱们的需要时，咱们通过第二种形式来解决。
第二种形式是进行垂直拆分。垂直拆分的概念和业务的拆分类似，咱们依据服务将数据库拆分为 Users、Orders、Apps 等等，让每一个服务都领有本人的数据库，防止对立申请从而晋升并发性。随同业务量的持续增长，即使是独自的库也会达到瓶颈，这时咱们就须要用到第三种形式。
第三种形式是程度拆分。比方咱们将 Users 这个数据库内的表进一步拆分为 Users1，Users2，Users3 等等多个表。要实现这个拆分咱们须要思考，面对多个表咱们在查问时要如何去做的问题。这时咱们须要依照咱们的具体业务来判断。比方查问用户，咱们能够依据用户 ID，将 ID 拆分分片，而后应用哈希算法让他们对立在肯定范畴内。之后咱们每次拿到 Users 就通过哈希来计算具体在哪一片并疾速到达相应地位。Auting 多租户的设计就用到了拆分的概念，如下图所示。
服务限流
等到业务量多到肯定水平后咱们必定会波及到服务限流，这是一个变相的降级策略。尽管咱们的现实都是零碎可能接受越来越多的用户越来越多的量，然而因为资源总是无限的，所以你必须要进行限度。
申请回绝
服务限流有两种次要算法，漏桶算法与令牌桶算法。咱们能够看一下上图，它画的比拟形象。漏桶算法中咱们能够将流量设想成一杯水，在水流流出的中央进行限度，无论水流流入的速度有多快，然而流出速度是一样的。令牌桶则是建设一个发放令牌的工作，让每一个申请进入前都须要先拿到令牌，如果申请速度过快令牌不够用时就采取对应的限流策略。除去这两种算法，个别还会用到大家都很相熟的计数器算法，感兴趣的敌人也能够去自行理解一下，这里咱们就不细谈了。
这几种算法其实实质上都是在流量适量的时候，回绝适量的局部的申请。而除去这种回绝式的策略，咱们还有一种排队的策略。
音讯队列
当咱们的业务有无奈限流、回绝的状况存在时，咱们就须要用到队列音讯。
如图所示，音讯队列的次要概念是生产者会将音讯放入队列中，由消费者从队列中获取音讯并解决。咱们通常应用 MQ、Redis、Kafka 来做音讯队列。队列负责解决公布 / 订阅和客户端推拉两个问题，生产者负责解决以下问题：
- 缓冲：为入口处过大的流量设置缓冲
- 削峰：与缓冲的成果相似
- 零碎解耦：如果两个服务没有依赖调用关系，能够通过音讯队列进行解耦
- 异步通信
- 扩大：基于音讯队列能够做很多监听者进行监听
服务熔断
在业务失常提供服务时，咱们可能会遇到下图这种状况：
服务 A、B 别离调用服务 C、D，而这两者则都会调用服务 E，一旦服务 E 挂掉就会因为申请沉积而拖垮后面的全副服务。这个景象咱们个别称之为服务雪崩。
而为了防止这个状况的产生，咱们引入了服务熔断的概念，让它起到一个保险丝的作用。当服务 E 的失败量达到肯定水平后，下一个申请就不会让服务 E 持续解决，而是间接返回失败信息，防止持续调用服务 E 的申请沉积。
简略来讲这是一种服务降级，通常的服务降级还有以下几种：
- 页面降级：可视化界面禁用点击按钮、调整动态页面
- 提早服务：如定时工作提早解决、音讯入 MQ 后提早解决
- 写降级：间接禁止相干写操作的服务申请
- 读降级：间接禁止相干读的服务申请
- 缓存降级：应用缓存形式来降级局部读频繁的服务接口
- 停服务：敞开不重要的性能，为外围服务让出资源
压测
上图就是咱们具体压测要关注的货色。首先咱们要晓得压测其实是一个闭环，因为咱们可能会须要反复这个流程很屡次，一直地反复发现问题、解决问题、验证是否失效、发现新问题这个过程，直到最终达到咱们的压测指标。
在压测开始前咱们会制订压测指标，而后根据指标来筹备环境。压测模型能够是线上的，也能够是线下。个别线下思考到老本问题，因而会抉择单机或小集群来进行，这可能让后果不太精准，所以通常大家都抉择在线上或者机房来进行压测，数据更精准。在压测过程中咱们会发现新的问题，而后解决它，并验证后果直到达到压测指标。
在压测的过程中咱们须要关注以下几点。首先是 QPS，即每秒查问量。它和 TPS 的区别在于，TPS 有事务的概念，须要实现事务才算一次申请。而 QPS 没有这个概念，它只有查问到后果就算做一次申请。其次是 RT（响应工夫），这个须要咱们重点关注，而且越是高并发的零碎，RT 越重要。之后在压测中咱们须要关注零碎到底能承载多大的并发数和吞吐量。成功率则是指在压测过程中，当压力越来越大的时候咱们的业务是否能依照原打算执行并失去既定后果。GC 则是指垃圾回收，这也是个很大的问题，因为如果咱们代码写的不好，那么随着压力的增大 GC 逐步频繁最终会导致系统进展。
之后则是硬件方面，须要咱们关注 CPU、内存、网络、I/O 的占有率，有一种任意一项卡主就有可能导致一个零碎瓶颈。最初是数据库，这里暂不开展细讲。
日志
在压测过程中产生的问题咱们要如何能力晓得呢？那就要依附日志了，它让零碎变得可视化，不便咱们发现问题的本源。
那日志要如何做呢？这里次要是依附埋点来实现，比方通过埋点申请进入每一个零碎、每一层的工夫和响应工夫，而后通过这两个时间差看出零碎的耗时。由此能够看出只有埋点清晰，能力精准发现问题的所在。
上图是一个比拟通用的日志解决计划，每一个服务产生的日志都是通过 Filbeat 收集到 Kafka，而后到 Logstach，最初到 ElasticSearch。其中 Kibana 是一个可视化界面，不便咱们剖析日志。
上图是 Auting 的日志和监控零碎。两头是 K8S 集群，右边是业务上的音讯队列，左边则是咱们的监控零碎。监控零碎咱们只有是应用 Grafana 依据业务报警，比方咱们会配置当成功率低于多少时就报警的状况。次要的日志零碎则是应用 logstash 抽取 log 文件到 ES 内应用 Kibana 查看。
最初，我想说的是所有的高可用零碎肯定不能遗记一个外围概念，那就是异地多活。举例来讲就是咱们须要在多地备署多个机房，领有多地备份和多地容灾。上图是我对上述全副的利用架构优化进行的总结，心愿可能为大家提供参考，谢谢。
举荐浏览
go-zero：开箱即用的微服务框架
开箱即用的微服务框架 Go-zero（进阶篇）