软件架构
文章平均质量分 90
知识记录者-vincent
这个作者很懒,什么都没留下…
展开
-
云计算服务三层架构-IaaS-PaaS-SaaS解析
IaaS 基础设施即服务 Infrastructure as a service 通即虚拟的硬件资源,如虚拟的主机、存储、网络、安全等资源用户无需购买服务器、网络设备和存储设备,只需要通过网络租赁即可搭建自己的应用系统将硬件外包到别的地方去,IaaS公司会提供场外服务器,存储和网络硬件,你可以租用,节省了维护成本和办公场地公司产品有: Amazon, Microsoft,阿里云,腾讯云,各自的产品最熟悉的例子:阿里云ECS主机的带宽、磁盘空间、GPU等 PaaS 平台即服务..原创 2021-08-03 00:05:52 · 2781 阅读 · 0 评论 -
软件架构场景之—— 接口 Mock:第三方服务还没好,功能设计如何继续?
业务场景场景一:公司外部之间的调用我们都知道,联调外部接口,往往需要先申请测试环境,而申请测试环境的时间一般都很长,会耗费很多精力比如有一次,我们需要对接一个第三方支付的接口,自己系统的功能需求做出来后,对接三方支付接口的功能还迟迟没有动工。我们不断催商务,商务不断催第三方支付的联系人,第三方支付的联系人一直说在走流程,最终光一个第三方支付接口的测试环境就等了 3 周。以至于每次在例会上过项目进度时,这个标红旗的延期项目都会抢镜头场景二:公司内部之间的接口调用曾经有一个项目需要配合另一个原创 2021-02-20 10:00:53 · 1288 阅读 · 0 评论 -
软件架构场景之—— BFF:如何处理好微服务之间千丝万缕的关系?
业务场景之前设计的一个供应链系统中,它包含了商品、销售订单、加盟商、门店运营、门店工单等服务,涉及了各种用户角色,比如总部商品管理、总部门店管理、加盟商员工、门店人员等,而且每个部门的角色还会进行细分。而且这个系统中还包含了两个客户端 App:一个面向客户,另一个面向公司员工和加盟商此时,整个供应链系统的架构如下图所示上图中的网关层主要负责路由、认证、监控、限流熔断等工作路由: 所有的请求都需要通过网关层进行处理,网关层再根据 URI 将请求指向对应的后台服务,如果同一个服务存在多个服原创 2021-02-17 23:41:13 · 1583 阅读 · 3 评论 -
软件架构场景之—— 数据同步:如何解决微服务之间的数据依赖问题?
业务场景曾经设计的一个供应链系统中,存在商品、销售订单、采购这三个服务,它们的主数据的部分结构如下所示在设计这个供应链系统时,我们需要满足以下两个需求根据商品的型号/分类/生成年份/编码等查找订单; 根据商品的型号/分类/生成年份/编码等查找采购订单初期的方案是这样设计的:严格按照的微服务划分原则将商品相关的职责存放在商品系统中。因此,在查询订单与采购单时,如果查询字段包含商品字段,需要按照如下顺序进行查询先根据商品字段调用商品的服务,然后返回匹配的商品信息; 在订单或采购原创 2021-02-17 23:15:11 · 4482 阅读 · 3 评论 -
软件架构场景之—— 数据一致性:下游服务失败上游服务如何独善其身?
业务场景使用微服务时,很多时候我们往往需要跨多个服务去更新多个数据库的数据,类似下图所示的架构如图所示,如果业务正常运转,3 个服务的数据应该变为 a2、b2、c2,此时数据才一致。但是如果出现网络抖动、服务超负荷或者数据库超负荷等情况,整个处理链条有可能在步骤二失败,这时数据就会变成 a2、b1、c1,当然也有可能在步骤三失败,最终数据就会变成 a2、b2、c1,这样数据就对不上了,即数据不一致为了针对数据一致性问题给出一个完美解决方案,把数据一致性的问题归类为以下 2 种场景第一种原创 2021-01-29 15:18:38 · 2444 阅读 · 2 评论 -
软件架构场景之—— 微服务的痛点
单体式架构 VS 微服务架构为了快速理解单体式架构与微服务架构之间的区别,先来看一个新零售系统的例子比如门店(门店分为自营店和加盟店)想研发一款新零售系统进行商品售卖,它需要包含订单、营销、门店、商品、加盟商、会员等功能模块在搭建新零售系统架构时,如果我们使用单体式架构进行设计,它的架构图如下所示新零售系统:单体式架构图从图中发现,单体式架构将所有模块的代码存放在一个应用中,所有模块的数据存放在一个数据库中。在这种架构模式下,当业务功能增加到一定程度,我们只要稍微有点小改动,就有可能影响整个原创 2021-01-29 14:20:06 · 792 阅读 · 2 评论 -
软件架构场景之—— 限流:如何保障服务器承受亿级流量?
业务场景在秒杀活动中,总计有 100 个特价商品,且每个商品的价格都非常低,活动计划于 10 月 10 日晚上 10 点 10 分 0 秒开启当时,服务器架构图如下,所有客户端的 API 请求先进入 1 个 Nginx 层,再由 Nginx 层转发至网关层(Java,使用 Spring Cloud Zuul),最后转发至后台服务1(Java)预测到秒杀开始那一瞬间会有海量用户涌入,致使系统无法处理所有用户请求,为保障服务器承受住大流量,只能通过限流的方式将部分流量放入后台服务中什么是限流原创 2021-01-29 10:41:13 · 348 阅读 · 0 评论 -
软件架构场景之—— 熔断:如何预防一个服务故障崩掉整个系统?
业务场景在一个新零售架构系统中,有一个通用用户服务(很多页面都会使用),它包含两个接口,第一个接口是用户状态接口,包含用户车辆所在位置,并且在用户信息展示页面都会使用到,比如客服系统中的用户信息页面。第二个接口是需要我们返回用户一个可操作的权限列表,它包含一个通用权限,也包含用户定制权限,而且每次用户打开 App 时都会使用它第一个接口会遇到的问题:请求慢用户状态的接口、服务间的调用关系如下图所示在 Basic Data Service 中,有个接口 /currentCarLocatio原创 2021-01-29 10:07:24 · 2210 阅读 · 0 评论 -
软件架构场景之—— 全链路日志:这个请求到底经历了什么?
业务场景公司的微服务刚刚迁移到 Spring Cloud,服务的注册发现基于 Spring Cloud ZooKeeper 实现,不过组件方面只使用了 Spring Cloud 的服务间调用(Feign)。迁移到微服务后,就得考虑日志跟踪的事情了之前我们只是简单地把日志打印到本地文件上,然后使用 ELK 进行日志收集、分析,因此日志记录比较随意且没有形成一个统一的规范,后来决定把日志进一步规范化,于是提出了如下 3 点需求记录什么时候调用了缓存/MQ/ES 等中间件,在哪个类的哪个方法中耗时多原创 2021-01-28 20:11:18 · 596 阅读 · 0 评论 -
软件架构场景之—— 注册发现:如何对后台服务进行高效管理?
业务场景公司拥有多个服务,并且很多服务之间都有调用关系,而这些服务是使用各种语言编写的,比如 Java、Go、Node.js。因为跨语言,而目前流行的 Spring Cloud、Dubbo 都是针对 Java 语言的,所以没有使用 Spring Cloud、Dubbo 这些微服务框架如何配置各个服务之间的调用关系的呢?因为有多个服务都有负载均衡,所以我们首先需要把服务的地址和负载均衡全部配置在 Nginx 上,类似这样upstream user-servers { server 192原创 2021-01-28 19:43:11 · 237 阅读 · 0 评论 -
软件架构场景之—— 秒杀架构:设计秒杀架构必知必会的那些事
业务场景之前,公司策划了一场秒杀活动,该活动提供了 100 件特价商品(商品价格非常低)供用户于 10 月 10 日 22 点 10 分 0 秒正式参与秒杀当时,平台已经积累了几千万的用户量,预计数十万的用户对此特价商品感兴趣。按照秒杀活动的调性,特价商品一般会在 1-2 秒内被一抢而光,剩余时间涌进来的流量只能看到秒杀结束界面,因此我们预测秒杀开启那一瞬间会出现一个瞬间流量峰值。这也是一场短暂性的活动,需要以最小的技术代价搞定这次秒杀活动。因此,这次秒杀架构的设计目标是以较小的改动保证秒杀时间的流原创 2021-01-21 11:13:08 · 313 阅读 · 0 评论 -
软件架构场景之—— 数据收集:高频数据收集请求如何不影响主业务?
业务背景因业务快速发展,某天公司的日活用户高达 500 万,基于现有业务模式,业务侧要求我们根据用户的行为做埋点,旨在记录用户在特定页面的所有行为、开展数据分析与第三方进行费用结算,另外可以对用户的行为进行推送业务等当然,在数据埋点的过程中,业务侧还要求在后台能准实时查询用户行为数据及统计报表,为了让你更加容易理解后续方案的设计思路,把真实业务场景中的数据结构进行了相关简化(真实的业务场景数据结构更加复杂)。首先,我们需要收集的原始数据结构如下表所示指标 备注 IMEI 用户设备原创 2021-01-26 09:31:56 · 342 阅读 · 0 评论 -
软件架构场景之—— 写缓存:如何节省数据库写操作资源?
业务场景曾经,公司策划过一场超低价预约大型线上活动,在某天 10:00-10:15 期间,用户可以前往预约详情页半价预约抢购一款热门商品。根据市场部门的策划方案,这次活动运营目标是几十万左右的预约量面对如此大的预约量,如何防止涌进来的请求压垮数据库?之前,给公司的系统做过一次压测:并发量保持在 8000 左右时,系统响应速度最高,并发量数据要是再上升,系统响应速度就会急剧变慢。如果几十万的用户同时在那个期间预约商品,可以预见高峰期(特别是 10 点那一瞬间)的并发量肯定超过 10000,到时我们原创 2021-01-12 09:48:53 · 398 阅读 · 2 评论 -
软件架构场景之—— 读缓存:如何减少数据库读操作压力?
业务场景负责的一个电商系统中,存放了 50000 多条商品数据,每次用户浏览商品详情页时,需要先从数据库中读取数据,再进行数据拼装和计算,耗费的时间有时长达 1 秒这就导致用户每次点击商品详情页时,页面打开速度慢,此时该如何减少数据库读操作压力呢?此时我们采取的方案也很通用,把所有的商品数据缓存起来就行关于缓存问题,最简单的实现方法是使用本地缓存。在 Google Guava 中有一个 cache 内存缓存模块,它把所有商品的 ID 与商品详情信息一对一缓存至 JVM 内存中,用户获取商品详原创 2021-01-11 14:54:33 · 446 阅读 · 0 评论 -
软件架构场景之—— 分表分库:单表数据量大读写缓慢如何解决?
业务背景一个电商系统的架构优化,该系统中包含用户和订单 2 个主要实体,每个实体涵盖数据量如下表所示实体 数据量 增长趋势 用户 上千万 每日十万 订单 上亿 每日百万级速度增长,之后可能是千万级 从上表中我们发现,目前订单数据量已达上亿,且每日以百万级的速度增长,之后还可能是千万级。面对如此庞大的数据量,此时存储订单的数据库表竟然还是一个单库单表。对于单库单表而言,一旦数据量实现疯狂增长,无论是 IO 还是 CPU 都会扛不住为了使系统抗住千万级原创 2021-01-11 10:47:29 · 869 阅读 · 1 评论 -
软件架构场景之—— Elasticsearch 使用注意要点
如何使用Elasticsearch 设计表结构?我们知道 ES 是基于索引的设计,它没办法像 MySQL 那样使用 join 查询,所以,查询数据时我们需要把每条主数据及关联子表的数据全部整合在一条记录中比如 MySQL 中有一个订单数据,使用 ES 查询时,我们会把每条主数据及关联子表数据全部整合在下表中表名 作用 与订单主表关系 order 订单主表 自身 order_invoice 订单发票 1对1 order_product_item原创 2021-01-08 15:17:14 · 585 阅读 · 0 评论 -
软件架构场景之—— 查询分离:表数据量大查询缓慢如何优化?
冷热分离解决方案的性价比高,但它并不是一个最优的方案,仍然存在诸多不足,比如:查询冷数据慢、业务无法再修改冷数据、冷数据多到一定程度系统依旧扛不住,我们如果想把这些问题一一解决掉,可以用另外一种解决方案——查询分离。(注意:查询分离与读写分离还是有区别的)业务场景SaaS 客服系统的架构优化,系统里有一个工单查询功能,工单表中存放了几千万条数据,且查询工单表数据时需要关联十几个子表,每个子表的数据也是超亿条。面对如此庞大的数据量,跟冷热分离一样,每次客户查询数据时几十秒才能返回结果,即便我们使.原创 2021-01-07 16:08:15 · 565 阅读 · 0 评论 -
软件架构场景之—— 冷热分离:表数据量大读写缓慢如何优化?
业务场景曾经遇到过供应链相关的架构优化,当时平台有一个订单功能,里面的主表有几千万的数据量,加上关联表,数据量达到上亿这么庞大的数据量,让平台的查询订单变得格外迟缓,查询一次都要二三十秒,而且多点击几次就会出现宕机。比如业务员多次查询时,数据库的 CPU 会立马狂飙,服务器线程也降不下来。当时,我们尝试了优化表结构、业务代码、索引、SQL 语句等办法来提高响应速度,但这些方法治标不治本,查询速度还是很慢。考虑到我们手头上还有其他优先级高的需求需要处理,为此,我们跟业务方反馈:“这功能以后你们能不用就原创 2021-01-07 14:33:11 · 523 阅读 · 0 评论