- 博客(1178)
- 收藏
- 关注
RSS订阅
原创 阿昌教你看懂mybatisplus的sql语句的创建过程
前言前置版本：MybatisPlus3.0.5前些日子，阿昌写过一篇【mybatisplus的SqlSessionFacotry的创建过程】的菜鸡文章，这里我打算再记录一篇，关于mybatisplus的sql语句的创建过程。前戏同样，学过springboot的人都知道，如果要整合什么框架，肯定要去找XXXAutoConfiguration。在MybatisPlusAutoConfiguration中有如下，对SpringIoc容器进行注入sqlSessionFactory在这个方法中，他
2021-11-23 18:36:55
4320
7
原创 谁再用Arrays.asList就开除谁
针对对应的坑，所以不推荐使用，来直接从根源上避免出现坑。不然就想要注意在使用中的场景是否符合你的要求，如不对创建的List进行增删改的操作。等等。
2024-02-13 16:49:32
662
原创 LiteFlow规则引擎框架
那首先得知道什么是规则引擎？规则引擎是 一种用于自动化处理业务规则的软件组件。在软件行业中，规则引擎通常用于解决复杂的业务逻辑处理问题。它可以将业务规则从应用程序中分离出来，并以一种易于管理和维护的方式进行配置和修改。规则引擎能够根据预先定义的规则集对输入数据进行评估和处理，并根据规则的结果执行相应的操作。这样可以提高软件系统的灵活性、可扩展性和可维护性。规则引擎在许多软件领域都有广泛的应用，比如金融行业的风险评估、保险业的理赔处理、电子商务的促销活动等。
2024-02-09 17:41:48
1190
原创 Mybatis中的sql-xml延迟加载机制
主查询对象关联对象假设咱们现在有2张表，一张是item表，一张是sku表，对应关系是1对多的关系主查询对象：itemDO关联对象：itemDO对象中的skuIdList。
2024-02-05 13:45:08
894
原创 Http请求Cookie失效问题
在cookies的使用中，要符合对应的使用规范，避免开发中出现问题；业务解决方案：将替换为最后不再报错，符合业务。
2024-02-02 18:04:42
763
原创 dubbo项目发布时Destroyed异常分析
源码可知，消费者调用dubbo时，调用invoke()，其会判断当前消费者的标记位是否被销毁状态，如果是就抛出以上异常，否则继续执行调用逻辑。相关的报错日志，来提示dubbo消费者调用生产者时，生产者服务已经DESTROYED。结合发布场景每次服务发布的时候才产生异常，所以先考虑2/3的情况；溯源找到对应的业务代码，发现时。在发布项目时，elk有打印。定时任务的调用业务，
2024-01-18 10:50:00
760
原创 电商概念之商品模型
广义定义：商品是为了出售而生产的劳动成果，人类社会生产力发展到一定历史阶段的产物，用于交换的劳动产品。商品类目商品属性销售属性商品编码&商品规格编码SKU和SPU。
2024-01-15 17:19:05
1112
原创 阿昌教你如何优雅的数据脱敏
Target(ElementType.FIELD) //作用于字段上@JacksonAnnotationsInside // 表示自定义自己的注解Sensitive@JsonSerialize(using = SensitiveInfoSerializer.class) // 该注解使用序列化的方式/*** 方法来源于ContextualSerializer，获取属性上的注解属性,同时返回一个合适的序列化器*/@Override// 获取自定义注解。
2023-11-01 16:59:32
477
原创 基于aop & 代理 & Sentinel & Nacos配置控制包装类实现原理
com.alibaba.csp.sentinel.slots.block.flow.FlowSlot#checkFlow中会有com.alibaba.csp.sentinel.slots.block.flow.FlowRuleChecker来根据对应的FlowRule规则来判断是否通过或者执行对于的降级逻辑等;这里涉及到Sentinel中的Slot责任链，依然用的com.alibaba.csp.sentinel.slots.block.flow.FlowSlot举例。
2023-10-25 17:34:31
701
原创 Day982.各大开放平台是如何使用OAuth 2.0 -OAuth 2.0
开放平台体系的整体结构和授权流程，以及第三方软件开发者关心的对接开放平台的通信流程中需要传递的参数。以下三点内容。当有多个受保护资源服务的时候，基本的鉴权工作，包括访问令牌的验证、第三方软件应用信息的验证都应该抽出一个 API 网关层，并把这些基本的工作放到这个 API 网关层。各大开放平台都是推荐使用授权码许可流程，无论是网页版的 Web 应用程序，还是移动应用程序。
2023-10-24 22:42:00
399
原创 23.10.13数据库升级流程记录
涉及到数据库升级，只能部分分库用户使用，或者全库停机，当前场景为。将之前的数据库升级为8.0版本，切只涉及一个分库；因为是全库停机发布，所以选择低流量时间点凌晨3点🕙。
2023-10-13 10:10:32
334
原创 23.09.26用户切库流程记录
因为db_A用户数据量超过预期，磁盘空间逐渐不足，需要换成db_A库的压力，所以将部分db_A用户切至db_B中。先整理出想要切库到db_B和保留在db_A的用户名单；将A库的用户，切到B库中，db分片为单独存储到话，如。db_A删除切出用户，db_B删除未迁移的用户；先将db_A中的数据全量复制到db_B中；对应到值，以确保切库后表路由的。，则切后用户需要更新分片信息。
2023-09-28 10:20:18
352
原创 Day981.OAuth 2.0的工作流程与安全问题 -OAuth 2.0
OAuth 2.0 是一个授权协议，它通过访问令牌来表示这种授权。第三软件拿到访问令牌之后，就可以使用访问令牌来代表用户去访问用户的数据了。所以，我们说授权的核心就是获取访问令牌和使用访问令牌。OAuth 2.0 是一个安全协议，但是如果使用不当，它并不能保证一定是安全的。如果不按照 OAuth 2.0 规范中的建议来实施，就会有安全风险。比如，没有遵循授权服务中的授权码只能使用一次、第三方软件的重定向 URL 要精确匹配等建议。安全防护的过程一直都是“魔高一尺道高一丈”，相互攀升的过程。
2023-09-16 16:52:35
356
原创 Day980.OAuth 2.0实现一个OpenID Connect用户身份认证协议 -OAuth 2.0
在一些较大的、已经具备身份认证服务的平台上，可能并没有发现 OIDC 的描述，但大可不必纠结。有时候，可能会困惑于，到底是先有 OIDC 这样的标准，还是先有类似微信登录这样的身份认证实现方式呢？其实，要理解这层先后关系，可以拿设计模式来举例。当想设计一个较为松耦合、可扩展的系统时，即使没有接触过设计模式，通过不断地尝试修改后，也会得出一个逐渐符合了设计模式那样“味道”的代码架构思路。理解 OIDC 解决身份认证问题的思路，也是同样的道理。
2023-09-07 17:00:30
466
原创 Day979.OAuth2.0可能存在的安全问题 -OAuth 2.0
OAuth 2.0 相关的常见又比较隐蔽的 5 种安全问题，包括 CSRF 攻击、XSS 攻击、水平越权、授权码失窃、重定向 URI 被篡改。互联网场景的安全攻击类型比如 CSRF、XSS 等，在 OAuth 2.0 中一样要做防范，因为 OAuth 2.0 本身就是应用在互联网场景中。除了常见的互联网安全攻击，OAuth 2.0 也有自身的安全风险问题，比如授权码失窃、重定向 URI 被篡改。
2023-08-26 14:32:43
557
原创 Day978.如何在移动App中使用OAuth 2.0？ -OAuth 2.0
没有 Server 端的 App和有 Server 端的 App分别是如何使用授权码许可类型的。使用 OAuth 2.0 协议的目的，就是要起到安全性的作用，但有些时候，因为使用不当反而会造成更大的安全问题，比如将 app_secret 放入 App 中的最基本错误。如果放弃了 app_secret，又是如何让没有 Server 端的 App 安全地使用授权码许可协议呢？针对这种情况，介绍了PKCE 协议。它是一种在失去 app_secret 保护的时候，防止授权码失窃的解决方案。
2023-08-19 13:27:11
611
原创 Day977.除了授权码许可类型，OAuth 2.0还支持什么授权流程？ -OAuth 2.0
现实世界总是有各种各样的变化，OAuth 2.0 也要适应这样的变化，所以才有了另外这三种许可类型。同时，关于如何来选择使用这些许可类型，给了一个建议。加上前面授权码许可类型，一共讲了 4 种授权许可类型，它们最显著的区别就是获取访问令牌 access_token 的方式不同。最后，一张表格来对比下：除了上面这张表格所展现的 4 种授权许可类型的区别之外，记住以下两点。所有的授权许可类型中，授权码许可类型的安全性是最高的。因此，只要具备使用授权码许可类型的条件，一定要首先授权码许可类型。
2023-07-18 23:20:16
1334
1
原创 Day976.如何安全、快速地接入OAuth 2.0？ -OAuth 2.0
总结下来，能够记住以下两点。对于第三方软件，比如小兔打单软件来讲，它的主要目的就是获取访问令牌，使用访问令牌，这当然也是整个 OAuth 2.0 的目的，就是让第三方软件来做这两件事。在这个过程中需要强调的是，第三方软件在使用访问令牌的时候有三种方式，建议在平台和第三方软件约定好的前提下，优先采用 Post 表单提交的方式。受保护资源系统，比如小兔软件要访问开放平台的订单数据服务，它需要注意的是权限的问题，这个权限范围主要包括:不同的权限会有不同的操作不同的权限也会对应不同的数据。
2023-07-04 11:28:50
1471
原创 Day975.如何使用JWT结构化令牌 -OAuth 2.0
OAuth 2.0 的核心是授权服务，更进一步讲是令牌，没有令牌就没有 OAuth，令牌表示的是授权行为之后的结果。一般情况下令牌对第三方软件来说是一个随机的字符串，是不透明的。大部分情况下，提及的令牌，都是一个无意义的字符串。但是，人们“不甘于”这样的满足，于是开始探索有没有其他生成令牌的方式，也就有了 JWT 令牌，这样一来既不需要通过共享数据库，也不需要通过授权服务提供接口的方式来做令牌校验了。这就相当于通过 JWT 这种结构化的方式，在做令牌校验的时候多了一种选择。
2023-06-13 21:34:27
872
原创 Day974.授权码和访问令牌的颁发流程 -OAuth 2.0
授权服务可以说是整个 OAuth 2.0 体系中的 “灵魂” 组件，任何一种许可类型都离不开它的支持，它也是最复杂的组件。这是因为它将复杂性尽可能地“揽在了自己身上”，才使得诸如小兔这样的第三方软件接入 OAuth 2.0 的时候更加便捷。授权服务的核心就是，先颁发授权码 code 值，再颁发访问令牌 access_token 值。在颁发访问令牌的同时还会颁发刷新令牌 refresh_token 值，这种机制可以在无须用户参与的情况下用于生成新的访问令牌。
2023-06-12 18:36:43
1053
原创 Day973.授权码许可类型中，为什么一定要有授权码？ -OAuth 2.0
从为什么需要授权码这个问题开始讲起，并通过授权码把授权码许可流程整体的通信过程串了一遍，提到了授权码这种方式解决的问题，也提到了授权码流程的通信方式。总结来说，以下两点。授权码许可流程有两种通信方式。一种是前端通信，因为它通过浏览器促成了授权码的交互流程，比如京东商家开放平台的授权服务生成授权码发送到浏览器，第三方软件小兔从浏览器获取授权码。正因为获取授权码的时候小兔软件和授权服务并没有发生直接的联系，也叫做间接通信。另外一种是后端通信，在小兔软件获取到授权码之后，在后端服务直接。
2023-06-05 23:06:33
757
原创 Day972.OAuth 2.0是要通过什么方式解决什么问题？ -OAuth 2.0
OAuth 到底是什么，为什么需要它，以及它大概的运行逻辑是怎样的。OAuth 2.0 的核心是授权许可，更进一步说就是令牌机制。也就是说，像小兔软件这样的第三方软件只有拿到了京东商家开放平台颁发的访问令牌，也就是得到了授权许可，然后才可以代表用户访问他们的数据。互联网中所有的受保护资源，几乎都是以Web API 的形式来提供访问的，比如极客时间 App 要获取用户的头像、昵称，小兔软件要获取用户的店铺订单，说 OAuth 2.0 与安全相关，是用来保护 Web API 的。
2023-06-03 15:42:02
498
原创 Day971.为什么要学OAuth 2.0？ -OAuth 2.0
开放平台相关的技术，主要包括网关、授权两块的内容。在开始的几年时间里面，一直都认为是开放平台的核心，起到 “中流砥柱” 的作用，毕竟网关要。随着对开放平台理解的不断深入，要想在开放平台支持更多样的业务场景，才发现网关和授权同样重要，相当于开放平台的 “两条腿”。而对于授权 “这条腿”，它不仅要像网关一样要承载访问量，还要同时兼顾业务场景的发展。什么样的业务场景呢？类似的微信登录就是其中之一，越来越多的，来。而这个解决方案的背后原理，也是要讲到的。
2023-05-18 23:21:18
481
原创 Day970.数据库表解耦 -遗留系统现代化实战
一张表格，对比了拆分查询 SQL 的三种方案，以及上面没有提到的一些优势和不足。结合自己的实际需求，对照表格选择更合理的方案。解耦数据库表的方法都是基于查询的 SQL，对于 INSERT、UPDATE 和 DELETE 的 SQL，也可以用 API 调用来取代。
2023-05-16 23:24:24
1236
原创 Day969.如何拆分代码 -遗留系统现代化实战
反向代理”和“数据同步”是之后的基础，微服务拆分的方方面面都离不开这两个实践。如果数据库是 Oracle，强烈建议使用基于 DBLink 的同义词来进行“数据同步”。其实严格来说，这并不算是同步，而只是一种转换，但它可以让暂时不用考虑数据的问题，降低了认知负载的同时，还能帮梳理数据的所有权。等代码解耦完成，在核保库中所创建的同义词，都是需要拆分到核保库中的数据表。除此之外，还分享了“用 API 取代代码依赖”，这也是比较基础的一个实践，是代码解耦的基本方法。
2023-05-15 23:21:21
921
原创 Day968.如何开启一个遗留系统现代化项目？ -遗留系统现代化实战
讨论了如何开启一个遗留系统现代化项目。花了不少篇幅去梳理开启项目的步骤，需要先对不熟悉的业务进行梳理，得到初步的用户旅程或用户故事地图；再通过动名词法等工具，对系统进行战略建模，并设计出目标架构；然后选择一个端到端的业务进行试点，并以假设驱动的方式寻找合适的现代化方案；确定目标架构以及制定演进计划，并按照计划逐个迭代地增量演进；最后，每个迭代都需要得到充分验证。目标很明确，就是要把核保业务从单体大泥球架构中拆分出来，形成具有独立数据库的微服务。这已经是个非常艰巨的任务了。
2023-05-14 14:17:47
626
原创 Day967.团队拓扑学 -遗留系统现代化实战
一种全新的团队结构模型——团队拓扑学。所以在它后面加了一个“学”字，是因为它相比特性团队和 Spotify 模型，更接近一门学问。它提出的团队认知负载和团队优先的理念，更是超前于这个时代。组件团队、特性团队、Spotify 模型或团队拓扑，它们并不是相互替换的关系，而是可以按需合并和剪裁的。它们面向的问题域不同、目标不同、出发点不同，因此不存在谁比谁高明的情况。一张表格，总结几种讲过的团队类型，做个参考。应该根据自己团队的实际问题，找出合适的方案。
2023-05-11 23:37:07
1966
原创 Day966.从组件团队到Spotify模型 -遗留系统现代化实战
Hi，我是阿昌，今天学习记录的是关于的内容。。这个方向跟管理有关，但无论掌控全局的 CTO、架构师，还是身处遗留系统一线战队的队员，都有必要了解现代化团队结构是什么样子的。这是因为遗留系统的现代化，除了技术调整，也离不开人的因素。在维护遗留系统的团队，结构往往并不合理。直接后果就是给软件开发的质量与速度拖后腿，长远来看，还会让我们的架构规划无法落地，回到满是泥潭的老路上。
2023-05-11 00:17:03
953
原创 Day965.从持续集成到持续部署 -遗留系统现代化实战
分支策略。这是一个充满争议的话题，每次对于 GitFlow 的批判，都会引发热议。只有应用了主干开发，遗留系统现代化的增量演进原则才能更好地贯彻。每次增量演进都能及时 PUSH 到主干，从而过一遍持续集成流水线，并部署到各个环境。而如果是特性分支策略，会不自觉地等着全部完成后再合并代码。灵活的分支功能是 Git 的一大亮点，但它并不是为了开发特性而设计的。利用特性分支在本地长期保存多份代码版本，这是对 Git 分支的滥用，增加了不必要的认知负载。
2023-05-09 23:06:05
1215
原创 Day964.从持续构建到持续集成 -遗留系统现代化实战
如何在一个没有持续集成流水线的遗留系统中，逐步搭建基础设施，从持续构建开始，慢慢做到持续集成的初级阶段。这其中包含很多工作习惯的改变，比如任务分解、小步提交等，一开始你可能并不适应，但要知道，只有做好任务分解，才能做到小步提交，才能做到持续提交代码并持续构建。这些都是 DevOps 文化的一部分。一个遗留系统要想真正做好 DevOps 现代化，就必须转变思想，摒弃成见，彻底拥抱 DevOps。七步提交法，图解，供参考。在做到持续构建之后，可以逐步引入分级构建、制品晋级等实践，慢慢向持续集成演进。
2023-05-09 00:57:18
1086
原创 Day963.如何拆分数据 -遗留系统现代化实战
Hi，我是阿昌，今天学习记录的是关于如何拆分数据的内容。，这个场景在建设新老城区，甚至与其他城市（外部系统）交互时都非常重要。作为开发人员，理想中的业务数据存储方式是什么样呢？当然是负责一个业务的数据都在一张或几张名称相关的表中，这样通过名称就可以一目了然，查找起来很方便。不过很遗憾，现实有时候总是事与愿违，遗留系统中负责处理一个业务的数据，有的放在这张表，有的放在那张表，总是不在一起，名称甚至都没关系；而一张表中也有可能存放几种业务的数据。
2023-05-07 16:35:07
694
原创 Day962.如何更好地重构和组织后端代码 -遗留系统现代化实战
修缮者模式和绞杀植物类似，可以用来改善单体内的某个模块。抽象分支模式可以通过一个抽象，优雅地替换旧的实现。扩张收缩模式主要用于接口无法向后兼容的情况，一张一缩，一个接口就改造完了。同时，除了代码中的接缝，架构中也存在接缝，可以利用它们来实现架构中的替换。无论是绞杀植物、修缮者、抽象分支还是扩张收缩，它们在实施的过程中，都允许新旧实现并存，这种思想叫做并行运行这是贯彻增量演进原则的基本思想，希望能牢牢记住。
2023-05-05 21:52:54
1272
原创 Day961.老城区前端改造 -遗留系统现代化实战
遗留系统前端的特点，以及前端重构的八个步骤， 分别是：梳理业务、模块化、重构 JavaScript、移除 Scriptlet、引入前端框架、前端组件化、前端工程化和 API 治理。最后，为了在旧页面中更好地集成新的前端组件，粗略地了解了微前端技术。在重构前端的时候，对开发人员的要求是很高的。如果他只会前端，可能无法移除 Scriptlet；如果只会后端，也许可以按重构 Java 代码的方式重构 JavaScript，但却很难对前端进行组件化和工程化，更别提什么微前端。
2023-05-04 22:18:47
1493
原创 Day960.架构现代化-微服务 -遗留系统现代化实战
如何选择遗留系统的目标架构，到底是单体合适，还是微服务合适呢？看起来“二选一”的题目，还有更适合自己业务的隐藏选择么？拆与不拆，要看认知负载。拆成什么样，要按步骤演进。除了微服务，基于组件的单体架构和基于服务的分布式架构也有可能是大泥球单体的最终目标，如何取舍主要还是看业务上是否具有弹性需求。在拆分时，你可以使用基于组件的分解和战术分叉两种模式。微服务是个非常庞大的话题，很难在一节课中体现所有内容。奉劝你一句，拆分微服务一定要想清楚为什么要拆。
2023-05-02 19:09:23
2363
2
原创 Day959.架构现代化模式 -遗留系统现代化实战
从 Martin Fowler“灵光一现”发明的绞杀植物模式出发，接着学习了 Eric Evans 发明的气泡上下文和自治气泡模式，以及在气泡中可以使用的数据同步和访问方式，包括变动数据捕获、事件拦截和遗留系统封装 API。从气泡上下文，到自治气泡，再到微服务，这其实描述了一个新需求落地成微服务的演进路线。一步到位地去开发一个微服务，认知负载偏高，而且你可能也并不需要。按需演进地去开发，认知负载就会低得多，也更容易得到一个刚刚好的架构。有很多新需求都可以通过气泡上下文来构建，比如报表、问卷、评分等。
2023-05-01 23:04:59
935
原创 Day958.代码的分层重构 -遗留系统现代化实战
遗留系统中常见的代码样例说起，将一个事务脚本一步步重构成了 DDD 中常见的分层架构。这期间穿插着介绍了领域模型、数据映射器、仓库、应用服务等多种模式。不管系统位于这个路线的哪个阶段，都应该有能力把它重构好。项目业务没有这么复杂，事务脚本也能解决绝大部分应用场景。没错，事务脚本本身就是一种解决领域逻辑位置的模式，这条路最终会走向混乱。有的时候，之所以觉得业务没那么复杂，是因为在脑子里将业务映射成了数据库表，那么写出的代码自然是事务脚本。
2023-04-29 12:59:05
2130
1
原创 Day957.重构“烂代码” -遗留系统现代化实战
重构手法和模式还有很多很多，之所以认为这两个特别实用，是因为在重构了大量遗留代码后，发现拆分阶段和方法对象是必不可少的中间步骤。当通过这两种方式完成了初步重构之后，还要审视一下代码，根据坏味道实现下一步的重构。方法对象的时候，穿插了如何使用快捷键来完成重构。可能会觉得记住额外的快捷键属于外在认知负载，其实不然。它们能够提高你的工作效率，而且一旦记住并且熟练掌握，就能一劳永逸。这种知识属于内在认知负载，是完成工作必须具备的技能。
2023-04-28 01:04:12
1966
1
原创 Day956.代码现代化 -遗留系统现代化实战
首先学习了接缝的位置和接缝的类型。接缝的位置是指那些可以让 DOC 的行为发生改变的位置，有构造函数、方法参数、字段三种；而接缝的类型则是说改变 DOC 行为的方式，包括对象接缝和接口接缝。遗留代码中有了接缝，就可以着手写测试了。然而复杂的遗留代码很难去梳理清楚头绪，想你推荐用决策表的方式，将测试用例一一列出来。在遗留系统中，如果存储过程中包含大量的业务逻辑，传统的金字塔型的测试策略可能并不适合，可以多写一些端到端的 UI 测试，以及与数据库交互的集成测试（服务测试）。
2023-04-26 23:25:52
813
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人