【技术分享】Go 工程化-前端性能监控接入层 Layout 设计实践

作者：黎志航&张翔，腾讯监控高级工程师

前言

本文主要介绍 腾讯云前端性能监控（RUM）在全新接入层上的 Go 工程化实践，介绍 Go 项目布局（下文称 Project Layout）的设计理念、设计规范、项目上的思考与实践，以及如何在多人协作开发下高效完成项目。

腾讯云前端性能监控介绍

前端性能监控（Real User Monitoring，RUM）是一站式前端监控解决方案，专注于 Web、小程序等场景监控。前端性能监控聚焦用户页面性能（页面测速，接口测速，CDN 测速等）和质量（JS 错误，Ajax 错误等），并且联动腾讯云应用性能观测实现前后端一体化监控。用户只需要安装 SDK 到自己的项目中，通过简单配置化，即可实现对用户页面质量的全方位守护，真正做到低成本使用和无侵入监控。点击文末「阅读原文」了解腾讯云前端性能监控。

目前前端性能监控平台每天处理超过上百亿的页面数据上报，日均 QPS 也超过百万。

如何理解项目的 Project Layout？

谈起这个，我想起一个特别有意思的聊天。

问：“我想做一个 go 的项目，用什么框架好？”

答：“你可能难以置信，原生最好！”

这个看法，对于一个项目的项目布局同样适用。如果你现在正在创建一个学习的项目，或者是一个很小的项目，没有必要纠结于如何创建 layout？怎么分层？因为绝大部分情况下，这个项目就是一个 main.go 可以搞定！“一把梭哈“把 datasource、业务逻辑、配置、路由全写到一个地方。

但是随着这样“一把梭哈”的方式生产出的项目不断扩大，不断有新成员加入你的项目，这个时候少了设计理念、规范、约束的项目就会变成杂乱、难以继续扩展，甚至不可维。

这时候就要做更多架构相关的事情了，而一个好的 Project Layout 来管理包/库/项目是非常重要的。而 Go 又恰好是一个面向包名设计的语言，可以通过各个包名进行组织 Go 的项目布局。

倘若研发团队的成员都遵循一个的 Layout 规范，可以很好地降低团队成员之间的合作成本，可以很好做好代码的防腐，减少代码的“坏味道”。

Standard Go Project Layout：

https://github.com/golang-standards/project-layout

该 git 库里面提到了很多 Golang 的规范，例如 /cmd , /internal ，/pkg， 其中 /cmd 会放置项目启动、停止的逻辑， /internal 放置项目内部使用的文件，/pkg 放置可复用的文件、库，例如 commons、utils、logger的封装等，更多更详细的说明，可以查阅 Standard Go Project Layout：https://github.com/golang-standards/project-layout。

既然 Go 社区已经规定了一些 Project Layout 的标准模版，为什么我们还需要一个自己的 Layout 规范呢？但是发生在 standard 和 reald world 的问题往往让人觉得很意外，下列我们将会一一揭晓。

RUM Project Layout 的思考

相信大家在写后台的时候第一种接触的目录结构，也就是三层架构或者 MVC 架构。

传统 Project Layout——三层架构

相信大家已经耳熟能详了，我再简单复习一下：

• Controller 负载处理用户的请求，面向用户暴露的接口逻辑写在这里

• Service 负责编写业务层的逻辑

• DAO 负责处理数据层的逻辑，针对数据的增添、删除、修改、查找等

• （View 层一般是端侧的面向用户的界面，与后台无关，不展开说明）

某头部互联网公司规约也对三层架构有过比较清晰的定义：

这里小编专门用中文标注了一个层级—manager 层，manager 层是常规规定 Controller、Service、DAO 之外的一个规范。

Manager 层的作用：1. 对第三方平台封装的层，预处理返回结果及转 化异常信息；2. 对 Service 层通用能力的下沉，如缓存方案、中间件通用处理；3. 与 DAO 层交互，对多个 DAO 的组合复用。

《Java 开发手册》

Manager 层也简单可以理解为是对于上层 service 的一些通用逻辑的封装，从而达到共享这部分逻辑的功能。以上看来三层架构是无懈可击的，普遍适用了绝大部分的场景，而且最重要的是容易理解，初学者都能很好上手。

但是从 PHP 一直到 Golang，写三层架构的时候都给我带来了一些困惑，我先来简化一下这个请求的逻辑：

1. 实践中存在的问题：职责不清

传统的 Controller 层即接口处理层与 Service 业务逻辑层&#