Nebula

选题契机 随着智能设备产业的蓬勃发展，智能设备配件生产的质量追踪和溯源要求变得越来越严格。智能设备配件的生产涉及多个环节，从原材料采购、加工、组装到最终成品出库，每一个环节都关系到产品的质量与合规性。传统的生产管理方式依赖人工记录和手工操作，数据滞后、溯源信息不透明，难以应对复杂的质量控制和监管要求。 在对多家智能设备配件制造企业的调研中，发现企业在物料追踪、生产过程监控及质量管理方面的信息化水平较低，无法实时获取生产环节的精确数据，生产异常和质量问题难以及时预警和处理。因此，设计一套针对于智能设备配件生产的溯源管理系统显得尤为迫切。该系统能够实时采集生产数据，记录每个生产环节的物料流转和质量检测信息，从而帮助企业提高质量管控能力，实现产品的全过程追踪。 通过整合各个生产环节的数据，并利用数据分析技术，系统能够为企业管理层提供直观的可视化界面，帮助他们实时监控生产状态，进行科学决策。这不仅能提升生产效率、降低运营成本，还能确保产品符合严格的质量和监管标准。 核心功能 实时数据采集：通过传感器和设备接口实时采集生产数据，包括物料使用、设备状态、生产进度等。 生产流程监控：实时监控生产流程，提供生产状态的可视化展示，确保生产线的高效运转。 物料追踪：对原材料、半成品和成品进行全面追踪，记录物料的来源、使用和去向。 质量管理：集成质量检验和追踪功能，实时记录质量检测数据，确保产品符合标准。 历史数据查询：提供历史生产数据查询功能，方便管理者进行数据分析和决策。 异常报警：设定阈值监控，及时报警处理生产异常情况，如设备故障或质量问题。 数据分析与报告：提供数据分析工具，生成各类报告，支持决策和优化生产流程。 溯源追踪：实现对产品的完整溯源追踪，记录每个环节的操作和变更，便于质量追溯。 智能预测：基于历史数据和趋势分析，提供生产需求和设备维护的智能预测。 权限管理：提供多层次的用户权限管理，确保数据安全和操作的合规性。 可视化仪表盘：提供直观的可视化仪表盘，汇总关键指标，帮助管理者快速掌握生产状况。 用户反馈系统：集成用户反馈和建议收集功能，持续改进系统和生产流程。 技术选型 前端框架： Vue.js：用于构建用户界面，提供良好的用户体验和响应式设计。 后端框架： Spring Boot（Java）：用于快速构建RESTful API，处理业务逻辑和数据交互。 数据库： MariaDB：关系型数据库，支持复杂查询和事务处理。 数据采集与传输： RabbitMQ：用于消息传输，确保数据的实时性和可靠性。 可视化工具： Echarts：用于展示数据的可视化，生成实时仪表盘和报告。 API文档： Swagger：用于生成和维护API文档，方便前后端协作。 身份验证与权限管理： Sa-Token：用于用户身份验证和权限管理。 容器化与部署： Docker：用于容器化应用，简化部署和管理。

需求分析 软件需求分析 软件层面主要负责氧舱实时数据采集与可视化展示、用户支付与设备交互、用户与系统数据安全、设备信息与用户信息的统一管理、 设备远程控制与监控、并为后期持续迭代与优化提供资源与业务的冗余空间 客户端主要功能分析 小程序：主要负责用户业务，以展示数据与支付功能为主 可部署至微信小程序或支付宝小程序等轻量化平台，可以通过扫码一件开启并通过微信账号或其他平台绑定进行登录以及支付授权 配备设备信息可视化面板，如氧气浓度，氧舱湿度，氧舱温度，剩余使用时间等。数据清晰，便于用户理解 接入云端服务，可远程播报提醒，提醒用户当前使用时间与设备运行状态，同时可以在小程序中远程控制设备的空调温度、照明开关等 网页端：主要负责用户管理与系统维护，以设备调度与运维功能为主 在小程序登录与下单的用户信息存储于云端，便于数据统计与分析以及用户运营 设备远程控制，可以远程开启空调、开启灯光、远程播报等，可以根据天气条件、用户使用情况等环境因素进行设备调控 监控设备运行状态，如设备当前运行时间，是否使用，氧气浓度，压力值等 可视化统计分析设备数据，如使用高峰地区、使用高峰时间段、平均使用时间等，便于精细化市场决策 私有通信服务，可以通过网页端与小程序端的客户进行沟通，提高交易问题解决效率 服务端主要功能分析 负责业务数据存储与分析以及数据安全传输，协调用户端与管理端并架设物联网架构与硬件通信 保证数据安全传输，避免用户支付信息以及设备信息泄露 直接与硬件通信，协调软硬件交互，实现高性能、低延迟处理数据，减少云服务成本 高效率部署与高健壮性服务端设计，降低后期软件维护的人工成本 前期准备 注册认证企业微信开发平台，开通支付服务 申请域名 域名的小程序服务ICP备案 服务公安备案 购买云服务器产品，预计16C、32G、28M 技术选型 前端 小程序开发框架采用基于Uniapp的微信开发框架构建，可以无缝衔接原生应用、微信小程序与支付宝小程序等平台，界面美观，符合国人审美，可以高效对接后期多平台迁移需求 网页端基于Vue3构建，使用Vite构建工具，使用Element Plus组件库，设计风格采用Material Design，界面简洁，用户体验好 后端 后端采用Spring Boot构建，使用MyBatis作为数据库访问层，使用MySQL作为数据库，使用Redis作为缓存，使用RocketMQ作为消息队列，性能高效、稳定性强、高可用 使用Docker作为容器编排，使用Nginx作为反向代理，使用K8S作为容器编排，达到高可用性、高可靠性，提升用户体验 采用Outhor2.0协议，实现用户认证与授权，保护用户数据安全 采用Nats Streaming作为MQTT消息队列，与硬件连接稳定，减少设备通信成本 开发计划 团队配置为3人，前端开发一名，后端开发一名，硬件开发一名 前端开发周期预计30天，后端开发周期预计30天，测试周期15天，试运行联调周期15天，共计约100天

正好和我的网名一样，缘分妙不可言 项目地址 GitHub: https://github.com/slackhq/nebula 主要文件 nebula：主程序 nebula-cert：证书生成工具 基本使用 创建CA证书 1 2 3 4 #linux ./nebula-cert ca -name "网络证书名" #windows nebula-cert ca -name "网络证书名" 网络证书名随意填写，方便记忆即可 执行完成后生成ca.key（私钥）和ca.crt（公钥）两个文件 ca.key用于签名所有的Nebula节点，尽可能单独存放不要放在任何一个节点上 创建密钥与证书 格式： 1 ./nebula-cert sign -name "节点名称" -ip "节点IP/24" -subnets "子网" -groups "组名" -name，节点名称，可以任意填写，也可以用域名的方式填写 -ip，指定IP地址，需要手动指定，且不能与已分配的IP地址冲突 -subnets，指定当前节点的非Nebula路由，以便其它节点能访问当前节点的子网 -group，指定该节点所在的组，方便 Nebula 进行防火墙规则配置 示例 1 2 3 ./nebula-cert sign -name "lighthouse" -ip "192.168.100.1/24" ./nebula-cert sign -name "router" -ip "192.168.100.11/24" -subnets "172.16.1.0/24" -groups "router,servers" ./nebula-cert sign -name "laptop" -ip "192.168.100.100/24" -groups "laptop,ssh" 配置节点 官方配置文件：https://github.com/slackhq/nebula/blob/master/examples/config.yml 在Nebula中节点分为两类：LightHouse节点和和Nebula节点，LightHouse节点需要部署在有公网IP的服务器上 在Nebula网络中，节点之间通过Nebula IP进行通信，注意区分Nebula IP和IP的区别 配置LightHouse节点 配置重点 1 2 3 4 5 6 7 8 9 static_host_map: #静态路由设置为空 lighthouse: am_lighthouse: true #设置为LightHouse节点 listen: host: "[::]" #同时监听Ipv6和Ipv4 port: 4242 #监听端口 relay: #如果NAT穿透连接异常，可以设置转发节点通过中继节点进行流量转发 am_relay: true #是否为中继节点 use_relays: true 示例配置文件 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 pki: ca: /etc/nebula/ca.crt cert: /etc/nebula/host.crt key: /etc/nebula/host.key static_host_map: #空 lighthouse: am_lighthouse: true #设置为LightHouse节点 listen: host: "[::]" #同时监听Ipv6和Ipv4 port: 4242 punchy: punch: true cipher: aes relay: am_relay: true use_relays: true tun: disabled: false dev: nebula1 drop_local_broadcast: false drop_multicast: false tx_queue: 500 mtu: 1300 routes: unsafe_routes: logging: level: info format: text firewall: conntrack: tcp_timeout: 12m udp_timeout: 3m default_timeout: 10m max_connections: 100000 outbound: - port: any proto: any host: any inbound: - port: any proto: any host: any 配置Nebula节点 配置重点 1 2 3 4 5 6 7 8 9 10 11 12 13 14 static_host_map: "192.168.100.1": ["LightHouse域名或IP:端口"] #设置Nebula IP到真实域名或IP的映射 lighthouse: am_lighthouse: false #设置为Nebula节点 interval: 60 hosts: - "192.168.100.1" #LightHouse的Nebula IP listen: host: "[::]" #同时监听Ipv6和Ipv4 port: 0 #启用动态端口 tun: unsafe_routes: #(可选配置)可以路由某个子节点所在的路由，在所有需要访问该转发节点的访问节点中添加 - route: 172.16.1.0/24 #想要访问子节点的网段 via: 192.168.100.11 # 转发节点对应的路由 示例配置文件 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 pki: ca: "/etc/nebula/ca.crt" cert: "/etc/nebula/host.crt" key: "/etc/nebula/host.key" static_host_map: "192.168.100.1": ["124.222.162.210:4242"] lighthouse: am_lighthouse: false interval: 60 hosts: - "192.168.100.1" listen: host: "[::]" port: 0 punchy: punch: true relay: relays: - 192.168.100.1 #中继节点的Nebula IP am_relay: false use_relays: true tun: disabled: false dev: nebula1 drop_local_broadcast: false drop_multicast: false tx_queue: 500 mtu: 1300 routes: unsafe_routes: logging: level: info format: text firewall: outbound_action: drop inbound_action: drop conntrack: tcp_timeout: 12m udp_timeout: 3m default_timeout: 10m outbound: - port: any proto: any host: any inbound: - port: any proto: any host: any 防火墙规则 官方默认：对外访问网络没有任何限制，对内访问只能通过PING，属于laptop和home组的可以通过443/TCP访问当前节点 ...

选题契机 在企业中，软件系统开发主要包括项目管理，需求分析、设计、编码、测试、部署、运维、监控、优化、迭代、升级、维护几大阶段。 在项目管理阶段，开发人员需要完成需求分析与设计，以确定开发需求与功能。同时对模块进行划分与设计，并分配开发任务 在需求分析阶段结束后，开发人员需要按照软件设计详情进行开发，对于软件工程师来说，工作内容应该主要集中在核心业务开发过程中。 而在我日常开发与实习过程中，我发现有很多时间都浪费在了非核心业务中，以后端工程师为例，我们的主要精力应该在编码阶段。 但是我们实际开发过程中却将大量的时间浪费在了测试、部署、运维等阶段。在一些中小型公司中，专职运维工程师和测试工程师相对较少， 无法及时对接开发人员的工作，导致开发人员不得不身兼数职，在增加工作量的同时，降低了工作效率，还导致项目的开发周期变长，致使项目整体整体质量下降。 为了解决这个问题，我浏览了大量相关项目与框架，并尝试搭建一个符合自己需求与场景的DevOps平台。 但是在实际实施过程中，我认为现在的一体化DevOps开发平台问题主要分为两类， 一类是侧重点相对集中，另一类则是过于庞大。 第一类以Focalboard，Gitness为代表，这一类开发平台侧重于某一个开发节点，他们在所在节点效果良好，很好的完成了业务功能， 但是如果要完成一个完整的开发工作流程，就不得不部署多个服务，造成了服务难以统一管理与配置。 如Focalboard重点在于任务记录，而Gitness侧重于CI/CD。 第二类则是侧重点分散，各个开发流程均有覆盖，但是由于架构过于庞大，导致部署成本较高。 这一类以JetBrains TeamCity为例，我的服务器采用2Core 4G配置，在如此环境下仍然无法完整的容器化部署。 因此，本系统将尝试将这些开发平台进行整合，以实现一个符合自己需求的DevOps平台。 本系统主要是辅助开发工程师，遵循DevOps开发流程，尽可能将非编码任务交给自动化任务完成。 同时集成项目管理模块，尽可能在一个平台上完成软件开发周期。 而庞大的架构必然会带来额外的性能开销，在这个基础上，我选择采用云原生架构容器化部署项目，尽可能体现出不同语言之间的优势， 将性能敏感型交给Go服务执行，而将基本的项目管理交由Kotlin完成。 在提高工作效率的同时，减少了测试和运维工作成本，增加整体产出。 启发 本项目的开发与理念受益于多个开源项目以及DevOps与CloudNative开发哲学，其中影响最深的项目包括Gitness、Jetbrains TeamCity与JetBrains YouTrack。 DevOps与CloudNative开发哲学相比传统开发模式，除了容器化开发与部署之外，还将开发与运维结合起来，使项目上线阻力更小， 结合我在日常开发中对于这几款项目的使用以及DevOps的实践，加上开发需求的推动，才有了本项目。 在此，对Gitness项目组与Jetbrains公司以及其他一线开源工作者致以最崇高的敬意。 no Gitness and Jetbrains,no StellarCloud 核心功能 1. 轻量化开发与团队管理 本系统主要面向对象是小中型企业或者开发团队，这个群体有一个相对显著的特点： 相较于大型组织，他们更多的重点是在于业务的迅速上线以及短周期开发，主要是针对于某个业务场景而单独开发的一套系统。 因此本系统在一定程度上减少开发流程的冗余，尽可能减少开发人员负担。采用敏捷开发模式，结合自动化任务的优势，将一些相对耗时、重复性任务交给自动化任务完成。 在程序的健壮性和开发周期上做一定取舍，以提升整体开发效益。 2. 自动化测试 本系统通过集成TestContainers与容器化部署，实现自动化跨语言测试并给出测试报告。 3. 容器化CI/CD 本系统为常用服务部署提供了基础模板，用户可以直接使用模板进行CI/CD管理，同时允许用户自定义CI/CD流程，以实现更复杂的CI/CD需求。 4. 基于容器化架构的应用监控与管理 本系统通过集成Prometheus与Grafana，实现服务的可视化监控。 5. 远程执行 本系统同通过集成libp2p，除了支持本地工作流执行，还支持远程工作流执行。更加符合分布式架构的设计。 技术选型 以前过于追求性能，导致丢失了一些开发框架最基本的东西。有句话说的好，不要重复造轮子。除非底层架构有本质上的迭代，不然一点点的小修小补并不能带来本质上的收益。 生态好，用着顺手才是优秀的技术。出了问题，你能找到解决办法，用着舒服，开发效率高，这才是最重要的。 大部分框架所谓的性能提升都是针对于http请求进行优化，而在业务流程中，http请求时间固然重要，但不是全部。 真正的“高并发”应该是对于系统资源的合理调度，而不是简单的的“http请求数量”。 编程语言： Kotlin：语言层级的协程支持，针对异步任务场景可以比传统的多线程模型更加高效，加上函数式开发范式与现代化语法特性，使项目开发效率更高，代码可重用性更强。 且跟Java无缝集成，可以共享Java庞大的生态。在本项目中，主要负责Web层业务开发，如基础REST开发，包括项目管理、成员管理、任务分配等。 Golang：天然面向高并发，加之可以编译为本机可执行程序与低内存占用，使得Golang项目天生适用于云原生场景。 由于Golang协程不依靠虚拟机，更低的协程创建开销，对高并发任务有更好的性能表现。低内存占用与极高的启动速度也成为容器化程序的理想选择。 JavaScript：前端开发语言，拥有丰富的生态。 框架： 后端框架： Springboot：作为主要的常驻服务，主要负责业务基础设施开发，如基本的数据管理、缓存、事务等。 Fiber：作为上层应用服务开发，如容器化的代码测试与流水线、应用伴生监控、资源调度等。 前端框架： React：作为主要前端开发框架。 Material-UI：作为主要前端UI组件库。 中间件： Nats是一个基于Golang的消息系统，不同于传统的MQ与RPC，Nats同时支持发布/订阅模式与请求/相应模式，可以同时实现同步和异步消息传递。 Socket.IO：基于WebSocket的实时通讯框架，可以支持多端多平台的实时通讯。 Resty：基于Golang的HTTP客户端，可以支持各种HTTP请求，如GET、POST、PUT、DELETE，做自动化脚本处理。 组网： Nebula： 实现P2P网络，用于分布式架构下容器间的通信。 frp：实现内网穿透，用于实现内网与公网之间的连接，将服务暴露至公网，同时可以基于XTcp进行P2P通信。 核心库 go-git：Git操作库，用于实现Git仓库的克隆与操作。 go-task：Task自动化任务库，用于实现自动化任务，如CI/CD流水线、代码测试等。 docker-client：Docker客户端，用于实现Docker容器的创建与管理。 libp2p：实现P2P网络，用于实现容器间的通信。 数据库： PostgreSQL：作为主要数据库，支持关系型数据库与非关系型数据库。 Redis：作为缓存数据库，支持多种数据结构，如字符串、哈希、列表、集合、有序集合等。 Prometheus：用于实现服务的监控与可视化。 SQlite：作为执行单元数据库，存储单元临时数据 构建工具： Gradle：Gradle作为构建工具，支持更丰富的自动化构建脚本与插件，提供更好的拓展性。 项目结构 StellarCloud（后端协作面板业务部分） stellar-admin：后台管理与启动入口 stellar-common：基础公共模块 stellar-system：系统基础模块 stellar-bridge：与Golang服务的通信集成 StellarCloud-Core（后端容器化业务） StellarCloud-Agent（后端可执行单元业务） StellarCloud-UI（前端可视化部分） 项目原型 英文字母对应权限分配 ...

选题契机 随着计算机技术的发展，企业生产管理系统的需求不断增加，而传统的基于数据库的管理系统已经无法满足企业需求， 需要一种新的系统，能够实现企业数据的采集、存储、分析、可视化、预测等功能，以实现企业生产管理。 在我调研的单位中，公司的主要业务是手机、移动终端等智能设备配件的流水线生产。 在调研过程中我发现，企业信息化程度较低，对于物料管理、生产管理、运营管理等方面还是传统的人工管理， 因此针对于这个问题，我认为应该设计一套智慧车间智能化生产管理系统，深度融合erp生产管理思想，进一步提升管理维度， 如可视化管理、智能预测、历史生产统计等。降本增效，提升企业运营效率。 核心功能 职工生产管理 上游物料管理 生产流程管理 下游产品管理 产线监测 生产可视化统计 智能报表生成 技术选型 编程语言 Java Javascript 框架 SpringBoot VUE 数据库 mysql redis 构建工具 maven