- 博客(677)
- 收藏
- 关注
RSS订阅原创 170. MQ本地消息表模式是如何保障分布式最终一致性的
事务消息是投递消息的一种方式，可以确保业务执行成功，消息一定会投递成功。需要在业务本地库创建一个消息表(t_msg)id varchar(32) not null primary key comment '消息id',body_json text not null comment '消息体,json格式',status smallint not null default 0 comment '消息状态，0：待投递到mq，1：投递成功，2：投递失败',
2025-04-06 01:42:43
598
原创 168. DDD战术设计改造实践（三）：货拉拉用户CRM改造实践
在本文中，我们深入探讨了DDD战术设计架构模式，并为大家分享了我们货拉拉用户CRM的实际落地经验。以笔者个人的经验来说，DDD首先，DDD的实践并没有统一的标准或固定的模式，每个团队都应该根据自身的业务需求和实际情况来进行设计和调整。其次，不要过于局限于DDD的理论概念，理论与实践之间存在差距，灵活应用才能真正提高开发效率和实现业务价值。最后，牢记DDD的初心——通过更好的业务建模，提升业务系统的维护性和扩展性。无论在何种背景下，DDD。
2025-01-20 01:09:00
747
2
原创 167.DDD战术设计改造实践(二）： 商城订单业务编码实战
无论在什么领域，订单业务都是一个比较复杂且典型的场景，考虑到本文的读者可能来自不同的行业，为了便于大家理解，这里我们选择了商城订单业务中的用户下单场景来演示DDD的编码实践。以此来为读者逐步展开讲述DDD战术设计中的实践形式。
2025-01-19 22:48:46
866
原创 166. DDD战术设计改造实践（一）：DDD简介
在快速发展的互联网行业中，企业的业务需求和技术架构之间的关系愈发紧密。如何在复杂多变的业务环境中保持系统的稳定性、灵活性与可扩展性，一直都是技术团队面临的重要挑战。注：由于篇幅有限，本系列文章以实践为主，DDD相关基础概念请读者自行查阅资料了解。希望通过这篇文章，能够帮助同行们更好地理解DDD战术设计在复杂业务系统中的应用，并为未来的技术创新与业务发展提供借鉴与启发。
2025-01-19 20:44:44
979
原创 165.如何开发一个好的接口
接口其实是一种规范，在生活中随处可见，比如：不同厂商的水管使用统一的水管接口对接、电脑厂商和配件厂商按照统一的USB接口标准进行生产完成配对、应用程序之间通过API进行信息交互。亚马逊集团创始人贝佐斯规定，亚马逊的所有系统、团队之间的交互，都必须通过服务接口，现在云计算技术非常火爆，其起源实际上是亚马逊的这种API文化，可以说，API构建了当前数字化世界的通路。所有的团队必须通过服务来对外暴露数据和功能。所有的团队之间的功能，必须通过这些服务接口来进行交互。网络上不允许任何除服务接口的其它交互方式。
2025-01-19 18:30:18
601
原创 164.链路诊断最佳实践：1 分钟定位错慢根因
【toc]本文聚焦于线上应用的风险管理，特别是针对和两大类问题，提出了一个系统化的根因诊断方案。线上应用风险主要分为“错”、“慢”两大类。JVMCPUFGC然而，面对复杂的应用间依赖，如何抽丝剥茧快速定位异常节点，深入分析异常背后的根本原因，并在极短的时间完成定位与恢复动作，每一步都面临巨大的技术挑战。根据近十年APMTraceAPPABC3sABSQLCLLM。
2025-01-04 23:02:48
982
原创 163.浅谈API错误码设计与链路追踪
根据亚马逊官方文档的定义，错误码是通过对错误进行抽象，帮助用户或开发者识别和理解异常性质的代号。错误码与具体错误不是一对一的关系，而是错误类型的一种抽象表示，如策略执行失败是一个错误码，但是引起策略执行失败的错误原因可能很多。尽管错误码在系统中只是一个小模块，但它是不可或缺的。错误消息应该帮助用户轻松并快速地理解并解决API错误，以下是一些设计原则：不要假设用户非常了解你的API。用户可能是客户端开发者、运维人员、IT人员或者APP的普通用户。
2025-01-04 22:36:39
772
原创 162.如何尽可能快地上手一个业务or项目？
了解了这些可以方便我们以后定位不同的代码在的位置，方便我们快速定位我们疑问的答案可能会出现在哪个目录（包）下。之后我们就可以开始链路上的熟悉，参照我们之前搞出来的数据模型，我们可以逐个了解数据模型在系统内对应的业务逻辑设计/实现（这些在文档里或多或少也会提及，我们要对比着看），对于每个模块或者功能的业务流程，我们可以边看边作业务流程图来梳理。作图可以帮我们理清逻辑，也方便实在有看不懂的地方的时候，请教他人。当然啦，遇到看不懂的流程也很正常，每个系统都会有很多新手不友好的内容。
2025-01-01 17:46:46
641
原创 161.Go语言Optional模式和Builder模式对比
Optional模式和Builder模式都是Go语言中用于对象构建和配置的重要设计模式。Optional模式通过函数选项提供灵活的配置选项，适用于参数较少且相对简单的情况。Builder模式则通过逐步构建对象并提供多种配置选项，适用于构建复杂对象的情况。在选择使用哪种模式时，应根据具体需求和对象复杂程度进行权衡。
2025-01-01 17:30:03
636
原创 160. 两种常用代码范式
文章中的代码范式可以应用在大部分场景，在项目初起的时候直接套用，可以省下大部分关于包模块划分的思考精力，并且在后续迭代中，团队统一规范，持续按照这个框架演进，可以让代码更加井井有条，减少一些诡异的类职责划分问题。
2025-01-01 16:55:16
787
原创 159.Go简易本地缓存包go-cache一览
go-cache 是一种内存中的键值存储/缓存，类似于memcached，适用于在单台机器上运行的应用程序。它的主要优点是，本质上是一个具有到期时间的线程安全map[string]interface{}，它不需要序列化或通过网络传输其内容。任何对象都可以存储一段时间或永久存储，并且缓存可以安全地由多个goroutine 使用。
2025-01-01 15:34:54
429
原创 158.Go语言并发模式实战指南
并发基础Goroutine是 `Go`` 并发的基本单位Channel是goroutine间通信的推荐方式合理使用context控制并发流程并发模式选择生产者-消费者模式适合任务队列处理扇出模式适合并行处理任务扇入模式适合多数据源聚合根据实际场景选择合适的模式性能优化关键使用对象池避免频繁创建对象合理设置缓冲区大小控制并发数量注意锁的粒度最佳实践要点始终处理错误情况实现优雅关闭添加监控指标注意资源释放实践建议开发阶段编写单元测试验证并发逻辑使用。
2025-01-01 13:35:11
646
原创 智能风控决策引擎系统代码实现篇（十一）基本信息定义【操作符、特征、规则】
前几篇文章我们已经介绍完了服务启动时的各种加载和启动工作，但实际最底层工作的最小单元是规则，规则的执行则依赖特征和操作符，本文我们就介绍与它们相关的代码。
2024-12-25 22:51:32
271
原创 智能风控决策引擎系统代码实现篇（十）加载DSL转换为决策流DecisionFlow，启动Gin路由、决策流启动执行
在上一篇文章中，我们已经介绍了Dsl元信息，决策流执行基本要素INode接口，以及决策流构成、决策流执行上下文记录器Pipeline。本文接着介绍，将决策流yaml文件加载为Dsl结构体到内存，而后转换为决策流，并启动Gin路由，监听执行请求。本文完成后的目录结构。
2024-12-25 21:54:48
407
原创 智能风控决策引擎系统代码实现篇（九）Dsl、INode接口、DecisionFlow、Pipeline上下文定义
DSL: 读取yaml文件后对应的结构体，还需要转换为才是真正可以执行的图: 可实际执行决策流（图)，FlowNode记录了具体的一个节点类比到DB存储，则是DB一条记录是一个DSL元信息配置，我们将其加载到内存后用结构体（DSL）保存，而后这个结构体需要再转换为另一个结构体（DecisionFlow）方可执行。
2024-12-25 21:22:21
547
原创 智能风控决策引擎系统代码实现篇（八）配置文件加载与日志模块
在项目中，日志是不可获取的组件，我们后续万一有问题，最有效的手段就是根据日志排查各种问题。为了后续可以很方便的获取到配置信息，我们专门定义了全局变量，用于存储配置信息。运行后输出如下，因为我们这里选择输出到文件，所以本地会产生一个out文件。在服务启动时，一般第一步就是加载相关的配置文件，如服务启动的端口号，最后，就是服务启动时，将配置文件的信息加载，保存到全局变量中。最后，我们可以将日志的初始化，也放到服务启动入口。接着，我们需要写一个Logger接口的实现类。等服务地址，日志相关配置等。
2024-12-25 20:16:19
331
原创 157. Go实现指数后退算法的自旋锁【单机+Redis版（带自动续期）】
工作中经常会用到锁来处理一些并发安全问题，拿到锁的协程可以执行某些操作，获取不到锁的则需要进行等待。
2024-12-22 22:52:52
1008
原创 156. Go手写一个简易的协程池
在工作中，我们经常需要开启不少的协程去处理一些事情，当然协程池是一个不错的选择，并且也有一些优秀的开源库可以直接使用。但是授人以鱼不如授人以渔，知其然更知其所以然，才能让我们更好的使用它，本文就实现一个简单的协程池，对于一些简单的业务，可以直接使用。
2024-12-22 22:16:13
409
2
原创 智能风控决策引擎系统可落地实现方案（七）：理论总结
Q：互金领域的风险有哪些？A：欺诈风险 、 信用风险、合规风险（监管要求）Q：如何对抗风险？A：通过大数据来构建规则和模型进行风险控制和风险预警Q：业务规则和模型策略 如何落地？A：通过决策引擎承载规则和模型的自动化实施和部署风控决策引擎，支持规则和模型的配置、管理、执行，支持通过专家经验和大数据机器学习进行风险控制。如图所示，风控决策引擎作为风控核心支撑组件，对风控管控起到重要的决策作用。决策引擎作为系统，那么系统设计的功能目标和性能目标都有哪些？决策流。
2024-12-01 11:49:35
1109
原创 智能风控决策引擎系统可落地实现方案（五）评分卡实现
之前介绍了决策引擎的规则集决策流，以及决策树决策表决策矩阵等功能实现。评分卡作为决策引擎不可或缺的功能之一，今天主要聊一下评分卡及其相关实现。先看下官方的定义。信用评分模型是一个量化工具，利用可观察到的借款人特征变量计算出一个数值（得分）来代表债务人的信用风险，并将借款人归类于不同的等级风险。评分卡，又称信用评分卡模型，是最常见的金融风控手段，用于信贷审批、信用卡申请等业务。区别于规则单维度评估，信用评分引入多特征维度，通过建立模型进行评分，作为资产质量的重要量化标准，如芝麻分即为一种评分卡。
2024-11-27 00:10:17
761
原创 智能风控决策引擎系统可落地实现方案（四）风控决策实现
互联网金融风控场景中，除了根据规则（反欺诈策略、政策准入）对用户进行准入或拒绝外，还会对用户进行更多维度的授信评估，如根据模型评分对用户进行评级，输出用户可借额度、期限、费率等，如何利用模型结果和规则结果来决策输出？常见的决策方式包括：决策树、决策表、决策矩阵。本文将主要介绍决策相关设计实现，并给出rete算法实现方案。
2024-11-25 23:34:27
1137
原创 智能风控决策引擎系统可落地实现方案（三）模型引擎实现
在之前的文章中，我们实现了规则引擎和决策流，基本完成了风控决策引擎系统的雏形。大数据风控领域通常根据规则对风险用户进行有效识别并拒绝准入或提高准入门槛，如判断用户信用卡历史逾期记录>5次且逾期总金额>5000元，用户多头共债数大于5，这部分用户风险较大，应该拒绝或进一步人审处理。而使用规则策略做风控有一定的局限性，依赖人经验，依赖单维特征，可决策结果单一。建立机器学习模型预测用户未来逾期风险（概率），对用户进行分级，可以更灵活给予不同金融产品方案，不同额度、费率、期限方案，进一步提升风控能力。
2024-11-25 21:57:07
1014
原创 智能风控决策引擎系统可落地实现方案（二）：决策流(流程编排）实现
在上一篇文章中，我们实现了一个完整的规则集解析过程，实现了规则引擎。智能风控决策引擎系统可落地实现方案（一）：DSL。实际风控需求通常不会只有一组规则，会对不同的规则、规则集进行编排，还会出现分支流程，子流程，形成一个更复杂风控流程，我们叫决策流决策流的解析就是实现一个流程引擎。流程引擎也叫工作流引擎，有很多开源实现，比较出名的是java的ActivitijBPM5。这里我们从业务需求分析，抽象建模并自己实现流程解析过程。
2024-11-21 00:07:56
1188
原创 智能风控决策引擎系统可落地实现方案（一）：DSL
风控决策引擎系统是在大数据支撑下，根据行业专家经验制定规则策略、以及机器学习/深度学习/AI领域建立的模型运算，对当前的业务风险进行全面的评估，并给出决策结果的一套系统。决策引擎，常用于金融反欺诈、金融信审等互金领域，由于黑产、羊毛党行业的盛行，风控决策引擎在电商、支付、游戏、社交等领域也有了长足的发展，刷单、套现、作弊，凡是和钱相关的业务都离不开风控决策引擎系统的支持保障。决策引擎和规则引擎比较接近（严格说决策引擎包含规则引擎，之前也有叫专家系统，推理引擎），它实现了业务决策与程序代码的分离。
2024-11-20 00:29:36
1240
原创 155.微服务注册中心分布式集群设计原理与 Golang 实现（二：集群版）
本文实现了注册中心的集群版，在集群实现过程中，先明确了点对点的平等架构方式，并通过复制技术实现各副本间一致性问题，也说明了在可用性和一致性问题上做的取舍。注册中心早期的Zookeeper使用ZAB协议（Paxos算法）实现了线性一致性，到etcd的Raft算法，分布式一致性算法是做分布式集群绕不开的话题，后续有机会会展开了讲。注册中心功能上还有一些待完善的地方，比如多机房流量调度，与结合，还有客户端方案等，本文项目参考 bilibili 的 discovery 开源项目。
2024-11-17 14:27:29
1088
原创 154. 服务注册发现之服务注册中心设计原理与Golang实现（一：单机版）
以上注册中心实现的所有功能如下图至此，一个单机版的注册中心就可以工作了，但生产环境单点肯定是不能容忍的，因此有必要实现一个注册中心集群。那么是否部署多个注册中心实例就可以了，当然不行！这只能保障有多个注册中心节点，而每个节点中维护自己的注册表，那么就需要进行注册表数据同步。多节点数据同步又会涉及著名的一致性问题，这时Paxos、Raft、ZAB、Gossip 等算法名词涌现，而我们将使用 P2P（Peer to Peer）对等网络协议来实现。关于集群设计与实现我们将在后续文章中展开。
2024-11-16 23:24:15
754
原创 153.拓扑排序典型应用场景：校验DAG中是否有环
在做一些较为底层的开发工作时，基本都会使用到流程编排，即将相关业务作为节点，组成有效无环图（语言实现的拓扑排序算法来判断带有父节点、子节点的有向无环图（）的顶点进行排序，使得对于图中的每条有向边 (同时，通过拓扑排序可以校验。拓扑排序是对有向无环图（在排序结果中都出现在顶点。
2024-11-16 19:10:39
374
原创 152.分布式任务调度系统【三】：分布式任务调度系统之任务编排及工作流实现原理与 golang 实践
定时调度系统（定时任务、定时执行）算是工作中经常依赖的中间件系统，简单使用操作系统的crontab，或基于Quartzxxl-job来搭建任务调度平台，行业有很多优秀的开源产品和中间件。了解其工作和设计原理，有助于我们完善或定制一套适合公司业务场景的任务调度中间件，本文对调度任务的依赖关系及编排展开分析，实现一套工作流，来满足任务间的复杂依赖的场景。任务调度依赖 & 工作流图相关知识golang并发相关。
2024-11-16 19:09:43
798
原创 151. 分布式任务调度系统【二】:分布式延时任务调度系统设计与golang实现
延时方案方案除上述几种外还有最小堆的形式，文中提到的Go内置定时器即采用四叉堆结构，其实现原理与排序链表大同小异。选择何种方案根据业务场景和业务规模而定。数据库轮询方案简单实用，在业务初期非常合适。延时队列方案实现简单，可以结合队列一起使用。当这些都不能满足业务时，再考虑自建延时系统，可以采用时间轮方案或有序链表方案。原文地址：https://mp.weixin.qq.com/s/bDb1xY2CFT0bIgOUWpoROA。
2024-11-16 15:52:32
1180
原创 150. 分布式任务调度系统【一】：分发及负载均衡、心跳检测实现方案
任务调度器分发任务前，先从协调者获取服务地址，然后进行任务分发，协调者本身可以作为任务分发者共同参与，也可只负责协调不处理任务，协调者如果发生故障，可由。服务发生故障，需要协调者能及时发现并从服务列表中移除故障节点，进行故障隔离或故障转移。协调者发送请求到服务提供者探针接口，如正常返回放入服务列表中，当请求失败达到阈值从列表中移除，协调者起到服务健康检查的效果。请求失败超阈值，也可以置为失效并不移除，并间隔一段时间进行重试，如果恢复则重新置为可用。协调者负责维护有效服务列表，分发路由策略，故障隔离或转移。
2024-11-16 15:07:08
767
原创 148. Go实现简易Cron能力
定时任务在日常的开发中使用的频率越来越高，比如电商系统每天进行的数据统计任务，再比如信用卡还款日提醒等等，都可能会使用定时任务来实现。所以如何实现定时任务是我们经常碰到的问题，采用哪种方案，可能影响到系统的架构设计。在系统的不断迭代的过程中，定时任务的实现方式也会一直会跟随着演进。本篇我们介绍定时任务的实现方案之一cron。
2024-11-10 14:03:13
1166
原创 26. 删除有序数组中的重复项【数组、双指针】
删除重复出现的元素，使每个元素 只出现一次 ，返回删除后数组的新长度。元素的 相对顺序 应该保持 一致。如果所有断言都通过，那么您的题解将被 通过。个元素包含唯一元素，并按照它们最初在。给你一个 非严格递增排列 的数组。
2024-11-02 14:39:32
321
原创 80. 删除有序数组中的重复项 II【双指针】
请注意，输入数组是以「引用」方式传递的，这意味着在函数里修改输入数组对于调用者是可见的。删除重复出现的元素，使得出现次数超过两次的元素只出现两次 ，返回删除后数组的新长度。为什么返回数值是整数，但输出的答案是数组呢？不要使用额外的数组空间，你必须在。修改输入数组 并在使用。额外空间的条件下完成。
2024-11-02 13:27:04
160
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人