微服务及分布式框架
文章平均质量分 67
AlbenXie
这个作者很懒,什么都没留下…
展开
-
微服务2:微服务全景架构
微服务架构提倡的单一应用程序划分成一组松散耦合的细粒度小型服务,辅助轻量级的协议,互相协调、互相配合,实现高效的应用价值,符合我们应用服务开发的发展趋势。后续我们围绕它的核心模块:服务注册与发现、API 网关服务、分布式配置中心、服务通信、服务治理、分布式服务追踪与监控等,从原理到实践,一步步展开来研究。转载 2023-04-24 18:33:46 · 315 阅读 · 0 评论 -
微服务3:微服务拆分策略
先少后多(微服务数量)、先粗后细(粒度)基于业务逻辑进行拆分(用户群体、业务领域等模型)基于可靠性(核心模块独立化、主次链路隔离)基于性能拆分(独立拆分高性能场景)接口需保证幂等接口数据定义严禁内嵌,透传规范化工程结构,符合微服务风格不止对计算服务记性拆分,服务层 -> 缓存层 -> 数据层 的逐步拆解,才能发挥最大功效。转载 2023-04-24 13:10:01 · 516 阅读 · 0 评论 -
细数线程池的10个坑
使用线程池时,如果没有给线程池一个有意义的名称,将不好排查回溯问题。这不算一个坑吧,只能说给以后排查埋坑,哈哈。我还是单独把它放出来算一个点,因为个人觉得这个还是比较重要的。/*** 关注公众号:捡田螺的小男孩*/System.out.println("关注公众号:捡田螺的小男孩");});关注公众号:捡田螺的小男孩可以发现,默认打印的线程池名字是,如果排查问题起来,并不友好。因此建议大家给自己线程池自定义个容易识别的名字。其实用。转载 2023-04-23 18:03:29 · 300 阅读 · 0 评论 -
延时任务-基于redis zset的完整实现
所谓的延时任务给大家举个例子:你买了一张火车票,必须在30分钟之内付款,否则该订单被自动取消。这两种方法都有一个缺点:都是基于单体应用的内存的方式运行延时任务的,一旦出现单点故障,可能出现延时任务数据的丢失。所以此篇文章给大家介绍实现延时任务的第三种方式,结合redis zset实现延时任务,可以解决单点故障的问题。给出实现原理、完整实现代码,以及这种实现方式的优缺点。转载 2023-04-23 17:40:16 · 634 阅读 · 0 评论 -
消息队列常见问题总结
如果采用推送的方式,A 系统通过接口调用发送数据到 B、C、D 三个系统,A 系统的维护成本就非常的高,而且 A 系统要时时刻刻考虑B、C、D 四个系统如果出现故障该怎么办?使用消息队列就可以解决这个问题。A 系统只负责生产数据,不需要考虑消息被哪个系统来消费。转载 2023-04-23 17:36:23 · 140 阅读 · 0 评论 -
RabbitMQ实现订单超时案例
DelayQueue是java并发包下的延时阻塞队列,常用于实现定时任务。DelayQueue是一个支持延时获取元素的无界阻塞队列。里面的元素全部都是“可延期”的元素,列头的元素是最先“到期”的元素,如果队列里面没有元素到期,是不能从列头获取元素的,哪怕有元素也不行。也就是说只有在延迟期到时才能够从队列中取元素。DelayQueue主要用于两个方面:- 缓存:清掉缓存中超时的缓存数据- 任务超时处理DelayQueue实现了BlockingQueue,所以它是一个阻塞队列。转载 2023-04-23 11:04:32 · 901 阅读 · 0 评论 -
Lombok原理就是这么简单
从上面的Lombok执行的流程图中可以看出,在Javac 解析成AST抽象语法树之后, Lombok 根据自己编写的注解处理器,动态地修改 AST,增加新的节点(即Lombok自定义注解所需要生成的代码),最终通过分析生成JVM可执行的字节码Class文件。接下来,我们进行lombok的原理分析,以Oracle的javac编译工具为例。编译机会调用lombok程序对第一步得到的AST进行处理,找到其注解所在类对应的语法树(AST),然后修改该语法树,增加注解对应的方法或代码片段到定义的相应树节点;转载 2023-02-24 17:27:10 · 431 阅读 · 0 评论 -
系统设计系列之如何设计一个短链服务
短链服务其实比较简单,没有太多的业务逻辑,主要考察对于分布式系统常用设计的理解,也是经常被用在面试过程中的一道题。这里只是提供大家一些设计思路,文中涉及到的发号器(分布式ID)、布隆过滤器、MurmurHash等都没有太过深入,因为每一个都不是三言两语可以说明白的,需要大家自行解决了。转载 2023-02-06 14:05:20 · 482 阅读 · 0 评论 -
java 实现 生成短链接服务
现在常用的还是第二种,用自增的发号器生成对应的短链接。生产环境要用,可以用数据库的自增id来发号,或者分布式下生成id用类似雪花算法来发号。同时,避免原始链接重复,可做重复判断,可用布隆过滤器或redis长链接和短链接的对应关系,可保存在数据库,也可保存在类似redis中,顺带还可以设置过期时间。也有开源的生成短链接的,比如yourls,PHP实现,安装只需要装PHP和mysql即可。转载 2023-02-03 16:46:53 · 1817 阅读 · 0 评论 -
Nacos 集群部署3
这里只是测试,使用的单机版nginx为Nacos集群提供一个统一的入口并使用默认的轮询策略实现简单的负载均衡。准备四台网络互通并能上外网的主机,这里使用的是四台虚拟机,Nacos节点所需的JDK和Maven均已装好。挂载SLB模式(内网SLB,不可暴露到公网,以免带来安全风险),直连SLB即可,下面挂server真实ip,可读性不好。域名 + SLB模式(内网SLB,不可暴露到公网,以免带来安全风险),可读性好,而且换ip方便,推荐模式。在3个Nacos节点上都执行以下命令进入Nacos Server的。转载 2023-01-11 16:05:30 · 490 阅读 · 0 评论 -
Nacos 集群部署2
Nacos支持三种部署模式单机模式 - 用于测试和单机试用。集群模式 - 用于生产环境,确保高可用。多集群模式 - 用于多数据中心场景。注:本文以Linux CentOS7系统为讲述如何部署集群模式(cluster);(虚拟机使用VMware)老规矩环境准备,请确保是在环境中安装使用:64 bit OS Linux/Unix/Mac,推荐使用Linux系统。下载.配置。下载.配置。集群需要依赖mysql,单机可不必3个或3个以上Nacos节点才能构成集群。转载 2023-01-10 18:08:47 · 452 阅读 · 0 评论 -
Nacos 集群部署1
在所有 nacos目录的conf的目录下,有个文件 cluster.conf.example ,将其命名为 cluster.conf,并将每行配置成ip:port。(请配置3个或3个以上节点)在所有 nacos目录的conf的目录下,有个文件 application.properties ,并将修改端口和地址、配置数据库连接。转载 2023-01-10 17:40:34 · 365 阅读 · 0 评论 -
Kafka消息数据积压如何处理
消费能力不足,则可以考虑增加Topic的分区数(一般一个Topic分区数为3-10个),并且同时提升消费组的消费者数量,消费者数==分区数。2、如果是下游的数据处理不及时:则提高每批次拉取的数量。批次拉取数据过少(拉取数据/处理时间转载 2022-12-13 11:18:15 · 365 阅读 · 0 评论 -
Kafka消息数据积压如何处理
消费能力不足,则可以考虑增加Topic的分区数(一般一个Topic分区数为3-10个),并且同时提升消费组的消费者数量,消费者数==分区数。2、如果是下游的数据处理不及时:则提高每批次拉取的数量。批次拉取数据过少(拉取数据/处理时间转载 2022-12-13 11:16:54 · 376 阅读 · 0 评论 -
Kafka消息数据积压如何处理
消费能力不足,则可以考虑增加Topic的分区数(一般一个Topic分区数为3-10个),并且同时提升消费组的消费者数量,消费者数==分区数。2、如果是下游的数据处理不及时:则提高每批次拉取的数量。批次拉取数据过少(拉取数据/处理时间转载 2022-12-13 11:16:43 · 539 阅读 · 0 评论 -
利用redis生成流水号
利用redis生成流水号转载 2022-12-06 10:14:06 · 372 阅读 · 1 评论 -
使用 Redis 实现自增流水号
项目上有个场景是客餐申请审核以后需要生成一个流水号,规则为:202202150001,202202150002,前几位为年月日,后四位依次递增。想到 Redis 是基于内存操作的,而且速度比较快,也不占用数据库资源。于是便采用 Redis 实现的方式。形成规则工具类:获取递增:具体实现:输出结果:本地 Redis 库中的数据: Redis 序列化的策略有两种,分别是 StringRedisTemplate 和 RedisTemplate,其中StringRedisTemplate 用转载 2022-12-06 10:12:52 · 2973 阅读 · 0 评论 -
RestTemplateUtil工具类
【代码】RestTemplateUtil工具类。转载 2022-11-28 20:49:39 · 1052 阅读 · 0 评论 -
Mybatis-plus 分页查询超过最大页数返回空数据问题
其中的paginationInnerInterceptor.setOverflow(true) 这个就是针对此问题的解决方案,意思就是-溢出总页数的时候默认是跳到第一页。类com/baomidou/mybatisplus/extension/plugins/inner/PaginationInnerInterceptor.java。即:total/pageSize = 40/10 = 4(页数) < 5(要访问的页)从上面源码中可以看出,如果溢出总页数的时候默认是跳到第一页。数据库查询返回的数据为空。转载 2022-11-22 15:49:29 · 3335 阅读 · 0 评论 -
RedisConfig
【代码】RedisConfig。原创 2022-11-21 19:51:41 · 109 阅读 · 0 评论 -
蓝绿发布、滚动发布、灰度发布(金丝雀发布)、A/B测试
验证新版本符合预期后,逐步调整流量权重比例,使得流量慢慢从老版本迁移至新版本,期间可以根据设置的流量比例,对新版本服务进行扩容,同时对老版本服务进行缩容,使得底层资源得到最大化利用。所谓滚动升级,就是在升级过程中,并不一下子启动所有新版本,是先启动一台新版本,再停止一台老版本,然后再启动一台新版本,再停止一台老版本,直到升级完成,这样的话,如果日常需要10台服务器,那么升级过程中也就只需要11台就行了。相比于前两种发布策略,灰度发布的思想则是将少量的请求引流到新版本上,因此部署新版本服务只需极小数的机器。转载 2022-11-17 10:57:28 · 1420 阅读 · 0 评论 -
架构师学习笔记(四)架构师线路之系统架构师&企业架构师
系统架构师是一个最终确认和评估系统需求,给出开发规范,搭建系统实现的核心构架,并澄清技术细节、扫清主要难点的技术人员。主要着眼于系统的“技术实现”。因此他/她应该是特定的开发平台、语言、工具的大师,对常见应用场景能给出最恰当的解决方案,同时要对所属的开发团队有足够的了解,能够评估自己的团队实现特定的功能需求需要的代价。系统架构师负责设计系统整体架构,从需求到设计的每个细节都要考虑到,把握整个项目,使设计的项目尽量效率高,开发容易,维护方便,升级简单等。转载 2022-10-19 16:59:56 · 778 阅读 · 0 评论 -
架构师学习笔记(三)架构师线路之业务架构师
业务架构师往往擅长对专业领域做业务建模,经过多年业务的熏陶成为细分领域的专家。业务架构师负责在组织或公司实施成功的战略。这种类型的架构师不处理字面上的蓝图和平面图,也不在架构师工作室工作。相反,业务架构师是一个现代架构师,他必须能够设想一个企业的几个不同要素,并使它们协调一致地工作,他或她还必须能够用未来主义的术语来思考,并确定企业的发展方向业务架构师可以作为全职员工或承包商和顾问工作。业务架构师可以作为全职员工或承包商工作组织需要一个持续的业务架构师或项目架构师。转载 2022-10-19 16:57:19 · 203 阅读 · 0 评论 -
架构师学习笔记(二)架构师线路之应用领域架构师
本篇文章,我们着重了解应用领域架构师。应用领域架构师负责从应用程序的,负责某个应用的技术架构,主要偏业务系统,关注理解业务,梳理模型,设计模式,接口,数据交互等方面。转载 2022-10-19 16:32:03 · 189 阅读 · 0 评论 -
我们从来都反对“大中台,小前台”的架构设计
此时,业务中台诞生了。中台,是共性业务的部分。问题:中台,应该做厚还是做薄?最早,阿里提出了“大中台,小前台”的中台战略。对此,快狗打车有不同的看法,中台太厚,势必夹杂个性化业务逻辑,不要让中台成为业务发展的瓶颈,我们提倡“小中台,大前台”,只有足够通用的业务,才适合下沉到中台。转载 2022-10-19 16:20:46 · 932 阅读 · 0 评论 -
关于去中台化的一点思考
大概意思就是所有的公共逻辑都给你定义好了,你想创新还创新不了,我只能说这个中台没留钩子,没给自定义的后门,让你们家的中台设计者好好思考一下,中台没能约束你创新,是你的中台本身没创新,产品逻辑还没捋顺,这个道理大家应该很清楚;1、中台是反创新的,中台最擅长的不是创新,而是复制,是管控,是创新的反面,中台擅长从1到100,但是却无法解决从0到1的问题,因为所有的创新,一定是底层的,当底层已经被中台定义好,那么也就失去了创新的所有可能。阿里云,华为云不也是中台吗?真的是中台不行了,还是你家的中台不行?转载 2022-10-18 15:47:57 · 1662 阅读 · 0 评论 -
中台彻底搞砸了?下一站,小中台大前台
以电商行业为例,一家大型零售公司,包括社区拼团、电商、线下超市、B2B等业务模式,真正具备业务共性的,往往是具备高度抽象的业务实例,比如:用户、商家、订单、支付。这个时候,中台建设进入到了碎片化中台阶段,组织和业务线拆分得更细粒度,比如:安全中台、财务中台、移动中台、客服中台、供应商中台、物流中台等等。在过去几年里,中台解决了大型企业“烟囱”的问题、山头林立的问题,使得企业的生产力被进一步的释放。,各业务线团队,既是服务调用方,也是服务提供方,在中台组织的指导之下,将各业务线的服务能力,开放给其它业务方。转载 2022-10-18 14:51:09 · 228 阅读 · 0 评论 -
“中台”仅用5年就消失了?
可现在的问题是,互联网时代,用户的新鲜感和注意力比任何时候都转移得更快,早些年的积累下来的习惯,也极有可能在短期内就悄悄改变——可是中台所有通用功能全都是在多年的业务经验当中积攒下来的,太通用的东西,注定不太可能跟创新沾边,一旦业务场景发生一百八十度大转变,那怕是立马就要失灵了。但很明显,中台作为这样一个“庞然大物”,什么都往里面都装,什么都通用,是很难调转方向作出颠覆性创新的,除非拆了重建——可现在的问题是,中台建设的工程量浩大,不要说短期内,就算是一年两年也未必能完成。转载 2022-10-13 23:09:03 · 658 阅读 · 0 评论 -
中台是不是要凉了
中台最早是由阿里巴巴推动在国内火起来的,早在2015年,马云带领阿里多位高管拜访芬兰著名的游戏公司Supercell,看到平均一款游戏落地只需要5~7人,被这种高效工作模式触动。于是,开始在公司内部尝试“大中台,小前台”的架构模式,诞生了阿里巴巴中台战略。经过15、16两年的时间孕育,在2017年,中台的声音越来越大,很多大厂开始开始搞中台建设,市面上关于中台建设的分享经验也多了起来。中台极大的释放了企业创新和变革的能力,像阿里的盒马、钉钉都是阿里中台创新的成果。18年、19年可谓是中台发展元年,很多中小厂转载 2022-10-13 23:03:09 · 145 阅读 · 0 评论 -
中台现在已经凉了吗
B业务系统来了,说想在登录失败N次后,给用户发送短信提醒,发送邮件提醒,平台开发人员和业务只好扑腾扑腾派两个人去接这些需求。当我们平台开发人员并不能确保我们能搞清楚业务人员的需求是产品经理拍脑袋,还是实际需求时,大量频繁地平台开发,甚至规则变更。无论对平台的稳定性和业务团队来说,都是灾难性的。开始总是分分钟都妙不可言,我们设计的平台总能非常好地满足业务的诉求,对于一些需要扩展平台能力的地方,也响应得比较及时。根据我们的设计一个登录服务平台,大体需要提供发送验证码,注册,登录,登出,身份/权限验证 等服务。转载 2022-10-13 22:44:10 · 200 阅读 · 0 评论 -
数据中台为什么搞不下去了
搞数据的都知道,阿里发明了数据中台,然后“”这个概念就马上成为了国内大多数企业趋之若鹜的风口,真正实施后却发现中台与数据平台、数据湖等项目大差不差,又有好多机构开始忙着拆中台了,中台虽然还没到人见人烦的地步,但总体来讲已经不那么受待见了。我发现网上也有很多文章进行分析,但大多是长篇大论,表述也过于技术,今天我就用最通俗的话跟大家解释一下。转载 2022-10-13 22:35:33 · 197 阅读 · 0 评论 -
架构师学习笔记(一)技术债的危害和治理
参考连接:https://www.bilibili.com/video/BV1FP4y177it?稳定压倒一切VS落后就要挨打。转载 2022-10-10 11:07:32 · 192 阅读 · 0 评论 -
阿里DTS 学习笔记
DTS(Data Transmission Service, 数据传输服务),用于在关系型数据库、NoSQL数据库、数据仓库之间迁移数据。可以使用DTS将数据迁移至阿里云,也可以在阿里云和本地数据系统之间做数据迁移。转载 2022-10-09 09:46:01 · 5238 阅读 · 0 评论 -
架构师之路:微服务拆分的规范
微服务接口之间传递数据,往往通过数据结构,如果数据结构透传,从底层一直到上层使用同一个数据结构,或者上层的数据结构内嵌底层的数据结构,当数据结构中添加或者删除一个字段的时候,波及的面会非常大。因而接口数据定义,在每两个接口之间约定,严禁内嵌和透传,即便差不多,也应该重新定义,这样接口数据定义的改变,影响面仅仅在调用方和被调用方,当接口需要更新的时候,比较可控,也容易升级。原创 2022-09-21 16:19:21 · 1076 阅读 · 0 评论 -
微服务拆分:业务横向拆分和纵向拆分
大规模系统架构的设计一般原则就是尽可能地拆分,以达到更好的独立扩展与伸缩、更灵活的部署、更好的隔离和容错、更好的开发效率。纵向拆分主要从业务角度进行,根据业务分割为不同的子系统;而横向拆分侧重于原业务深入拆分,然后服务重组。具体的拆分策略大体上可以分为。转载 2022-09-21 15:55:57 · 1266 阅读 · 0 评论 -
什么是架构?架构的本质和作用!
架构一个系统在其所处环境中所具备的各种基本概念和属性,具体体现为其所包含的各个元素、他们之间的关系以及架构的设计和演进原则之中。架构的本质就是对系统进行有序化地重构以致符合当前业务的发展,并可以快速扩展。视角(Viewpoint):一个针对某视图所采用的观察角度的定义,是构建和使用某视图的规约的描述(通常采用一个适当的模式或模版的形式)。通俗的说,视图描述了所看到的内容;而视角则描述了站在何处进行观察——一个能够决定你所能看到的事物的制高点或角度。视图(View):针对一系列相互关联的关注点的表达。转载 2022-09-21 15:04:45 · 2007 阅读 · 0 评论 -
架构师成长之路:什么是软件框架?框架和设计模式什么关系?
如同上图,大长方块代表最终要完成的功能,蓝色代表我们要实现的功能,所以,要完成实际的功能,可能的情况就是:我们做一部分,框架做一部分,然后我们再做一部分,然后框架再做一部分,最后我们再做一部分,终于完成了实际的功能。在实际工作中,框架和我们实现的功能,分得特别清楚,泾渭分明,通常只是一种理想情况,实际的情况是,我们的实现和框架提供的功能,经常是交织在一起的,犬齿交互,是融合的这么一个状态。来理解一下这句话:框架是软件,也就是说,框架不再是一个思想上的产物,而是一个已经落地实现,真实可用的软件。转载 2022-09-21 14:53:33 · 477 阅读 · 0 评论 -
架构师成长之路:概要设计到底做什么?怎么做?任务和方法?
然后再结合着具体业务,来进行选择使用。这个不一定是每个项目都需要的,主要是针对项目中的重难点技术点、不确定的技术点,进行实际开发前的技术研究,以确保在现有的架构设计和技术体系下,能合理的实现这些功能点或技术点。如果是微服务架构,这个可能会更麻烦一些,假如选择的是SpringCloud,那么它不同的版本所包含的技术组件是不一样的,组合方式也不一样,直接会影响到整个技术实现。这里会设计具体的功能,只不过是把一些具体的、通用的功能做了一定的抽象和封装,并考虑未来具体应用,该如何简单的来使用这些功能。转载 2022-09-21 14:42:57 · 316 阅读 · 0 评论 -
架构师成长之路:如何进行服务模块拆分(架构师方法经验干货)
前面已经讲到了系统高层架构设计落地的第一步,确定系统边界。接下来具体地看看系统高层架构设计落地的第二步:如何进行服务拆分,这也是很多新手架构师犯怵的地方,一起来看看吧。转载 2022-09-21 13:56:40 · 752 阅读 · 0 评论 -
微服务拆分之道
服务拆分之后,由于服务是以独立进程的方式部署,所以服务之间通信就不再是进程内部的方法调用而是跨进程的网络通信了。在这种通信模型下服务接口的定义要具备可扩展性,否则在服务变更时会造成意想不到的错误。比如微服务的接口因为升级把之前的三个参数改成了四个,上线后导致调用方大量报错,推荐做法服务接口的参数类型最好是封装类,这样如果增加参数就不必变更接口的签名,而只需要在类中添加字段就可以了。原创 2022-09-20 16:58:53 · 623 阅读 · 0 评论