架构设计
文章平均质量分 93
程序猿加油站
自我评价
从事软件研发10年有余,喜欢钻研技术,擅长软件架构设计,linux负载,go语言开发,php开发!
展开
-
Kong Api Gateway
在微服务的架构中,一个应用可能背拆分许多个小的服务系统,这些小系统可能自成一体,有自己的硬件资源、数据库、框架,甚至连语言都各不相同,这些小系统通常以Restfull API风格的借口提供给前端或者其他系统调用,一个应用可能会被拆分上百上千个API,管理起来极其不变,这个时候出现了API网关,API网关提供了一个统一的入口,将流量转发给对应的后端取得数据后再一次返回,并且在次基础上提供各种认证鉴权流控等等功能让后端专心于自己的业务。统一API入口隔离后端认证鉴权流控负载均衡。原创 2023-01-20 00:09:44 · 2065 阅读 · 2 评论 -
系统容量评估和性能保障
系统容量评估和性能保障非功能质量需求的概述非功能质量需求的具体指标非功能质量需求的概述核心非功能质量指标,主要体现在高性能、高可用、可伸缩、可扩展、安全性等方面,并讲解其他非功能质 量指标, 例如:可测试性、可监控性等。核心非功能质量指标如下表所示:核心非功能质量指标描述高性能运行效率高、性价比高可用性持续可用性、缩短岩机时间、出错恢复、可靠性可伸缩性垂直伸缩、水平伸缩可扩展性可插拔、组件重用安全性数据安全、加密、熔断、防攻击这里,对于一个原创 2021-10-24 17:23:07 · 2260 阅读 · 0 评论 -
从0开始学架构总结
从0开始学架构总结架构设计三原则合适原则简单原则演化原则小结:架构设计流程:识别复杂度如何识别复杂度小结架构设计流程:设计备选方案第一种常见的错误:设计最优秀的方案第二种常见的错误:只做一个方案小结架构设计流程:评估和选择备选方案评估和选择备选方案小结架构设计流程:详细方案设计方案设计需要注意的事项小结高性能数据库集群:读写分离读写分离原理复制延迟分配机制小结高性能数据库集群:分库分表业务分库分表小结高性能NoSQL常见的NoSQL方案分为4类:小结高性能缓存架构缓存的架构设计要点缓存穿透缓存雪崩实现方式小原创 2021-10-21 11:39:03 · 1531 阅读 · 4 评论 -
架构设计手册
架构设计参考手册系统设计的一些原则在设计系统时,应该多思考墨菲定律在系统划分时,也要思考康威定律高并发原则高可用原则业务设计原则总结负载均衡与反向代理Nginx负载均衡算法失败重试健康检查备份上游服务器不可用上游服务器隔离线程隔离进程隔离集群隔离机房隔离读写隔离动静隔离爬虫隔离热点隔离资源隔离使用Hystrix实现隔离限流详解限流算法应用级限流分布式限流接入层限流降级降级预案自动开关降级人工开关降级超时与重试机制代理层超时与重试web容器超时数据库 | NoSql连接超时业务超时回滚机制事务回滚代码回滚部署原创 2021-10-08 19:33:58 · 1530 阅读 · 0 评论 -
限流量控制:高并发系统中我们如何操纵流量?
限流量控制:高并发系统中我们如何操纵流量?究竟什么是限流应该知道的限流算法固定窗口与滑动窗口的算法漏桶算法与令牌筒算法总结如果系统的峰值流量会超过了预估的峰值,对于核心服务也产生了比较大的影响,而我们总不能把核心服务整体降级吧?那么在这个时候要如何保证服务的稳定性呢?你认为可以使用限流的方案。而提到限流,相信我们多多少少在以下几个地方出错过:限流算法选择不当,导致限流效果不好;开启了限流却发现整体性能有损耗;只实现了单机的限流却没有实现整体系统的限流;说白了,之所以出现这些问题还是对限流的算法原创 2021-10-02 14:26:15 · 1810 阅读 · 0 评论 -
应用性能管理:用户的使用体验应该如何监控?
应用性能管理:用户的使用体验应该如何监控?如何搭建 APM 系统需要监控用户的哪些信息总结我们了解了服务端监控搭建的过程。有了监控报表之后,团队在维护垂直电商系统时,就可以更早地发现问题,也有直观的工具辅助我们分析排查问题了。但是有一些问题,服务端的监控报表无法排查,甚至无法感知。比如,有用户反馈创建订单失败,但是从服务端的报表来看,并没有什么明显的性能波动,从存储在 Elasticsearch 里的原始日志中,甚至没有找到这次创建订单的请求。这有可能是客户端有 Bug,或者网络抖动导致创建订单的请求并原创 2021-10-02 14:02:50 · 279 阅读 · 0 评论 -
给系统加上眼睛:服务端监控要怎么做?
给系统加上眼睛:服务端监控要怎么做?监控指标如何选择如何采集数据指标监控数据的处理和存储总结在一个项目的生命周期里,运行维护占据着很大的比重,在重要性上,它几乎与项目研发并 驾齐驱。而在系统运维过程中,能够及时地发现问题并解决问题,是每一个团队的本职工 作。所以,我们的系统在搭建之初,运维团队肯定完成了对于机器 CPU、内存、磁 盘、网络等基础监控,期望能在出现问题时,及时地发现并且处理。本以为万事大吉,却没想到系统在运行过程中,频频得到用户的投诉,原因是:使用的数据库主从延迟变长,导致业务功能上出现原创 2021-10-02 13:44:16 · 265 阅读 · 0 评论 -
多机房部署:跨地域的分布式系统如何做?
多机房部署:跨地域的分布式系统如何做?多机房部署的难点是什么?逐步迭代多机房部署方案同城双活异地多活总结多机房部署的难点是什么?多机房部署的含义是:在不同的 IDC 机房中,部署多套服务,这些服务共享同一份业务数据,并且都可以承接来自用户的流量。这样,当其中某一个机房出现网络故障、火灾,甚至整个城市发生地震、洪水等大的不可抗的灾难时,你可以随时将用户的流量切换到其它地域的机房中,从而保证系统可以不间断地持续运行。这种架构听起来非常美好,但是在实现上却是非常复杂和困难的,那么它复杂在哪儿呢?假如我们有原创 2021-09-25 19:12:14 · 2466 阅读 · 0 评论 -
负载均衡:怎样提升系统的横向扩展能力?
负载均衡:怎样提升系统的横向扩展能力?负载均衡服务器的种类常见的负载均衡策略有哪些如何检测节点是否故障总结在实际的工作中,我们经常使用的负载均衡的组件应该算是 Nginx,它的作用是承接前端的 HTTP 请求,然后将它们按照多种策略,分发给后端的多个业务服务器上。这样,我们可以随时通过扩容业务服务器的方式,来抵挡突发的流量高峰。与 DNS 不同的是, Nginx 可以在域名和请求 URL 地址的层面做更细致的流量分配,也提供更复杂的负载均衡策略。我们可能会想到,在微服务架构中,我们也会启动多个服务节点,原创 2021-09-25 18:46:55 · 775 阅读 · 0 评论 -
RPC框架:10万QPS下如何实现毫秒级的服务调用?
RPC框架:10万QPS下如何实现毫秒级的服务调用?RPC如何提升网络传输性能选择合适的序列化方式总结:我们已经决定对系统做服务化拆分,以便解决扩展性和研发成本高的问题。与此同时,我们在不断学习的过程中还发现,系统做了服务化拆分 之后,会引入一些新的问题,这些问题我在上节课提到过,归纳起来主要是两点:服务拆分单独部署后,引入的服务跨网络通信的问题;在拆分成多个小服务之后,服务如何治理的问题;如果想要解决这两方面问题,就需要了解,微服务化所需要的中间件的基本原理,和使用技巧,我们先解决第一点问题的原创 2021-09-24 00:19:39 · 755 阅读 · 0 评论 -
系统架构:每秒1万次请求的系统要做服务化拆分吗?
系统架构:每秒1万次请求的系统要做服务化拆分吗?一体化架构的痛点如何使用微服务化解决这些痛点那么我们怎么解决这个问题呢?总结现在,我们的系统运行稳定,好评不断,每天高峰期的流量,已经达到了 10000/s 请求, DAU 也涨到了几十万。 领导非常高兴,打算继续完善产品功能,以便进行新一轮的运营推 广,争取在下个双十一可以将 DAU 冲击过百万。这时,我们开始考虑,怎么通过技术上的 优化改造,来支撑更高的并发流量,比如支撑过百万的 DAU。于是,我们重新审视了自己的系统架构,分析系统中有哪些可以优化的点原创 2021-09-23 23:29:54 · 504 阅读 · 0 评论 -
消息队列:如何降低消息队列系统中消息的延迟?
消息队列:如何降低消息队列系统中消息的延迟?如何监控消息延迟减少消息延迟的正确姿势总结我们知道了如何使用消息队列应对秒杀时的峰值流量已经有所了解。当然了,你也应该知道要如何做,才能保证消息不会丢失,尽量避免消息 重复带来的影响。那么我们在使用消息队列时:除了这些内容,还需要关注哪些点呢?先来看一个场景:在我们的电商项目中,会在用户下单支付之后,向消息队列里面发送 一条消息,队列处理程序消费了消息后,会增加用户的积分,或者给用户发送优惠券。那么用户在下单之后,等待几分钟或者十几分钟拿到积分和优惠券是可以接原创 2021-09-23 00:05:12 · 583 阅读 · 0 评论 -
消息投递:如何保证消息仅仅被消费一次?
消息投递:如何保证消息仅仅被消费一次?消息为什么会丢失如何保证消息只被消费一次总结:我们在电商系统中增加了消息队列,用它来对峰值写流量做削峰填谷,对次要的业务逻辑做异步处理,对不同的系统模块做解耦合。因为业务逻辑从同步代码中移除 了,所以,我们也要有相应的队列处理程序来处理消息、执行业务逻辑,这时,我们的系统架构变成了下面的样子:这是一个简化版的架构图,实际上,随着业务逻辑越来越复杂,会引入更多的外部系统和服务来解决业务上的问题。比如说,我们会引入 Elasticsearch 来解决商品和店铺搜索的问原创 2021-09-22 23:41:11 · 806 阅读 · 0 评论 -
消息队列:秒杀时如何处理每秒上万次的下单请求?
消息队列:秒杀时如何处理每秒上万次的下单请求?我所理解的消息队列削去秒杀场景下的峰值写流量通过异步处理简化秒杀请求中的业务流程解耦实现秒杀系统模块之间松耦合总结我们了解了高并发系统设计的三个目标:性能、可用性和可扩展性,而在提升系统性能方面,我们一直关注的是系统的查询性能。也学习了数据库的分布式改造,各类缓存的原理和使用技巧。究其原因在于,我们遇到的大部分场景都是读多写少,尤其是在一个系统的初级阶段。比如说,一个社区的系统初期一定是只有少量的种子用户在生产内容,而大部分的用户都 在“围观”别人在说什么。原创 2021-09-22 23:02:32 · 795 阅读 · 0 评论 -
CDN:静态资源如何加速?
CDN:静态资源如何加速?静态资源加速的考虑点CDN 的关键技术总结现在,我们应该对包括本地 缓存、分布式缓存等缓存组件的适用场景和使用技巧有了一定了解了。结合我们前面学过的客户端高可用方案,我们会将单个缓存节点扩展为高可用的缓存集群,现在,我们的系统架构演变成了下面这样:在这个架构中我们使用分布式缓存对动态请求数据的读取做了加速,但是在我们的系统中存在着大量的静态资源请求:对于移动 APP 来说,这些静态资源主要是图片、视频和流媒体信息。对于 Web 网站来说,则包括了 JavaScript原创 2021-09-21 23:30:11 · 1198 阅读 · 0 评论 -
缓存的使用姿势(3):缓存穿透了怎么办?
缓存的使用姿势(3):缓存穿透了怎么办?什么是缓存穿透缓存穿透的解决方案回种空值使用布隆过滤器总结我们应该知道,对于缓存来说,命中率是它的生命线。在低缓存命中率的系统中,大量查询商品信息的请求会穿透缓存到数据库,因为数据库对于并发的承受能力是比较脆弱的。一旦数据库承受不了用户大量刷新商品页面、定向搜索衣服信息,就会导致查询变慢,导致大量的请求阻塞在数据库查询上,造成应用服务器的连接和线程资源被占满,最终导致电商系统崩溃。一般来说,我们的核心缓存的命中率要保持在 99% 以上,非核心缓存的命中率也要尽量原创 2021-09-21 17:00:14 · 134 阅读 · 0 评论 -
缓存的使用姿势(2):缓存如何做到高可用?
缓存的使用姿势(2):缓存如何做到高可用?客户端方案中间代理层方案服务端方案总结我们了解了缓存的原理、分类以及常用缓存的使用技巧。我们开始用缓存承担大部分的读压力,从而缓解数据库的查询压力,在提升性能的同时保证系统的稳定性。这时,我们的系统整体的架构演变成下图的样子:我们在 Web 层和数据库层之间增加了缓存层,请求会首先查询缓存,只有当缓存中没有需要的数据时才会查询数据库。在这里,我们需要关注缓存命中率这个指标(缓存命中率 = 命中缓存的请求数 / 总请求数)。一般来说,在我们的电商系统中,核心缓原创 2021-09-21 15:17:50 · 379 阅读 · 0 评论 -
缓存的使用姿势(1):如何选择缓存的读写策略?
缓存的使用姿势(1):如何选择缓存的读写策略?Cache Aside(旁路缓存)策略Read / Write Through(读穿 / 写穿)策略Write Back(写回)策略总结我们可能觉得缓存的读写很简单,只需要优先读缓存,缓存不命中就从数据库查询,查询到了就回种缓存。实际上,针对不同的业务场景,缓存的读写策略也是不同的。而我们在选择策略时也需要考虑诸多的因素,比如说,缓存中是否有可能被写入脏数据,策略的读写性能如何,是否存在缓存命中率下降的情况等等。接下来,就以标准的“缓存 + 数据库”的场景为原创 2021-09-21 14:47:31 · 228 阅读 · 0 评论 -
缓存:数据库成为瓶颈后,动态数据的查询要如何加速?
缓存:数据库成为瓶颈后,动态数据的查询要如何加速?什么是缓存缓存案例缓存与缓冲区缓存分类缓存的不足总结什么是缓存缓存,是一种存储数据的组件,它的作用是让对数据的请求更快地返回。我们经常会把缓存放在内存中来存储, 所以有人就把内存和缓存画上了等号,这完全是外 行人的见解。作为业内人士,我们要知道在某些场景下我们可能还会使用 SSD 作为冷数据的缓存。比如说 360 开源的 Pika 就是使用 SSD 存储数据解决 Redis 的容量瓶颈的。实际上,凡是位于速度相差较大的两种硬件之间,用于协调两者数据传原创 2021-09-21 14:14:10 · 182 阅读 · 0 评论 -
NoSQL:在高并发场景下,数据库和NoSQL如何做到互补?
NoSQL:在高并发场景下,数据库和NoSQL如何做到互补?NoSQL,No SQL?使用 NoSQL 提升写入性能NoSQL 数据库是怎么解决这个问题的呢?总结对于存储服务来说,我们一般会从两个方面对它做改造:提升它的读写性能,尤其是读性能,因为我们面对的多是一些读多写少的产品。比方说,你离不开的微信朋友圈、微博和淘宝,都是查询 QPS 远远大于写入 QPS。增强它在存储上的扩展能力,从而应对大数据量的存储需求。NoSQL,No SQL?NoSQL 想必我们都很熟悉,它指的是不同于传统的关系原创 2021-09-13 20:03:52 · 262 阅读 · 0 评论 -
发号器:如何保证分库分表后ID的全局唯一性?
发号器:如何保证分库分表后ID的全局唯一性?数据库的主键要如何选择?基于 Snowflake 算法搭建发号器总结我们通过分库分表和主从读写分离的方式解决了数据库的扩展性问题,但是在,数据库在分库分表之后,我们在使用数据库时存在的许多限制,比如说查询的时候必须带着分区键;一些聚合类的查询(像是 count())性能较差,需要考虑使用计数器等其它的解决方案,其实分库分表还有一个问题,就是主键的全局唯一性的问题。数据库的主键要如何选择?数据库中的每一条记录都需要有一个唯一的标识,依据数据库的第二范式,数据库原创 2021-09-13 19:49:36 · 587 阅读 · 0 评论 -
数据库优化方案(2):写入数据量增加时,如何实现分库分表?
@TOC随着项目的持续发展,运营推广持续带来了流量,我们所设计的电商系统的订单量突破了五千万,订单数据都是单表存储的,我们的压力倍增,因为无论是数据库的查询还是写入性能都在下降,数据库的磁盘空间也在报警。所以,我们主动分析现阶段自己需要考虑的问题,并寻求高效的解决方式,以便系统能正常运转下去。我们考虑的问题主要有以下几点:系统正在持续不断地的发展,注册的用户越来越多,产生的订单越来越多,数据库中存 储的数据也越来越多,单个表的数据量超过了千万甚至到了亿级别。这时即使使用了索引,索引占用的空间也随着数据原创 2021-09-13 17:46:30 · 289 阅读 · 0 评论 -
数据库优化方案(1):查询请求增加时,如何做主从分离?
@TOC主从读写分离其实,大部分系统的访问模型是读多写少,读写请求量的差距可能达到几个数量级。这很好理解,刷朋友圈的请求量肯定比发朋友圈的量大,淘宝上一个商品的浏览量也肯定远大于它的下单量。因此,我们优先考虑数据库如何抗住更高的查询请求,那么首先你需要把读写流量区分开,因为这样才方便针对读流量做单独的扩展,这就是我们所说的主从读写分离。它其实是个流量分离的问题,就好比道路交通管制一样,一个四车道的大马路划出三个车道给领导外宾通过,另外一个车道给我们使用,优先保证领导先行,就是这个道理。这个方法本身原创 2021-09-13 16:20:00 · 96 阅读 · 0 评论 -
池化技术:如何减少频繁创建数据库连接的性能损耗?
系统设计目标(3):池化技术:如何减少频繁创建数据库连接的性能损耗?用连接池预先建立数据库连接用线程池预先创建线程总结假设公司的领导,把我们叫到会议室,告诉我们公司有一个新的商业机会,希望我们可以迅速研发出一套面向某个垂直领域的电商系统。在人手紧张,时间不足的情况下,为了能够完成任务,我们毫不犹豫地采用了最简单的架构:前端一台 Web 服务器运行业务代码,后端一台数据库服务器存储业务数据。这个架构图是我们每个人最熟悉的,最简单的架构原型,很多系统在一开始都是长这样的,只是随着业务复杂度的提高,架构做原创 2021-09-13 11:21:43 · 436 阅读 · 0 评论 -
系统设计目标(3):如何让系统易于扩展?
系统设计目标(3):如何让系统易于扩展?为什么提升扩展性会很复杂高可扩展性的设计思路总结从架构设计上来说,高可扩展性是一个设计的指标,它表示可以通过增加机器的方式来线性提高系统的处理能力,从而承担更高的流量和并发。一般来说,基于成本考虑,在业务平稳期,我们会预留 30%~ 50% 的冗余以应对运营活动或者推广可能带来的峰值流量,但是当有一个突发事件发生时,流量可能瞬间提升到 2~3 倍甚至更高。我们还是以微博为例:鹿晗和关晓彤互圈公布恋情,大家会到两个人的微博下面,或围观,或互动,微博的流量短时间内原创 2021-09-12 23:38:31 · 883 阅读 · 0 评论 -
系统设计目标(2):系统怎样做到高可用?
系统设计目标(2):系统怎样做到高可用?可用性的度量高可用系统设计的思路总结高可用性(High Availability,HA)是我们在系统设计时经常会听到的一个名词,它指的是系统具备较高的无故障运行的能力。我们在很多开源组件的文档中看到的 HA 方案就是提升组件可用性,让系统免于宕机无法 服务的方案。比如,Hadoop 1.0 中的 NameNode 是单点的,一旦发生故障则整个集群就会不可用;而在 Hadoop2 中提出的 NameNode HA 方案就是同时启动两个 NameNode,一个处于 A原创 2021-09-12 21:25:21 · 492 阅读 · 0 评论 -
系统设计目标(1):如何提升系统性能?
系统设计目标(1):如何提升系统性能?高并发系统设计的三大目标:高性能、高可用、可扩展性能优化原则性能的度量指标高并发下的性能优化总结提到互联网系统设计,你可能听到最多的词儿就是“三高”,也就是“高并发”、“高性能”、“高可用”,它们是互联网系统架构设计永恒的主题。高并发系统设计的三大目标:高性能、高可用、可扩展高并发:是指运用设计手段让系统能够处理更多的用户并发请求,也就是承担更大的流量。 它是一切架构设计的背景和前提,脱离了它去谈性能和可用性是没有意义的。很显然,在每秒一次请求和每秒一万次请求,两原创 2021-09-12 17:29:52 · 1579 阅读 · 0 评论 -
架构分层:我们为什么一定要这么做?
架构分层:我们为什么一定要这么做?什么是分层架构分层有什么好处如何来做系统分层分层架构的不足总结在系统从 0 到 1 的阶段,为了让系统快速上线,我们通常是不考虑分层的。但是随着业务越来越复杂,大量的代码纠缠在一起,会出现逻辑不清晰、各模块相互依赖、代码扩展性差、改动一处就牵一发而动全身等问题。这时,对系统进行分层就会被提上日程,那么我们要如何对架构进行分层?架构分层和高并发架构设计又有什么关系呢?什么是分层架构软件架构分层在软件工程中是一种常见的设计方式,它是将整体系统拆分成 N 个层次,每个层次原创 2021-09-12 15:30:49 · 277 阅读 · 0 评论 -
高并发系统:它的通用设计方法是什么?
高并发系统:它的通用设计方法是什么?Scale-up vs Scale-out使用缓存提升性能异步处理总结我们知道,高并发代表着大流量,高并发系统设计的魅力就在于我们能够凭借自己的聪明才智设计巧妙的方案,从而抵抗巨大流量的冲击,带给用户更好的使用体验。这些方案好似能操纵流量,让流量更加平稳得被系统中的服务和组件处理。来做个简单的比喻吧。从古至今,长江和黄河流域水患不断,远古时期,大禹曾拓宽河道,清除淤沙让流水更加顺畅;都江堰作为史上最成功的的治水案例之一,用引流将岷江之水分流到多个支流中,以分担水流压原创 2021-09-12 14:46:56 · 160 阅读 · 0 评论 -
系统设计的一些原则
系列文章目录提示:这里可以添加系列文章的所有文章的目录,目录需要自己手动添加例如:第一章 Python 机器学习入门之pandas的使用提示:写完文章后,目录可以自动生成,如何生成可参考右边的帮助文档文章目录系列文章目录 前言 一、在设计系统时,应该多思考墨菲定律 二、在系统划分时,也要思考康威定律 三、高并发原则 总结前言业务千变万化,技术层出不穷,设计理念也是百花齐放,看起来似乎很难有一套通用的规范来适 用所有的架构设计场景。但是总是有一些原则是...原创 2020-11-14 11:46:51 · 1794 阅读 · 0 评论