Thesis

SkyWalking 和 Prometheus 不是竞争关系，而是互补关系，在 Java 微服务监控中通常搭配使用。
简单说：Prometheus 负责“系统整体健康吗”，SkyWalking 负责“这个请求为什么慢”。

核心定位差异
* Prometheus：指标监控与告警系统，专注采集时序数据（QPS、CPU、内存、错误率、延迟分位数），通过 PromQL 查询，配合 Grafana 可视化，是云原生监控的事实标准。
* SkyWalking：APM（应用性能管理）一站式可观测平台，核心是分布式链路追踪，通过 Java Agent 字节码增强无侵入地记录请求完整调用路径、每个环节耗时、服务拓扑关系，还能关联日志。

选型建议
* 中小团队、Java 技术栈、想快速见效：优先上 SkyWalking，一天内能看到服务拓扑和调用链路，内置告警够用。
* 有专职 SRE、需要深度定制指标和复杂告警：Prometheus 生态上限更高，配合 Grafana 做业务大盘。
* 大型系统追求全栈可观测：两者都用，SkyWalking 管链路+应用指标，Prometheus 管基础设施+业务指标，Grafana 统一展示。

秒杀系统的设计与实现多租户系统的设计与实现云原生系统的设计与实现

prometheus+grafana实现系统监控和可观测

Nacos作为服务注册与配置中心，Sentinel实现熔断限流，Seata处理分布式事务
针对服务间调用，同步调用采用Feign+Ribbon实现负载均衡，异步解耦采用Kafka消息队列，避免同步调用链过长导致的级联故障

TPS 是每秒处理的事务数，
QPS 是每秒处理的查询请求数
CPS（Connections Per Second）每秒新建连接数

经过上述设计，
【量化效果，如系统共拆分为32个微服务，各服务平均代码规模从原来的200万行降至6万行，新功能上线周期从2周缩短至2天，团队并行开发效率提升400%】。

为保障系统高可用，我们从接入层、服务层、数据层三个维度构建了多层次的高可用防护体系：
在接入层，【采用Nginx集群+LVS实现四层负载均衡，通过Keepalived实现VIP漂移，单节点故障自动切换时间小于3秒】；
在服务层，【基于Sentinel实现三级熔断降级策略：当接口错误率超过50%时触发熔断，进入10秒熔断窗口；熔断期间请求直接走降级逻辑，返回缓存数据或友好提示；采用半开状态探测机制，每隔5秒放行10%流量进行健康检测，连续成功20次后关闭熔断器】；
在数据层，【采用MySQL一主两从架构，通过MHA实现主库故障自动切换，RTO小于30秒，RPO=0；Redis采用哨兵模式，主节点故障后30秒内完成自动切换】。
【效果数据】
【系统可用性从99.5%提升至99.99%，年故障时长从43小时降至52分钟，在模拟下游服务全部宕机的极端场景下，核心链路仍可正常提供降级服务】。

【指标1，如响应时间从800ms降至120ms，降幅达85%】；【指标2，如系统可用性从99.5%提升至99.99%】；【指标3，如峰值吞吐量从2000 TPS提升至15000 TPS】。系统的成功上线不仅解决了技术层面的挑战，更为公司业务的持续高速增长提供了坚实的技术底座。


为什么主流的落地方式是Keepalived加VIP(虚拟IP)
Keepalived加虚拟IP，这也是我最终选择并落地验证的方案。
Keepalived通过VRRP协议在多台服务器之间共享一个虚拟IP，
正常情况下VIP绑定在其中一台主节点上，请求都走主节点；一旦主节点出现故障，备用节点会接管这个VIP，流量自动切换过去。
整个过程对客户端完全透明，客户端访问的还是同一个IP。


ELK（Elasticsearch + Logstash + Kibana）是一套开源的日志管理与数据分析解决方案，由 Elastic 公司开发，用于日志收集、存储、检索和可视化展示
核心组件
* Elasticsearch（ES）：分布式搜索和分析引擎，基于 Lucene 构建，负责数据存储、全文检索和聚合分析，支持 PB 级数据横向扩展。
* Logstash：数据处理管道，通过 Input → Filter → Output 三段式结构，从多源采集数据、清洗转换后输出到 ES。
* Kibana：可视化交互平台，提供 Web 界面，用于数据查询、图表制作、仪表盘和告警配置。

* 最简架构：Filebeat → ES → Kibana（适合小项目）
* 标准架构：Filebeat → Logstash → ES → Kibana（适合大多数企业）
* 高可用架构：Beats → Kafka → Logstash → ES → Kibana（适合大规模生产环境，削峰填谷
* 传感器 → MQTT → Logstash → Elasticsearch → Kibana
 
Beats（轻量级采集器）：
1.Filebeat：采集日志文件。
2.Metricbeat：采集系统指标。
3.Packetbeat：网络流量分析。

1. 日志集中管理与分析(filebeat)
应用场景：
 服务器日志聚合（Nginx/Apache 访问日志、错误日志）。
 容器化环境日志采集（Docker、Kubernetes）。
2. 实时业务监控与告警(metricbeat)
应用场景：
 电商平台实时订单监控（成功率、延迟）。
 微服务 API 健康状态追踪。 
3. 安全分析与威胁检测
应用场景：
 入侵检测（SSH 暴力破解日志分析）。
 合规审计（用户操作日志留存与查询）。
4. 物联网（IoT）数据流处理(Logstash 集成 MQTT 插件)
应用场景：
 传感器数据实时存储与异常检测。
 设备状态历史查询与报表生成。
 
性能具体的数值
测试和运维项目
架构风格和架构评估
软件开发全生命周期: 开发访求、开发模型。需求分析、设计、开发、测试、部署、维护
云原生、微服务、安全架构
系统可靠性、安全性、容错技术


论文字数2200~3000字，建议字数：
摘要300 + 项目背景500 + 主体1200 + 结尾500 

1.摘要(300字)
包含内容:项目名称、项目金额、项目历时、项目简介、我的责任;本文讨论主题概括。
(1)本文讨论......系统项目的.....(指的是项目主题，例如进度管理等)，该系统是由某单位建设的，投资多少万，系统是用来做什么的(项目背景，简单功能等)。在本文中，首先讨论了....
(过程、方法、措施)，最后.....(主要是不足之处/如何改进/特色之处/发展趋势等)。在本项目的开发过程中，我主要担任了.....(在本项目中的角色)。

(2)根据...需求(项目背景)，我所在的.....组织了.....项目的开发。该项目.....(项目背景、简单功能介绍)。在该项目中，我担任了.....(角色)。我通过采取.....(过程、方法、措施等)，使项目圆满成功，得到了用户的一致好评。但通过项目的建设，我发现..(主要是不足之处/如何改
进/特色之处/发展趋势等)

(3)....年...月,我参加了.....项目的开发,担任....(角色)。该项目投资多少，建设工期是多少，该项目是为了(项目背景、功能介绍)。本文结合作者的实践，以....项目为例，讨论......(论文主题)，包括.....(过程、方法、措施)

(4)......是.....(戴帽子，讲述论文主题的重要性，比如进度的重要性)。本文结合作者的实践，以......项目为例，讨论......(论文主题)，包括......(过程、方法、措施)。在本项目的开发过程中，
我担任了.....(角色)

2.项目背景(500~600字)
包括内容:项目开发的原因、你的岗位职责、项目开发周期及规模、项目功能组成介绍、项目技术(可省略)。
项目背景模板(为什么要做这个项目+项目功能和技术介绍+回应子题目并过渡到主体):

3.主体(1200~1500字)

4.结尾(500~600字)
结尾可以写400-600字左右，是对整体论文的总概。
包括内容:项目上线及运行效果、客户评价、项目收获、项目不足和解决思路。
经过近15个月的项日开发，该型号航天卫星的全数字仿真验证系统顺利投入使用，协助客户对卫星软件进行全面的功能和性能上的测试，运行至今客户反馈良好。该系统由于保密性高，性能要求高，技术实现难度高，项目建设周期长等原因，建设过程困难重重。但由于笔者及项目团队成员十分重视项目的......(回应具体论文题目)，最终保证了该项目按质按量顺利交付。

当然，在本项目中，还有一些不足之处，比如:......(自己去想一些小问题，切忌，别出现什么大问题)，不过，经过我后期的纠偏，并没有对项日产生什么影响。在后续的学习和工作中，我将不断的充电学习，和同行进行交流，提升自己的专业技术水平，更好的完成系统架构设计的工作。


艺术品鉴证备案及商务系统

深入解析负载均衡：四层（L4）与七层（L7）的核心区别与实践指南

Nginx 集群搭配 Keepalived 的核心思路是：
用 Keepalived 的 VRRP 协议实现 VIP 漂移，解决 Nginx 单点故障；
用 Nginx 的 upstream 做七层负载均衡，
并配合 keepalive 指令优化后端长连接复用。 
这两者解决的是不同层面的问题，通常组合使用

架构与原理
* 高可用（Keepalived）：两台 Nginx 节点（主/备）通过 VRRP 协议共享一个虚拟 IP（VIP）。正常情况下 VIP 绑定在主节点，当主节点宕机或 Nginx 进程异常时，VIP 自动漂移到备节点，实现秒级切换。
* 负载均衡（Nginx upstream）：Nginx 通过 upstream 模块将请求分发到后端应用服务器，支持 weight、ip_hash、least_conn 等策略。
* 长连接优化（Nginx keepalive）：这里的 keepalive 不是“探活”，而是指 Nginx 与后端之间维持空闲长连接池，减少反复 TCP 三次握手和 TLS 协商的开销。


搭建Nginx高可用集群的过程，本质上是一次思维方式的转变。以前你的运维思路可能是"出了故障人再上去处理"，现在变成了"让系统自己快速感知故障、自动切换，人只需要事后查看日志确认发生了什么"。

要达到这个效果，有几个习惯可以从开始搭建时就养成。第一，所有配置文件都纳入版本管理，主备节点的配置只用一套模板，通过参数区分角色，能有效减少配置不一致的问题。第二，notify脚本一定要写，把Master和Backup的状态切换事件记录下来，能让你在复盘故障的时候省很多力气。第三，定期做故障演练，我建议至少每个季度手动触发一次主备切换，确认整个链路没有因为系统升级、防火墙变更等因素悄悄失效。没有经过验证的高可用集群，跟没有高可用几乎没有区别。

还有一个小技巧——Keepalived的日志默认输出到/var/log/messages，日志信息比较分散。建议在启动脚本里加上--log-detail参数，或者单独配置日志输出文件，这样的好处是故障排查时不用在系统日志里翻半天。我在实际线上环境里给Keepalived配置了独立的日志文件，查询状态切换记录的时候效率提升非常明显。

最后再分享一个我个人的体会：高可用集群不是一次搭好就一劳永逸的东西，Nginx版本升级、Keepalived参数调整、业务拓扑变化都会影响集群的行为。每次变更之后，我都会主动触发一次主备切换，观察日志、观察VIP漂移时间、观察后端服务的连通性，确认没有引入新的问题。这套验证习惯帮我避开了很多潜在的大坑。如果你准备在生产环境上做这个方案，一定不要跳过验证这一步。