goMars的学习随记

SpringBoot自动装配概述使用 Spring 进行开发各种配置过于麻烦比如开启某些 Spring 特性时，需要用 XML 或 Java 进行显式配置。于是，Spring Boot 诞生了！Spring 旨在简化 J2EE 企业应用程序开发。Spring Boot 旨在简化 Spring 开发（减少配置文件，开箱即用！） Spring Boot只是简化了配置，如果你需要构建MVC架构的Web程序，你还是需要使用Spring MVC作为MVC框架，只是说SpringBoot帮你简化了Spring MVC的很多配置，真正做到开箱即用! 自动装配原理SpringBoot 定义了一套接口规范，这套规范规定：SpringBoot 在启动时会扫描外部引用 jar 包中的META-INF/spring.factories文件，将文件中配置的类型信息加载到 Spring 容器（此处涉及到 JVM 类加载机制与 Spring 的容器知识），并执行类中定义的各种操作。对于外部 jar 来说，只需要按照 SpringBoot 定义的标准，就能将自己的功能装置进 SpringBoot。通过注解或者一些简单 ...

线程池的监控概述线程池的监控是指对应用程序中使用的线程池进行实时跟踪、分析和管理的过程。线程池监控旨在确保线程池的有效运行，并及时发现并解决潜在的问题，以保障应用程序的性能和稳定性。 线程池监控最好支持三个地方： 动态调参：在运行时动态调整线程池参数，包括核心线程数、最大线程数、空闲线程超时时间、任务队列大小等 从前端接参，根据前端传的线程池名从map中获取线程池进行set方法动态修改（这个参数也可以持久化数据库） 通知报警：目前支持调参通知、活性、队列容量、拒绝策略、超时共六类通知报警维度，在运行时实时+定时检测，触发阈值进行推送 运行监控：定时采集线程池运行指标数据，提供 jsonlog、micrometer、endpoint、jmx 四种指标数据采集方式，可灵活选择 监控指标 核心参数： 线程池名称 基本配置：核心线程数、最大线程数 最大线程过期时间 任务队列类型、以及最大容量 拒绝策略 活跃度监控： 当前存在线程数、活跃线程数（通过get方法） 任务队列大小、任务队列剩余大小（通过get方法） 任务总数、完成任务数（通过get方法）、拒绝任务数（自定义拒绝策略 ...

LiteFlow规则引擎概述规则引擎是一种计算机系统，它允许将业务规则从应用程序代码中分离出来，以便更灵活、可维护、可扩展和可管理。这些规则可以是条件、动作和约束的组合，用于自动化决策和业务逻辑。规则引擎的主要目标是实现“业务逻辑与应用程序代码分离”的原则，从而使业务规则更易于修改和更新。 为什么需要规则引擎？ 灵活性：规则引擎允许业务规则在不修改应用程序代码的情况下进行动态更改。这提供了更大的灵活性，可以应对不断变化的业务需求。 可维护性：业务规则的维护和管理变得更加容易，因为它们可以独立于应用程序逻辑进行维护。 可扩展性：通过规则引擎，可以轻松添加新规则或调整现有规则，而无需大规模修改代码。 决策自动化：规则引擎可以用于自动执行决策，从而降低人为错误的风险并提高效率。 LiteFlow规则引擎 LiteFlow是一个非常强大的现代化的规则引擎框架，轻量，快速，稳定可编排的组件式规则引擎，融合了编排特性和规则引擎的所有特性。 优点： 组件化：让每一个业务片段都是一个组件，可以任意编排，组件与组件之间是解耦的，组件可以用脚本来定义，组件之间的流转全靠规则来驱动。 组件可实时热更替 ...

系统监控概述分布式系统的系统指标监控是确保系统正常运行、性能稳定和问题排查的关键方面之一。这种监控涵盖了一系列指标，用于衡量系统的各个方面，以及帮助管理员和运维团队识别问题、优化性能和规划资源。以下是分布式系统的一些常见系统指标监控的概述： 性能指标： 响应时间：衡量系统对请求的响应速度，通常以毫秒或秒为单位。 吞吐量：指系统在单位时间内能够处理的请求数量，通常以请求/秒来表示。 并发连接数：跟踪同时连接到系统的客户端数量。 资源利用率： CPU利用率：监控CPU的负载，以确保系统不超负荷。 内存利用率：跟踪系统内存使用情况，以防止内存泄漏或资源耗尽。 磁盘利用率：监控磁盘空间的使用情况，以确保不会出现存储问题。 网络带宽利用率：测量网络连接的带宽利用率，以确保网络性能。 错误和异常： 日志和异常信息：监控系统日志以及异常和错误报告，以识别问题和故障。 错误码计数：跟踪特定错误代码的出现次数，以便快速定位问题。 安全指标： 入侵检测：检测未经授权的访问或潜在威胁。 漏洞扫描：定期扫描系统以查找潜在的安全漏洞。 访问控制日志：记录系统访问以跟踪用户活动并排查潜在的安全问题。 ...

基本网络攻击与防御CRF攻击用户访问恶意网站，被恶意网站利用用户信息对用户的信息进行盗取，对用户发送邮件、短信或者转账支付等恶意行为。 1、用户A在访问信任网站B，并进行登录。 2、信任网站B返回给用户A的cookie。 3、用户A在没有退出网站A的情况下，访问恶意网站C。 4、恶意网站C通过用户的cookie访问信任网站A。 相关防御： 将cookie设置为HttpOnly：response.setHeader("Set-Cookie","cookiename=cookievalue;HttpOnly") 增加JWT防盗用机制 通过Referer识别：referer中存储的是请求源地址，如果用户在登录一个银行网站为www.xxxx.com，在恶意网站进行请求时请求源网站为恶意网站地址，后台代码可以对源地址进行判断就可以防止CRF攻击。 XSS漏洞xSS攻击通常指的是通过利用网页开发时留下的漏洞，通过巧妙的方法注入恶意指令代码到网页，使用户加载并执行攻击者恶意制造的网页程序。 防范方法： 字符转义：在后端进行处理，因为前端处理还是会被攻击。 ...

HTTP优化策略我们可以从下面这三种优化思路来优化 HTTP/1.1 协议： 尽量避免发送 HTTP 请求； 利用缓存技术（强制缓存、协商缓存） 在需要发送 HTTP 请求时，考虑如何减少请求次数； 减少重定向次数 合并请求，减少了重复发送的 HTTP 头部。 延迟发送请求 减少服务器的 HTTP 响应的数据大小； 无损压缩； 有损压缩；

HTTP接口安全策略 通信层面上HTTPS加密传输 在后端内部传输时，敏感数据加密传输 数据加签验签，例如JWT 基于Token机制传输登录用户非敏感数据 关键接口建立nonce防盗用机制 前端携带nonce，提交数据后，服务器端先根据nonstr字符串提取用户环境md5，然后使用相同规则对当前发来的用户特征进行校对，只有用户环境完全没有发生变化的前提下才运行执行该接口 限流机制、黑名单、白名单 数据脱敏放弃规律 数据后端校验

事务 spring的事务是由aop来实现的，首先要生成具体的代理对象，然后按照aop的整套流程来执行具体的操作逻辑，正常情况下要通过通知来完成核心功能，但是事务不是通过通知来实现的，而是通过一个TransactionInterceptor，然后调用invoke来实现具体的逻辑 1. 先做准备工作，解析各个方法上事务相关的属性，根据具体的属性来判断是否开始新事务 2. 当需要开启的时候，获取数据库连接，关闭自动提交功能，开起事务 3. 执行具体的sql逻辑操作 4. 在操作过程中，如果执行失败了，那么会通过completeTransactionAfterThrowing来完成事务的回滚操作，回滚的具体逻辑是通过doRollBack方法来实现的，实现的时候也是要先获取连接对象，通过连接对象来回滚 5. 如果执行过程中，没有任何意外情况的发生，那么通过commitTransactionAfterReturning来完成事务的提交操作，提交的具体逻辑是通过doCommit方法来实现的，实现的时候也是要获取连接，通过连接对象来提交 6. 当事务执行完毕之后需要清除相关 ...

epoll、poll 和 selectepollepoll 要做的事情，就是管理这些文件描述符。或者用一句话来描述：epoll 就是增删改查文件描述符。epoll 里面有两个关键结构。一个是红黑树，每一个节点都代表了一个文件描述符。另外一个是双向链表，也叫做就绪列表。 epoll 并不是在我发起 epoll 调用的时候才把文件描述符挪到就绪列表的。而是在 epoll 创建之后，不管你有没有发起 epoll_wait 调用，只要文件描述符满足条件了，就会被挪到就绪列表（需要时会复制到用户空间中）。 每一个和 IO 有关的文件描述符都有一个对应的驱动，这个驱动会告诉 epoll 发生了什么。比如说，当有数据发送到网卡的时候，会触发一个中断。借助这个中断，网卡的驱动会告诉 epoll，这里有数据了。而超时也是利用了中断，不过是时钟中断。时钟中断之后，内核会去检查发起 epoll_wait 的线程有没有超时，如果超时了就会唤醒这个线程。调用者就会得到超时响应。 poll 和 select发起 select 调用的时候会传给 select 一堆代表连接的文件描述符，内核会帮你检查这些文件描 ...

微服务治理的手段(二)服务容错常用的手段主要有以下几种。 FailOver：失败自动切换。就是服务消费者发现调用失败或者超时后，自动从可用的服务节点列表总选择下一个节点重新发起调用，也可以设置重试的次数。这种策略要求服务调用的操作必须是幂等的，也就是说无论调用多少次，只要是同一个调用，返回的结果都是相同的，一般适合服务调用是读请求的场景。 FailBack：失败通知。就是服务消费者调用失败或者超时后，不再重试，而是根据失败的详细信息，来决定后续的执行策略。比如对于非幂等的调用场景，如果调用失败后，不能简单地重试，而是应该查询服务端的状态，看调用到底是否实际生效，如果已经生效了就不能再重试了；如果没有生效可以再发起一次调用。 FailCache：失败缓存。就是服务消费者调用失败或者超时后，不立即发起重试，而是隔一段时间后再次尝试发起调用。比如后端服务可能一段时间内都有问题，如果立即发起重试，可能会加剧问题，反而不利于后端服务的恢复。如果隔一段时间待后端节点恢复后，再次发起调用效果会更好。 FailFast：快速失败。就是服务消费者调用一次失败后，不再重试。实际在业务执行时，一般非核心业 ...