结合 qws 和 qbt ，本地开发环境搭建

作者：陈彦贝

安装qws容器 以及 初始化化本地项目

qws 是腾讯云内部封装的一个NodeJS框架，它主要解决NodeJS及公共库的版本管理、进程线程管理、公共Api抽离、日志搜集等功能，简洁来说，qws主要完成三部分功能：

• pm2类似的进程管理
• 在框架层集成通用服务（通用数据接口、日志搜集等中间件服务）
• 依赖版本管理（NodeJS及公共库）

这些功能如果分开开发以及分开应用的话，个人觉得效果会更好一些。

如何安装qws

qws提供了Linux 安装方法 和Windows 安装方法，嗯，完美的避开了Mac环境的安装。

可以通过以下的方式手动安装：

1. 下载代码：git clone http://git.code.oa.com/kimhou/qws.git
2. 运行npm run init，它完成了两个工作：
   • 构建代码（src/server和src/qws-api）
   • 建立qws-api本地链接
3. 运行npm run publish
4. 修改./bin/qws-cli.js文件，并且建立全局软链
   • 把./bin/qws-cli.js第一行代码改成#!/usr/bin/env node
   • 建立全局软链：ln -s /Users/ablechen/tx-work/qws/build/qws/bin/qws-cli.js /usr/local/bin/qws，需要替换成你本地的qws-cli的地址。

自此，qws命令就可以在你的本地正常运行了。

如何初始化本地项目的依赖

以 dcdb_proj项为例，我们来讲讲如何安装它的本地依赖。

1. 下载代码：git svn clone http://svn-cd1.tencent.com/qcloudcd/dcdb_proj
2. 安装npm依赖：npm install
3. 安装本地npm包依赖，分别是node相关的qws-api和前端相关的组件库qcloud-components-react。
   • 下载qws，然后找到qws-api运行npm link，然后在dcdb_proj中运行npm link qws-api
   • 下载QcloudWebComponents_proj，然后在项目中运行npm link，然后在dcdb_proj中运行npm link qcloud-components-react

使用qws启动本地NodeServer

前面准备好了qws和Node项目，接下来，我们看看如何将qws和Node项目连接起来。

如何利用qws运行本地NodeServer

理论上来说，本地项目应该跑一个 npm run dev 之类的命令即可运行。 但是前面提过，qws本质上是一个NodeJS框架，它将一些通用服务统一管理之后，我们的本地开发就再也离不开它了。

qws提供了npm run debug [env]，可以读取本地的配置文件启动NodeServer。

那么如何提供本地的配置文件呢？

新建./src/server/config/qws.apps.local.js文件，指向对应项的配置文件。

export default {
    dcdb: {
        online: true,
        // 同样，指向你本地项目的配置文件即可
        config: '/Users/ablechen/tx-work/dcdb_proj/branches/isolation/server/lib/qws.config.js'
    }
}

到此，你已经在某个端口启动了你的项目，你访问 http://127.0.0.1:3501 能够在qws控制台看到对应的日志。 是的，qws启动并监听了本地NodeServer。而这，也才是第一步而已。

使用代理进行本地开发

前面启动的NodeServer，你通过 http://127.0.0.1:3501 访问就会遇到第一个问题：登录状态保持。

使用nginx转发，解决cookie同步问题

腾讯云有统一的单点登录页面，我们访问本地项目的时候，会自动跳转到登录页面，那么如何同步cookie，保持登录状态呢？ 最简单的就是使用nginx转发请求，我们安装nginx并且修改 /usr/local/etc/nginx/nginx.conf 如下：

图： nginx配置

这时，你可以通过对应的url访问咱们本地的项目，也就是说，我们已经把NodeServer相关的东西给串起来了。

紧接着，咱们再来把前端资源给串起来，整个项目就算能够正常运行了。

使用nproxy/anyproxy转发，解决JS/CSS等资源的代理问题

前面虽然把NodeServer相关的东西成功运行起来，但是你如果通过Chrome DevTools查看里面的JS/CSS等静态资源，你会发现，他们都是线上的文件而并非本地的代码，也就是说，你改了本地的JS/CSS文件并不会生效到页面上。 因此，我们需要将这些资源文件也代理到本地，这儿我们通过nproxy来解决这个问题。

const path = require('path');
const buildPath = path.join(__dirname, 'statics/bundle/')
const destPath = path.join(__dirname, 'statics/dest/dcdb')

module.exports = [{
    pattern: /(entra\.qcloud\.dcdb\.\w+\.\d+)/i,
    responder: path.join(destPath, '$1.js')
  },
  {
    pattern: /(\/qcloud\.dcdb\.\w+)\.\d+/i,
    responder: path.join(buildPath, '$1.js')
  },
  {
    pattern: /(app\.dcdb\.\w+\.index\.\d+)/i,
    responder: path.join(buildPath, '$1.js')
  },
  {
    pattern: /(app\/dcdb\/index)/i,
    responder: path.join(buildPath, 'app.dcdb.index.js')
  },
  {
    pattern: /http:\/\/(imgcache.qq.com.*)/,
    responder: 'https://$1'
  }
];

然后通过运行 nproxy -l ./nproxy.surejin.js 启动代理服务器。 有了nproxy代理之后，我们还需要配置浏览器，将浏览器的请求打到我们的代理服务器上

图：浏览器配置

而其中的dcdb开发模式，指向的就是nproxy代理服务器。 到此为止，我们就将JS/CSS等静态资源映射到了本地，本地开发环境的大致样貌出来了。

使用qbt构建代码

构建工具的引入是为了让本地开发更加高效：更高效的组织代码、运用更优秀的特性、完成自动化任务。

如何安装qbt

1. 安装qbt：sudo tnpm install -g @tencent/qbt
2. 运行构建命令：npm run build，它会监听client下的目录，然后构建输出。

图：构建输出

qbt是一款构建工具，它能够静态分析代码从而解析模块间的依赖并且输出一份入口文件，而入口文件中就包含相应的依赖关系。

有几个实际中遇到的问题分享一下：

首先，如果你发现的Chrome Console中有报错提示找不到某些模块，很有可能是需要运行qbt vms async去同步新的入口文件。

其次，如果你的代码有服务端渲染，需要在qbt中配置webpackForNode，并且运行qbt bn去进行服务端渲染的编译。

最后，如果你发现配置文件报错，请第一时间联系相关开发人员寻求帮助，因为无论是qbt还是qws，目前都有一些改动，可能配置项已然发生了变化。

总结说点啥

本文较为浅显的梳理了运行一个项目所需的所有步骤

1. 安装qws、qbt、react组件库
2. clone对应项目，并且建立它和qws/qws-api、react组件库之间的关系
3. 项目提供配置给qws，然后运行qws debug模式，启动并监听NodeServer实例
4. 配置nginx代理解决NodeServer的cookie同步问题
5. 运行qbt build，监听client代码并构建输出
6. 配置nproxy代理，将JS/CSS等资源映射到本地环境
7. 如有需要，运行qbt vms async更新入口文件的依赖，配置webpackForNode支持服务端渲染。

整体来说，要为一个项目搭建本地开发环境还是略微有点困难，这当然有多方面的原因，其中也有一些历史的包袱。 这儿抛出一些思路和想法，或许考虑不太全面，大家可以随意讨论。

将qws拆分？

qws本质上是为了统一管理Node实例，并且管理业务相关的一些通用服务，比如登录服务、日志统计等。

但是从一个系统的设计来说，尽量和业务解耦或许更便于维护和使用。

那么我们是否可以将qws至少拆分成两部分：

• 进程管理 这一部分类似pm2的功能 本地运行的时候，读取本地项目的qws配置文件，应避免配置到qws项目中
• 通用服务基础库 可以将部分业务相关的api封装到一个基础库中，被其他项目引用 可以将部分中间件服务抽离出来封装到基础库中，比如日志统计、性能统计等，被其他项目引用

最终设计成一个qws-pm2 + qws-node，分别负责进程管理和底层通用服务的封装，本地开发过程中，只需要引入qws-node即可。

本地NodeServer尽量脱离qws？

本地NodeServer应该尽量脱离qws，从而减轻本地开发环境的搭建成本。最终设计成运行npm install && npm run dev就可以让项目成功的跑起来。

这个需求很依赖前面的qws拆分，只要将qws-node拆分出来，作为依赖引入到本地NodeServer中，那么我们的NodeServer就可以独立运行而不依赖qws。

JS/CSS资源能否脱离代理配置？

现在的JS/CSS资源代理更多算是一种hack手段，各种切换代理还是会影响开发的效率。之所以需要资源代理主要有三方面的原因：

1. 当初设计的方案是SeaJS按需加载加强版，通过VMS来实现combo按需加载。
2. 模块都在线上进行管理，可以做到一次上线，全量紧急修复。
3. JS/CSS等资源来源比较复杂，可能是线上地址/测试地址/IP地址等

线上打包还是本地打包，这是一个相对的问题，本地打包可以解决频繁代理切换的问题，并且能够对本地代码有更好的掌控性。

• 本地打包也可以解决按需加载的问题。
• 对于通用业务，也可以做到全量修复，对于业务代码，不全量也更安全。
• 那对于不同来源的JS/CSS，可以继续利用combo的方式加载。可通过配置不同开发环境下的layout便于开发。

规范并精简项目结构及代码？

目前目录结构略显冗余，主要存在几个问题：

1. 基本上是按页面拆分逻辑，会导致代码复用性不是特别方便
2. Redux部分目录结构略显冗余，且模板代码较多，可考虑适当精简，采用类似dva的封装
3. 目录结构的就近原则可以进一步加强，通用无业务组件抽离到公共components中去，通用业务相关的组件可以考虑抽离成另一个级别的组件库，用subtree管理。

由于对项目的历史原因并不深入了解，加之对代码的熟悉也不够深入，所以以上只是一些粗略的想法，也并没有具体深入到实现方案上，肯定有不少疏漏之处，欢迎大家拍砖！也欢迎大家讨论！

初衷就是希望本地开发能够更方便一些，代码和目录结构能够更加规范更加轻量一些。