goMars的学习随记

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：快速失败。就是服务消费者调用一次失败后，不再重试。实际在业务执行时，一般非核心业 ...

微服务治理的手段节点管理1. 注册中心主动摘除机制这种机制要求服务提供者定时的主动向注册中心汇报心跳，注册中心根据服务提供者节点最近一次汇报心跳的时间与上一次汇报心跳时间做比较，如果超出一定时间，就认为服务提供者出现问题，继而把节点从服务列表中摘除，并把最近的可用服务节点列表推送给服务消费者。 2. 服务消费者摘除机制虽然注册中心主动摘除机制可以解决服务提供者节点异常的问题，但如果是因为注册中心与服务提供者之间的网络出现异常，最坏的情况是注册中心会把服务节点全部摘除，导致服务消费者没有可用的服务节点调用，但其实这时候服务提供者本身是正常的。所以，将存活探测机制用在服务消费者这一端更合理，如果服务消费者调用服务提供者节点失败，就将这个节点从内存中保存的可用服务提供者节点列表中移除。 服务节点摘除保护机制 需要根据实际业务的情况，设定一个阈值比例，即使遇到刚才说的这种情况，注册中心也不能摘除超过这个阈值比例的节点。 负载均衡1. 随机算法顾名思义就是从可用的服务节点中随机选取一个节点。一般情况下，随机算法是均匀的，也就是说后端服务节点无论配置好坏，最终得到的调用量都差不多。 2. 轮询 ...

监控微服务调用监控对象监控对象可以分为四个层次，由上到下可归纳为： 用户端监控。通常是指业务直接对用户提供的功能的监控。以微博首页 Feed 为例，它向用户提供了聚合关注的所有人的微博并按照时间顺序浏览的功能，对首页 Feed 功能的监控就属于用户端的监控。 接口监控。通常是指业务提供的功能所依赖的具体 RPC 接口的监控。继续以微博首页 Feed 为例，这个功能依赖于用户关注了哪些人的关系服务，每个人发过哪些微博的微博列表服务，以及每条微博具体内容是什么的内容服务，对这几个服务的调用情况的监控就属于接口监控。 资源监控。通常是指某个接口依赖的资源的监控。比如用户关注了哪些人的关系服务使用的是 Redis 来存储关注列表，对 Redis 的监控就属于资源监控。 基础监控。通常是指对服务器本身的健康状况的监控。主要包括 CPU 利用率、内存使用量、I/O 读写量、网卡带宽等。对服务器的基本监控也是必不可少的，因为服务器本身的健康状况也是影响服务本身的一个重要因素，比如服务器本身连接的网络交换机上联带宽被打满，会影响所有部署在这台服务器上的业务。 监控指标 请求量。请求量监控分为两个维 ...