weixin_43751271的博客

代码评审 熵减的过程 减少系统混乱 提高代码质量 工程师互相review，扫除知识盲区，提升代码的质量 团队成长 养成团队成员间的交流文化，有利于团队的知识共享 提升代码规范度 通过代码审查，发现纠正不规范情况，慢慢形成良好开发规范 健壮性与鲁棒性 如何构建健壮的系统 面向失败的架构思想 混沌工程 ...

分布式锁介绍 在同一个JVM 内部，大家往往采用synchronized 或者Lock 的方式来解决多线程间的安全问题，但是在分布式架构下，在JVM 之间，那么就需要一种更佳高校的锁机制，来处理这种跨JVM 进程之间的线程安全问题，解决方案就是: 使用分布式锁。 Redis分布式锁 原理 Redis 分布式锁机制，主要借助setnx 和 expire 两个命令完成。 setnx 当key 不存在，将key 设置为value, 存在不做任何操作，返回0. expire 设置key 过期时间。 原理解析:

JWT Json web token (JWT), 是为了在⽹络应⽤环境间传递声明⽽执⾏的⼀种基于JSON的开放标准（(RFC 7519).定义了⼀种简洁的，⾃包含的⽅法⽤于通信双⽅之间以JSON对象的形式安全的传递信息。因为数 字签名的存在，这些信息是可信的，JWT可以使⽤HMAC算法或者是RSA的公私秘钥对进⾏签名。 JWT组成 Header头部 头部包含了两部分，token 类型和采⽤的加密算法 Payload负载 这部分就是我们存放信息的地⽅了，你可以把⽤户 ID 等信息放在这⾥，JWT 规范⾥⾯

单元测试规约 单元测试 单元测试是对软件组成单元进行的测试。其目的是检验软件基本组成单位的正确性。 测试对象是软件设计的最小单元：模块，又称为模块测试。 单元测试的益处： • 提高软件质量 • 促进代码优化 • 提升研发效率 AIR原则 可重复性 独立性 自动化 BCDE原则 B：Border 边界值测试 C：Correct 正确的输入，并得到预期的结果 E：Error 证明程序有错 D：Design 与设计文档相结合 常用单元测试框架 系统安全规约 权限控制 -越权访问漏洞 前后端同时对用户

OAuth2 OAuth2是什么 目前最流行的授权协议，用来授权第三方应用，获得用户数据。 授权模式 OAuth2的特点 Cookie Session 和 Token的区别 cookie不能跨域，前后端分离分布式架构实现多系统SSO非常困难 移动端应用没有cookie,所以对移动端支持不好 token基于header传递，部分解决了CSRF攻击 token要比sessionID大，客户端存储在了Local Storage中，可以直接被JS读取 基于token的分布式方案 OAuth2的使用 t31项

开发避坑指南 浮点数据处理 正确选择数据类型 任何货币金额：均以最小货币单位且整形类型来存储 浮点数据类型的问题：精度丢失 日期数据处理 Java传统的日期API：Date、SimpleDateFormat、Calendar Java8新的日期API：LocalDate、LocalTime、LocalDateTime 传统API存在的问题：线程不安全，没有区分日期和时间对应的类、格式化不方便。 控制语句的避坑规范 switch要记得写break；否则会产生case穿透现象，导致多层调用 swit

缘由 熵增定律 目的 减少维护成本 改善可读性 提高团队开发的合作效率 锻炼出更加严谨的思维 身心愉悦 代码格式和命名风格 命名体现代码元素特质 抽象类命名使用abstract或base开头 异常类命名使用Exception结尾 测试类命名以它要测试的类名开始,以Test结尾 类型与中括号紧挨相连来定义数组 枚举类名带上Enum后缀， 枚举成员名称需要全大写，单词间用下划线隔开 命名最好望文知义 某些不规范的缩写会导致理解成本增加，比如condition缩写成condi 主流的编程语言基本上以英语为基

技术架构选型 目标 降低研发成本 提高研发效率 数据访问层选型 数据库连接池选型 常用中间件选型 功能不具备一票否决 重性能、重拓展 技术栈、团队拓展能力 远程通讯框架选型 RPC框架核心技术点 网关层选型 网关分类 流量网关：关注稳定与安全 全局性流控 防止Web攻击 屏蔽工具扫描 黑白IP名单 证书/加解密处理 业务网关：提供更好的服务 服务级别流控 服务降级与熔断 路由与负载均衡、灰度策略 服务过滤、聚合与发现 多级缓存策略 ...

1. 应用分层 1.1 为什么要分层？ 隐藏下层业务逻辑的复杂性 提高系统的组件化和可维护性 可扩展性、可维护性 计算机领域的任何问题都可以通过增加一个中间层解决 1.2 MVC框架模式 View Model Controller 1.3 推荐分层结构 1.4 分层异常处理 DAO层- 异常类型很多，不需要打印日志。 SERVICE层-必须记录出错日志到磁盘，尽可能带上参数信息， 保护案发现场。 WEB层-绝不能往上抛异常，应跳转到友好错误页面， 友好的错误提示信息。 开放接口层- 将异常处理成

异常与目录规约异常规约Java异常体系异常处理日志规约日志时效规约日志记录规约日志输出规约扩展日志的设计与规约错误码规约二级目录三级目录 异常规约 Java异常体系 异常处理 异常处理流程 异常处理机制 异常抛出与捕获原则 非必要不适用异常 使用描述性消息抛出异常 力所能及的异常一定要处理 异常忽略要有理有据 特殊NPE场景及其处理对策 日志规约 日志的目的：监控告警、记录行为轨迹和快速定位问题 日志时效规约 当天日志命名：以“应用名.log” 来保存 过往日志命名：以{logname}.log.

MySQL数据库规约建表规约索引规约SQL规约ORM映射规约 建表规约 表、字段命名 • 必须使用小写字母或数字 • 禁止出现数字开头 • 禁止两个下划线中间只出现数字 • 不使用复数名词 • 禁用保留字 • 是与否概念的字段，必须使用 is_xxx 的方式命名 数据类型 小数类型为 decimal 货币数据使用最小货币单位，数 据类型为bigint 字符串长度几乎相等使用 char varchar长度不要超过 5000 表必备三字段 id create_time update_time 建表推荐规约 表

需求、设计以及架构## 需求分析 需求分析原则 从用户的诉求出发 注意边界：那些需求需要做的，那些需求是不需要做的 需求分类 伪需求：没有调研，没有目的，没有逻辑的需求 强需求或者强势力方提出需求 先肯定需求然后在提出成本等问题 根据实际情景来做推演 架构设计 用户，业务，产品，技术不同层次 KISS原则 keep it simle and smile 大道至简 simle ：可扩展性和可维护性 smile：价值，可测试性 DRY原则 DRY是Andy Hunt 和 Dave Th