第一周学习总结

T31

Day0开班仪式

开始了，跟着程序员天花板坚持一个月，相信自己，不轻贱不放弃。

开局五问

孤尽

1. 孤帆远影碧空尽
2. 独孤九剑，破尽天下武功

Java东南方向的旅游胜地

巴厘岛

Java工具包里经常能看见的东西：Jakarta

训练营31天

二进制 11111

一月31天（改变要多久

21天真心学不会（不是21天养成一个习惯

杭州到北京的T31次列车

手掌的意思

张开的五根手指对应五个1

钢铁侠的科技元素

拯救地球（我不觉得，如果拯救地球需要一个人那也太悲哀了，这个人不是应该受到种种影响做出决定吗）

钢铁侠不断升级，加强战力（update）

门徒模式

• 什么是门徒/p>

  虚心求学的人，科举时代及第者对主考官自称“门生”。《东关汉记》：好学问，治《严氏春秋》，门徒数百人

毕业、淘汰、证书

毕业分值：

听课、笔记分享、考试测验、互评表现

淘汰：

听课一次未完成扣7分，直播60%，录播80%

笔记分享一次未完成扣7分，字数500+，群里+外

证书：

综合成绩大于等于60

不做损害训练营的事情

不与伙伴发生“对人不对事”的矛盾(这很重要，但第一次见到把这个作为规范的，团体协作人的主观意性太大)

学习理念:

练测评

任务驱动模式

授之以渔

拒绝培训，坚持教育 （说到框架自己解决，以前在 上自学的时候特别是大数据，框架之间的整合问题很多，总以为知道几套搭的来的框架就行了，从未想过自己去整合框架，看框架不兼容的问题到底出现在哪里。就像内存泄漏，如果框架有这个问题，程序肯定会内存泄漏，那个时候你该怎么解决

培训VS教育

维度	培训	教育
引导方式	授人以鱼	授人以渔
教学方式	填鸭式	启发式
培养目标	技能	综合能力
培养方式	教是主体	“教学练”一体化

STAR法则：

Situation Task Action Result

Situation：事情是在什么情况下发生

Task：任务

Result：结果怎么样，在这样的情况下你学习到了什么

make a long story short，START法则，就是一种讲述自己故事的方式，或者说，是一个清晰、条理的作文模板。不管是什么，合理熟练运用此发展，可以轻松的对面试官描述事务的逻辑方式，表现出自己分析阐述问题的清晰性、条理性和逻辑性。

方法论

如何学习的能力：

思维能力

融会贯通的力量

总结能力

快速学习能力：

抓住主要相信的能力

（导航的出发地和目的地，我们只关注导航提示我们下一步该怎么走）

提升摄入的质量

（单位时间内摄入的数量和质量）

加深内化的深度

学会表达、输出

收集

整理

专题

哲学

当你一直退无可退的时候，总有一天你会强大到让你想象不到的地步。

T31项目是什么/h2>

类似于12306 站

• 从查票、下单、付钱、通知的主流程
• 了解架构设计背后的方法论
• 抽象商品、订单、支付的核心模型
• 以战促练，全面提升代码能力、设计能力、交付能力和协作能力

授课模式

直播学习，有问题问带班老师

项目：

• 简介
• 交付
• 安排
• 答辩

课程大纲

• 系统顶层设计篇
• 系统规范落地篇
• 系统效能提升篇
• 系统审计健壮性突破篇

技术栈

SpringBoot、CloudAlibaba、MybatisPlus

MySQL、Redis

RocketMQ

项目架构

规范的开发流程

基于分布式微服务的购票系统

学习之后的提升

学习能力的提升：知识的摄入、内化、表达

思维能力的提升：结构化思维、逆向思维、抽象思维

专业能力的提升：Java进阶的能力、架构能力、定义问题和解决问题的能力

第一节 架构设计

1、T31 项目简介

T31项目是类似于12306的售票 站

• 从查票、下单、付钱、通知的主流程
• 抽象商品、订单、支付的核心模型
• 处理票务异常和日志
• 了解架构设计背后的方法论
• 以战促练，全面提升代码能力、设计能力、交付能力和协作能力

2、需求分析

理解和挖掘用户的诉求、以及背后的逻辑，准换成可行性的分析结果。从非结构化到结构化，确定系统的职责、模块的过程。

边界、用户故事、用户路径

• 分析背后的人性：人性是提出需求的本源

• 需求产品化：模块化、配置化、有逻辑

• 需求落地分析

  需求分析 -> 可行性 -> 设计 -> 编码 -> 测试 -> 发布

伪需求

? 没有经过调研、没有目标、没有逻辑的无脑需求

应对：

1. 用数据化结果否定需求合理性
2. 用正反案例来说明需求需要改进的地方
3. 用户路径和触点推演需求合理性

权力需求

? 老板或者是强势业务方的需求

应对：

1. 先肯定需求价值再提出需求实现的成本
2. 给出更好的需求替代方案
3. 从数据和案例角度说明需求快速上线危害性

最后我们得出的需求分析

1. 用户通过 站注册并且登录
2. 车次、车厢、经停站、时刻表
3. 修改个人信息
4. 乘客管理
5. 余票管理
6. 创建（票）订单
7. 第三方支付
8. 支付成功通知（MOCK）

问题的分层

（本源问题）用户问题：“我想支付”

（经营视角）业务问题：支付一切可以支付的第三方工具

（体系结构）产品问题：支付需要逆向流程、异常流程、对账模式等

（架构代码）技术问题：高并发、可用性，实现第三方支付的链接

3、设计原则

KISS原则

Keep it simple and smile

架构的理念是大道至简：解决问题

• 如何让我们的系统有可扩展性和可维护性
• 如何让我们的系统能够恰到好处地解决问题
• 如何让我们的系统能够运行3-5年不重构
• 业务部门的挑战（价值问题）
• 成本部门的挑战（ROI问题）
• 测试部门的挑战（可测试性）
• 技术部门的挑战（可行性和工期）

DRY原则

Don’t Repeat yourself

一切重复代码都可以抽象

重复代码的危害性：

• 不一致性
• 代码冗余
• 易出BUG

七大设计原则

共同点：提升软件的可扩展性，可维护性是抽象思维和归纳思维的集中体现

1、单一职责

最简单的，但是却是最难的！

高内聚、低耦合的延申

属性和行为向着模块预先定义的功能内聚

模块的名字非常重要

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-r92CipG3-1635754418234)(D:大数据笔记孤尽T31.assetsimage-20211027125515008.png)]

2、里氏代换原则

里氏代换原则（Liskov Substitution Principle），任何基类出现的地方，子类一定可以出现。LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类耶讷狗狗在基类的基础上增加新的行为。里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范

父类能够出现的地方，子类一定能够出现，这是里氏代换原则；

而子类出现的地方，用父类去代替，一般都有问题

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-LGJJVCkm-1635754418236)(D:大数据笔记孤尽T31.assetsimage-20211027131208424.png)]

3、接口隔离原则

接口的力度尽可能地小，同一接口的方法强内聚于同一特征

比如，飞机的接口Fly，有land()、takeoff()

如果我们要加入引擎启动的方法 start()，那就必须定义另一个接口Engine

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-wzKwGBsy-1635754418238)(D:大数据笔记孤尽T31.assetsimage-20211027131611422.png)]

4、组合复用原则

继承是一种绑定关系，相当于父子关系

组合是一种松散的合作关系，相当于谈恋爱

组合产生的对象，方法暴露的少

继承产生的对象，继承路线上的方法会全部暴露出来

增加用户的选择成本，容易误用

正面例子：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-v5z7slug-1635754418240)(D:大数据笔记孤尽T31.assetsimage-20211027134741199.png)]

5、依赖倒置原则

细节依赖抽象

底层依赖于高层

• 宪法不可能依赖于地方法律
• 我们的 络服务只依赖于协议，而不是具体的硬件

6、迪米特原则

迪米特法则（Law of Demeter）又叫作最少知识原则（The Least Knowledge Principle），一个类对于其他类知道的越少越好，就是说一个对象应当对其他对象有尽可能少的了解,只和朋友通信，不和陌生人说话。英文简写为: LOD。

互相了解的信息尽可能的少

当你使用一个接口的时候，你只需要关注：

输入和输出，你不需要关注具体代码实现

7、开闭原则

程序对修改关闭，对扩展开放。

对扩展开放，对修改关闭

扩展能力主要是对需求继续变化的适应能力

代码最大的稳定性，一旦成功运行，就不应该再对具体的代码做修改

通过依赖倒置，实现增加类或模块的方式，实现需求的变化

任何变化的点都是需要被隔离出来的

架构师最大的难点：识别和隔离变化点

熵增定律

我们活着就是在对抗这个定律

孤立系统总是趋向于熵增，最终达到熵的最大状态，也就是系统的最混乱无序状态。但是，对开放系统而言，由于它可以将内部能量交换产生的熵增通过向环境释放热量的方式转移，所以开放系统有可能趋向熵减而达到有序状态。

熵增的热力学理论与几率学理论结合，产生形而上的哲学指导意义：事物的混乱程度越高，则其几率越大。

现代科学还用信息这个概念来表示系统的有序程度。信息本来是通讯理论中的一个基本概念，指的是在通讯过程中信 不确定性的消除。后来这个概念推广到一般系统，并将信息量看作一个系统有序性或组织程度的量度，如果一个系统有确定的结构，就意味着它已经包含着一定的信息。这种信息叫做结构信息，可用来表示系统的有序性；结构信息量越大，系统越有序。因此，信息意味着负熵、反熵增或熵减。

开闭原则是熵减定律

上面讲了，熵减最重要的是形成开放性；

开放性设计是系统能够有序接纳外部能量的能力。在软件领域，我们的外部能量值得是需求的多变和业务的不断试错。扩展性设计是一种开闭原则的思维，比如T31中的支付，我们未来支付VISA，MASTER（VISA和Mastercard是两家国际信用卡发卡机构），或者是APPLE PAY，我们的通知未来支持电话、语言通知，钉钉等各类办公软件通知等。

实践点

类图设计

接口设计

组合设计

4、架构与架构图

什么是架构

架构是一种能力，而不是一个职位

架构 = 组成+决策

组成 = 模块结构+模块关系

决策 = 约束+设计原则+演化方向

架构的目的

确定系统边界，在技术层面上做与不做

确定系统里各模块之间的依赖关系与模块的宏观输入与输出

使后续的子系统或模块设计在一个既定的框架内和技术方向上继续演化

明确非功能性需求，非功能性需求是指安全性、可用性、可扩展性等

如何画架构图

1. 搞清楚要画的架构图类型
2. 确认架构图中的关键要素（比如产品、技术、服务）
3. 梳理关键要素之间的关联：包含、支撑、同级并列等
4. 输出关联关系清晰的架构图

架构图的好坏

布局（图像的上下左右六个方向的位置关系）

颜色（视觉中心在哪里，哪些元素被忽略）

逻辑（组件之间的依赖，业务实现的可行性）

架构图的分类

业务架构

使用一套方法论，对所涉及到的业务单元进行边界划分，熟悉业务

比如：团购 站系统 ——> 商品类目，订单服务，支付，退款等进行清洗划分

应用架构

对阵个系统的实现进行可视化落地实践，系统的层次 / 开发原则 / 各个层次的应用服务，一般为垂直依赖型。

比如：团购 站系统 ——> 数据层，服务层，通讯层，展现层

数据架构

是一套对存储数据的架构逻辑，根据各个系统应用场景、不同时间段的应用场景。对数据进行注入数据异构、读写分离、缓存使用、分布式数据策略等划分。

思考：系统需要什么样的数据何存储这些数据何进行数据架构设计/p>

技术架构

承接应用架构的技术需求，并根据识别的技术需求，进行技术选型，把各个关键技术和技术之间的关系描述清楚

系统架构图

物理视图：和部署相关的架构决策（一般不画）

逻辑视：设计满足功能需求的架构（UML图）

开发试图：设计满足开发期质量属性的架构（UML图）

处理视图：设计满足运行期质量属性的架构（UML图）

场景试图：需求分析技术，通常采用UML的用例图进行设计

UML定义

Unified Model Language

Unified：

Model：

Language：

UML分类

统一建模语言，使用图形和符 描述软件模型中的各个元素和它们之间的关系

UML分为两大类：

静态结构图：类图、对象图、包图、组件图、部署图

动态行为图：交互图（时序图与协作图）、状态图、活动图

UML类图的六大关系

泛化关系：继承

实现关系：实现接口

聚合关系：业务上整体与部分可以分开，是关联关系的特例

组合关系：业务上整体与部分可以分开，是关联关系的特例

依赖关系：只要在类中用到了对方，就存在依赖关系

关联关系：体现的是业务逻辑的关系，是依赖关系的特例，具有导航性&多重性

类图示例

类图（Class diagram）可显示模型的静态结构，特别是模型中存在的类、类的内部结构以及它们与其他类的关系等。

• T31的核心模型：票
• 核心服务：订单

T31类图

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-w5iotnFX-1635754418241)(D:大数据笔记孤尽T31.assetsimage-20211027165656137.png)]

时序图示例

时序图通过描述对象之间发送消息的时间顺序显示多个对象之间的动态协作。

• 关注正常流程
• 不关注逆流程
• 不关注异常流程
• 不关注分支判断

T31时序图

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-6zeLiEKG-1635754418242)(D:大数据笔记孤尽T31.assetsimage-20211027170717196.png)]

架构图

什么是架构图

架构图就是表达架构这种集合的载体，是水平的业务单元+垂直的技术单元组成的逻辑架构图

架构图的作用什么/p>

将目标系统的架构可视化，通过直观的方式描述技术思维，减少沟通障碍，提升协作效率，划分目标系统的边界

5、Q&A

quality assurance 的简称，质量保证。质量保证是指为使软件产品符合规定需求所进行的一系列有计划的必要工作；为使某项目或产品符合已建立的技术需求提供足够的置信度，而必须采取的有计划和有系统的全部动作的模式。

6、其他补充

PMF

Product Market Fit的简写，是指产品和市场达到最佳的契合点，提供的产品正好满足市场的需求，令客户满意，这是事业成功的第一步。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-zJqR4NFr-1635754418243)(D:大数据笔记孤尽T31.assets20a55d484f2f7db91cb38a645f31eb2f.png)]

从上到下：用户体验（UX）、产品的功能集、价值主张、用户未被满足的需求、目标用户

确定你的目标用户发现用户未被满足的需求定义你的价值主张设计你的最小可行产品（MVP）的功能集创建你的MVP原型完成MVP的客户测试

• PMF三种策略

  • 用更好的产品体验来满足已被证实的市场，如京东。
  • 抓住细分市场用产品来满足已有但尚未满足的市场，如一 店。
  • 全新的市场，用产品创造一个新市场，如淘宝

• PMF的实现标准

  以下标准作为参考

  • 当场能不能出票
  • 同时买同一列火车的临近座位的多张票是否能在一起
  • 候补多久出票
  • 30%次日留存
  • 月流失低于2%

总结

PMF指产品和市场达到最佳的契合点，概念比较简单，但是在做产品的过程中我们往往会由于经验主义或者其他原因使产品脱离用户陷入自嗨，脱离市场产品就失去了意义。我们在产出的过程中一定要客观的人事市场，不断收集反馈信息从中汲取营养，不断强化优势，及时纠正错误，找到适合自己产品的PMF状态。

项目介绍

需求分析架构

架构设计目的

模块设计原则

Day1产出：系统设计方案论笔记

Day2 作业

实操

• 购票系统的需求与设计实现

  0. 购票系统需求分析
  1. 购票系统用例图 (1)
  2. 订单模块类图 ()
  3. 订单的状态类图 ()
  4. 订单的状态图 (1)
  5. 购买车票的活动图 ()
  6. 购买车票的时序图 (1)
  7. 车票改签的协作图
  8. 购买系统部署图

• 产出结果

  系统用例图

  系统状态图

  系统时序图

  关键类图

  活动图

第二节 MySQL设计

建表规约

解决数据库相关名称的纠结

选择合适的数据类型和长度

表、字段命名

• 必须使用小写字母或数字
• 禁止出现数字开头
• 禁止两个下划线中间只出现数字
• 不使用复数名字
• 禁用保留字
• 是与否概念性的字段，必须使用is_xxx的方式命名

数据类型

• 小数类型为 decimal
• 货币数据使用最小货币单位，数据类型我bigint
• 字符串长度几乎相等使用char，一般定长是char
• varchar长度不要超过5000（本身6553），不定长数据用varchar

建表强制规约

表必备三字段

id

create_time

update_time

建表推荐规约

1. 表的命名最好遵循“业务名称_表的作用”
2. 库名和应用名称尽量保持一致
3. 如果修改字段含义或对字段表示的状态追加时，需要及时更新字段注释
4. 字段允许适当荣誉，以提高查询性能，但必须考虑数据一致
   1. 单表行数超过500万行或者单表容量超过2GB，才推荐进行分库分表·

索引规约

索引的特性

索引占比和表是1比1的关系

持久性

有序性

索引的分类

• 存储形式
  1. 聚簇索引
  2. 非聚簇索引
• 数据约束
  1. 主键索引
  2. 唯一索引
  3. 非唯一索引
• 索引列的数量
  1. 单列索引
  2. 组合索引
• innoDB可以创建的索引
  1. 主键索引
  2. 唯一索引
  3. 普通索引

不可以创建的索引 覆盖索引

索引的数据结构

二叉查找树

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-lTwQrvww-1635754418244)(D:大数据笔记孤尽T31.assetsimage-20211029154722335.png)]

索引名称规约

索引命名

• 主键索引名为pk_字段名
• 在varchar字段上建立索引时，必须指定索引长度
• 建组合索引的时候，区分度最高的在最左边

创建索引避免有如下的极端误解

索引宁滥勿缺

认为一个查询就需要建一个索引

吝啬索引创建

认为索引会消耗空间、严重拖慢记录的更新以及行的新增速度

抵制唯一索引

认为唯一索引一律需要在应用层通过“先查后插”方式解决

SQL规约-索引

• 注意字段类型

  防止因字段类型不同造成的隐式转换，导致索引失效

• 利用覆盖索引

  利用覆盖索引来进行查询操作，避免回表

• 利用有序性

  如果有order by 的场景，请注意利用索引的有序性

• 禁模糊

  页面搜索严禁左模糊或者全模糊，如果需要请走索引擎来解决

SQL规约-避坑指南

1. 不得使用外键与级联，一切外键概念必须在应用层解决
2. 禁止使用存储过程，存储过程难以调试和扩展，更没有移植性
3. 数据订正时，要先select，避免出现误删除，确认无误才能执行更新语句
4. 只要涉及多个表，都需要在列名前加表的别名（或表名）进行限度
5. SQL语句中表的别名前加as，并且以t1、t2、t3、…的顺序依次命名
6. in后边的集合元素数量，控制在1000个之内

SQL与ORM映射规约

ORM映射规约

1. 在表查询中，一律不要使用 * 作为查询的字段列表
2. POJO类的boolean属性不能加 is，而数据库字段必须加 “is_”
3. 查询返回结果都需要使用ResultMap映射
4. 不要使用${}
5. 不要使用MyBatis自带的queryForList方法
6. 不允许直接使用hashMap与Hashtable接收结果集
7. 更新数据表记录时，必须同时更新 update_time
8. 不要写一个大而全的数据更新接口

数据库设计实战

数据库设计三大范式

第一范式

每列属性不可拆卸

第二范式

表中的每列都和主键相关

第三范式

每列都和主键列直接相关，而不是间接相关

MySQL explain 使用技巧

1、explain简介

MySQL提供了一个explain命令，它可以对Select语句的执行计划进行分析，并输出select执行的详细信息，以供开发人员针对性优化。

使用explain来查看SQL语句的执行计划，查看该SQL语句有没有使用上索引，有没有做全表扫描，这都可以通过explain命令来查看。

可以通过explain命令深入了解MySQL的基于开销的优化器，还可以获得很多可能被优化器考虑到的访问策略的细节，以及当运行SQL语句时哪种策略预计会被优化器采用。

一般使用的时候在 Select 前面加上 explain 就行了

2、参数说明

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-g6cIqk2x-1635754418245)(D:大数据笔记孤尽T31.assetsimage-20211030164135722.png)]

mysql> explain select * from tuser where id = 2 G

*************************** 1. row ***************************

id: 1

select_type: SIMPLE

table: tuser

partitions: NULL

type: const

possible_keys: PRIMARY

key: PRIMARY

key_len: 4

ref: const

rows: 1

filtered: 100.00

Extra: NULL

1 row in set, 1 warning (0.01 sec)

第三节 异常处理和日志

Java异常体系

Java异常机制

使用异常、日志为系统保驾护航

道路千万条，安全第一条

日志不规范，排查两行泪

异常应当描述导致当前异常发生的原因

根据异常栈快速定位倒异常发生的位置

结合异常描述和异常栈解决异常

C语言的“异常处理”

异常处理

日志规约

错误码规约

异常与日志综合

Day6 实操

日志设计文档

日志的功能

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-xqWlNUxp-1635754418245)(D:大数据笔记孤尽T31.assets日志的功能.jpg)]

日志的时效规约

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-dgL36rqT-1635754418246)(D:大数据笔记孤尽T31.assetsimage-20211101120521307.png)]

日志记录规约

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-jWlOrlnX-1635754418247)(D:大数据笔记孤尽T31.assetsimage-20211101135325093.png)]

系统应依赖使用日志框架（SLF4J、JCL）的API而不是具体日志库中的API

SLF4j绑定具体日志框架的过程

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-fcxdiPmK-1635754418248)(D:大数据笔记孤尽T31.assetsimage-20211101135408638.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-1W7USx5o-1635754418249)(D:大数据笔记孤尽T31.assetsimage-20211101135431415.png)]

1. 系统应依赖使用日志框架（SLF4J、JCL）的API而不是具体日志库中的API
2. 在日志输出时，字符串变量之间的拼接使用占位符的方式
3. 日志打印时禁止直接用JSON工具将对象转换为String
4. 尽量用英文来描述日志错误信息

logback框架使用之核心配置对象及属性分析

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-w9Z7atkb-1635754418250)(D:大数据笔记孤尽T31.assetsimage-20211101140221931-1635746543388.png)]

logback日志框架使用之配置文件解析

根节点-configuration及其通用属性的配置示例

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-RLnCQtnm-1635754418251)(D:大数据笔记孤尽T31.assetsimage-20211101140330349.png)]

Appender节点配置示例

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-oFN2XBJ9-1635754418252)(D:大数据笔记孤尽T31.assetsimage-20211101140436215.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-6XasYnKw-1635754418253)(D:大数据笔记孤尽T31.assetsimage-20211101140509271.png)]

logback日志框架使用之关键类图分析

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-7BU5gnMM-1635754418254)(D:大数据笔记孤尽T31.assetsimage-20211101140546120.png)]

异步Appender配置示例

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-hslrnue4-1635754418254)(D:大数据笔记孤尽T31.assetsimage-20211101140618478.png)]

logback日志记录线程模型分析

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-whP0Dp2e-1635754418255)(D:大数据笔记孤尽T31.assetsimage-20211101140651843.png)]

异常错误日志实时通知

将错误异常日志发送至邮箱与企业微信

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-c9hgXhcR-1635754418256)(D:大数据笔记孤尽T31.assetsimage-20211101140757724.png)]

整合Sentry将错误日志发送至钉钉消息

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-adB8XDNo-1635754418257)(D:大数据笔记孤尽T31.assetsimage-20211101140833663.png)]

日志输出规约

日志级别开关判断

异常信息要完整

避免重复打印日志

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-0EVFkyjy-1635754418258)(D:大数据笔记孤尽T31.assetsimage-20211101140952422.png)]

扩展日志设计与规约

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ikHTgMMo-1635754418258)(D:大数据笔记孤尽T31.assetsimage-20211101141038713.png)]

T31日志设计标准

基于以上我们的日志设计将按以下标准来设计

1、系统应依赖使用日志框架（SLF4J、JCL）的API而不是具体日志库中的API，这样有利于哦我们维护和统一各个类的日志处理方式

2、为了检查异常错误是否是在应用运行期间周期性发送，我们的日志文件起码要保存两周以上。

3、应用中的扩展日志的命名方式应该统一 ：

例如：

T31server应用中余票监控时区转换异常，如：

我们为了方便查看和便于通过日志对系统进行及时监控，应该对日志进行分类，比如将错误日志和业务日志分开存放

4、级别日志输出（trace/debug/info）必须使用条件输出形式或者使用占位符的方式。

说明：logger.debug(“Processing trade with id: ” + id + ” symbol: ” + symbol);如果日志级别是 warn，上述日志不会打印，但是会执行字符串拼接操作，如果 symbol 是对象， 会执行 toString()方法，浪费了系统的计算资源，就算执行了上述操作，可日志却也没有打印。

例如：

使用条件输出形式

使用占位符的方式

5、为了避免重复打印日志，造成磁盘IO浪费，所以一定要做log4j.xml中设置additivity=false。

6、异常信息必须包括两类信息：系统异常现场信息和异常堆栈信息。如果不处理，那就要关键字 throws 往上抛出。

7、对于日志的使用要谨慎。生产环境禁止输出debug日志；对于info日志要有选择的输出；warn级别的日志要注意日志输出量的问题，避免把服务器磁盘占满，及时删除这些观察日志。

错误码设计文档

错误码的功能和应用

1. 错误码暂定都是5位数字，并配有相应的英文解释
2. 错误码为 0 表示成功，其他都表示错误
3. 错误码按模块按功能场景分级分段，前三位错误码表示模块，第四位表示模块下的功能。举例，商城系统里有交易模块和商品模块，则可以这样划分：401开头的表示交易模块，402开头的表示商品模块，4011开头的表示交易模块里的下单场景需要用到的错误码，4021表示商品模块下的添加商品场景里需要用到的错误码。如果某个场景功能下需要的比较多的错误码，则可以使用其他未被使用的码段，即该场景功能可以拥有多个码段，然后通过添加注释等方式让人理解即可。
4. 数字 1 开头的错误码表示系统级别的错误，比如缺少某种字符集，连不上数据库之类的，系统级的错误码不需要分模块，可以按照自增方式进行添加
5. 数字 4 开头的错误码表示API参数校验失败，比如 “交易模块下单场景中，订单金额参数不能为空” 可以用 40111 错误码来表示
6. 数字 5 开头的错误码表示后台业务校验失败，比如 “交易模块下单场景中，该用户没有下单权限” 可以用 50111 错误码来表示
7. 数字 4 开头的错误码与数字 5 开头的错误码对应的模块分类需要保持一致，即 4011 表示交易模块下单场景的API错误，5011 表示交易模块下单场景的业务错误
8. 错误码按需分配，逐步增加，灵活扩展

错误码规约

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-z8vulS3g-1635754418259)(D:大数据笔记孤尽T31.assetsimage-20211101152244310.png)]

T31错误码设计文档

错误码举例

一、授权／令牌请求接口返回码

描述应用发起授权请求或令牌请求时，开放平台的返回码。

错误码	错误描述	Error Description
10000	非法的请求参数	Invalid request
10001	用户认证失败	Invalid client
10002	非法的授权信息	Invalid grant
10003	应用没有被授权，无法使用所指定的grant_type	Unauthorized client
10004	grant_type字段超过定义范围	Unsupported grant_type
10005	scope信息无效或超出范围	Invalid scope
10006	提供的更新令牌已过期	Expired token
10007	redirect_uri字段与注册应用时所填写的不匹配	Redirect_uri mismatch
10008	response_type参数值超过定义范围	Unsupported response type
10009	用户或授权服务器拒绝授予数据访问权限	Access denied

二、API通用返回码

描述API接口的共性返回码

错误码	错误描述	Error Description
0	成功	Success
1	未知错误	Unknown error
2	服务暂不可用	Service temporarily unavailable
3	未知的方法	Unsupported openapi method
4	接口调用次数已达到设定的上限	Open api request limit reached
5	请求来自未经授权的IP地址	Unauthorized client IP address
6	无权限访问该用户数据	No permission to access user data
7	来自该refer的请求无访问权限	No permission to access data for this referer
100	请求参数无效	Invalid parameter
101	api key无效	Invalid API key
104	无效签名	Incorrect signature
105	请求参数过多	Too many parameters
106	未知的签名方法	Unsupported signature method
107	timestamp参数无效	Invalid/Used timestamp parameter
109	无效的用户资料字段名	Invalid user info field
110	无效的access token	Access token invalid or no longer valid
111	access token过期	Access token expired
210	用户不可见	User not visible
211	获取未授权的字段	Unsupported permission
212	没有权限获取用户的email	No permission to access user email
800	未知的存储操作错误	Unknown data store API error
801	无效的操作方法	Invalid operation
802	数据存储空间已超过设定的上限	Data store allowable quota was exceeded
803	指定的对象不存在	Specified object cannot be found
804	指定的对象已存在	Specified object already exists
805	数据库操作出错，请重试	A database error occurred. Please try again
900	访问的应用不存在	No such application exists

异常处理设计文档

1、在Controller层统一捕获异常

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-cR2fCtEr-1635754418260)(D:大数据笔记孤尽T31.assetsimage-20211101153800619.png)]

2、全局异常处理组件GlobalExceptionHandler 的定义和使用

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-gFos3uwJ-1635754418261)(D:大数据笔记孤尽T31.assetsimage-20211101153818178.png)]

3、API层异常设计实践

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-cgSgYiVA-1635754418262)(D:大数据笔记孤尽T31.assetsimage-20211101153829115.png)]

4、Service层异常设计实

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来