首页
学习
活动
专区
圈层
工具
发布
    • 综合排序
    • 最热优先
    • 最新优先
    时间不限
  • 来自专栏超级架构师

    【微服务架构】为故障设计服务架构

    服务架构的风险 微服务架构将应用程序逻辑转移到服务中,并使用网络层在它们之间进行通信。通过网络而不是内存调用进行通信会给系统带来额外的延迟和复杂性,这需要多个物理和逻辑组件之间的协作。 #microservices 允许您实现优雅的服务降级,因为可以将组件设置为单独失败。 与单体架构相比,微服务架构的最大优势之一是团队可以独立设计、开发和部署他们的服务。 泰坦尼克号沉没的主要原因之一是它的舱壁设计失败,水可以通过上面的甲板从舱壁顶部倾泻而下,淹没整个船体。 断路器通常在一定时间后关闭,为底层服务恢复提供足够的空间。 请记住,并非所有错误都应该触发断路器。例如,您可能希望跳过客户端问题,例如具有 4xx 响应代码的请求,但包括 5xx 服务器端故障。 团队无法控制他们的服务依赖关系。 缓存、隔板、断路器和速率限制器等架构模式和技术有助于构建可靠的微服务

    78440编辑于 2022-05-25
  • 来自专栏架构之美

    服务架构设计

    服务架构是一种架构模式,它提倡将单一应用程序划分成一组小的服务服务之间互相协调、互相配合,为用户提供最终价值。 关于微服务架构设计呢? 这个步骤很像单体架构下我们所做的系统高层架构设计,通过高层架构设计会识别并定义出各个业务领域模型,这些业务领域模型包含了业务对象的关键操作流程,通过这些业务领域模型就可以辅助我们规划出整个应用架构,即各模块之间的协作关系 那么如何衡量我们所设计的微服务粒度是否合适呢? 当你想单拎出一个服务时,发现几乎不可能,因为每一个微服务都依赖于其他微服务,同时又被其他微服务所依赖。 微服务架构设计一定是与时俱进的,因此我们也不可能在第一次设计时就设计出一个完美的架构体系。 - 微服务交互原则 - 当我们开始使用微服务架构进行开发时,一个清晰明了、规范的交互方式将极大提升应用开发效率。通常,我们可以使用以下原则作为微服务接口设计的准则。

    77610发布于 2020-09-28
  • 来自专栏超级架构师

    【微服务架构】微服务设计模式

    这是微服务架构系列文章的第 3 篇 高可用性、可扩展性、故障恢复能力和性能是微服务的特征。您可以使用微服务架构模式来构建微服务应用程序,从而降低微服务失败的风险。 分解模式 选择如何将单体系统分解为服务 按业务能力分解——服务是围绕业务能力组织的。 按子域分解——服务是围绕域驱动设计的子域组织的。 本文https://jiagoushi.pro/microservices-design-patterns讨论:知识星球【首席架构师圈】或者加信小号【cea_csa_cto】或者加QQ群【792862318 信小号 【cea_csa_cto】 50000人社区,讨论:企业架构,云计算,大数据,数据科学,物联网,人工智能,安全,全栈开发,DevOps,数字化. 知识星球【职场和技术】博【智能时刻】智能时刻哔哩哔哩【超级架构师】抖音【cea_cio】超级架构师快手【cea_cio_cto】超级架构师 小红书【cea_csa_cto】超级架构师 谢谢大家关注

    1.1K20编辑于 2022-04-18
  • 来自专栏性能与架构

    架构设计 -- 服务降级

    功能维度 包括:读服务降级、写服务降级。 系统层次维度 包括:多级降级。 ? 1. 统计失败次数 有的服务可能不太稳定,例如外部的机票服务,当调用失败次数超过容忍度后就自动降级。可以通过异步线程去探测服务是否恢复了,可用后自动取消降级。 还以商品详情页为例,在促销活动之前,可以将整个页面切换为静态化,最大程度的降级读服务4. 写服务降级 写服务都是很关键的,降级思路基本就是同步写转异步写。 例如扣减库存的操作,正常情况下的设计一般是: 方案1:数据库中扣减,成功后更新 Redis 缓存。 方案2:先扣减 Redis 缓存,同步扣减数据库,如果失败则回滚 Redis 缓存。 内容整理自《亿级流量网站架构核心技术》

    1.6K30发布于 2019-03-07
  • 来自专栏超级架构师

    (4) 微服务架构采用准则

    顾名思义,微服务体系结构是将服务器应用程序构建为一组小型服务的方法。这意味着微服务架构主要面向后端,尽管这种方法也用于前端。 每个微服务在特定的上下文边界内实现特定的端到端域或业务能力,并且每个微服务都必须自主开发和独立部署。 最后,每个微服务都应该拥有其相关的域数据模型和域逻辑(主权和分散的数据管理),并且可以基于不同的数据存储技术(SQL、NoSQL)和不同的编程语言。 微服务应该有多大? 在开发微服务时,大小不应该是重点。相反,重要的一点应该是创建松散耦合的服务,这样您就可以为每个服务自主地进行开发、部署和扩展。 当然,在识别和设计服务时,只要不与其他微服务有太多直接依赖关系,就应该尽量使它们尽可能小。比微服务的大小更重要的是它必须具有的内部内聚性及其与其他服务的独立性。

    35731发布于 2020-07-18
  • 来自专栏超级架构师

    服务与SOA架构(4

    应用范围 应用范围是指某种架构可以支持的应用的总体规模。例如,内核或者管道架构更适合较小的应用或者子系统,而其他模式如事件驱动的架构则适合于大型、更复杂应用。 这时,你很可能会用SOA架构模式替代初始的微服务架构。当然,反之亦然。你也可能最开始设计的是复杂的、大规模的SOA架构,在后来意识到其实并不需要SOA架构的所有的强大能力。 如图4-1所示,事实上,了解服务客户与服务之间所采用的远程访问协议并不意味着就了解任何一方是如何实现的,也不意味着双方在实现上要保持一致。 例如,如图4-2所示,在.NET平台上用C#实现的某个服务客户端可以使用REST调用对应的服务,但是服务(本例中是EJB3 Bean)只能使用RMI通信。 图4-2 如果你发现自己所处的是异构环境,需要对多种使用不同协议的系统或者服务进行整合,那么很可能需要采用SOA架构而不是微服务架构

    1.3K40发布于 2018-04-09
  • 来自专栏高性能服务器开发

    什么是内核架构设计

    本文从插件化(Plug-in)架构的角度来诠释内核架构设计,通过内核架构和微服务架构的对比,分享其对微服务设计的参考意义。 插件化架构对微服务架构设计帮助非常大,考虑到隔离性,插件可能是以独立进程方式运行的,那么这些进程如果扩展到网络上,分布在众多的服务器上,这个就是微服务架构的原型,所以了解内核的同学都不屑于和你讨论微服务架构 回到微服务架构设计场景,我们将Plug-in component重新命名为服务(Service),这个和内核设计中的服务也差不多,这个时候微服务内核就差不多了,都涉及到服务注册、管理和服务之间的通讯等 分布式的进程通讯是微服务的核心,我们理解的服务服务的通讯,就是服务A启动监听端口,服务B会和服务A建立连接,然后两者通讯即可。这个方式和内核设计中内核负责消息接收和转发的总线架构设计是不一样的。 内核架构设计对微服务设计有非常好的参考意义,但是微服务有一个非常大的问题就是服务边界的划分,对比操作系统,已经发展几十年,而且非常稳定,功能划分非常容易。

    1.8K20发布于 2021-01-03
  • 企业信接口在微服务架构下的集成设计与治理

    企业信接口在微服务架构下的集成设计与治理随着企业IT架构向云原生与微服务演进,将第三方平台能力如企业信接口,系统地集成至分布式系统中,成为一项关键的架构设计任务。 这远非简单的API调用,而是涉及服务发现、配置管理、弹性容错和可观测性等多个维度的工程实践。本文将探讨如何在微服务架构下,将企业信接口设计为一种稳定、可治理的内部基础服务。 一、核心挑战与设计目标在单体应用中调用企业信接口相对直接,但在微服务架构下,挑战凸显:配置分散:多个服务需要调用企业信API时,CorpID、Secret等凭证的管理容易混乱。 因此,设计目标是将企业信接口抽象并封装为一个独立的内部基础服务(如wecom-service),对内提供简洁、稳定的客户端SDK,并集中处理所有复杂性。 二、架构设计:企业信接口服务化推荐的设计模式是构建一个专用的微服务(WeComService),作为与企业信官方API交互的唯一出口。

    18710编辑于 2026-01-08
  • 来自专栏架构师之路

    服务架构多“”才合适?

    如@田卫所说,分布式事务是业界没有彻底解决的难题,任何架构设计都是一个折衷,吞吐量?时延?一致性?哪个是主要矛盾,优先解决哪个问题。 二、互联网微服务架构多“”才适合 大家也都认可,随着数据量、流量、业务复杂度的提升,服务架构架构演进中的必由之路,今天要讨论的话题是:微服务架构多“”才合适? 垂直拆分是个好的方案,将子业务一个个拆出来,那么信的服务架构或许会变成这个样子: ? 常见的,加入一个高可用服务分发层集群,并在协议设计时加入服务号,可以减少蜘蛛网状的依赖关系: (1)调用方依赖分发层,传入服务号 (2)分发层依赖服务层,通过服务号参数分发 【一个数据库对应一个service 扩展性更好 (6)… 细粒度拆分的不足也很明显: (1)拆得越细,系统越复杂 (2)系统之间的依赖关系也更复杂 (3)运维复杂度提升 (4)监控更加复杂 (5)出问题时定位问题更难 (6)… 关于微服务架构

    1.6K61发布于 2018-03-01
  • 来自专栏慕枫技术笔记

    服务架构服务容错设计分析

    引言 在微服务体系架构中,由于拆解的服务数变多了,服务发生故障的地方也会相应的增加,因此如何保证服务架构健壮是一个值得深思的问题。 在微服务架构体系中的熔断降级正是起到保险丝作用的基础组件。 我们在进行架构设计时,不仅需要满足业务要求,同时也需要面向失败进行设计,意思就是说当外部条件发生变化或者内部出现异常时,平台的架构能够将这种异常的影响降到最低,强大的容错能力是优秀架构的关键指标。 因此基于以上分析,微服务架构中引入熔断降级组件是为了提升微服务架构整体的容错能力。主要避免以下三种场景对平台稳定性的影响。 在熔断机制中,核心的内容就是断路器的设计,断路器设计主要有两方面一个是状态转换的设计,一个是如何根据阈值以统计数据来执行核心的断路功能。

    67020编辑于 2023-03-20
  • 来自专栏Rainbond开源「容器云平台」

    服务架构设计模式

    前不久,Java Code Geeks发表了一篇文章,分析单体应用与微服务的优缺点。近日,该网站又发表了一篇文章,提供了六种微服务架构设计模式。 1. 因此,服务调用链不宜过长,以免客户端长时间等待。 4. 分支微服务设计模式 这种模式是聚合器模式的扩展,允许同时调用两个微服务链,如下图所示: ? 5. 数据共享微服务设计模式 自治是微服务设计原则之一,就是说微服务是全栈式服务。 因此,在单体应用到微服务架构的过渡阶段,可以使用这种设计模式,如下图所示: ? 在这种情况下,部分微服务可能会共享缓存和数据库存储。不过,这只有在两个服务之间存在强耦合关系时才可以。 因此部分基于微服务架构可能会选择使用消息队列代替REST请求/响应,如下图所示: ?

    71860发布于 2018-05-31
  • 来自专栏码农沉思录

    架构设计之「服务隔离」

    本文转载自公众号不止思考 我们在做系统架构设计的时候,经常离不开的一个话题就是进行服务的隔离设计。 那什么是「服务隔离」呢? 一、为什么要做服务隔离设计呢? 比如上图里面,博项目可以把 Feed信息流、用户系统、评论系统 都分拆为独立业务模块,这些模块无论是对外的接口应用、还是到数据库、到底层硬件资源都是完全隔离的。 其实这也是一种「多租户架构」,在SaaS服务中用得比较多。 多租户模式有三种形式: 完全的隔离,即服务和数据都是完全独立的。 服务隔离的设计模式能降低依赖服务对整个系统的影响,保护有限的资源不被耗尽,提高了整个系统的可用性。本文参考了很多其它资料,属于抛砖引玉,希望大家能一起交流,提出更好的架构设计思路。

    90220发布于 2019-07-15
  • 来自专栏贝丝的专栏

    极光商城服务架构设计

    服务架构设计 高并发支撑思考 我们先来看看这张图,首先我们可以思考一下,这个架构中,哪些地方可以做负载均衡,来承载更高的 QPS 呢? 首先,我们可以在 Nginx 外层,做负载均衡。 也就是说,从请求到服务器经历了三层负载均衡: 应用型负载均衡ALB:支持加权轮询和最小连接数调度算法,可根据自身需求选择相应算法来分配用户流量。 一块高性能的 http 代理/反向代理服务器,一般在 Java 开发中,也经常用来做“负载均衡”。Nginx实现负载均衡的方式主要有三种:轮询、加权轮询、ip hash轮询。 业务架构设计 回到最上面的那张图片,用户最先访问网站的时候,加载的静态资源通过 CDN 进行分发,这里当然也包括图片了。 最后,服务集群也可以做进一步的优化。比如说网关的黑/白名单、非入侵监控设计、数据库路由组件、服务治理、调用限流等等,都可以抽出来做中间件,这样能一定程度的解耦,而且便于以后的维护。

    1.1K40发布于 2021-07-23
  • 来自专栏Java架构师必看

    服务架构设计模式

    大家好,我是架构君,一个会写代码吟诗的架构师。今天说一说微服务架构设计模式,希望能够帮助大家进步!!! 在开发应用程序的第一个版本时,你通常不会遇到需要微服务架构才能解决的问题。此外,使用精心设计的分布式架构将减缓开发速度。 另一种策略是围绕领域驱动设计的子域来分解和设计服务。但这些策略的最终结果都是围绕业务概念而非技术概念分解和设计服务。 定义应用程序架构的第三步是确定每个服务的 API。 领域模型会被紧密地映射到应用的设计和实现环节。在微服务架构设计层面,DDD 有两个特别重要的概念,子域和限界上下文 领域驱动为每一个子域定义单独的领域模型。 当使用微服务架构时,每一个限界上下文对应一个或者一组服务。换一种说法,我们可以通过 DDD 的方式定义子域,并把子域对应为每一个服务,这样就完成了微服务架构设计工作。

    57711编辑于 2022-01-12
  • 来自专栏不止思考

    架构设计之「服务隔离」

    我们在做系统架构设计的时候,经常离不开的一个话题就是进行服务的隔离设计。 那什么是「服务隔离」呢? 顾名思义,它是指将系统按照一定的原则划分为若干个服务模块,各个模块之间相对独立,无强依赖。 一、为什么要做服务隔离设计呢? 比如上图里面,博项目可以把 Feed信息流、用户系统、评论系统 都分拆为独立业务模块,这些模块无论是对外的接口应用、还是到数据库、到底层硬件资源都是完全隔离的。 其实这也是一种「多租户架构」,在SaaS服务中用得比较多。 多租户模式有三种形式: 完全的隔离,即服务和数据都是完全独立的。 服务隔离的设计模式能降低依赖服务对整个系统的影响,保护有限的资源不被耗尽,提高了整个系统的可用性。本文参考了很多其它资料,属于抛砖引玉,希望大家能一起交流,提出更好的架构设计思路。

    68930发布于 2018-08-31
  • 来自专栏不止思考

    架构设计之「服务限流」

    上一篇我们聊过了架构设计中的「服务隔离」模式,今天我们继续来探索一下在分布式系统架构中的另一个常用的设计服务限流。 那么,什么是「服务限流」呢? 在解释「服务限流」之前,我们来看一下前些时间网上很火的一个段子,说的是新浪博的一名工程师正在家里办婚礼,突然接到公司的电话要紧急处理线上流量激增的问题,那天应该是某当红明星突然在博上公布恋情,博流量突增好几倍 一、为什么要做服务限流设计? 因此为了保证系统至少还能为100W用户提供正常服务,我们需要对系统进行限流设计。 有的人可能会想,既然会有300W用户来访问,那为啥系统不干脆设计成能足以支撑这么大量用户的集群呢? 这是个好问题。 二、服务限流应该怎么做? 对系统服务进行限流,一般有如下几个模式: 熔断: 这个模式是需要系统在设计之初,就要把熔断措施考虑进去。

    74330发布于 2018-08-31
  • 来自专栏小二的折腾日记

    服务器-Nginx设计架构

    服务器-Nginx设计架构 Nginx服务架构 Nginx服务器启动后,产生一个主进程,主进程执行一系列工作后产生一个或多个工作进程。 如下图所示:Nginx服务器的结构大致分为主进程、工作进程、后端服务器和缓存。 缓存索引重建是在Nginx服务启动一段时间后由主进程生成,在缓存元数据重建完成后自动退出。

    90920发布于 2018-08-02
  • 来自专栏芋道源码1024

    服务架构设计模式

    源码解析 分布式事务中间件 TCC-Transaction 源码解析 Eureka 和 Hystrix 源码解析 Java 并发源码 来源:colstuwjx.github.io/2020/01 /翻译-微服务架构设计模式 微服务能够对企业产生积极影响。因此,了解如何处理微服务架构(MSA)以及一些微服务设计模式,一个微服务架构的一些通用目标或者设计原则是很有价值的。下面是在微服务架构方案中值得考虑的四个目标。 1、缩减成本:MSA将会降低设计、实现和维护IT服务的总体成本 2、加快发布速度:MSA将会加快服务从想法到部署的落地速度 3、增强弹性:MSA将会提升我们服务网络的弹性 4、开启可见性:MSA支持为服务和网络提供更好的可见性 你需要了解建设微服务架构背后的几个设计原则: 可扩展性 可用性 韧性 灵活性 独立自主性,自治性 去中心化治理 故障隔离 自动装配 通过 DevOps 持续交付 听取上述原则,在你实施的解决方案或系统付诸实践的同时 使用正确及匹配的设计模式可以克服这些问题。微服务有一些设计模式,这可以大体分为五类。每类都包含许多具体的设计模式。下图展示了这些设计模式。

    78520编辑于 2022-06-14
  • 来自专栏愿天堂没有BUG(公众号同名)

    SpringCloud微服务架构实战:高并发微服务架构设计

    目前来看,在互联网环境之中产生的微服务架构设计是一个比较理想的解决方案。 微服务总体架构设计 一个使用了微服务的电商平台的总体架构设计如图 2-1 所示。 前台应用层可支持任何应用的客户端,如物联网、信小程序、移动 App API 开放平台等。 这种管理机制可以提高微服务架构设计中各个微服务应用的应变能力,可以快速响应整个系统的变更和更新,从而充分提升整个微服务架构的总体效能。 如图 2-4 所示,是根据阿里云设计的一个安全管理架构,通过安全防护和安全预警 对不安全的访问或可能存在的攻击进行有效隔离,从而保证系统的安全和稳定。 本文就是愿天堂没有BUG给大家分享的内容,大家有收获的话可以分享下,想学习更多的话可以到信公众号里找我,我等你哦。

    1.3K20编辑于 2022-10-28
  • 来自专栏闲余说

    架构设计 11-可扩展架构内核架构

    导读:《架构设计》系列为极客时间李运华老师《从0开始学架构》课程笔记。本文为第十一部分。主要介绍了如何面向功能拆分架构,首先介绍了内核架构的基本架构设计,以及几种常见架构的实现与特点。 最后分享了内核架构典型开源规则引擎 JBoss Drools。 关注本公众号 回复 “架构设计” 获取架构设计笔记完整思维导图 基本架构 两类组件 核心系统(core system) 负责和具体业务功能无关的通用功能: 模块加载 模块间通信 插件模块(plug-in 规则引擎架构 规则引擎从结构上来看也属于内核架构的一种具体实现,其中执行引擎可以看作是内核,执行引擎解析配置好的业务流,执行其中的条件和规则,通过这种方式来支持业务的灵活多变。 实现 插件管理 规则引擎中的规则就是内核架构的插件,引擎就是内核架构的内核。规则可以被引擎加载和执行。 规则引擎架构中,规则一般保存在规则库中,通常使用数据库来存储。

    1.1K20编辑于 2022-08-19
领券