Java设计模式,架构设计等思想
文章平均质量分 70
不同的业务场景,不同的架构设计,DDD等
AlbenXie
这个作者很懒,什么都没留下…
展开
-
Bridge设计模式
Bridge设计模式:分离抽象和具体,然后抽象部分可以按照自己的继承树来发展;同样具体部分也可以按照自己的继承树来发展;最后用聚合方式(桥)连接抽象和具体。原创 2023-05-28 20:36:20 · 108 阅读 · 0 评论 -
Adapter(Wrapper)设计模式
Adapter(Wrapper)模式-适配器/接口转换器通俗解释:当一个类不能直接访问另外一个类的时候,中间加一个转换;就叫适配器。原创 2023-05-28 19:54:02 · 125 阅读 · 0 评论 -
微服务2:微服务全景架构
微服务架构提倡的单一应用程序划分成一组松散耦合的细粒度小型服务,辅助轻量级的协议,互相协调、互相配合,实现高效的应用价值,符合我们应用服务开发的发展趋势。后续我们围绕它的核心模块:服务注册与发现、API 网关服务、分布式配置中心、服务通信、服务治理、分布式服务追踪与监控等,从原理到实践,一步步展开来研究。转载 2023-04-24 18:33:46 · 317 阅读 · 0 评论 -
微服务3:微服务拆分策略
先少后多(微服务数量)、先粗后细(粒度)基于业务逻辑进行拆分(用户群体、业务领域等模型)基于可靠性(核心模块独立化、主次链路隔离)基于性能拆分(独立拆分高性能场景)接口需保证幂等接口数据定义严禁内嵌,透传规范化工程结构,符合微服务风格不止对计算服务记性拆分,服务层 -> 缓存层 -> 数据层 的逐步拆解,才能发挥最大功效。转载 2023-04-24 13:10:01 · 525 阅读 · 0 评论 -
延时任务-基于redis zset的完整实现
所谓的延时任务给大家举个例子:你买了一张火车票,必须在30分钟之内付款,否则该订单被自动取消。这两种方法都有一个缺点:都是基于单体应用的内存的方式运行延时任务的,一旦出现单点故障,可能出现延时任务数据的丢失。所以此篇文章给大家介绍实现延时任务的第三种方式,结合redis zset实现延时任务,可以解决单点故障的问题。给出实现原理、完整实现代码,以及这种实现方式的优缺点。转载 2023-04-23 17:40:16 · 642 阅读 · 0 评论 -
RabbitMQ实现订单超时案例
DelayQueue是java并发包下的延时阻塞队列,常用于实现定时任务。DelayQueue是一个支持延时获取元素的无界阻塞队列。里面的元素全部都是“可延期”的元素,列头的元素是最先“到期”的元素,如果队列里面没有元素到期,是不能从列头获取元素的,哪怕有元素也不行。也就是说只有在延迟期到时才能够从队列中取元素。DelayQueue主要用于两个方面:- 缓存:清掉缓存中超时的缓存数据- 任务超时处理DelayQueue实现了BlockingQueue,所以它是一个阻塞队列。转载 2023-04-23 11:04:32 · 929 阅读 · 0 评论 -
nacos+ribbon+feign+gateway设计实现灰度方案
2、服务消费者基于 Feign 调用服务提供者对外发布的接口,先对调用的本地接口加上注解@FeignClient,Feign会针对 加了该注解的接口生成动态代理,服务消费者会针对 Feign 生成的动态代理去调用方法时,在底层会生成Http协议格式的请求,类似 /stock/deduct?ZuulFilter, 后面的案例多了, 我们就发现, 其实zuul网关的本质就是拦截器, zuul的各种功能,也是通过拦截器来实现的。1. 根据需要设置灰度规则, 比如: 城市, 大班, 小班, 版本号, 学科等,转载 2023-02-21 21:32:32 · 1446 阅读 · 0 评论 -
利用阿里云的MSE,上一个真正的灰度发布方案
如果路由线上版本,返回:device.v1111 -> charge.v1111 --> order.v1111 --> base.v1111 (userId: xxx)如果路由灰度版本,返回:device.v1111 -> charge.v2222 --> order.v2222 --> base.v1111 (userId: xxx)例如桩服务中设置mse-deviceCode,网关服务设置mse-userId, mse-userName, mse-ipAddress等。转载 2023-02-21 17:23:44 · 633 阅读 · 0 评论 -
全链路灰度新功能:MSE上线配置标签推送
然而配置中心的管理维度仅仅是配置项本身,并不能感知到前来获取配置的服务实例的环境信息,即无法区分请求配置的是正式环境的实例还是灰度环境的实例。更极端的场景下,如果在测试的灰度环境还有多套,每套环境中的配置值都不同,负责获取配置项的代码还会更复杂。在弹出的推送窗口中,我们选择需要推送的标签,并设置待推送的配置值,点击“下一步:值对比”,可以看到新老配置项的差异。除了微服务实例和流量的灰度,微服务应用中的配置项也应该具备相应的灰度能力,以应对灰度应用对特殊配置的诉求。针对标签的配置值推送都是持久化的。转载 2023-02-21 14:34:49 · 151 阅读 · 0 评论 -
Kafka如何处理大量积压消息
1. 如果是Kafka消费能力不足,则可以考虑增加 topic 的 partition 的个数,1. 消费kafka消息时,应该尽量减少每次消费时间,可通过减少调用三方接口、读库等操作,Kafka分区数是Kafka并行度调优的最小单元,如果Kafka分区数设置的太少,产生消息堆积,消费不及时,kafka数据有过期时间,一些数据就丢失了,主要是消费不及时。(拉取数据/处理时间 < 生产速度),使处理的数据小于生产的数据,也会造成数据积压。3. 每次接受kafka消息时,先打印出日志,包括消息产生的时间戳。转载 2022-12-15 15:00:02 · 9523 阅读 · 0 评论 -
Kafka消息积压
本次出现的问题是由于客户端的消息消费逻辑耗时太长,如果生产端出现消息发送增多,消费端每次都拉取了 500 条消息进行消费,这时就很容易导致消费时间过长,如果超过了 max.poll.interval.ms 所设置的时间,就会被消费组所在的 coordinator 剔除掉,从而导致重平衡,Kafka 重平衡过程中是不能消费的,会导致消费组处于类似 stop the world 的状态下,重平衡过程中也不能提交位移,这会导致消息重复消费从而使得消费组的消费速度下降,导致消息堆积。转载 2022-12-13 12:14:54 · 347 阅读 · 0 评论 -
平时只会用Kafka发消息,昨天突然遇到一次Kafka消息堆积生产事故!
线上kafka消息堆积,所有consumer全部掉线,到底怎么回事?最近处理了一次线上故障,具体故障表现就是kafka某个topic消息堆积,这个topic的相关consumer全部掉线。整体排查过程和事后的复盘都很有意思,并且结合本次故障,对kafka使用的最佳实践有了更深刻的理解。好了,一起来回顾下这次线上故障吧,最佳实践总结放在最后,千万不要错过。1、现象线上kafka消息突然开始堆积消费者应用反馈没有收到消息(没有处理消息的日志)kafka的consumer group上看没有消费者注册。转载 2022-12-13 12:10:08 · 510 阅读 · 0 评论 -
kafka消息积压解决
Kafka分区数是Kafka并行度调优的最小单元,如果Kafka分区数设置的太少,会影响Kafka Consumer消费的吞吐量。如果数据量很大,Kafka消费能力不足,则可以考虑增加Topic的Partition的个数,同时提升消费者组的消费者数量。使用Kafka Producer消息时,可以为消息指定key,但是要求key要均匀,否则会出现Kafka分区间数据不均衡。如果消费任务宕机时间过长导致积压数据量很大,除了重新启动消费任务、排查问题原因,还需要解决消息积压问题。解决消息积压可以采用下面方法。转载 2022-12-13 11:51:32 · 4737 阅读 · 0 评论 -
Kafka消息积压的原因和处理的方法
作为目前主流的消息中间件,被广泛的应用在了生产环境中。消息积压是日常生产经常遇到的问题,下面我们来展开了说一下。转载 2022-12-13 11:48:57 · 806 阅读 · 0 评论 -
Kafka-消息积压处理方案
如果现在资源不够了,简单啊,给topic增加partition,然后做数据迁移,增加机器,不就可以存放更多数据,提供更高的吞吐量了?那落磁盘的时候怎么落啊?首先,临时写个程序,连接到mq里面消费数据,收到消息之后直接将其丢弃,快速消费掉积压的消息,降低MQ的压力,然后走第二种方案,在晚上夜深人静时去手动查询重导丢失的这部分数据。其实回答这类问题,说白了,起码不求你看过那技术的源码,起码你大概知道那个技术的基本原理,核心组成部分,基本架构构成,然后参照一些开源的技术把一个系统设计出来的思路说一下就好。转载 2022-12-13 11:45:01 · 1179 阅读 · 0 评论 -
如何解决Kafka消息积压问题
通常情况下,企业中会采取轮询或者随机的方式,通过Kafka的producer向Kafka集群生产数据,来尽可能保证Kafk分区之间的数据是均匀分布的。如果对Kafka不了解的话,可以先看这篇博客《》。转载 2022-12-13 11:37:52 · 1510 阅读 · 0 评论 -
利用redis生成流水号
利用redis生成流水号转载 2022-12-06 10:14:06 · 379 阅读 · 1 评论 -
使用 Redis 实现自增流水号
项目上有个场景是客餐申请审核以后需要生成一个流水号,规则为:202202150001,202202150002,前几位为年月日,后四位依次递增。想到 Redis 是基于内存操作的,而且速度比较快,也不占用数据库资源。于是便采用 Redis 实现的方式。形成规则工具类:获取递增:具体实现:输出结果:本地 Redis 库中的数据: Redis 序列化的策略有两种,分别是 StringRedisTemplate 和 RedisTemplate,其中StringRedisTemplate 用转载 2022-12-06 10:12:52 · 3031 阅读 · 0 评论 -
java中日志打印规范
根据不同的日志级别,打印在不同的日志文件中,例如debug、info、warn、error日志级别的日志分别创建一个日志文件debug.log、info.log、warn.log、error.log进行日志打印;使用log来打印日志会记录到日志文件中,占用的是磁盘内存,一般不会经常出现卡(运行极慢)的现象,但如果磁盘内存占用比较高时,需要对日志进行备份处理,然后清理日志;业务系统中,核心功能的代码,尽可能打印日志完整,核心代码执行频率极高,出问题时,根据日志信息能快速定位。转载 2022-12-01 15:34:50 · 3700 阅读 · 0 评论 -
关于架构师的一点思考
但是,这个程序还是被推倒了,当然也有其公司派系斗争的因素在里面。但是,不得不引起我们的注意,这个程序败就败在了太拘泥于细节,而忽略了顶层设计被客户牵着鼻子走,想知道客户自己说什么吗?某公司,建立的程序又被推倒,外人觉得很奇怪,这个程序的主管非常敬业,关注到了程序每一个细节,甚至包括每一个按钮的文字和位置。可以从看似复杂的东西中找到共性,抽象出共性的东西,以最直接和最简洁的方案通过逻辑构造出千奇百怪的应用结构!这个主管很委屈,他说,他完全是按照客户需求制作的,客户怎么说的,他就怎么做了,难道有错?原创 2022-11-29 07:18:18 · 145 阅读 · 0 评论 -
SDK和API的区别
SDK的封装是在客户端层面的一个library(也叫做“包”或者“库”),这个library提供一些客户端API接口,类似于已经写好了的函数,你只需要调用它就好了。SDK暴露出来的接口都是和语言相关的,如果SDK是用Java写的,就需要用Java去调用那个函数;API是封装在服务端层面的library,从网络服务的层面暴露出一些API接口,提供给使用这些服务的人去调用。因为封装在服务的层面,传输数据用的是网络协议(常用HTTP/TCP),就不需要管他是用什么语言实现的;原创 2022-11-28 15:50:10 · 401 阅读 · 0 评论 -
MybatisPlusConfig
自定义ISqlInjector sql注入器,添加通用方法。2、自定义配置见下面文章。1、详细说明见下面文章。原创 2022-11-22 16:14:16 · 3631 阅读 · 0 评论 -
Mybatis Plus 自定义SqlInjector sql注入器
3、MybatisPlus自定义SQL方法枚举类GeneralMybatisPlusSqlMethod。然后所有的mapper和servcie继承我们自定义扩展的基础mapper和service。2、方法对应的实现类UpdateAllColumnById。参考其他基本方法的实现类源码如:UpdateById等等。4、MybatisPlus配置类,加载自定义sql注入器。6、自定义基础service继承IService及实现类。5、自定义基础Mapper继承BaseMapper。转载 2022-11-22 16:11:03 · 5416 阅读 · 1 评论 -
Mybatis Plus分页查询超过最大页码的自定义处理
之前在很长一度按时间内,因为我做的项目不会这么多的使用分页,所以一直都是手动的判断页码是否溢出,如果溢出就将page的当前页码设置为查询得到的页面数量,再次进行查询。分页用的少还好,一旦像是现在这个项目这样大量的用到分页,就比较头疼了,所以,今天便打算自己封装一个Helper类。最近在做一个管理后台的项目,有很多分页查询,Mybatis Plus提供了非常优秀的分页插件,但是当查询页码大于最大页码的时候,就会出现结果空白。但是这样产生的效果是溢出后按照第一页查询,而笔者现想要在页码溢出时展示最后一页。转载 2022-11-22 15:58:56 · 1830 阅读 · 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 · 3388 阅读 · 0 评论 -
蓝绿发布、滚动发布、灰度发布(金丝雀发布)、A/B测试
验证新版本符合预期后,逐步调整流量权重比例,使得流量慢慢从老版本迁移至新版本,期间可以根据设置的流量比例,对新版本服务进行扩容,同时对老版本服务进行缩容,使得底层资源得到最大化利用。所谓滚动升级,就是在升级过程中,并不一下子启动所有新版本,是先启动一台新版本,再停止一台老版本,然后再启动一台新版本,再停止一台老版本,直到升级完成,这样的话,如果日常需要10台服务器,那么升级过程中也就只需要11台就行了。相比于前两种发布策略,灰度发布的思想则是将少量的请求引流到新版本上,因此部署新版本服务只需极小数的机器。转载 2022-11-17 10:57:28 · 1427 阅读 · 0 评论 -
MySQL 常用高可用方案
在使用 MGR 时,如果要实现完整的高可用方案,就需要用到 InnoDB Cluster。MHA(Master High Avaliable) 是一款 MySQL 开源高可用程序,MHA 在监测到主实例无响应后,可以自动将同步最靠前的 Slave 提升为 Master,然后将其他所有的 Slave 重新指向新的 Master。其大致原理是:在主实例的 Keepalived 中,增加监测本机 MySQL 是否存活的脚本,如果监测 MySQL 挂了,就会重启 Keepalived,从而使 VIP 飘到从实例。转载 2022-11-14 17:28:03 · 7289 阅读 · 0 评论 -
架构师学习笔记(四)架构师线路之系统架构师&企业架构师
系统架构师是一个最终确认和评估系统需求,给出开发规范,搭建系统实现的核心构架,并澄清技术细节、扫清主要难点的技术人员。主要着眼于系统的“技术实现”。因此他/她应该是特定的开发平台、语言、工具的大师,对常见应用场景能给出最恰当的解决方案,同时要对所属的开发团队有足够的了解,能够评估自己的团队实现特定的功能需求需要的代价。系统架构师负责设计系统整体架构,从需求到设计的每个细节都要考虑到,把握整个项目,使设计的项目尽量效率高,开发容易,维护方便,升级简单等。转载 2022-10-19 16:59:56 · 782 阅读 · 0 评论 -
架构师学习笔记(三)架构师线路之业务架构师
业务架构师往往擅长对专业领域做业务建模,经过多年业务的熏陶成为细分领域的专家。业务架构师负责在组织或公司实施成功的战略。这种类型的架构师不处理字面上的蓝图和平面图,也不在架构师工作室工作。相反,业务架构师是一个现代架构师,他必须能够设想一个企业的几个不同要素,并使它们协调一致地工作,他或她还必须能够用未来主义的术语来思考,并确定企业的发展方向业务架构师可以作为全职员工或承包商和顾问工作。业务架构师可以作为全职员工或承包商工作组织需要一个持续的业务架构师或项目架构师。转载 2022-10-19 16:57:19 · 204 阅读 · 0 评论 -
架构师学习笔记(二)架构师线路之应用领域架构师
本篇文章,我们着重了解应用领域架构师。应用领域架构师负责从应用程序的,负责某个应用的技术架构,主要偏业务系统,关注理解业务,梳理模型,设计模式,接口,数据交互等方面。转载 2022-10-19 16:32:03 · 194 阅读 · 0 评论 -
我们从来都反对“大中台,小前台”的架构设计
此时,业务中台诞生了。中台,是共性业务的部分。问题:中台,应该做厚还是做薄?最早,阿里提出了“大中台,小前台”的中台战略。对此,快狗打车有不同的看法,中台太厚,势必夹杂个性化业务逻辑,不要让中台成为业务发展的瓶颈,我们提倡“小中台,大前台”,只有足够通用的业务,才适合下沉到中台。转载 2022-10-19 16:20:46 · 937 阅读 · 0 评论 -
中台战略-建中台与拆中台
说到中台,绕不开阿里,应该说阿里带火了国内的中台建设,此后,不断涌现出多种新业态的中台,如数据中台、技术中台、业务中台等。但是从2020年下半年开始,阿里又开始拆中台,于是乎,业界一片惊奇,甚至有些企业,还没有建立中台,甚至在建中台,忽然阿里又开始拆中台了,不免疑惑。于此,我也说说自己的看法,一家之言,或者说也是通过在不断的学习过程中,以及拜读其他的一些大神的著作进行思考。转载 2022-10-18 16:24:10 · 258 阅读 · 0 评论 -
关于去中台化的一点思考
大概意思就是所有的公共逻辑都给你定义好了,你想创新还创新不了,我只能说这个中台没留钩子,没给自定义的后门,让你们家的中台设计者好好思考一下,中台没能约束你创新,是你的中台本身没创新,产品逻辑还没捋顺,这个道理大家应该很清楚;1、中台是反创新的,中台最擅长的不是创新,而是复制,是管控,是创新的反面,中台擅长从1到100,但是却无法解决从0到1的问题,因为所有的创新,一定是底层的,当底层已经被中台定义好,那么也就失去了创新的所有可能。阿里云,华为云不也是中台吗?真的是中台不行了,还是你家的中台不行?转载 2022-10-18 15:47:57 · 1689 阅读 · 0 评论 -
中台彻底搞砸了?下一站,小中台大前台
以电商行业为例,一家大型零售公司,包括社区拼团、电商、线下超市、B2B等业务模式,真正具备业务共性的,往往是具备高度抽象的业务实例,比如:用户、商家、订单、支付。这个时候,中台建设进入到了碎片化中台阶段,组织和业务线拆分得更细粒度,比如:安全中台、财务中台、移动中台、客服中台、供应商中台、物流中台等等。在过去几年里,中台解决了大型企业“烟囱”的问题、山头林立的问题,使得企业的生产力被进一步的释放。,各业务线团队,既是服务调用方,也是服务提供方,在中台组织的指导之下,将各业务线的服务能力,开放给其它业务方。转载 2022-10-18 14:51:09 · 231 阅读 · 0 评论 -
“中台”仅用5年就消失了?
可现在的问题是,互联网时代,用户的新鲜感和注意力比任何时候都转移得更快,早些年的积累下来的习惯,也极有可能在短期内就悄悄改变——可是中台所有通用功能全都是在多年的业务经验当中积攒下来的,太通用的东西,注定不太可能跟创新沾边,一旦业务场景发生一百八十度大转变,那怕是立马就要失灵了。但很明显,中台作为这样一个“庞然大物”,什么都往里面都装,什么都通用,是很难调转方向作出颠覆性创新的,除非拆了重建——可现在的问题是,中台建设的工程量浩大,不要说短期内,就算是一年两年也未必能完成。转载 2022-10-13 23:09:03 · 683 阅读 · 0 评论 -
中台是不是要凉了
中台最早是由阿里巴巴推动在国内火起来的,早在2015年,马云带领阿里多位高管拜访芬兰著名的游戏公司Supercell,看到平均一款游戏落地只需要5~7人,被这种高效工作模式触动。于是,开始在公司内部尝试“大中台,小前台”的架构模式,诞生了阿里巴巴中台战略。经过15、16两年的时间孕育,在2017年,中台的声音越来越大,很多大厂开始开始搞中台建设,市面上关于中台建设的分享经验也多了起来。中台极大的释放了企业创新和变革的能力,像阿里的盒马、钉钉都是阿里中台创新的成果。18年、19年可谓是中台发展元年,很多中小厂转载 2022-10-13 23:03:09 · 147 阅读 · 0 评论 -
中台现在已经凉了吗
B业务系统来了,说想在登录失败N次后,给用户发送短信提醒,发送邮件提醒,平台开发人员和业务只好扑腾扑腾派两个人去接这些需求。当我们平台开发人员并不能确保我们能搞清楚业务人员的需求是产品经理拍脑袋,还是实际需求时,大量频繁地平台开发,甚至规则变更。无论对平台的稳定性和业务团队来说,都是灾难性的。开始总是分分钟都妙不可言,我们设计的平台总能非常好地满足业务的诉求,对于一些需要扩展平台能力的地方,也响应得比较及时。根据我们的设计一个登录服务平台,大体需要提供发送验证码,注册,登录,登出,身份/权限验证 等服务。转载 2022-10-13 22:44:10 · 202 阅读 · 0 评论 -
数据中台为什么搞不下去了
搞数据的都知道,阿里发明了数据中台,然后“”这个概念就马上成为了国内大多数企业趋之若鹜的风口,真正实施后却发现中台与数据平台、数据湖等项目大差不差,又有好多机构开始忙着拆中台了,中台虽然还没到人见人烦的地步,但总体来讲已经不那么受待见了。我发现网上也有很多文章进行分析,但大多是长篇大论,表述也过于技术,今天我就用最通俗的话跟大家解释一下。转载 2022-10-13 22:35:33 · 202 阅读 · 0 评论 -
架构师学习笔记(一)技术债的危害和治理
参考连接:https://www.bilibili.com/video/BV1FP4y177it?稳定压倒一切VS落后就要挨打。转载 2022-10-10 11:07:32 · 197 阅读 · 0 评论 -
阿里DTS 学习笔记
DTS(Data Transmission Service, 数据传输服务),用于在关系型数据库、NoSQL数据库、数据仓库之间迁移数据。可以使用DTS将数据迁移至阿里云,也可以在阿里云和本地数据系统之间做数据迁移。转载 2022-10-09 09:46:01 · 5289 阅读 · 0 评论