Electron 進程管理工具開發日記3：進程池負載均衡、智能啓停

文中實現的部分工具方法正處於早期/測試階段，仍在持續優化中，僅供參考...

在 Ubuntu20.04 上進行開發/測試，可用於 Electron 項目，測試版本：[email protected] / 9.3.5

├── Contents (you are here!)
│
├── I. 前言
├── II. 架構圖
│
├── III.electron-re 可以用來做什麼？
│   ├── 1) 用於 Electron 應用
│   └── 2) 用於 Electron/Nodejs 應用
│
├── IV. UI 功能介紹
│   ├── 主界面
│   ├── 功能1：Kill 進程
│   ├── 功能2：一鍵開啓 DevTools
│   ├── 功能3：查看進程日誌
│   ├── 功能4：查看進程 CPU/Memory 佔用趨勢
│   └── 功能5：查看 MessageChannel 請求發送日誌
│
├── V. 新特性：進程池負載均衡
│   ├── 關於負載均衡
│   ├── 負載均衡策略說明
│   ├── 負載均衡策略的簡易實現
│   ├── 負載均衡器的實現
│   └── 進程池配合 LoadBalancer 來實現負載均衡
│
├── VI. 新特性：子進程智能啓停
│   ├── 使進程休眠的各種方式
│   ├── 生命週期 LifeCycle 的實現
│   └── 進程互斥鎖的雛形
│
├── VII. 存在的已知問題
├── VIII. Next To Do
│
├── IX. 幾個實際使用示例
│   ├── 1) Service/MessageChannel 使用示例
│   ├── 2) 一個實際用於生產項目的例子
│   ├── 3) ChildProcessPool/ProcessHost 使用示例
│   ├── 3) test 測試目錄示例
│   └── 4) github README 說明
│

I. 前言

之前在做 Electron 應用開發的時候，寫了個 Electron 進程管理工具 electron-re，支持 Electron/Node 多進程管理、service 模擬、進程實時監控(UI功能)、Node.js 進程池等特性。已經發布爲npm組件，可以直接安裝(最新特性還沒發佈到線上，需要再進行測試)：

>> github地址

$: npm install electron-re --save
# or
$: yarn add electron-re

本主題前面兩篇文章：

《Electron/Node多進程工具開發日記》描述了electron-re的開發背景、針對的問題場景以及詳細的使用方法。
《Electron多進程工具開發日記2》介紹了新特性 "多進程管理 UI" 的開發和使用相關。UI 界面基於 electron-re 已有的 BrowserService/MessageChannel 和 ChildProcessPool/ProcessHost 基礎架構驅動，使用 React17 / Babel7 開發。

這篇文章主要是描述最近支持的進程池模塊新特性 - "進程池負載均衡" 和 "子進程智能啓停"，以及相關的基本實現原理。同時提出自己遇到的一些問題，以及對這些問題的思考、解決方案，對之後版本迭代的一些想法等等。

II. electron-re 架構圖

Electron Core：Electron 應用的一系列核心功能，包含了應用的主進程、渲染進程、窗口等等(Electron 自帶)。
BrowserWindow：渲染窗口進程，一般用於UI渲染 (Electron 自帶)。
ProcessManager：進程管理器，負責進程佔用資源採集、異步刷新UI、響應和發出各種進程管理信號，作爲一個觀察者對象給其它模塊和UI提供服務 (electron-re 引入)。
MessageChannel：適用於主進程、渲染進程、Service 進程的消息發送工具，基於原生 IPC 封裝，主要服務於 BrowserService，也可替代原生的 IPC 通信方法 (electron-re 引入)。
ChildProcess：由 child_process.fork 方法生成的子進程，不過以裝飾器的方式爲其添加了簡單的進程休眠和喚醒邏輯 (electron-re 引入)。
ProcessHost：配合進程池使用的工具，我稱它爲 "進程事務中心"，封裝了 process.send / process.on 基本邏輯，提供了 Promise 的調用方式讓主進程/子進程之間 IPC 消息通信更簡單 (electron-re 引入)。
LoadBalancer：服務於進程池的負載均衡器 (electron-re 引入)。
LifeCycle：服務於進程池的生命週期 (electron-re 引入)。
ChildProcessPool：基於 Node.js - child_process.fork 方法實現的進程池，內部管理多個 ChildProcess 實例對象，支持自定義負載均衡策略、子進程智能啓停、子進程異常退出後自動重啓等特性 (electron-re 引入)。
BrowserService：基於 BrowserWindow 實現的 Service 進程，可以看成是一個運行在後臺的隱藏渲染窗口進程，允許 Node 注入，不過僅支持 CommonJs 規範 (electron-re 引入)。

III. electron-re 可以用來做什麼？

1. 用於 Electron 應用

BrowserService
MessageChannel

在 Electron 的一些“最佳實踐”中，建議將佔用cpu的代碼放到渲染過程中而不是直接放在主過程中，這裏先看下 chromium 的架構圖：

每個渲染進程都有一個全局對象 RenderProcess，用來管理與父瀏覽器進程的通信，同時維護着一份全局狀態。瀏覽器進程爲每個渲染進程維護一個 RenderProcessHost 對象，用來管理瀏覽器狀態和與渲染進程的通信。瀏覽器進程和渲染進程使用 Chromium 的 IPC 系統進行通信。在 chromium 中，頁面渲染時，UI進程需要和 main process 不斷的進行 IPC 同步，若此時 main process 忙，則 UIprocess 就會在 IPC 時阻塞。所以如果主進程持續進行消耗 CPU 時間的任務或阻塞同步 IO 的任務的話，就會在一定程度上阻塞，從而影響主進程和各個渲染進程之間的 IPC 通信，IPC 通信有延遲或是受阻，渲染進程窗口就會卡頓掉幀，嚴重的話甚至會卡住不動。

因此 electron-re 在 Electron 已有的 Main Process 主進程和 Renderer Process 渲染進程邏輯的基礎上獨立出一個單獨的 Service 概念。Service即不需要顯示界面的後臺進程，它不參與 UI 交互，單獨爲主進程或其它渲染進程提供服務，它的底層實現爲一個允許 node注入 和 remote調用 的 隱藏渲染窗口進程。

這樣就可以將代碼中耗費 cpu 的操作(比如文件上傳中維護一個數千個上傳任務的隊列)編寫成一個單獨的js文件，然後使用 BrowserService 構造函數以這個 js 文件的地址 path 爲參數構造一個 Service 實例，從而將他們從主進程中分離。如果你說那這部分耗費 cpu 的操作直接放到渲染窗口進程可以嘛？這其實取決於項目自身的架構設計，以及對進程之間數據傳輸性能損耗和傳輸時間等各方面的權衡，創建一個 Service 的簡單示例：

const { BrowserService } = require('electron-re');
const myServcie = new BrowserService('app', path.join(__dirname, 'path/to/app.service.js'));

如果使用了 BrowserService 的話，要想在主進程、渲染進程、service 進程之間相互發送消息就要使用 electron-re 提供的 MessageChannel 通信工具，它的接口設計跟 Electron 內建的IPC基本一致，底層也是基於原生的 IPC 異步通信原理來實現的，簡單示例如下：

/* ---- main.js ---- */
const { BrowserService } = require('electron-re');
// 主進程中向一個 service 'app' 發送消息
MessageChannel.send('app', 'channel1', { value: 'test1' });

2. 用於 Electron/Nodejs 應用

ChildProcessPool
ProcessHost

此外，如果要創建一些不依賴於 Electron 運行時的子進程（相關參考nodejs child_process），可以使用 electron-re 提供的專門爲 nodejs 運行時編寫的進程池 ChildProcessPool 。因爲創建進程本身所需的開銷很大，使用進程池來重複利用已經創建了的子進程，將多進程架構帶來的性能效益最大化，簡單示例如下：

/* --- 主進程中 --- */
const { ChildProcessPool, LoadBalancer } = require('electron-re');

const pool = new ChildProcessPool({
  path: path.join(app.getAppPath(), 'app/services/child.js'), // 子進程執行文件路徑
  max: 3, // 最大進程數
  strategy: LoadBalancer.ALGORITHM.WEIGHTS, // 負載均衡策略 - 權重
  weights: [1, 2, 3], // 權重分配
});

pool
  .send('sync-work', params)
  .then(rsp => console.log(rsp));

一般情況下，在我們的子進程執行文件中，爲了在主進程和子進程之間同步數據，可以使用 process.send('channel', params) 和 process.on('channel', function) 的方式實現(前提是進程以以 fork 方式創建或者手動開啓了 IPC 通信)。但是這樣在處理業務邏輯的同時也強迫我們去關注進程之間的通信，你需要知道子進程什麼時候能處理完畢，然後再使用process.send再將數據返回主進程，使用方式繁瑣。

electron-re 引入了 ProcessHost 的概念，我稱之爲"進程事務中心"。實際使用時在子進程執行文件中只需要將各個任務函數通過 ProcessHost.registry('task-name', function) 註冊成多個被監聽的事務，然後配合進程池的 ChildProcessPool.send('task-name', params) 來觸發子進程事務邏輯的調用即可，ChildProcessPool.send() 同時會返回一個 Promise 實例以便獲取回調數據，簡單示例如下：

/* --- 子進程中 --- */
const { ProcessHost } = require('electron-re');

ProcessHost
  .registry('sync-work', (params) => {
    return { value: 'task-value' };
  })
  .registry('async-work', (params) => {
    return fetch(params.url);
  });

IV. UI 功能介紹

UI 功能基於 electron-re 基礎架構開發，它通過異步 IPC 和主進程的 ProcessManager 進行通信，實時刷新進程狀態。操作者可以通過 UI 手動 Kill 進程、查看進程 console 數據、查看進程數 CPU/Memory 佔用趨勢以及查看 MessageChannel 工具的請求發送記錄。

主界面

UI參考 electron-process-manager 設計

預覽圖：

主要功能如下：

展示 Electron 應用中所有開啓的進程，包括主進程、普通的渲染進程、Service 進程(electron-re 引入)、ChildProcessPool 創建的子進程(electron-re 引入)。
進程列表中顯示各個進程進程號、進程標識、父進程號、內存佔用大小、CPU 佔用百分比等，所有進程標識分爲：main(主進程)、service(服務進程)、renderer(渲染進程)、node(進程池子進程)，點擊表格頭可以針對對某項進行遞增/遞減排序。
選中某個進程後可以 Kill 此進程、查看進程控制檯 Console 數據、查看1分鐘內進程 CPU/Memory 佔用趨勢，如果此進程是渲染進程的話還可以通過 DevTools 按鈕一鍵打開內置調試工具。
ChildProcessPool 創建的子進程暫不支持直接打開 DevTools 進行調試，不過由於創建子進程時添加了 --inspect 參數，可以使用 chrome 的 chrome://inspect 進行遠程調試。
點擊 Signals 按鈕可以查看 MessageChannel 工具的請求發送日誌，包括簡單的請求參數、請求名、請求返回數據等。

功能：Kill 進程

功能：一鍵開啓 DevTools

功能：查看進程日誌

功能：查看進程 CPU/Memory 佔用趨勢

功能：查看 MessageChannel 請求發送日誌

V. 新特性：進程池負載均衡

簡化的初版實現

>> 代碼地址

➣ 關於負載均衡

“ 負載均衡，英文名稱爲 Load Balance，其含義就是指將負載（工作任務）進行平衡、分攤到多個操作單元上進行運行，例如 FTP 服務器、Web服務器、企業核心應用服務器和其它主要任務服務器等，從而協同完成工作任務。
負載均衡構建在原有網絡結構之上，它提供了一種透明且廉價有效的方法擴展服務器和網絡設備的帶寬、加強網絡數據處理能力、增加吞吐量、提高網絡的可用性和靈活性。” -- 《百度百科》

➣ 負載均衡策略說明

之前的實現中，進程池創建好後，當使用 pool 發送請求時，採用兩種方式處理請求發送策略：

默認使用輪詢策略選擇一個子進程處理請求，只能保證基本的請求平均分配。
另一種使用情況是通過手動指定發送請求時的額外參數 id：pool.send(channel, params, id)，這樣子讓 id 相同的請求發送到同一個子進程上。一個適用情景就是：第一次我們向某個子進程發送請求，該子進程處理請求後在其運行時內存空間中存儲了一些處理結果，之後某個情況下需要將之前那次請求產生的處理結果再次拿回主進程，這時候就需要使用 id 來區分請求。

新版本引入了一些負載均衡策略，包括：

POLLING - 輪詢：子進程輪流處理請求
WEIGHTS - 權重：子進程根據設置的權重來處理請求
RANDOM - 隨機：子進程隨機處理請求
SPECIFY - 指定：子進程根據指定的進程 id 處理請求
WEIGHTS_POLLING - 權重輪詢：權重輪詢策略與輪詢策略類似，但是權重輪詢策略會根據權重來計算子進程的輪詢次數，從而穩定每個子進程的平均處理請求數量。
WEIGHTS_RANDOM - 權重隨機：權重隨機策略與隨機策略類似，但是權重隨機策略會根據權重來計算子進程的隨機次數，從而穩定每個子進程的平均處理請求數量。
MINIMUM_CONNECTION - 最小連接數：選擇子進程上具有最小連接活動數量的子進程處理請求。
WEIGHTS_MINIMUM_CONNECTION - 權重最小連接數：權重最小連接數策略與最小連接數策略類似，不過各個子進程被選中的概率由連接數和權重共同決定。

➣ 負載均衡策略的簡易實現

參數說明：

tasks：任務數組，一個示例：[{id: 11101, weight: 2}, {id: 11102, weight: 1}]。
currentIndex: 目前所處的任務索引，默認爲 0，每次調用時會自動加 1，超出任務數組長度時會自動取模。
context：主進程參數上下文，用於動態更新當前任務索引和權重索引。
weightIndex：權重索引，用於權重策略，默認爲 0，每次調用時會自動加 1，超出權重總和時會自動取模。
weightTotal：權重總和，用於權重策略相關計算。
connectionsMap：各個進程活動連接數的映射，用於最小連接數策略相關計算。

1. 輪詢策略(POLLING)

原理：索引值遞增，每次調用時會自動加 1，超出任務數組長度時會自動取模，保證平均調用。
時間複雜度 O(n) = 1

/* polling algorithm */
module.exports = function (tasks, currentIndex, context) {
  if (!tasks.length) return null;

  const task = tasks[currentIndex];
  context.currentIndex ++;
  context.currentIndex %= tasks.length;

  return task || null;
};

2. 權重策略(WEIGHTS)

原理：每個進程根據 (權重值 + (權重總和 * 隨機因子)) 生成最終計算值，最終計算值中的最大值被命中。
時間複雜度 O(n) = n

/* weight algorithm */
module.exports = function (tasks, weightTotal, context) {

  if (!tasks.length) return null;

  let max = tasks[0].weight, maxIndex = 0, sum;

  for (let i = 0; i < tasks.length; i++) {
    sum = (tasks[i].weight || 0) + Math.random() * weightTotal;
    if (sum >= max) {
      max = sum;
      maxIndex = i;
    }
  }

  context.weightIndex += 1;
  context.weightIndex %= (weightTotal + 1);

  return tasks[maxIndex];
};

3. 隨機策略(RANDOM)

原理：隨機函數在 [0, length) 中任意選取一個索引即可
時間複雜度 O(n) = 1

/* random algorithm */
module.exports = function (tasks) {

  const length = tasks.length;
  const target = tasks[Math.floor(Math.random() * length)];

  return target || null;
};

4. 權重輪詢策略(WEIGHTS_POLLING)

原理：類似輪詢策略，不過輪詢的區間爲：[最小權重值, 權重總和]，根據各項權重累加值進行命中區間計算。每次調用時權重索引會自動加 1，超出權重總和時會自動取模。
時間複雜度 O(n) = n

/* weights polling */
module.exports = function (tasks, weightIndex, weightTotal, context) {

  if (!tasks.length) return null;

  let weight = 0;
  let task;

  for (let i = 0; i < tasks.length; i++) {
    weight += tasks[i].weight || 0;
    if (weight >= weightIndex) {
      task = tasks[i];
      break;
    }
  }

  context.weightIndex += 1;
  context.weightIndex %= (weightTotal + 1);

  return task;
};

5. 權重隨機策略(WEIGHTS_RANDOM)

原理：由 (權重總和 * 隨機因子) 產生計算值，將各項權重值與其相減，第一個不大於零的最終值即被命中。
時間複雜度 O(n) = n

/* weights random algorithm */
module.exports = function (tasks, weightTotal) {
  let task;
  let weight = Math.ceil(Math.random() * weightTotal);

  for (let i = 0; i < tasks.length; i++) {
    weight -= tasks[i].weight || 0;
    if (weight <= 0) {
      task = tasks[i];
      break;
    }
  }

  return task || null;
};

6. 最小連接數策略(MINIMUM_CONNECTION)

原理：直接選擇當前連接數最小的項即可。
時間複雜度 O(n) = n

/* minimum connections algorithm */
module.exports = function (tasks, connectionsMap={}) {
  if (tasks.length < 2) return tasks[0] || null;

  let min = connectionsMap[tasks[0].id];
  let minIndex = 0;

  for (let i = 1; i < tasks.length; i++) {
    const con = connectionsMap[tasks[i].id] || 0;
    if (con <= min) {
      min = con;
      minIndex = i;
    }
  }

  return tasks[minIndex] || null;
};

7. 權重最小連接數(WEIGHTS_MINIMUM_CONNECTION)

原理：權重 + ( 隨機因子 * 權重總和 ) + ( 連接數佔比 * 權重總和 ) 三個因子，計算出最終值，根據最終值的大小進行比較，最小值所代表項即被命中。
時間複雜度 O(n) = n

/* weights minimum connections algorithm */
module.exports = function (tasks, weightTotal, connectionsMap, context) {

  if (!tasks.length) return null;

  let min = tasks[0].weight, minIndex = 0, sum;

  const connectionsTotal = tasks.reduce((total, cur) => {
    total += (connectionsMap[cur.id] || 0);
    return total;
  }, 0);

  // algorithm: (weight + connections'weight) + random factor
  for (let i = 0; i < tasks.length; i++) {
    sum =
      (tasks[i].weight || 0) + (Math.random() * weightTotal) +
      (( (connectionsMap[tasks[i].id] || 0) * weightTotal ) / connectionsTotal);
    if (sum <= min) {
      min = sum;
      minIndex = i;
    }
  }

  context.weightIndex += 1;
  context.weightIndex %= (weightTotal + 1);

  return tasks[minIndex];
};

➣ 負載均衡器的實現

代碼都不復雜，有幾點需要說明：

params 對象保存了用於各種策略計算的一些參數，比如權重索引、權重總和、連接數、CPU/Memory佔用等等。
scheduler 對象用於調用各種策略進行計算，scheduler.calculate() 會返回一個命中的進程 id。
targets 即所有用於計算的目標進程，不過其中僅存放了目標進程 pid 和其權重 weight：[{id: [pid], weight: [number]}, ...]。
algorithm 爲特定的負載均衡策略，默認值爲輪詢策略。
ProcessManager.on('refresh', this.refreshParams)，負載均衡器通過監聽 ProcessManager 的 refresh 事件來定時更新各個進程的計算參數。ProcessManager 中有一個定時器，每隔一段時間就會採集一次各個被監聽的進程的資源佔用情況，並攜帶採集數據觸發一次 refresh 事件。

const CONSTS = require("./consts");
const Scheduler = require("./scheduler");
const {
  RANDOM,
  POLLING,
  WEIGHTS,
  SPECIFY,
  WEIGHTS_RANDOM,
  WEIGHTS_POLLING,
  MINIMUM_CONNECTION,
  WEIGHTS_MINIMUM_CONNECTION,
} = CONSTS;
const ProcessManager = require('../ProcessManager');

/* Load Balance Instance */
class LoadBalancer {
  /**
    * @param  {Object} options [ options object ]
    * @param  {Array } options.targets [ targets for load balancing calculation: [{id: 1, weight: 1}, {id: 2, weight: 2}] ]
    * @param  {String} options.algorithm [ strategies for load balancing calculation : RANDOM | POLLING | WEIGHTS | SPECIFY | WEIGHTS_RANDOM | WEIGHTS_POLLING | MINIMUM_CONNECTION | WEIGHTS_MINIMUM_CONNECTION]
    */
  constructor(options) {
    this.targets = options.targets;
    this.algorithm = options.algorithm || POLLING;
    this.params = { // data for algorithm
      currentIndex: 0, // index
      weightIndex: 0, // index for weight alogrithm
      weightTotal: 0, // total weight
      connectionsMap: {}, // connections of each target
      cpuOccupancyMap: {}, // cpu occupancy of each target
      memoryOccupancyMap: {}, // cpu occupancy of each target
    };
    this.scheduler = new Scheduler(this.algorithm);
    this.memoParams = this.memorizedParams();
    this.calculateWeightIndex();
    ProcessManager.on('refresh', this.refreshParams);
  }

  /* params formatter */
  memorizedParams = () => {
    return {
      [RANDOM]: () => [],
      [POLLING]: () => [this.params.currentIndex, this.params],
      [WEIGHTS]: () => [this.params.weightTotal, this.params],
      [SPECIFY]: (id) => [id],
      [WEIGHTS_RANDOM]: () => [this.params.weightTotal],
      [WEIGHTS_POLLING]: () => [this.params.weightIndex, this.params.weightTotal, this.params],
      [MINIMUM_CONNECTION]: () => [this.params.connectionsMap],
      [WEIGHTS_MINIMUM_CONNECTION]: () => [this.params.weightTotal, this.params.connectionsMap, this.params],
    };
  }

  /* refresh params data */
  refreshParams = (pidMap) => { ... }

  /* pick one task from queue */
  pickOne = (...params) => {
    return this.scheduler.calculate(
      this.targets, this.memoParams[this.algorithm](...params)
    );
  }

  /* pick multi task from queue */
  pickMulti = (count = 1, ...params) => {
    return new Array(count).fill().map(
      () => this.pickOne(...params)
    );
  }

  /* calculate weight */
  calculateWeightIndex = () => {
    this.params.weightTotal = this.targets.reduce((total, cur) => total + (cur.weight || 0), 0);
    if (this.params.weightIndex > this.params.weightTotal) {
      this.params.weightIndex = this.params.weightTotal;
    }
  }

  /* calculate index */
  calculateIndex = () => {
    if (this.params.currentIndex >= this.targets.length) {
      this.params.currentIndex = (ths.params.currentIndex - 1 >= 0) ? (this.params.currentIndex - 1) : 0;
    }
  }

  /* clean data of a task or all task */
  clean = (id) => { ... }

  /* add a task */
  add = (task) => {...}

  /* remove target from queue */
  del = (target) => {...}

  /* wipe queue and data */
  wipe = () => {...}

  /* update calculate params */
  updateParams = (object) => {
    Object.entries(object).map(([key, value]) => {
      if (key in this.params) {
        this.params[key] = value;
      }
    });
  }

  /* reset targets */
  setTargets = (targets) => {...}

  /* change algorithm strategy */
  setAlgorithm = (algorithm) => {...}
}

module.exports = Object.assign(LoadBalancer, { ALGORITHM: CONSTS });

➣ 進程池配合 LoadBalancer 來實現負載均衡

有幾點需要說明：

當我們使用 pool.send('channel', params) 時，pool 內部 getForkedFromPool() 函數會被調用，函數從進程池中選擇一個進程來執行任務，如果子進程數未達到最大設定數，則優先創建一個子進程來處理請求。
子進程創建/銷燬/退出時需要同步更新 LoadBalancer 中監聽的 targets，否則已被銷燬的進程 pid 可能會在執行負載均衡策略計算後被返回。
ForkedProcess 是一個裝飾器類，封裝了 child_process.fork 邏輯，爲其增加了一些額外功能，如：進程睡眠、喚醒、綁定事件、發送請求等基本方法。

const _path = require('path');
const EventEmitter = require('events');

const ForkedProcess = require('./ForkedProcess');
const ProcessLifeCycle = require('../ProcessLifeCycle.class');
const ProcessManager = require('../ProcessManager/index');
const { defaultLifecycle } = require('../ProcessLifeCycle.class');
const LoadBalancer = require('../LoadBalancer');
let { inspectStartIndex } = require('../../conf/global.json');
const { getRandomString, removeForkedFromPool, convertForkedToMap, isValidValue } = require('../utils');
const { UPDATE_CONNECTIONS_SIGNAL } = require('../consts');

const defaultStrategy = LoadBalancer.ALGORITHM.POLLING;

class ChildProcessPool extends EventEmitter {
  constructor({
    path, max=6, cwd, env={},
    weights=[], // weights of processes, the length is equal to max
    strategy=defaultStrategy,
    ...
  }) {
    super();
    this.cwd = cwd || _path.dirname(path);
    this.env = {
      ...process.env,
      ...env
    };
    this.callbacks = {};
    this.pidMap = new Map();
    this.callbacksMap = new Map();
    this.connectionsMap={};
    this.forked = [];
    this.connectionsTimer = null;
    this.forkedMap = {};
    this.forkedPath = path;
    this.forkIndex = 0;
    this.maxInstance = max;
    this.weights = new Array(max).fill().map(
      (_, i) => (isValidValue(weights[i]) ? weights[i] : 1)
    );
    this.LB = new LoadBalancer({
      algorithm: strategy,
      targets: [],
    });

    this.initEvents();
  }

  /* -------------- internal -------------- */

  /* init events */
  initEvents = () => {
    // process exit
    this.on('forked_exit', (pid) => {
      this.onForkedDisconnect(pid);
    });
    ...
  }

  /**
    * onForkedCreate [triggered when a process instance created]
    * @param  {[String]} pid [process pid]
    */
  onForkedCreate = (forked) => {
    const pidsValue = this.forked.map(f => f.pid);
    const length = this.forked.length;

    this.LB.add({
      id: forked.pid,
      weight: this.weights[length - 1],
    });
    ProcessManager.listen(pidsValue, 'node', this.forkedPath);
    ...
  }

  /**
    * onForkedDisconnect [triggered when a process instance disconnect]
    * @param  {[String]} pid [process pid]
    */
   onForkedDisconnect = (pid) => {
    const length = this.forked.length;

    removeForkedFromPool(this.forked, pid, this.pidMap);
    this.LB.del({
      id: pid,
      weight: this.weights[length - 1],
    });
    ProcessManager.unlisten([pid]);
    ...
  }

  /* Get a process instance from the pool */
  getForkedFromPool = (id="default") => {
    let forked;
    if (!this.pidMap.get(id)) {
      // create new process and put it into the pool
      if (this.forked.length < this.maxInstance) {
        inspectStartIndex ++;
        forked = new ForkedProcess(
          this,
          this.forkedPath,
          this.env.NODE_ENV === "development" ? [`--inspect=${inspectStartIndex}`] : [],
          { cwd: this.cwd, env: { ...this.env, id }, stdio: 'pipe' }
        );
        this.forked.push(forked);
        this.onForkedCreate(forked);
      } else {
      // get a process from the pool based on load balancing strategy
        forked = this.forkedMap[this.LB.pickOne().id];
      }
      if (id !== 'default') {
        this.pidMap.set(id, forked.pid);
      }
    } else {
      // pick a special process from the pool
      forked = this.forkedMap[this.pidMap.get(id)];
    }

    if (!forked) throw new Error(`Get forked process from pool failed! the process pid: ${this.pidMap.get(id)}.`);

    return forked;
  }

  /* -------------- caller -------------- */

  /**
  * send [Send request to a process]
  * @param  {[String]} taskName [task name - necessary]
  * @param  {[Any]} params [data passed to process - necessary]
  * @param  {[String]} id [the unique id bound to a process instance - not necessary]
  * @return {[Promise]} [return a Promise instance]
  */
  send = (taskName, params, givenId) => {
    if (givenId === 'default') throw new Error('ChildProcessPool: Prohibit the use of this id value: [default] !')

    const id = getRandomString();
    const forked = this.getForkedFromPool(givenId);
    this.lifecycle.refresh([forked.pid]);

    return new Promise(resolve => {
      this.callbacks[id] = resolve;
      forked.send({action: taskName, params, id });
    });
  }
  ...
}

module.exports = ChildProcessPool;

VI. 新特性：子進程智能啓停

這個特性我也將其稱爲 進程生命週期 (lifecycle)。

主要作用是：當子進程一段時間未被調用，則自動進入休眠狀態，減少 CPU 佔用 (減少內存佔用很難)。進入休眠狀態的時間可以和由創建者控制，默認爲 10 min。當子進程進入休眠後，如果有新的請求到來並分發到該休眠的進程上，則會自動喚醒該進程並繼續處理當前請求。一段時間閒置後，將會再次進入休眠狀態。

➣ 使進程休眠的各種方式

1）如果是讓進程暫停的話，可以向進程發送 SIGSTOP 信號，發送 SIGCONT 信號可以恢復進程。

Node.js:

process.kill([pid], "SIGSTOP");
process.kill([pid], "SIGCONT");

Unix System (Windows 暫未測試):

kill -STOP [pid]
kill -CONT [pid]

2）Node.js 新的 Atomic.wait API 也可以做到編程控制。該方法會監聽一個 Int32Array 對象的給定下標下的值，若值未發生改變，則一直等待(阻塞 event loop)，直到發生超時(由 ms 參數決定)。可以在主進程中操作這塊共享數據，然後爲子進程解除休眠鎖定。

const nil = new Int32Array(new SharedArrayBuffer(4));
const array = new Array(100000).fill(0);
setInterval(() => {
console.log(1);
}, 1e3);
Atomics.wait(nil, 0, 0, Number(600e3));

➣ 生命週期 LifeCycle 的實現

代碼同樣很簡單，有幾點需要說明：

採用了 標記清除法，子進程觸發請求時更新調用時間，同時使用定時器循環計算各個被監聽子進程的 ( 當前時間 - 上次調用時間) 差值。如果有超過設定的時間的進程則發送 sleep 信號，同時攜帶所有進程 pid。
每個 ChildProcessPool 進程池實例都會擁有一個 ProcessLifeCycle 實例對象用於控制當前進程池中的進程的休眠/喚醒。ChildProcessPool 會監聽 ProcessLifeCycle 對象的 sleep 事件，拿到需要 sleep 的進程 pid 後調用 ForkedProcess 的 sleep() 方法使其睡眠。下個請求分發到該進程時，會自動喚醒該進程。

const EventEmitter = require('events');

const defaultLifecycle = {
  expect: 600e3, // default timeout 10 minutes
  internal: 30e3 // default loop check interval 30 seconds
};

class ProcessLifeCycle extends EventEmitter {
  constructor(options) {
    super();
    const {
      expect=defaultLifecycle.expect,
      internal=defaultLifecycle.internal
    } = options;
    this.timer = null;
    this.internal = internal;
    this.expect = expect;
    this.params = {
      activities: new Map()
    };
  }

  /* task check loop */
  taskLoop = () => {
    if (this.timer) return console.warn('ProcessLifeCycle: the task loop is already running');

    this.timer = setInterval(() => {
      const sleepTasks = [];
      const date = new Date();
      const { activities } = this.params;
      ([...activities.entries()]).map(([key, value]) => {
        if (date - value > this.expect) {
          sleepTasks.push(key);
        }
      });
      if (sleepTasks.length) {
        // this.unwatch(sleepTasks);
        this.emit('sleep', sleepTasks);
      }
    }, this.internal);
  }

  /* watch processes */
  watch = (ids=[]) => {
    ids.forEach(id => {
      this.params.activities.set(id, new Date());
    });
  }

  /* unwatch processes */
  unwatch = (ids=[]) => {
    ids.forEach(id => {
      this.params.activities.delete(id);
    });
  }

  /* stop task check loop */
  stop = () => {
    clearInterval(this.timer);
    this.timer = null;
  }

  /* start task check loop */
  start = () => {
    this.taskLoop();
  }

  /* refresh tasks */
  refresh = (ids=[]) => {
    ids.forEach(id => {
      if (this.params.activities.has(id)) {
        this.params.activities.set(id, new Date());
      } else {
        console.warn(`The task with id ${id} is not being watched.`);
      }
    });
  }
}

module.exports = Object.assign(ProcessLifeCycle, { defaultLifecycle });

➣ 進程互斥鎖的雛形

之前看文章時看到關於 API - Atomic.wait 的一篇文章，Atomic 除了用於實現進程睡眠，也能基於它來理解進程互斥鎖的實現原理。這裏有個基本雛形可以作爲參考，相關文檔可以參閱 MDN。

AsyncLock 對象需要在子進程中引入，創建 AsyncLock 的構造函數中有一個參數 sab 需要注意。這個參數是一個 SharedArrayBuffer 共享數據塊，這個共享數據快需要在主進程創建，然後通過 IPC 通信發送到各個子進程，通常 IPC 通信會序列化一般的諸如 Object / Array 等數據，導致消息接受者和消息發送者拿到的不是同一個對象，但是經由 IPC 發送的 SharedArrayBuffer 對象卻會指向同一個內存塊。

在子進程中使用 SharedArrayBuffer 數據創建 AsyncLock 實例後，任意一個子進程對共享數據的修改都會導致其它進程內指向這塊內存的 SharedArrayBuffer 數據內容變化，這就是我們使用它實現進程鎖的基本要點。

先對 Atomic API 做個簡單說明：

Atomics.compareExchange(typedArray, index, expectedValue, newValue)：Atomics.compareExchange() 靜態方法會在數組的值與期望值相等的時候，將給定的替換值替換掉數組上的值，然後返回舊值。此原子操作保證在寫上修改的值之前不會發生其他寫操作。
Atomics.waitAsync(typedArray, index, value[, timeout])：靜態方法 Atomics.wait() 確保了一個在 Int32Array 數組中給定位置的值沒有發生變化且仍然是給定的值時進程將會睡眠，直到被喚醒或超時。該方法返回一個字符串，值爲"ok", "not-equal", 或 "timed-out" 之一。
Atomics.notify(typedArray, index[, count])：靜態方法 Atomics.notify() 喚醒指定數量的在等待隊列中休眠的進程，不指定 count 時默認喚醒所有。

AsyncLock 即異步鎖，等待鎖釋放的時候不會阻塞主線程。主要關注 executeAfterLocked() 這個方法，調用該方法並傳入回調函數，該回調函數會在鎖被獲取後執行，並且在執行完畢後自動釋放鎖。其中一步的關鍵就是 tryGetLock() 函數，它返回了一個 Promise 對象，因此我們等待鎖釋放的邏輯在微任務隊列中執行而並不阻塞主線程。

/**
  * @name AsyncLock
  * @description
  *   Use it in child processes, mutex lock logic.
  *   First create SharedArrayBuffer in main process and transfer it to all child processes to control the lock.
  */

class AsyncLock {
  static INDEX = 0;
  static UNLOCKED = 0;
  static LOCKED = 1;

  constructor(sab) {
    this.sab = sab; // data like this: const sab = new SharedArrayBuffer(16);
    this.i32a = new Int32Array(sab);
  }

  lock() {
    while (true) {
      const oldValue = Atomics.compareExchange(
        this.i32a, AsyncLock.INDEX,
        AsyncLock.UNLOCKED, // old
        AsyncLock.LOCKED // new
      );
      if (oldValue == AsyncLock.UNLOCKED) { // success
        return;
      }
      Atomics.wait( // wait
        this.i32a,
        AsyncLock.INDEX,
        AsyncLock.LOCKED // expect
      );
    }
  }

  unlock() {
    const oldValue = Atomics.compareExchange(
      this.i32a, AsyncLock.INDEX,
      AsyncLock.LOCKED,
      AsyncLock.UNLOCKED
    );
    if (oldValue != AsyncLock.LOCKED) { // failed
      throw new Error('Tried to unlock while not holding the mutex');
    }
    Atomics.notify(this.i32a, AsyncLock.INDEX, 1);
  }

  /**
    * executeLocked [async function to acquired the lock and execute callback]
    * @param  {Function} callback [callback function]
    */
  executeAfterLocked(callback) {

    const tryGetLock = async () => {
      while (true) {
        const oldValue = Atomics.compareExchange(
          this.i32a,
          AsyncLock.INDEX,
          AsyncLock.UNLOCKED,
          AsyncLock.LOCKED
        );
        if (oldValue == AsyncLock.UNLOCKED) { // success if AsyncLock.UNLOCKED
          callback();
          this.unlock();
          return;
        }
        const result = Atomics.waitAsync( // wait when AsyncLock.LOCKED
          this.i32a,
          AsyncLock.INDEX,
          AsyncLock.LOCKED
        );
        await result.value; // return a Promise, will not block the main thread
      }
    }

    tryGetLock();
  }
}

VII. 存在的已知問題

由於使用了 Electron 原生的 remote API，因此 electron-re 部分特性(Service 相關)不支持 Electron 14 以及以上版本(已經移除 remote)，正考慮近期使用第三方 remote 庫進行替代兼容。
容錯處理做的不夠好，這一塊會成爲之後的重要優化點。
採集進程池中活動連接數時採用了"調用計數"的方式。這個處理方法不太好，準確性也不夠高，但是目前還未想到更好的解決方法用於統計子進程中活躍的連接數。我覺得還是要從底層進行解決，比如：宏任務和微任務隊列、V8 虛擬機、垃圾回收、Libuv 底層原理、Node 進程和線程原理...
暫時沒在 windows 平臺測試進程休眠功能，win 平臺本身不支持進程信號，但是 Node 提供了模擬支持，但是具體表現還需測試。

VIII. Next To Do

讓 Service 支持代碼更新後自動重啓
添加 ChildProcessPool 子進程調度邏輯
優化 ChildProcessPool 多進程console輸出
添加可視化進程管理界面
增強 ChildProcessPool 進程池功能
增強 ProcessHost 事務中心功能
子進程之間互斥鎖邏輯的實現
使用外部 remote 庫以支持最新版本的 Electron
Kill Bugs 🐛

IX. 幾個實際使用示例

electronux - 我的一個Electron項目，使用了 BrowserService/MessageChannel，並且附帶了ChildProcessPool/ProcessHost使用demo。
暗影襪子-electron - 我的另一個Electron 跨平臺桌面應用項目(不提供鏈接，可以點擊上面的查看原文)，使用 electron-re 進行調試開發，並且在生產環境下可以打開 ProcessManager UI 用於 CPU/Memory 資源佔用監控和請求日誌查看。
file-slice-upload - 一個關於多文件分片並行上傳的demo，使用了 ChildProcessPool and ProcessHost，基於 [email protected]開發。
也可直接查看 index.test.js 和 test 目錄下的測試樣例文件，包含了一些使用示例。
當然 github - README 也有相關說明項。