这篇文章对我过去 3 年的一大块工作内容进行复盘。我作为项目组的架构师，在下文中也对项目早期遗留的一些问题进行反思，并分享我个人的解决思路。

项目核心依赖开源组件，定制化过度

我们的项目是一个运行在边缘设备上的日志、软硬件性能指标的采集/监控系统。考虑到边缘计算设备（IPC）的性能，选择开源组件时就侧重于轻量化、支持丰富的输出标准。早期部门架构师采用了 Fluent-Bit 作为项目的核心组件。Fluent-Bit 是 C 编写的开源、轻量、可轻度扩展的数据收集器。它最开始用作日志收集，后来逐渐发展成全功能的 Agent。对比流行的OpenTelemetry ，Fluent-Bit 更开箱即用、更轻量，但是不易于修改和扩展。

最开始整个团队都没接触过监控系统，所以在设计系统时挖了不少坑。首先，用户在 UI 上操作过度繁琐，需要依次配置输出的目标（地址、端口、协议、格式、加密方式等等）、采集的指标类型，最后还要手动点击 Apply （应用）一下。

经过几轮迭代，适当简化了操作逻辑。但是像大部分工业 PC 上运行的程序一样，用户在初始化配置过后，通常不会主动去 UI 上修改配置。终端用户更关心占用系统资源多少、稳定性如何。所以最开始团队把这个项目做成了一个重交互的 C 端产品，这是个教训。

第二，后端开发为了满足 UI 设计的流程（比如，用户可以创建多份不同的配置项到不同的目标地址），做了复杂的 Work-around。因为 Fluent-Bit 是单进程事件驱动模型，只有单一配置文件，每次修改配置文件都要重启 Fluent-bit 进程。这就造成了 UI 上用户添加一个配置项，后台就要重新生成整个配置文件并重启 Fluent-Bit。这对于一个稳定运行的监控系统来说，无疑增加了重启过程中数据丢失的风险。另外，如果新增的配置项出错，就会让整个生成的配置文件报错，导致 Fluent-Bit 进程假死等问题。

为了解决这些问题，后端工程师又对 Fluent-Bit 的各项参数玩出各种花活儿。比如利用不同 tag 来分流不同用户配置项，为每个配置项单独配置参数和过滤规则。再比如设定缓存数据包大小和缓存 timeout 时间为 0，这样 Fluent-Bit 重启之后会首先尝试重发缓存在文件系统里的数据，这样间接防止用户数据丢失。

这些花活儿不但提高了维护难度，从用户角度看，也并没有带来任何真正的价值提升。

回顾来看，如果早期的 UI 设计改成单独的配置页面，不但简化的操作流程，还给业务代码降低的复杂度。

第三，核心项目依赖 Fluent-Bit 造成项目迁移到其他开源组件非常困难。加上 Fluent-Bit 更新频率高，公司对安全性合规要求使得我们团队每隔一段时间要对 Fluent-Bit 进行升级，同时对所有配置选项做回归测试。加上 Fluent-Bit 订制性很差，它虽然支持使用 Go 语言实现 Output 插件，但是只能用 C 语言编写 Input 插件。导致我们采集内部应用的数据，不得不用到它的 TCP 和 HTTP 插件来中转。部署多个 Agent 采集不同的内部服务。这让后期集成测试更添难度。

总体来说，Fluent-bit 的性能基本达到了预期，但是各种小 bug（比如 pgsql 插件在目标不可达时直接 Block 整个进程），开源社区维护者并没有引起重视，我们提交给开源社区的代码也被以各种理由驳回。如果让我重新选择，我更倾向于使用其他扩展性更强的开源组件。

对 Go 语言不熟悉，项目结构混乱

团队遇到的第二个挑战是对 Go 语言不熟悉。大部分开发成员只有 Java 开发经验，所以顺理成章把 Go 写成了 Java。因为框架（Go-Gin）的限制，导致开发中问题频出。

第一个问题来自面向对象和依赖反转。依赖反转对于使用 Java Spring 的人来说不会陌生，但是用 Go 实现依赖反转，需要利用 Interface 封装，并结合 Go-Mock 库做单元测试。团队成员早期不熟悉语言特性，经常错误封装抽象，或者干脆直接函数套函数，写成面条型代码 。这充分暴露了大部分国内 Java 程序员其实没有受过良好的 OOP 训练。对于单元测试、集成测试这些工程实践也是流于形式。软件质量在大部分企业里仍然靠测试人员手动验证。

第二个问题是 Go 语言不鼓励过度抽象。如泛型、异常处理，都要一步步重复琐碎的代码片段，这让 Sonar 静态检查经常 failed。没经验的同事就会用各种奇技淫巧逃避静态检查。这也说明开发团队定期 code review 的必要性。

第四，Go 语言其实是一个社区不那么完善的编程语言，它的很多框架（如最热门的 gorm 居然是个人开发项目），像 Flyway 这种 Java 工具链中很成熟的迁移工具，在 Go 里竟然需要组合多个开源项目来替代。所以 Go 只适合来开发中等以下规模的项目，或者对性能要求较高的平台核心组件。（在国内）不适合做复杂的业务场景。

API 接口粒度过细，没有对资源对象做好抽象

团队早期由于管理混乱：架构上，没有对业务模型做好抽象，资源对象拆分太碎；管理上，任务拆解太简单粗暴，给每个同事单独负责一个模块，导致每个业务流程都设计了专门的 API，维护压力大。好在业务场景少，用自动化测试能一定程度上保证了接口可靠性。

最开始做自动化集成测试时，我们仍然使用 BDD 的形式，以业务操作为基础编写，后来逐渐发现这种监控系统，其实真正的用户操作逻辑非常简单，复杂的部分是不同类型的数据、不同的 Input、Output 配置可能引起的异常。所以我们改成了数据驱动测试，用配置文件对不同类型的 Fluent-Bit 配置做全面的测试。

总结起来，Fluent-Bit 配置的修改，其实完全可以用 3~4 个宽泛的 API 来实现，除了前文提到流程过度设计原因，项目初期的不确定性，导致开发人员过度关注松耦合，而忽略了维护性。

错误的流水线设计

最开始项目沿用的部门其他团队的集成测试、部署模式，把 Python 写的测试用例和项目部署脚本放在单独的 Gitlab Repo 里。结果是每次项目部署时，要人工去网页上修改版本号触发流水线。从持续集成的角度看，业务代码和测试用例分开，造成了每次 commit 都要到不同 repo 里去提交，且一旦冲突又要分别执行多次集成测试（时间长，反馈慢）。

后期我们做了一些调整，把多个小模块合并成一个Monorepo ，同时把部分 API 相关的集成测试放在后端代码里，减少提交次数，也让原子提交更容易。

不过部署问题依然没有被解决，原因是边缘平台上的模块太多，系统集成需要多个团队合作，部署、发布版本时间长，出错的环节太多。对于这种情况，部门技术负责人设定了严格的代码提交、测试、review、文档更新流程，但是根本问题还在于团队责任模糊、部门团队跨多个国家和时区，缺少统一的调度和沟通机制。这些问题只能留给管理层逐渐缓解，或者随着业务收敛，减少、分流项目组。

小结

整体来看，我们团队遇到的很多问题出自项目早期，缺少项目和技术团队管理经验。对业务的愿景不了解，把做 C 端 Saas 产品的经验带到工业领域，用熟悉的开发范式套用到制造业。当然，不回避地说，在业务上，部门多流程长，业务负责人只能盲人摸象，用户反馈要先到达 Support 团队，再反馈给上层，最后才到开发团队。这让我们开发出来的产品要经过至少 3-6 个月才能得到有效的反馈。迭代周期太长，研发闭门造车。