微服务
文章平均质量分 85
爱琴孩
扫盲+科普+解惑,愿天下程序员每天少掉头发
展开
-
精通微服务,没听过SkyWalking?
上一篇文章介绍了分布式链路追踪的一种方式:Spring Cloud Sleuth+ZipKin,这种方案目前也是有很多企业在用,但是作为程序员要的追逐一些新奇的技术,Skywalking作为后起之秀也是值得大家去学习的。skywalking是一个优秀的国产开源框架,2015年由个人吴晟(华为开发者)开源 , 2017年加入Apache孵化器。转载 2024-08-29 22:36:04 · 134 阅读 · 0 评论 -
SkyWalking 和 ELK 实现链路追踪的实践
SkyWalking和 ELK 各自在 APM 与日志管理领域发挥着重要作用,尽管原生 ELK 不直接支持链路追踪,但通过与 SkyWalking 的集成,可以互补优势,共同提升微服务架构下的可观测性。转载 2024-08-11 16:38:29 · 105 阅读 · 0 评论 -
微服务中的日志链路追踪
本篇通过拦截器、MDC 功能,全链路加入了 traceId,然后将 traceId 输出到日志中,就可以通过日志来追踪调用链路。不论是进程内的方法级调用,还是跨进程间的服务调用,都可以进行追踪。另外日志还需要通过 ELK Stack 技术将日志导入到 Elasticsearch 中,然后就可以通过检索 traceId,将整个调用链路检索出来了。转载 2024-08-11 16:20:25 · 170 阅读 · 0 评论 -
微服务鉴权的几种实现方案
但需要注意的是应该将Web项目的容器换成Undertow,因为Tomcat是阻塞式的容器,不换也不是不行,但吞吐量可能会少一下,Undertow是非阻塞式的容器,可以与Gateway到达相同的效果。根据需求积分服务提供了一个给用户添加积分的API,如果你的API是通过获取的当前登录用户ID增加的积分,那么面对场景二时你需要重新编写一个给用户添加积分的API,因为当前登录的是后台管理员而不是用户(代码复用率较低)。各位服务都有自己的鉴权方式,当然也可以通过jar包的方式统一各服务的鉴权方式。转载 2024-03-23 21:06:06 · 289 阅读 · 1 评论 -
微服务中网关是不是必需的?
但是这样一个请求就转发了两次,所以最好的方式是网关单点服务部署在一台牛逼的机器上(通过压测来估算机器的配置),而且nginx与zuul的性能比较,根据国外的一个哥们儿做的实验来看,其实相差不大,zuul是netflix开源的一个用来做网关的开源框架;由于每个服务都引入了这个公共服务,那么我们后续升级这个服务可能就比较困难,而且公共服务的功能越多,升级就越难,而且假设我们改变了公共服务中的权限校验的方式,想让所有的服务都去使用新的权限校验方式,我们就需要将之前所有的服务都重新引包,编译部署。转载 2023-11-11 23:03:12 · 86 阅读 · 0 评论 -
对象存储那点事
对象存储,也称为“面向对象的存储”,英文是 Object-based Storage。现在很多云厂商,也直接称之为“云存储”。不同的云厂商对它有不同的英文缩写命名。例如阿里云把自家的对象存储服务叫做 OSS,华为云叫 OBS,腾讯云叫 COS,七牛叫 Kodo,百度叫 BOS,网易叫 NOS……五花八门,反正都是一个技术。DAS 和 SAN 是基于物理块的存储方式,而 NAS 是基于文件的存储方式。在 DAS 和 SAN 中,存储资源就像一块一块的硬盘,直接挂载在主机上,我们称之为块存储。转载 2023-10-31 23:15:25 · 159 阅读 · 0 评论 -
9种分布式文件系统
POSIX表示可移植操作系统接口(Portable Operating System Interface of UNIX,缩写为 POSIX ),也就是Unix下应用程序共同遵循的一种规范。支持POSIX的应用程序意味着在各个Unix系统间提供了跨平台运行的支持。转载 2023-10-30 23:53:31 · 2406 阅读 · 0 评论 -
Thrift、Dubbo、Spring Cloud 和 gRPC
Thrift、Dubbo、Spring Cloud 和 gRPC 都是现代软件开发中广泛使用的开源框架,它们在分布式系统开发中扮演着重要的角色。原创 2023-09-09 22:08:51 · 496 阅读 · 0 评论 -
6 个维度搞懂 Nacos 注册中心
本篇文章向大家介绍 Nacos 服务发现的基本概念和核心能力以。转载 2023-09-06 21:35:44 · 208 阅读 · 0 评论 -
gRPC那点事
gRPC(gRPC Remote Procedure Call)是一种高性能、开源的远程过程调用(RPC)框架。它允许分布在不同计算机上的应用程序能够像调用本地方法一样进行通信,从而实现了在分布式系统中进行高效的通信。Protocol Buffers(ProtoBuf) 是一种用于序列化结构化数据的轻量级、高效的数据交换格式。它最初由 Google 开发,用于解决跨平台、跨语言通信以及数据持久化的问题。转载 2023-09-03 20:30:26 · 61 阅读 · 0 评论 -
详解分布式共识(一致性)算法Raft
所谓分布式共识(consensus),与CAP理论中的一致性(consistency)其实是异曲同工,就是在分布式系统中,所有节点对同一份数据的认知能够达成一致。保证集群共识的算法就叫共识算法,它与一致性协议这个词也经常互相通用。当今最著名的共识算法就是Paxos算法。它由Leslie Lamport在1990年提出,很长时间以来都是一致性的事实标准。但是它有两个不小的缺点:难以理解和证明,难以在实际工程中实现。转载 2023-08-26 13:07:13 · 317 阅读 · 0 评论 -
关于Ribbon,这一篇足矣
今天我们来看下微服务中非常重要的一个组件:Ribbon。它作为负载均衡器在分布式网络中扮演着非常重要的角色。在介绍 Ribbon 之前,不得不说下负载均衡这个比较偏僻的名词。为什么说它偏僻了,因为在面试中,聊得最多的是消息队列和缓存来提高系统的性能,支持高并发,很少有人会问负载均衡,究其原因,负载均衡的组件选择和搭建一般都是运维团队或者架构师去做的,开发人员确实很少接触到。不过没关系,我们不止有 CRUD,还要有架构思维。简单来说,负载均衡就是将网络流量(负载)分摊到不同的网络服务器(可以平均分配,也可以不转载 2023-07-30 16:13:37 · 153 阅读 · 0 评论 -
通过一次线上问题,讲下Ribbon重试机制
前段时间,产品经理在线上验证产品功能的时候,发现某个功能不符合需求预期,后来测试验证发现是服务端的一个接口大概率偶现超时,前端做了兜底处理,所以对线上用户么有太大影响。原创 2023-07-29 16:20:51 · 1026 阅读 · 0 评论 -
精通分布式,却不懂服务治理?
微服务化的架构给系统带来了很多好处,但同时也带来了一些技术上的挑战。这些挑战包括服务注册与发现、负载均衡、监控管理、发布升级、访问控制等。而服务治理就是对这些问题进行管理和预防,保证系统持续平稳地运行。本文所讲的服务治理方案,也算是传统意义上的方案,有时会有一些代码的侵入,而框架的选择也会对编程语言有限制。在云原生时代,的出现又把服务治理的话题带入一个新的阶段。Service Mesh请参见服务网格那些事。转载 2023-07-29 11:42:44 · 96 阅读 · 0 评论 -
服务网格那些事
服务网格是一个专用的基础架构层,用于管理分布式应用程序中各个微服务之间的通信。它充当透明且分散的代理网络,这些代理部署在应用服务旁边。这些代理通常被称为sidecar,它们处理服务之间的通信,提供诸如服务发现、负载均衡、流量路由、身份验证和可观测性等关键功能。通过将网络通信的复杂性抽象化,服务网格使开发人员能够专注于应用程序逻辑,而不必处理网络代码的复杂性。它提供了一种一致且灵活的处理跨服务通信的方式,并允许实现高级的流量管理策略、安全策略和可观测性机制。转载 2023-07-29 10:33:14 · 107 阅读 · 0 评论 -
ServiceRegistryEndpointConfiguration required a single bean, but 2 were found
公司之前微服务是以Eureka作为注册中心的,近期项目引入Nacos(版本2.2.0)作为配置中心,添加Nacos依赖之后,服务启动报错,报错信息如下。原创 2023-06-02 21:44:36 · 227 阅读 · 0 评论 -
微服务架构 - 如何做多层限流
令牌桶算法是较为常用的限流算法,可以控制请求的速率。模拟一个实际漏斗,每次请求相当于向漏斗中放水,当漏斗中的水超过固定高度时,拒绝新的请求,同时可以设置漏口的大小,控制处理速度。实际应用中,可以结合以上几种算法来实现微服务项目的限流,根据不同的场景和需求,选择合适的限流算法,同时应该对限流算法进行测试和性能调优,确保限流策略的可靠性和有效性。当然,不同的中间件实现方式不同,应该根据不同的场景选择一个或多个中间件限流,并结合具体的业务情况和系统瓶颈进行评估和调优,以达到更好的限流效果。下面是常用的限流功能。转载 2023-05-21 12:03:49 · 779 阅读 · 0 评论 -
Spring Cloud Gateway,看这篇足矣
比如客户端登录时,将用户名和密码发送给网关,网关转发给认证服务器后,如果账号密码正确,则拿到一个 JWT token,然后客户端再访问应用服务时,先将请求发送给网关,网关统一做 JWT 认证,如果 JWT 符合条件,再将请求转发给应用服务。这个没有问题,毕竟只是后端服务知道,外界是不知道的。,当匹配到这个路由后,会将请求转发到 passjava-member 服务,且支持负载均衡转发,也就是先将 passjava-member 解析成实际的微服务的 host 和 port,然后再转发给实际的微服务。转载 2023-05-20 09:35:59 · 200 阅读 · 0 评论 -
Bootstrap.yml那点事
若application.yml 和bootstrap.yml 在同一目录下:bootstrap.yml 先加载 application.yml后加载,bootstrap.yml 用于应用程序上下文的引导阶段。bootstrap.yml 由父Spring ApplicationContext加载。但是spring cloud用上了配置中心,就一个boostrap.yml,且不支持文件名的方式来区分。多个配置以 — 分开,然后通过spring.profiles=环境表示具体的环境配置.。原创 2023-04-02 18:58:46 · 1213 阅读 · 0 评论 -
微服务注册到Eureka之后调用不了
前段时间,有同事反馈开发联调环境有个订单服务访问不了,在Eureka页面上点击服务也是链接拒绝,很奇怪,连接访问的ip是一个陌生IP,并不是订单服务部署服务器的ip,后来查看了下服务网卡信息,发现服务器上挂载了一个新网卡。而服务注册到Eureka服务端就是172.30.32.16的地址。当时这个ip实际是访问不了的,所以就出现服务注册Eureka成功,但是服务调用不了。原创 2023-02-08 23:17:50 · 2659 阅读 · 0 评论 -
如何设置OpenFeign请求超时
Feign集成了Ribbon、RestTemplate实现了负载均衡的执行Http调用,只不过对原有的方式(Ribbon+RestTemplate)进行了封装,开发者不必手动使用RestTemplate调服务,而是定义一个接口,在这个接口中标注一个注解即可完成服务调用,这样更加符合面向接口编程的宗旨,简化了开发。但遗憾的是Feign现在停止迭代了。:OpenFeign是springcloud在Feign的基础上支持了SpringMVC的注解,如等等。OpenFeign的可以解析SpringMVC的。原创 2023-01-18 10:19:58 · 8182 阅读 · 1 评论 -
一张图搞懂微服务架构设计
当前,微服务架构在很多公司都已经落地实施了,下面用一张图简要概述下微服务架构设计中常用组件。不能说已经使用微服务好几年了,结果对微服务架构没有一个整体的认知,一个只懂搬砖的程序员不是一个好码农!在上图中可以看到,Nginx作为整个架构的流量入口,可以理解为一个外部的网关,它承担着请求的路由转发、负载均衡、动静分离等功能。作为一个核心入口点,Nginx肯定要采用多节点部署,同时通过LVS+keepalived来实现高可用,从而保障整个平台的高可用。网关是在Nginx后的另外一个核心组件。它承担着请求鉴权,路由原创 2022-12-04 12:59:26 · 17040 阅读 · 8 评论 -
网关那点事(四)
这里的性能主要指每节点每秒处理的请求数。面对以上问题,API GATEWAY是一个不错的解决方案,其所提供的访问限制、安全、流量控制、分析监控、日志、请求转发、合成和协议转换功能,可以解放开发者去把精力集中在具体逻辑的代码,而不是把时间花费在考虑如何解决应用和其他微服务链接的问题上。首先最底层是基于Nginx, Nginx是高性能的基础层, 一个良好的负载均衡、反向代理器,然后在此基础上增加Lua脚本库,形成了OpenResty,拦截请求, 响应生命周期,可以通过Lua编写脚本,所以插件比较丰富。转载 2022-11-27 16:37:21 · 314 阅读 · 0 评论 -
网关那点事(三)
作为微服务体系中的核心基础设施,一般需要具备接口管理、协议适配、熔断限流、安全防护等功能,各种开源的网关产品(比如 zuul)都提供了优秀高可扩展性的架构、可以很方便的实现我们需要的一些功能、比如鉴权、日志监控、熔断限流等。这里需要补充一点的是,业务网关一般部署在流量网关之后、业务系统之前,比流量网关更靠近业务系统。与流量网关相对应的就是业务网关,业务网关更靠近我们的业务,也就是与服务器应用层打交道,那么有很多应用层需要考虑的事情就可以依托业务网关,例如在线程模型、协议适配、熔断限流,服务编排等。转载 2022-11-27 15:50:47 · 256 阅读 · 0 评论 -
网关那点事(二)
我们可以让网关来帮客户端请求多个后端的服务(有些场景下完全可以并发请求),然后把后端服务的响应结果拼装起来,回传给客户端(当然,这个过程也可以做成异步的,但这需要客户端的配合)。网关上需要考虑应用性能的监控,除了有相应后端服务的高可用的统计之外,还需要使用 Tracing ID 实施分布式链路跟踪,并统计好一定时间内每个 API 的吞吐量、响应时间和返回码,以便启动弹力设计中的相应策略。因为所有的流量或调用经过网关,所以网关必须成为一个高可用的技术组件,它的稳定直接关系到了所有服务的稳定。转载 2022-11-27 12:55:12 · 280 阅读 · 0 评论 -
网关那点事(一)
微服务架构下,单体应用被切割成多个微服务,如果将所有的微服务直接对外暴露,势必会出现安全方面的各种问题,另外内外耦合严重。你看看,网关的作用是不是就是这三个, 最终目的就是减少你与集团的耦合,具体到计算机上就是减少客户端与服务端的耦合,如果没有网关意味着所有请求都会直接调用服务器上的资源,这样耦合太强了,服务器出了问题,客户端会直接报错, 例如老板换工作的地方了,如果没有网关你直接去原来的地方找, 肯定会被告知老板不在这儿。网关,很多地方将网关比如成门, 没什么问题, 但是需要区分网关与网桥的区别,转载 2022-11-27 12:32:57 · 454 阅读 · 0 评论 -
精通分布式,没听过SnowFlake?
SnowFlake 中文意思为雪花,故称为雪花算法。最早是 Twitter 公司在其内部用于分布式环境下生成唯一 ID。在2014年开源 scala 语言版本。雪花算法原理就是生成一个的64位比特位的 long 类型的唯一 id。6024可以将雪花算法作为一个单独的服务进行部署,然后需要全局唯一 id 的系统,请求雪花算法服务获取 id 即可。对于每一个雪花算法服务,需要先指定10位的机器码,这个根据自身业务进行设定即可。例如机房号+机器号,机器号+服务号,或者是其他可区别标识的10位比特位的整数值都行。.转载 2022-08-13 10:04:20 · 193 阅读 · 0 评论 -
分布式ID那点事
看了这么多个分布式 ID 的解决方案,那么我们到底应该选哪个呢?首先,对于 UUID 而言,其在各个方面其实都不如雪花算法,唯一的优点是 JDK 自带 API。因此,如果你只是极其简单地使用,那么就直接使用 UUID 就可以,毕竟雪花算法还得写一写实现代码呢。其次,对于类雪花算法而言,其毋庸置疑是非常好的一种实现。与 UUID 相比,其不仅有 UUID 本地生成、不依赖第三方系统的优点,还有业务含义、能提高写入性能、解决了安全问题。但其缺点在于要实现雪花算法的代码,因此其研发成本稍稍比 UUID 高一些。.转载 2022-08-13 09:48:34 · 253 阅读 · 0 评论 -
微服务、容器和 Kubernetes那点事
前言微服务只是一个运行在服务器或虚拟计算实例上并响应网络请求的计算机程序。这与典型的 Rails/Django/Node.js 应用程序有何不同?它根本上没有什么不同。事实上,您可能会发现您的组织中已经部署了十几个微服务。没有任何新的神奇技术使您的应用程序有资格称为微服务。微服务不是由它的构建方式来定义的,而是由它如何变成更通用的系统或解决方案来定义的。那么是如何使服务成为微服务呢?一般来说,微服务的范围更窄,专注于做好较小的任务。让我们通过看一个例子来进一步探索。微服务示例:亚马逊产品列表让我转载 2022-05-14 12:23:03 · 173 阅读 · 0 评论 -
分布式服务跟踪(整合zipkin)【Dalston版】
Zipkin简介Zipkin是Twitter的一个开源项目,它基于Google Dapper实现。我们可以使用它来收集各个服务器上请求链路的跟踪数据,并通过它提供的REST API接口来辅助我们查询跟踪数据以实现对分布式系统的监控程序,从而及时地发现系统中出现的延迟升高问题并找出系统性能瓶颈的根源。除了面向开发的API接口之外,它也提供了方便的UI组件来帮助我们直观的搜索跟踪信息和分析请求链路明细,比如:可以查询某段时间内各用户请求的处理时间等。上图展示了Zipkin的基础架构,它主要有4个核心转载 2021-12-04 21:51:09 · 288 阅读 · 0 评论 -
SOA和微服务的区别
场景:如果我们打开支付宝首页,去看我们的余额,它会展示你的总资产,昨日收益、累计收益等信息。假如这个页面所展示的信息,都来自各个不同的系统/应用,我们通过各个接口把这些数据展示出来。如果我们现在要在前端页面展示这几项数据的话,我们应该怎么去展示呢?在这种情况下,我们不可能让客户端与6个不同的应用/系统都一一去通信来去完成数据的展示。而是6个应用/系统之间进行彼此通信来完成调用,最后客户端只需要调用一个接口来获取数据即可,而不是与每一个应用/系统进行通信。我们的架构可能是如下的样子:一个电..转载 2021-10-18 20:57:19 · 145 阅读 · 0 评论 -
异常:MIME type may not contain reserved characters
前言在微服务技术栈中,我们会经常Fegin调用,Fegin确实简化了http调用细节,让我们可以像调用内部方法一样调用外部接口。但是Fegin调用也有很多问题,这里来和大家一起看看MIME type may not contain reserved characters异常。从问题中学习上个礼拜有个同事说是在本地调试fegin调用接口出现一个异常,具体异常如下根据异常堆栈,我们可以看到如下关键代码 private ContentType getContentType(Req.原创 2021-09-12 11:47:43 · 3299 阅读 · 0 评论 -
Spring Cloud核心组件之Eureka
前言前面Spring Cloud微服务架构入门中,我们介绍了Eureka作为注册中心在微服务架构中的作用,这里来和大家一起学习下Eureka的原理。Netflix Eureka1、Eureka服务端:也称服务注册中心,同其他服务注册中心一样,支持高可用配置。如果Eureka以集群模式部署,当集群中有分片出现故障时,那么Eureka就转入自我保护模式。它允许在分片故障期间继续提供服务的发现和注册,当故障分片恢复运行时,集群中其他分片会把它们的状态再次同步回来。2、Eureka客户端:主要处理服转载 2020-08-04 23:28:01 · 229 阅读 · 0 评论 -
撸明白分布式事务(四)
前言在分布式系统中,消息队列在服务端的架构中的地位非常重要,主要解决异步处理、系统解耦、流量削峰等场景。多个系统之间如果同步通信很容易造成阻塞,同时会将这些系统会耦合在一起。因此,引入了消息队列,一方面解决了同步通信机制造成的阻塞,另一方面通过消息队列进行业务解耦。简单的服务间调用引入mq如下图所示可靠事件模式可靠事件模式,通过引入可靠的消息队列,只要保证当前的可靠事件投递并且消息队列确保事件传递至少一次,那么订阅这个事件的消费者保证事件能够在自己的业务内被消费即可。这里,请读者思考,是否.转载 2020-06-14 16:40:32 · 256 阅读 · 0 评论 -
撸明白分布式事务(三)
前言前面说的二阶段提交协议和三阶段提交协议很好的解决了分布式事务的问题,但是在极端情况下仍然存在数据的不一致性,此外它对系统的开销会比较大,引入事务管理者(协调者)后,比较容易出现单点瓶颈,以及在业务规模不断变大的情况下,系统可伸缩性也会存在问题。注意的是,它是同步操作,因此引入事务后,直到全局事务结束才能释放资源,性能可能是一个很大的问题。因此,在高并发场景下很少使用。因此,阿里提出了另外一种解决方案:TCC 模式。注意的是,很多读者把二阶段提交等同于二阶段提交协议,这个是一个误区,事实上,TCC 模转载 2020-06-14 16:22:57 · 257 阅读 · 0 评论 -
撸明白分布式事务(二)
前言前面介绍了传统单库,单服务通过数据库的ACID模式来解决事务的一致性,但是随着数据量的变大,采用了分库策略。或者服务架构逐渐演变为微服务或者其他分布式架构。这时候ACID也只能鞭长莫及了。这里来和大家一起学习下应对这种问题强一致性解决方案。二阶段提交协议在分布式系统中,每个数据库只能保证自己的数据可以满足 ACID 保证强一致性,但是它们可能部署在不同的服务器上,只能通过网络进行通信,因此无法准确的知道其他数据库中的事务执行情况。因此,为了解决多个节点之间的协调问题,就需要引入一个协调者负责转载 2020-06-14 08:44:44 · 231 阅读 · 0 评论 -
撸明白分布式事务(一)
传统的ACID什么是事务?回答这个问题之前,我们先来看一个经典的场景:支付宝等交易平台的转账。假设小明需要用支付宝给小红转账 100000 元,此时,小明帐号会少 100000 元,而小红帐号会多 100000 元。如果在转账过程中系统崩溃了,小明帐号少 100000 元,而小红帐号金额不变,就会出大问题,因此这个时候我们就需要使用事务了。大致流程如下图这里,体现了事务一个很重要的特性:原子性。事实上,事务有四个基本特性:原子性、一致性、隔离性、持久性。其中,原子性,即事务内的操作要么全部成功,转载 2020-06-13 21:27:47 · 326 阅读 · 0 评论 -
微服务API网关那些事
前言微服务火了也有一段时间了,但是之前一直没有在项目中用过微服务。公司的项目从dubbo过渡到spring Cloud。结合这段时间的实际使用,打算系统地学习下spring Cloud微服务。微服务中涉及到的东西还是比较多的,系统的学习需要一步一步来,毕竟一口吃不成胖子嘛。这里先和大家一起学习一下微服务API网关。之前在上家公司有大佬培训(介绍)过这块,但是一直没有实际应用,后来渐渐都还回去了...原创 2019-04-07 20:28:11 · 727 阅读 · 0 评论 -
Eureka手动下线服务
前言在微服务开发中,经常会在开发环境进行服务调试。我们将本地服务注册到Eureke上,同时开发服务器上部署的服务也注册到Eureka中,这时候我们调用服务,有的请求将会被路由到开发环境服务器上。而我们想要请求路由到本地的服务中,明明在本地服务中打了断点,但是请求却被路由到服务器上,导致本地调试很不方便。对于这种情况,我们只需要把服务器中注册到Eureke中的服务下线,这样,我们就可以在本地进行...原创 2019-05-19 16:57:04 · 11293 阅读 · 0 评论 -
Spring Cloud微服务架构入门(三分钟看懂)
前言Spring Cloud作为当下主流的微服务框架,可以让我们更简单快捷地实现微服务架构。Spring Cloud并没有重复制造轮子,它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来,通过Spring Boot风格进行再封装,屏蔽掉了复杂的配置和实现原理,最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。Spring Cloud中各个组件在微服务架...转载 2019-07-27 16:27:33 · 341 阅读 · 0 评论