开发在线办公、财务预算审批及学员收费计费系统，对接微信公众平台企业号，参与系统整体架构升级。
-
如何看待清华大学自动化系2020年大一c++大作业是写一个功能更强大的雨课堂（雷课堂）? 
朱一旦超话 #轻松防疫站# 一条劳力士的回家路#朱一旦的枯燥生活# @微博视频 
朱一旦的枯燥生活的微博视频 
.jpg)
![[允悲]](./微博_files/d_yunbei-9aa3c436a4.png)
远程修bug 
查看图片 网页链接
网页链接ruanyf的微博视频 
.jpg)
![[微笑]](./微博_files/d_hehe-039d0a6a8a.png)
//@StephanieYR:为什么我看这个有点唤起阴影呢……那些年都不知道给人重装过多少次系统了…![[跪了]](./微博_files/d_guile-7b3e474f7f.png)
![[二哈]](./微博_files/d_erha-0fecc90ac1.png)
![[失望]](./微博_files/d_shiwang-7925938d93.png)
//@令和最初的号:放工业盐 //@Yamaisi_Yuminaga: 真正的问题是：如果碰到个口重的男生放盐也不走怎么办？ 网页链接![[中国赞]](./微博_files/d_chnlike-2c6f482dac.png)
网页链接 ![[爱你]](./微博_files/d_aini-4a23c0524a.png)
鐘昭鈺_BabyKettey的微博视频 
![[并不简单]](./微博_files/d_bingbujiandan-e0c6936005.png)
//@tombkeeper :我记得多年前 Intel 有一批货经常出问题，最后发现是焊料里用的铅来自一个放射性同位素含量比较高的矿区。 //@美人她爹 : 这个多半不是宇宙射线，封装材料里面的同位素衰变影响大好几个数量级。另外如果内存无校验，单比特随机反转概率也不小![[费解]](./微博_files/d_feijie-bac8e40ab4.png)
.jpg)
![[喵喵]](./微博_files/d_miao-61fe2a7aaa.png)
南充·日兴镇 
.jpg)
洋子该昵称已被占用 的红包 .jpg)
![[笑cry]](./微博_files/d_xiaoku-d320324f00.png)
微博正文），决定搞个抽奖。只要转发这条微博就有机会。2018 年 1 月 1 日将在@微博抽奖平台 抽出一位朋友，送一台畅呼吸智能空气净化器，同时附赠一枚凯文·米特尼克的不锈钢名片。 
查看图片 
![[黑线]](./微博_files/d_heixian-bde08b426c.png)
最懒大学生：两周不收衣服，鸟儿在内做窝 
.jpg)
![[委屈]](./微博_files/d_weiqu-b069337758.png)
葫芦岛 
查看图片
.jpg)
![[威武]](./微博_files/f_v5-c583bc351a.png)
//@tombkeeper: 电影中的入侵场景很多都仿佛不可思议，而现实中能做到的可能更加神奇。秒拍视频 . 
![[哈哈]](./微博_files/d_haha-dd1c6d36cf.png)
针对无人机的常见攻击方式 
.jpg)
![[围观]](./微博_files/o_weiguan-182f18c20e.png)
![[干杯]](./微博_files/o_ganbei-7c906a72ba.png)
～@小贱同学lovexr 愿2C102友谊长存，愿我们大学四年好好走过！ 
.jpg)
我在这里:鞍山·龙源公寓 
![[给力]](./微博_files/f_geili-7e99751314.png)
![[good]](./微博_files/h_good-644bcfa993.png)
@辽宁科技大学- @辽宁科技大学团委 @辽宁科技大学微吧 @辽宁科技大学校内资讯 @辽宁科技大学微博协会 //@____一休不懂的太多
.jpg)
![[doge]](./微博_files/d_doge-861403219c.png)
![[可爱]](./微博_files/d_keai-7a5bf88086.png)
.jpg)
![[吃瓜]](./微博_files/d_chigua-c95cd5ba58.png)
![[酷]](./微博_files/d_ku-6fa1a42f7b.png)
![[小黄人得意]](./微博_files/minions_deyi-a458ad78cf.png)
![[摊手]](./微博_files/d_tanshou-3abaa4ed77.png)
![[小黄人剪刀手]](./微博_files/minions_jiandaoshou-092061dac4.png)
![[抱抱]](./微博_files/d_baobao-b928ba5761.png)
![[哆啦A梦微笑]](./微博_files/dr_weixiao-c7ecdd25aa.png)
![[挤眼]](./微博_files/d_jiyan-feeb0a726c.png)
![[泪]](./微博_files/d_lei-1b4b02f8b1.png)
![[吃惊]](./微博_files/d_chijing-e806473437.png)
![[嘻嘻]](./微博_files/d_xixi-813ededea2.png)
![[偷笑]](./微博_files/d_touxiao-15afb1c739.png)
+
+
+这里可以配置多个Redis的节点耳机域名。
+
+- 使用Medis 进行连接，可以查看服务器中`redis mode`为 sentinel哨兵模式。
+
+
+
+现在就可以`HA(High Avaliable)模式`高可用愉快的玩耍啦。
+
+----
+
+了解更多内容，可以关注我的微信公众号，更多首发文章。
+
diff --git a/_posts/202208/ddd-software-complexty.md b/_posts/202208/ddd-software-complexty.md
new file mode 100644
index 0000000..186953a
--- /dev/null
+++ b/_posts/202208/ddd-software-complexty.md
@@ -0,0 +1,122 @@
+---
+title: 《领域驱动设计》之软件复杂度
+date: 2022-08-08 11:13:36
+author: 聪聪
+category: DDD
+tags:
+- DDD
+- 领域驱动
+---
+
+hello，大家好，我是聪聪。
+
+---
+
+最近闲暇时间看了下张逸的《领域驱动设计》，书中对于软件复杂度包含的一些内容，让我有些同感。目前接触的一些系统中都会有一些`技术债`、`坏味道`在其中。
+
+那么就在这里结合自身现有的一些系统设计，做一个随笔记录。
+
+### 1.复杂系统
+
+什么是复杂的系统呢？
+> 由大量相互作用的部分组成的系统。与整个系统比起来，这些组成部分相对简单，没有中央控制，组成部分之间没有全局性通信，并且组成部分的相互作用导致了复杂行为。
+
+这样的描述可以引入目前被大家进津津乐道的`微服务架构`，`云原生Service Mesh`等等，专注于单一职责与功能的小型模块，利用模块化的方式组合出复杂的大型应用程序，各功能模块使用与语言无关的API进行相互通信。
+
+根据上述对于`复杂系统`的定义，可以将其划分到不同职能模块的微服务中，也可以对于单一系统的细粒度理解。
+
+函数、类、模块、组件和服务等，这些都是构成一个复杂系统元素。这些相对简单的元素之间的作用却导致了软件系统的复杂行为，从而提升软件系统的复杂度。
+
+可以从`理解能力维度`和`预测能力维度`两个方面来理解分析软件的复杂成因：
+
+- **理解能力维度**：
+ - 简单的 Simple
+ - 复杂的 Complicated
+- **预测能力维度**：
+ - 有序的 Ordered
+ - 复杂的 Complex
+ - 混沌的 Chaotic
+
+上述两个方面都蕴含了`复杂`，但是前者相对简单，可以理解为软件的被理解程度，从简单到复杂的进阶。
+
+后者是与有序相对的，包含了软件的发展规律难以预测，是无序的，可以将其理解为复杂难测。
+
+在`预测能力维度`中混沌才是最高层次的复杂，压根就不可预测，可以理解为业务上理解、梳理复杂难以理解，业务发展上无序且快速。
+
+那么，在剖析软件系统的复杂度时，我们可以从`理解能力`和`预测能力`两个维度去探索复杂度的成因。
+
+### 2.理解能力
+
+是什么阻碍了你的理解能力呢？是陌生而产生的畏惧，还是庞大的规模产生的恐惧。
+
+当项目组新来同学，需要快速理解整个项目架构、业务形态时，是否会迷失在错综复杂的系统调用、相互依赖的业务矩阵当中？
+
+就像你来到一个陌生城市旅游时，是否会因为城市错综复杂的交通体系而迷失自我，倘若这座城市就是一个乡郊野外的村落，只有几间房屋和一条南北贯穿的街道，抬头便能将整个村落尽收眼底，你还会产生迷失之感吗？
+
+因此，影响理解能力的第一要素便是：`规模`。
+
+#### 2.1 规模
+
+那么软件系统的规模是你我能够决定的吗？
+
+当然不能，当业务高速发展，需求呈线性增长时，需求就像树木那样生长，一颗小树也会成为参天大树，只有到达某个时间节点时，才会趋于稳定。
+
+当需求呈线性增长时，为了完成实现这些需求功能点时，软件系统的规模也会以近似的速度快速增长。
+
+当然系统规模的快速扩张，不仅仅取决于需求的数量增长，还有需求功能点之间的依赖关系。需求不会独立存在，彼此之间相互影响、相互依赖，修改便会牵一发东全身。
+
+- 函数方法存在副作用，调用时可能对函数方法的返回结果做了隐含的假设。
+- 类的职责繁多，违背了单一职责原则。导致后续开发人员不敢轻易修改，同时也不情况修改会影响到哪些模块，持续熵增，
+- 热点代码频繁改动，职责不单一，逻辑层层包裹，没有清洗的边界划分。
+- 存在隐藏bug，诱发条件具备时便会引起雪崩式调用链瘫痪。
+- 业务场景包含了过多例外场景，每种例外场景存在不同的处理方式。
+- 同步逻辑、异步逻辑相互纠缠，无法清晰明了预知程序执行顺序。
+
+随着软件规模的扩展，复杂度也在增长，这种增长非线性的，而是呈现更为陡峭的指数级增长，这实际上就是我们常说的软件的熵在产生副作用。我们无法规避熵增所带来的重击，软件的熵增可以理解为一个系统`无序`总量，当软件中无序增加时，便是我们常说的`软件在腐烂`。
+
+为什么我们无法避免软件熵增呢？
+
+源于我们构建软件时**无法避免技术债**，无论当前架构设计多么合理，技术决策多么优秀，随着软件的演进均会变得不堪一击，区别在于技术债多与少，以及后续利息有多高。
+
+- 抛弃就得系统，丢弃历史技术债，重新设计一套符合现在业务架构决策的系统，但是必须背负新旧系统同时运行的负担、同时旧系统迁移所带来的成本。可能这就是后人面对`屎山`一样的设计时常说的说的`历史原因所致`。
+- 需要花费大量尽力、寻找熟悉系统人员进行评估、"设计"系统，在开发阶段详细确认所有系统影响点。由于经手人员加多、业务迭代较快，这份详细系统设计也仅仅是“熟悉系统人员”的一份回忆录而已。这也是也分技术债，但更多的是组织架构层面的。
+- 不同业务存在不同分支，分支之间没有正相交，导致某一处的修改便会引入风险点；没有为业务准备合理、全面可行的单元测试，建立功能缺陷，导致系统运行风险增加。纷至沓来的技术债逐渐积累，积累到达临界点时，便会快速坍塌衰亡进入老年期，成为我们常说的“遗留系统”。繁重不堪，修改带来的收益远远小于风险，便无人敢动，只能说一句敬畏历史代码。
+
+最近看了一个这样的`历史原因`、`遗留系统`标签的系统，在该系统上会经常发生各类生产事故，我称之为风险点的熵增爆发：
+
+- 由于渠道名称命名无规范，经手人员随心所致。例如：一个渠道名称存在相同的业务含义，可以存在各类命名：`wechat`、`WeChat`、`WECHAT`。以至于后来判断逻辑上全部都得加上`StringUtils._equalsIgnoreCase_()`这荒唐的逻辑，再或者将其全部转换为大写。试问：统一的逻辑为什么不能抽象出更加职责单一的领域呢？
+- 重复代码的急剧上升。如果需求的功能数量与代码行数之间出现了不成比例的关系，可以说明该系统的健康体征出现了异常。例如：代码行数庞大，并不能说明该系统复杂，可能是得了`肥胖症`，存在大量重复代码。
+
+
+
+#### 2.2 结构
+
+同时，**结构**也是决定系统复杂度的一个关键因素。
+
+结构之所以复杂，多数情况下是我们系统的质量属性所决定的。
+
+例如：设计一个满足高性能、高并发需求的系统，你是否就需要考虑在系统中添加一系列中间件去满足该需求。引入缓存、并行处理、CDN、异步消息解耦削峰、异地容灾、分区可扩展。当然如果是一个海量数据进行处理，又得考虑数据如果分布式存储、如何多节点进行CPU内存高效利用执行，提高运算效率。
+
+如果系统是单体架构，需求简单、业务领域职责单一。同时单体架构一定比微服务架构更加简单便于维护，那为什么还需要这么微服务、服务网格架构呢？因此还是回到了上面提到的`质量属性`
+
+无论设计是优雅还是拙劣，系统结构都会因为设计而变得复杂，其中唯一的区别是：前者是主动地控制结构复杂度，而后者的复杂度变化是偶发性的，是一种技术债的产生，会随着系统规模的增大而产生的一种**无序设计**。
+
+- 代码没有显而易见的入口路径。
+- 不存在一致性，不存在风格，没有将各部分组织在一起的概念。系统当中的风格纯凭开发人员“喜好”、中间件使用方式也是“我想用这个中间件” ，“我在网上看到是这么使用的”，一盘散沙。
+- 系统中的控制流让人觉得不舒服，无法预测或难以预测。
+- 系统中有太多的“坏味道”，阅读代码时没有一种清新的感觉。
+- 数据很少放在它应该放在的地方，而是放在了更方便使用它的地方。例如：直接在业务中进行注入配置属性，应当引入统一、有规则、有结构的配置类进行一并管理。
+
+一个无序的系统，就像隔着毛玻璃观察事物，其中各类元素都变得模糊不清，充斥着各种技术债，在负责需求维护的开发人员中击鼓传花，谁也不愿意做那个踩坑，偿还历史技术债的人。
+
+细节层面，代码浑浊不堪，违背了**高内聚松耦合**的设计原则，许多代码为了方便而方便，放错了位置；有些代码为了避免修改历史代码，“避免踩坑”，直接复制原有逻辑，直接出现新分支逻辑，导致大量重复代码块儿。
+
+架构层面，缺乏系统、业务清晰边界。各种通信组件、调用依赖组件、底层架构组件相互纠缠在一起，缺乏统一管理，一旦修改某一点时往往时牵一发动全身。同一问题空间的解决方案是各式各样，让人烟花缭乱，散发这开发人员自我的喜好风格。
+
+### 3.预测能力
+
+
+---
+
+了解更多内容，可以关注我的微信公众号，更多首发文章。
+
diff --git a/_posts/202208/java-spi.md b/_posts/202208/java-spi.md
new file mode 100644
index 0000000..680bb68
--- /dev/null
+++ b/_posts/202208/java-spi.md
@@ -0,0 +1,508 @@
+---
+title: 利用SPI机制进行插件解耦
+date: 2022-08-16 15:07:09
+author: 聪聪
+category: Java
+tags:
+- SPI
+- Java
+---
+
+[toc]
+
+hello，大家好，我是聪聪。
+
+---
+
+最近在重构一款底层数据加解密中间件，里面有一些内容需要解耦：
+
+- 针对不同数据源处理单独，MySQL、MongoDB、ES数据源进行加解密处理。
+- 可插拔扩展不同加解密算法。
+- 兼容不同日志框架做数据脱敏，自定义客制化脱敏规则。
+
+在这里设想通过SPI机制，让接入业务方可进行插件客制化扩展。
+中间件内提供业务通用AES加解密方法，同时提供接口业务方自行扩展其他加解密算法：RSA等。
+那么就在这里总结一下SPI机制是什么。
+
+## 1.介绍
+> SPI 全称为 Service Provider Interface，是一种服务发现机制。通过在ClassPath路径下的META-INF/services文件夹查找文件，自动加载文件里所定义的类。通常用来实现扩展第三方API，进行插件替换。
+
+之前介绍过一篇Dubbo中的SPI机制，Dubbo中扩展点机制是对JDK的SPI进行了深度加强，解决了JDK SPI的一些痛点问题：
+
+- JDK标准SPI机制会一次性将所有实现进行加载(Iterator方式)，无论使用与否。如果实现类初始化过程较耗时，在加载上会很浪费资源。
+- 如果扩展点加载失败，也就连扩展点实现类的名称也无法拿到。
+- 增加了对扩展点的IoC和AOP的支持，一个扩展点可以直接setter注入其他扩展点。
+
+详细内容可以参考[Dubbo-ExtensionLoader](https://blog.ccoder.cc/dubbo-extensionloader/) 这篇文章。
+
+
+## 2.使用介绍
+按照上面SPI的思想我们下面实现一个小例子。
+### 2.1 定义一个标准接口
+```java
+package cc.ccoder.cipher;
+
+public interface CipherStrategy {
+
+ /**
+ * 加密处理
+ *
+ * @param plainText 明文
+ * @return 加密结束后返回密文,异常时原文本
+ */
+ String encrypt(String plainText);
+
+ /**
+ * 解密处理
+ *
+ * @param ciphertext 密文
+ * @return 解密结束后返回明文,异常时返回原文本
+ */
+ String decrypt(String ciphertext);
+}
+
+```
+### 2.2 定义实现类
+
+上面定义的接口可以理解为一个规范，各服务提供方可自行实现。
+下面就对上面接口进行实现。
+实现内容便是该接口的具体业务逻辑实现，在这里简化处理，直接打印一句话。
+
+- 实现一：AES加解密处理
+```java
+package cc.ccoder.cipher;
+
+public class AESCipherStrategy implements CipherStrategy {
+
+ @Override
+ public String encrypt(String plainText) {
+ System.out.println("AES加密处理");
+ return plainText;
+ }
+
+ @Override
+ public String decrypt(String ciphertext) {
+ System.out.println("AES解密处理");
+ return ciphertext;
+ }
+}
+
+```
+
+- 实现二：RSA加解密处理
+```java
+package cc.ccoder.cipher;
+
+public class RSACipherStrategy implements CipherStrategy {
+
+ @Override
+ public String encrypt(String plainText) {
+ System.out.println("RSA加密处理");
+ return plainText;
+ }
+
+ @Override
+ public String decrypt(String ciphertext) {
+ System.out.println("RSA解密处理");
+ return ciphertext;
+ }
+}
+
+```
+### 2.3 定义配置文件
+需要在`classpath`路径下定义一个配置文件。
+
+- 文件名称为：**接口全限定类名**
+- 文件内容为：**实现类的全限定类名，多个实现类用换行符分割**
+
+
+```java
+cc.ccoder.cipher.RSACipherStrategy
+cc.ccoder.cipher.AESCipherStrategy
+```
+### 2.4 使用方式
+上面已经使用SPI机制进行扩展实现`CipherStrategy`接口，并且存在两个扩展点`RSACipherStrategy`、`AESCipherStrategy`。
+通常情况下标准接口定义为规范，扩展点实现为不同服务提供方实现，从而实现可插拔解耦。
+例如：Java提供数据库驱动接口`java.sql.Driver`，不同数据库提供商对其进行实现。并且我们也能够在该数据库提供商的client 依赖中找到SPI定义的实现类名称。MySQL可以在`mysql-connenctor-java`依赖中的`META-INF/services`中找到对`java.sql.Driver`接口的实现：`com.mysql.jdbc.Driver`。
+看下面代码：
+```java
+public static void main(String[] args) {
+ //java.util中ServiceLoader
+ ServiceLoader