Posts

生产问题排查基本命令 当线上服务出现问题的时候, 可以通过固定的步骤, 获取线上环境的信息, 一步一步逐步定位问题所在. X00. 判断问题影响范围 当突然接到线上报警, 应立即判断问题影响范围,如果直接导致服务不可用,则需立即响应(包括重启服务,或进行服务迁移扩容,正常情况下靠谱的运维不会让这个情况发生). 如果是高可用部署, 则联系运维同事, 切换流量到另外几台正常的机器(修改NGINX配置等),保留作案现场,进行分析定位问题. X01. 查看cpu top 查看cpu详细信息: 按1 查看负载 按cpu使用率排序: 按P 查看COMMAND详细信息: 按c top -H -p pid 查看某进程下的线程信息 X02. 查看内存 top 按内存排序: 按M free -h X03. 查看磁盘 df -h X04. 定位进程号 方法1 通过ps命令 例如: 服务名称为fcrm-c-rest 命令: ps -ef | grep 'fcrm-c-rest' 则可以查询到名称为fcrm-c-rest的进程号 方法2 通过top命令 敲击top命令后, 输入M 或 P 分别根据内存使用量排序, 和CPU使用量排序来进行定位线程号 方法3 通过jps命令 通过jps 命令获取当前执行的java进程 jps - Lists the instrumented Java Virtual Machines (JVMs) on the target system....

Git规范 环境说明 公司有4套环境,dev ,uat, stag, prd. dev 开发联调环境 uat 测试环境 stag 预生产环境 prd 正式生产环境 相关GIT规范 总体流程图 分支说明 分支说明 分支 命名规范 分支说明 举例 发布环境 master Master 主分支,也是上线发布分支 master Prd/Stag dev dev 开发分支, 功能开发后合并的分支,uat环境测试分支 dev Uat feature feature/[月日(版本)]_[功能说明] 功能分支, 有新功能需要开发,从master分支拉取该分支 feature/0102_mall_order Dev hotfix hotfix/[月日(版本)]_[bug说明] 紧急bug修复分支 hotfix/0108_order_datetime Prd/Uat/Stag/Dev 流程说明 常规开发流程 接到新需求后, 从master分支拉取对应的功能分支, 分支命名规范为: feature/mmdd_功能说明 开发完成,并且dev环境自测通过后. 合并到 dev 分支,并部署提测到UAT环境 测试完成通过后, 合并dev分支到master分支, 发布stag环境进行回归测试 回归测试完成, 定义TAG号, 进行发版 紧急修复流程 线上出现紧急BUG需要修复,从上次发布的master分支拉取hotfix分支, 分支命名规范为: hotfix/mmdd_bug说明 紧急修复bug,并自测通过后, 提测并部署到UAT环境 紧急测试完成通过后, 合并hotfix分支到master分支 ,并发布到Stag环境进行回归测试. 回归测试完成, 定义FIX_TAG号,进行紧急上线发布 发布完成确认无误, 合并hotfix分支到dev分支 COMMIT & Merge规范 提交说明 提交时, 需说明提交属于哪个功能, 并且在该功能做了哪些修改....

开始使用 1 2 3 4 5 6 7 8 9 10 11 12 13 14 <jmh.version>1.23</jmh.version> <dependency> <groupId>org.openjdk.jmh</groupId> <artifactId>jmh-core</artifactId> <version>${jmh.version}</version> </dependency> <dependency> <groupId>org.openjdk.jmh</groupId> <artifactId>jmh-generator-annprocess</artifactId> <version>${jmh.version}</version> <scope>provided</scope> </dependency> 可以使用maven archtype进行自动生成 样例 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 @BenchmarkMode(Mode.Throughput) // 吞吐量 @OutputTimeUnit(TimeUnit.MILLISECONDS) // 结果所使用的时间单位 @State(Scope.Thread) // 每个测试线程分配一个实例 @Fork(2) // Fork进行的数目 @Warmup(iterations = 2) // 先预热4轮 @Measurement(iterations = 5) // 进行10轮测试 public class MyBenchmark { static AtomicInteger integer = new AtomicInteger(); @Benchmark public void testMethod() { integer....

删除其实是使用正则表达式替换 VSCODE 删除包含符串的行 删除包含INSERT的行 1 ^(.*)INSERT(.*)$\n VSCODE 删除空行 1 ^\s*(?=\r?$)\n

SOLID 原则 单一职责原则(SRP) 一个类或者模块只负责完成一个职责,不要设计大而全的类, 要设计力度小,功能单一的类,单一职责原则是为了实现代码高内聚,低耦合,提高代码的复用性,可读性, 可维护性. 开闭原则(OCP) 对扩展开放,对修改关闭. 添加一个新的功能应该是在已有的代码基础上扩展代码(新增模块,类,方法等), 而非修改已有代码. 开闭原则不是完全杜绝修改, 而是以最小的修改代码的代价来完成新功能的开发. 里氏替换原则(LSP) 子类对象能够替换程序中父类对象出现的任何地方,并且保证原来程序的逻辑行为不变及正确性不被破坏 哪些操作违背了LSP 子类违背父类申明要实现的功能 子类违背父类对输入输出,异常的约定 子类违背父类注释中所罗列的任何特殊说明 接口隔离原则(ISP) 客户端不应该强迫依赖它不需要的接口. 如果把接口理解为一组接口集合, 可以是某个微服务的接口, 也可以是某个类库的接口, 如果部分接口只被部分调用者使用,我们就需要将这部分接口隔离出来,单独给这部分调用者使用,而不强迫其他调用者也依赖这部分不会调用的接口. 如果把接口理解为单个API接口或者函数, 部分调用者只需要函数中的部分功能, 那我们就需要把函数拆分成粒度更细的多个函数, 让调用者只依赖他需要的那个细粒度函数. 如果把接口理解为OOP中的接口, 也可以理解为面向对象编程语言中的接口语法,那么接口的设计要尽量单一, 不要让接口的实现类和调用者, 依赖不需要的接口函数. 依赖反转原则(DIP) 高层模块不要依赖底层模块, 高层模块和底层模块应该通过抽象来互相依赖. 抽象不要依赖具体实现细节.具体实现细节依赖抽象. 在调用链上, 调用者属于高层, 被调用者属于底层. 控制反转 程序员利用框架进行开发的时候, 只需要往预留扩展点上,添加跟自己业务相关的代码,就可以利用框架来驱动整个程序流程的执行, 控制指的是对程序执行流程的控制,反转指的的是在没有使用框架之前, 程序自己控制整个程序的执行, 在使用框架之后,整个程序的执行流程可以通过框架来控制, 流程的控制权从程序员反转到了框架. 依赖注入 不通过new()的方式在类内部创建依赖对象,而是将依赖对象在外部创建好之后, 通过构造函数,函数参数等方式传递给类使用, 通过依赖注入的方式来将依赖的类对象传递进来, 这样就提高了代码的可扩展性,我们可以灵活的替换依赖的类. KISS 原则 Keep it Simple and Stupid 尽量保持简单. 如何满足KISS原则 不要使用同时可能不懂的技术来实现代码 不要重复造轮子,要善于使用已有的工具类. 不要过度优化. 不要过度使用一些奇技淫巧(位运算符代替算术运算, 复杂的条件语句代替 if-else,使用过于底层的函数)来优化代码,牺牲代码的可读性 越是能用简单的方法解决复杂的问题,越能体现一个人的能力. YAGNI 原则 You Ain’t Gonna Need It...