libuv 在 v1.36.0 之后移除了 gyp_uv.py (commit)，没办法通过它去创建一个 libuv.a 静态链接库（v1.35 文档有详细的介绍），现在我们需要通过cmake去创建。

构建静态链接库

1
2
3
4
5
6
7

// 下载 libuv
git clone https://github.com/libuv/libuv
cd libuv
mkdir -p build
// DCMAKE_BUILD_TYPE 将其设置为 Debug 模式，不然断点没办法进入 libuv 源码中
 (cd build && cmake -DCMAKE_BUILD_TYPE=Debug ..)
cmake --build build

之后 build 目录 如下，libuv_a.a 就是我们需要的 静态链接库。

新建 hello world 项目

通过 CLion 创建一个helloworld项目，在 CMakeLists.txt 里添加 libuv 相关的信息，将 libuv 的头文件和源码添加进来，最后把项目和 linuv 链接在一起

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

cmake_minimum_required(VERSION 3.17)
project(helloworld)
add_executable(helloworld main.cpp)

# 前面 clone libuv 绝对路径
set(LIBUVDIR /your/libuv/path)
# 将源码导入
include_directories(${LIBUVDIR}/src)
include_directories(${LIBUVDIR}/include)

add_library(libuv STATIC IMPORTED)
set_target_properties(libuv
        PROPERTIES IMPORTED_LOCATION
        ${LIBUVDIR}/build/libuv_a.a)

# 链接起来
target_link_libraries(helloworld libuv)

创建 main.cpp 文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

#include <stdio.h>
#include <uv.h>

static void cb(uv_write_t *req, int status) {
  printf("Hello from Callback.\n");
}

int main() {
  uv_tty_t tty;
  uv_write_t req;
  uv_tty_init(uv_default_loop(), &tty, 1, 0);
  char str[] = "Hello UV!\n";
  int len = strlen(str);
  uv_buf_t bufs[] = {uv_buf_init(str, len)};
  uv_write(&req, (uv_stream_t *) &tty, bufs, 1, cb);
  uv_run(uv_default_loop(), UV_RUN_DEFAULT);
  return 0;
}

之后就能愉快的打断点调试 libuv 了

学习 libuv 或者其它 C/C++相关的技术，感觉又回到了刚开始学习编程的时候，很多的不懂和挑战，不再像用 JavaScript 那样随心所欲，但是越是对底层的学习，越是能了解计算机原理，职业寿命才能变得更长。出于兴趣也好，出于无奈也好，总之新的学习让一切又变得有意思起来。

Cluster

这是一个比较熟悉的模块，早在 Node.js V0.8 版本的时候就已经被加入进来，平时在生产部署 Web 应用的时候，为了充分压榨多核 CPU，总是根据核数开启对应的数量的应用进程，来处理用户请求，这些在 PM2 工具 或者 Egg.js 框架里有相应的介绍，之前自己写的 简单梳理 Node.js 创建子进程的方法（下）—— cluster 有其原理介绍。

虽然 Cluster 已经很成熟，但是也有一些问题：

• 进程开销较大
• 很多第三方工具对 Cluster 不是很友好，还是以单进程为主，比如一些监控系统
• 需要有一个管理进程，在某个 Cluster 进程出错退出后将其重启起来；单进程出错奔溃，运维可以通过健康检查未能通过的方式重启整个 Docker 等，相比而言 Cluster 模式复杂的多
• 目前从框架上自然支持 Cluster 的只有 Egg.js，其它都需要辅助工具，比如 PM2，然而它并完全免费，所以真使用该项技术，又面临框架选择的问题

Worker Threads

在 Node.js V10.5.0 加入，但需要通过--experimental-worker开启，直到 V12 才默认支持。在密集计算任务处理上带来了新的解决方案。

我带领的团队有一个重要的业务需求，就是服务端渲染（SSR)，我们使用 Egg.js 的 Cluster 模式来帮助我们提升吞吐量。虽然业务问题解决了，但是 Egg.js 比起 Express 或者 Koa 这样的框架来说复杂很多，让一个前端同事学习或者招募有经验的新同事还是有点棘手。另外就是和其它非其生态圈的工具搭配使用也遇到不少麻烦。

好在 Worker Threads 同样可以压榨 CPU，提升整体吞吐量。

Read More

又想起了那本《黑客与画家》

最近总是想起这个书名，多年前在图灵社区购买的电子本，对于当时的自己来说感觉有些不适用，以至于内容忘记的差不多了，仅仅是书名让人感觉非常酷。写该文的时候又去翻阅了下，感觉有些东西还是很有趣的，有时间应该重读下。

过往的自己，手上大多是工具书，应用相关的，希望通过书中的介绍知道一个个技术的细节，感觉每看一页都是收获满满，对于《黑客与画家》这样非直观的技术呈现显得不感兴趣。

现在的自己，愿意通过源码去寻找技术细节（也是拜这些年 github 等社区带来的便利），更多是希望知道那些技术大师如何思考、如何设计程序、如何架构系统，需要更多其它的信息来构建自己的认知体系。为什么这样做比这是怎么做显得更加重要，为什么是因，怎么是果。

最近在给团队里年轻同事做培训或 Code Review 的时候也是感触良多，总是想起过去的自己，脑子中又闪现出了，码农与程序猿。

Read More

背景

随着公司业务的不断扩展 ，系统也变得越来越臃肿，需要被不断的拆分，引进诸如微前端这样的框架，开发人员也不断的扩充，甚至有不同办公地点的同事协作开发。除了基本的开发规范外，也需要有一套完善的监控来测试和记录每次代码提交是否比之前版本存在性能不足等问题，在 CI 阶段发现问题，提早解决避免上线后带来性能损失而流失用户。团队成员也能在工作中不断的成长、驱动、交付出优质的应用。

前端经常要关注的几个指标：

First Contentful Paint：浏览器首次绘制文本、图片（包含背景图）、非白色的 canvas 或 SVG 的时间节点。反映了网络的可用性和页面资源是否庞大导致传输时间过长。

First Meaningful Paint：页面的“主要内容”开始出现在屏幕上的时间点，测量用户加载体验的主要指标。反映了是否太多非重要资源加载或执行的优先级高于主要的呈现资源。

First CPU Idle：页面主线程首次可以触发 input 操作，通常叫做最小可交互时间。

Time to Interactive：页面完全达到可交互状态的时间点。

Lighthouse 介绍

是一个开源的自动化工具，用于改进网络应用的质量。 您可以将其作为一个 Chrome 扩展程序运行，或从命令行运行。 您为 Lighthouse 提供一个您要审查的网址，它将针对此页面运行一连串的测试，然后生成一个有关页面性能的报告。

Read More

背景

通常，系统环境分为生产、测试和开发等多套，测试又可能因为验证不同的业务版本、BUG 部署 N 套， 意味着每套环境都会有一整套系统，从入口网关到大量的微服务节点，还有数据库等等。人力上需要有人去维护它们，无论是用于测试数还是系统的运维工作，每多一套系统都需要额外部署和购买大量资源，其中很多服务节点的版本是相同的，这都大大增加了成本。

为了解决这样的问题，我们可以通过网关路由的方式，比如测试环境，所有的应用都部署在一套环境中，通过 HTTP Header 信息将不同的应用通过路由串联起来，大概如下：

Server A V1 -> Server B V1

Server A V2 -> Server B 其它版本

Read More