[代码重构](master): 文档更新

2022年11月1日18:39:36

best-practice/中间件.md

@@ -0,0 +1,44 @@
+# 中间件研究
+
+
+## 1. 中间件生态
+- ![中间件图](pic/中间件图.png)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+## 2. 数据结构
+
+
+
+
+
+## 3. 经典应用
+
+
+
+
+## 4. 场景分析
+
+
+
+## 5. 补充

best-practice/项目介绍.md

@@ -19,7 +19,51 @@
 
 
 
+## 解决方案研究1 - 核心业务的增长及治理
 
+### 0. 会产生的问题
+- 代码
+  - 原始的代码设计可能存在缺陷, 缺乏设计模式的应用, 或者需求的增加让代码的耦合性增加，可读性降低，可维护性降低
+- 数据
+  - 在存储容量不足，查询方面可能存在瓶颈, 以及数据的增加带来的表结构的改变灾难，要清楚怎么变，怎么设计变，怎么设计不变
+- 服务
+  - 原始服务的拆分可能存在不合理性，对于公用服务的封装可能也存在一定的缺陷，以及对服务的监控啥的，可能都需要重新去建设体系化
+- 扩展
+  - 抓住不变和可变，去预测和治理一些新增的需求和适应一些改变
+- 支撑
+  - 合理的应用和使用任何可靠手段来支撑业务，赋予业务更多的可能和支撑业务的大幅度增长和可用性
+- 安全
+  - 设计合理的安全架构，制定自己系统的安全测试线，去收集问题，发现问题，解决问题
 
+### 1. 解决问题方案
+- 代码
+  - 使用设计模式
+    - 1- 先确认要修改的代码范围，或者要重新设计的业务范围
+    - 2- 规划要变化的代码范围，做一些改变的界限，评估界限边缘的代码会带来的一些风险，检查边缘代码
+    - 3- 分解代码的功能，按设计模式的: 创建型，结构型，行为型 进行分类
+    - 4- 对不同模式的设计模式进行评估使用，注意还是不要创新，要有一些历史的借鉴经验在这里
+    - 5- 在使用设计模式的时候要想想后续改变大不大，以及有一些心里的标准，防止使用设计模式爆炸
+  - 封装通用
+    - 1- 对同一类的方法进行封装
+    - 2- 按照业务的对接和操作方式进行封装
+- 数据
+  - 数据结构
+    - 1- 对实体，实体之间的关系进行梳理-ER图
+    - 2- 存储的合理性进行分析，让表的结构和存储合理
+    - 3- 借助其他的存储载体的特有数据结构进行优化设计
+  - 表的优化
+    - 1- 对单业务模型进行大数据治理，比如分表分库
+    - 2- 对表的设计扩展进行预留，对单表的大小进行合理化检查，避免没必要的冗余过多，或联合查询过多
+    - 3- 盘点查询，对索引进行进一步的设计及规划，对一些文本处理的情形，
+  - 缓存
+    - 1- 添加数据层的缓存组件，对热数据进行缓存
+- 服务
+  - 服务拆组
+    - 1- 根据业务需求检查服务的设计合理性，对服务进行有必要地拆组
+  - 服务监控
+    - 1- 使用SpringCloud 及 SpringCloudAlibaba 对服务的调用和状态进行详尽的检测
+- 扩展
+  - 功能扩展
+    - 1- 对