新写得文章不能编辑了，最后在 删除旁边操作找到了。真难找
查看原文个人动态
rebareba 发布了文章 · 1月13日
RenderServer 前端部署、接口测试及文档
介绍
背景
对于前后端分离的前端项目，目前常用的前端部署方式是通过Nginx设置静态资源目录，再配置反向代理来转发API请求到后端服务，这种方式是比较通用简单，对于前端开发同学来说只需要了解一些Nginx的知识，知道怎么上传打包好的静态资源到正确目录。
但对于一些项目来说往往还需要中间层来处理一些东西，比如前端对于后端提供API接口不满意，对返回需要一些简单加工或者一些跳转逻辑处理，而后端往往愿意不配合，或者我们想在前端入口文件中动态注入一些配置项的时候，仅仅使用Nginx无法满足需求（当然Nginx的lua脚本扩展可以帮实现，但这个能力要求过高）。
所以为了解决这个问题，并扩展更多对前端项目开发有用的功能，这里分享Render-Server，它是一个可用于前端项目部署（入口模板渲染及接口转发)、后端API文档管理及接口测试于一身的Nodejs的BFF（ Backend For Frontend）服务。配合插件使用可以实现接口数据mock，文件上传，用户会话，auth2.0认证等功能。
Github: https://github.com/rebareba/r...
功能
Render-Server 主要功能包含：
- 一键部署 npm run deploy
- 支持集群部署配置
- 是一个文件服务
- 是一个静态资源服务
- 在线可视化部署前端项目
- 配置热更新
- 在线Postman及接口文档
- 支持前端路由渲染， 支持模板
- 接口代理及路径替换
- Web安全支持 Ajax请求验证，Referer 校验
- 支持插件开发和在线配置 可实现： 前端模板参数注入、请求头注入、IP白名单、接口mock、会话、第三方登陆等等
使用
为了演示render-server的功能，大致走一下如何安装及部署一个前端项目， 我们这里需要准一台测试机器里面安装好nodejs (v8.9+)和pm2。 这里测试机器ip为192.168.1.9
安装
下载Release版本render-server_1.0.0.tgz， 上传到测试机器的/opt/workspace目录下
$curl -LJO https://github.com/rebareba/render-server/releases/download/1.0.0/render-server_1.0.0.tgz
$scp render-server_1.0.0.tgz root@192.168.1.9:/opt/workspace
root@192.168.1.9's password:
render-server_1.0.0.tgz 进入服务192.168.1.9 解压render-server_1.0.0.tgz 到render-server目录比进入目录执行 npm run deploy部署
$ssh root@192.168.1.9
root@192.168.1.9's password:
[root@localhost ~]# cd /opt/workspace/
[root@localhost workspace]# ll
-rw-r--r--. 1 root root 649 1月 13 17:04 render-server_1.0.0.tgz
[root@localhost workspace]# tar -zxf render-server_1.0.0.tgz
[root@localhost workspace]# cd render-server
[root@localhost render-server]# npm run deploy
> render-server@1.0.0 deploy /opt/workspace/render-server
> node ./bin/deploy.js
配置文件列表： render-server.json
静态文件列表： public render-server
data/render-server/data文件列表： render-server.json
静态文件/data/render-server/static列表： public render-server
pm2 启动服务
部署完成
[root@localhost render-server]# pm2 ls
┌────────────────────────┬────┬─────────┬───────┬─────────┬─────────┬────────┬─────┬────────────┬──────┬──────────┐
│ App name │ id │ mode │ pid │ status │ restart │ uptime │ cpu │ mem │ user │ watching │
├────────────────────────┼────┼─────────┼───────┼─────────┼─────────┼────────┼─────┼────────────┼──────┼──────────┤
│ render-server │ 29 │ cluster │ 15435 │ online │ 0 │ 3s │ 0% │ 57.0 MB │ root │ disabled │
└────────────────────────┴────┴─────────┴───────┴─────────┴─────────┴────────┴─────┴────────────┴──────┴──────────┘
Use `pm2 show <id|name>` to get more details about an app到这里就部署成功了，会创建/data/render-server去存放静态资源和相关配置。
打开浏览器访问http://192.168.1.9:8888/render-server ，默认登陆账号是admin，密码是123456
登陆
登陆后可以看到一个默认的前端项目配置，这个配置是render-server当前管理平台前端配置项。
部署前端
git前端项目拉取
前端项目我们使用React-Starter，我们拉取代码并打包部署
$git clone https://github.com/rebareba/react-starter.git
$cd react-starter
➜ react-starter git:(main) npm i
➜ react-starter git:(main) npm start
Project is running at http://127.0.0.1:9999/打开浏览器本地开发页面
打包
执行npm run build 打包出来的前端代码在dist目录下
➜ react-starter git:(main) npm run build
➜ react-starter git:(main) tree dist -L 3 -a
dist
├── public
│ ├── antd
│ │ └── 3.23.6
│ └── react
│ └── 16.13.1
├── react-starter
│ ├── 1.0.0
│ │ ├── 1.css
│ │ ├── 2.a65cd3857d2b1c9af769.chunk.js
│ │ ├── index.5b1083b293274731c7eb.js
│ │ ├── index.css
│ │ ├── index.html
│ │ ├── vendor.757bd9434578e97b2c84.chunk.js
│ │ ├── vendor.757bd9434578e97b2c84.chunk.js.LICENSE.txt
│ │ └── vendor.757bd9434578e97b2c84.chunk.js.map
│ └── index.html
└── react-starter_1.0.0_public.tgzReact-Start打包的指定的publicPath是react-starter/1.0.0。 react-starter/index.html是入口文件
部署
在Render-Server管理界面上 我们上传两个目录的静态文件dist/public和dist/react-starter
新建前端项目配置保存
{
"key": "react-starter",
"account": "admin",
"name": "前端脚手架",
"description": "描述",
"pageIndex": "/react-starter",
"viewRender": [
{
"paths": [
"/react-starter/(.*)",
"/react-starter"
],
"hosts": [],
"plugins": [],
"defaultData": {
"partials": {}
},
"viewType": "path",
"viewPath": "react-starter/index.html",
"viewData": ""
}
],
"apiProxy": [],
"staticPrefix": []
}
可以看到这里的静态资源的目录就是我们之前上传的目录。
到这里我们已经成功通过Render-Server部署了一个前端项目， 后续版本迭代都可以通过打包上传静态资料来部署。
总结
这个流程是最简单的部署前端静态资源， 这里的访问路径要和前端代码指定的前端统一路由前缀一致。 还有其他配置项的配置功能没有介绍，不如接口代理配置。 多域名相同路径如何配置，插件如何配置。 都可以在说明下查阅。
接口测试及文档
前端和后端开发通过接口文档来进行约定，文档分享的媒介可以是： 具体的word或md文件、通过语雀或者其他在线系统文档、通过代码注释 生产文档（swagger）、swagger服务集成接口测试等。
为了降低复杂性，在Render-Server中集成了接口在线测试功能， 本身接口测试的配置也是接口文档的一种方式。在多人开发的情况下，测试用例能够复用也能加快项目的开发。
在Render-Server中我们配置了一个个前端的项目，一般一个前端项目对应一份后端接口文档。所以我们在项目配置下增加了接口入口
配置说明
新建测试接口
点击新建按钮，进入接口配置页面： 设置相关
保存后可以进行接口测试：
保存测试用例
全局配置
二次开发
后端Render-Server
Github:https://github.com/rebareba/r...
项目是基于koa开发，里面已经集成前端静态资源
➜ render-server git:(main) node app.js
[2021-01-13 18:44:34:989] - [info] - [18038]: ============= env: dev =============
[2021-01-13 18:44:35:000] - [info] - [18038]: Server listening on port: 8888访问本地的http://127.0.0.1:8888/render-server
打包 make build 可以查看makefile文件
➜ render-server git:(main) ✗ make build
Clean files...
Copy files...
....
➜ render-server git:(main) tree out -L 2 -a
out
├── render-server
│ ├── PLUGIN.md
│ ├── README.md
│ ├── api-test
│ ├── app.js
│ ├── bin
│ ├── common
│ ├── config
│ ├── controller
│ ├── data
│ ├── middleware
│ ├── node_modules
│ ├── package-lock.json
│ ├── package.json
│ ├── plugin
│ ├── pm2.json
│ ├── service
│ └── static
└── render-server_1.0.0.tgz
前端Render-Server-Front
前端项目是基于TS写的，因为是之前写的还没有复合Reat-Starter的一些规范。
Github: https://github.com/rebareba/r...
➜ render-server-front git:(main) ✗ npm start
ℹ ｢wds｣: Project is running at http://localhost:3333/- 开发
npm start - 打包
npm run build
更多可以参考React-Starter
查看原文赞 5 收藏 4 评论 0
rebareba 发布了文章 · 2020-11-29
前端mock完美解决方案实战
写在前面，本文阅读需要一定Nodejs的相关知识，因为会扩展webpack的相关功能，并且实现需要遵守一定约定和Ajax封装。沉淀的脚手架也放到Github上供给同学参考React-Starter， 使用手册还没写完善， 整体思路和React还是Vue无关，如果对大家有收获记得Star下。
它有这些功能：
- 开发打包有不同配置
- eslint 验证
- 代码风格统一
- commit 规范验证
- 接口mock
- 热更新
- 异步组件
Mock功能介绍
市面上讲前端mock怎么做的文章很多，整体上阅读下来的没有一个真正站在前端角度上让我觉得强大和易用的。下面就说下我期望的前端mock要有哪些功能：
- mock功能和前端代码解耦
- 一个接口支持多种mock情况
- 无需依赖另外的后端服务和第三方库
- 能在network看到mock接口的请求且能区分
- mock数据、接口配置和页面在同一个目录下
- mock配置改变无需重启前端dev
- 生产打包可以把mock数据注入到打包的js中走前端mock
- 对于后端已有的接口也能快速把Response数据转化为mock数据
上面的这些功能我讲其中几点的作用：
对于第7点的作用是后续项目开发完成，在完全没有开发后端服务的情况下，也可以进行演示。这对于一些ToB定制的项目来沉淀项目地图（案例）很有作用。
对于第8点在开发环境后端服务经常不稳定下，不依赖后端也能做页面开发，核心是能实现一键生成mock数据。
配置解耦
耦合情况
什么是前端配置解耦，首先让我们看下平时配置耦合情况有哪些：
- webpack-dev后端测试环境变了需要改git跟踪的代码
- dev和build的时候 需要改git跟踪的代码
- 开发的时候想这个接口mock 需要改git跟踪的代码 mockUrl ,mock?
如何解决
前端依赖的配置解耦的思路是配置文件conf.json是在dev或build的时候动态生成的，然后该文件在前端项目引用:
├── config
│ ├── conf.json # git 不跟踪
│ ├── config.js # git 不跟踪
│ ├── config_default.js
│ ├── index.js
│ └── webpack.config.js
├── jsconfig.json
├── mock.json # git 不跟踪webpack配置文件引入js的配置，生成conf.json
// config/index.js
const _ = require("lodash");
let config = _.cloneDeep(require("./config_default"))
try {
const envConfig = require('./config') // eslint-disable-line
config = _.merge(config, envConfig);
} catch (e) {
//
}
module.exports = config;默认使用config_default.js 的内容，如果有config.js 则覆盖，开发的时候复制config_default.js 为config.js 后续相关配置可以修改config.js即可。
// config/config_default.js
const pkg = require("../package.json");
module.exports = {
projectName: pkg.name,
version: pkg.version,
port: 8888,
proxy: {
"/render-server/api/*": {
target: `http://192.168.1.8:8888`,
changeOrigin: true, // 支持跨域请求
secure: true, // 支持 https
},
},
...
conf: {
dev: {
title: "前端模板",
pathPrefix: "/react-starter", // 统一前端路径前缀
apiPrefix: "/api/react-starter", //
debug: true,
delay: 500, // mock数据模拟延迟
mock: {
// "global.login": "success",
// "global.loginInfo": "success",
}
},
build: {
title: "前端模板",
pathPrefix: "/react-starter",
apiPrefix: "/api/react-starter",
debug: false,
mock: {}
}
}
};
在开发或打包的时候根据环境变量使用conf.dev或conf.build 生成conf.json文件内容
// package.json
{
"name": "react-starter",
"version": "1.0.0",
"description": "react前端开发脚手架",
"main": "index.js",
"scripts": {
"start": "webpack-dev-server --config './config/webpack.config.js' --open --mode development",
"build": "cross-env BUILD_ENV=VERSION webpack --config './config/webpack.config.js' --mode production --progress --display-modules && npm run tar",
"build-mock": "node ./scripts/build-mock.js "
},
...
}指定webpack路径是./config/webpack.config.js
然后在webpack.config.js中引入配置并生成conf.json文件
// config/webpack.config.js
const config = require('.')
const env = process.env.BUILD_ENV ? 'build' : 'dev'
const confJson = env === 'build' ? config.conf.build : config.conf.dev
fs.writeFileSync(path.join(__dirname, './conf.json'), JSON.stringify(confGlobal, null, '\t'))引用配置
在src/common/utils.jsx文件中暴露出配置项，配置也可以通过window.conf来覆盖
// src/common/utils.jsx
import conf from '@/config/conf.json'
export const config = Object.assign(conf, window.conf)然后就可以在各个页面中使用
import {config} from '@src/common/utils'
class App extends Component {
render() {
return (
<Router history={history}>
<Switch>
<Route path={`${config.pathPrefix}`} component={Home} />
<Redirect from="/" to={`${config.pathPrefix}`} />
</Switch>
</Router>
)
}
}
ReactDOM.render(
<App />,
document.getElementById('root'),
)Mock实现
效果
为了实现我们想要的mock的相关功能，首先是否开启mock的配置解耦可以通过上面说的方式来实现，我们一般在页面异步请求的时候都会目录定义一个io.js的文件, 里面定义了当前页面需要调用的相关后端接口：
// src/pages/login/login-io.js
import {createIo} from '@src/io'
const apis = {
// 登录
login: {
method: 'POST',
url: '/auth/login',
},
// 登出
logout: {
method: 'POST',
url: '/auth/logout',
},
}
export default createIo(apis, 'login') // 对应login-mock.json上面定义了登录和登出接口，我们希望对应开启的mock请求能使用当前目录下的login-mock.json文件的内容
// src/pages/login/login-mock.json
{
"login": {
"failed": {
"success": false,
"code": "ERROR_PASS_ERROR",
"content": null,
"message": "账号或密码错误!"
},
"success": {
"success": true,
"code": 0,
"content": {
"name": "admin",
"nickname": "超级管理员",
"permission": 15
},
"message": ""
}
},
"logout": {
"success": {
"success": true,
"code": 0,
"content": null,
"message": ""
}
}
}在调用logout登出这个Ajax请求的时候且我们的conf.json中配置的是"login.logout": "success" 就返回login-mock.json中的login.success 的内容，配置没有匹配到就请求转发到后端服务。
// config/conf.json
{
"title": "前端后台模板",
"pathPrefix": "/react-starter",
"apiPrefix": "/api/react-starter",
"debug": true,
"delay": 500,
"mock": {
"login.logout": "success"
}
}这是我们最终要实现的效果，这里有一个约定：项目目录下所有以-mock.jsom文件结尾的文件为mock文件，且文件名不能重复。
思路
在webpack配置项中devServer的proxy配置接口的转发设置，接口转发使用了功能强大的 http-proxy-middleware 软件包， 我们约定proxy的配置格式是：
proxy: {
"/api/react-starter/*": {
target: `http://192.168.90.68:8888`,
changeOrigin: true,
secure: true,
// onError: (),
// onProxyRes,
// onProxyReq
},
},它有几个事件触发的配置：
- option.onError 出现错误
- option.onProxyRes 后端响应后
- option.onProxyReq 请求转发前
- option.onProxyReqWs
- option.onOpen
- option.onClose
所以我们需要定制这几个事情的处理，主要是请求转发前和请求处理后
onProxyReq
想在这里来实现mock的处理， 如果匹配到了mock数据我们就直接响应，就不转发请求到后端。 怎么做呢： 思路是依赖请求头，dev情况下前端在调用的时候能否注入约定好的请求头 告诉我需要寻找哪个mock数据项， 我们约定Header：
mock-key来匹配mock文件如login-mock.json的内容， 如loginmock-method来匹配对应文件内容的方法项 如logout
然后conf.json中mock配置寻找到具体的响应项目如："login.logout": "success/failed"的内容
onProxyRes
如果调用了真实的后端请求，就把请求的响应数据缓存下来，缓存到api-cache目录下文件格式mock-key.mock-method.json
├── api-cache # git 不跟踪
│ ├── login.login.json
│ └── login.logout.json// api-cache/global.logout.json
{
"success": {
"date": "2020-11-17 05:32:17",
"method": "POST",
"path": "/render-server/api/logout",
"url": "/render-server/api/logout",
"resHeader": {
"content-type": "application/json; charset=utf-8",
...
},
"reqHeader": {
"host": "127.0.0.1:8888",
"mock-key": "login",
"mock-method": "logout"
...
},
"query": {},
"reqBody": {},
"resBody": {
"success": true,
"code": 0,
"content": null,
"message": ""
}
}
}这样做的目的是为了后续实现一键生成mock文件。
前端接口封装
使用
上面我们看到定义了接口的io配置：
// src/pages/login/login-io.js
import {createIo} from '@src/io'
const apis = {
// 登录
login: {
method: 'POST',
url: '/auth/login',
},
// 登出
logout: {
method: 'POST',
url: '/auth/logout',
},
}
export default createIo(apis, 'login') // login注册到header的mock-key我们在store中使用
// src/pages/login/login-store.js
import {observable, action, runInAction} from 'mobx'
import io from './login-io'
// import {config, log} from './utils'
export class LoginStore {
// 用户信息
@observable userInfo
// 登陆操作
@action.bound
async login(params) {
const {success, content} = await io.login(params)
if (!success) return
runInAction(() => {
this.userInfo = content
})
}
}
export default LoginStore通过 createIo(apis, 'login') 的封装在调用的时候就可以非常简单的来传递请求参数，简单模式下会判断参数是到body还是到query中。 复杂的也可以支持比如可以header，query, body等这里不演示了。
createIo 请求封装
这个是前端接口封装的关键地方，也是mock请求头注入的地方
// src/io/index.jsx
import {message, Modal} from 'antd'
import {config, log, history} from '@src/common/utils'
import {ERROR_CODE} from '@src/common/constant'
import creatRequest from '@src/common/request'
let mockData = {}
try {
// eslint-disable-next-line global-require, import/no-unresolved
mockData = require('@/mock.json')
} catch (e) {
log(e)
}
let reloginFlag = false
// 创建一个request
export const request = creatRequest({
// 自定义的请求头
headers: {'Content-Type': 'application/json'},
// 配置默认返回数据处理
action: (data) => {
// 统一处理未登录的弹框
if (data.success === false && data.code === ERROR_CODE.UN_LOGIN && !reloginFlag) {
reloginFlag = true
// TODO 这里可能统一跳转到 也可以是弹窗点击跳转
Modal.confirm({
title: '重新登录',
content: '',
onOk: () => {
// location.reload()
history.push(`${config.pathPrefix}/login?redirect=${window.location.pathname}${window.location.search}`)
reloginFlag = false
},
})
}
},
// 是否错误显示message
showError: true,
message,
// 是否以抛出异常的方式 默认false {success: boolean判断}
throwError: false,
// mock 数据请求的等待时间
delay: config.delay,
// 日志打印
log,
})
// 标识是否是简单传参数， 值为true标识复杂封装
export const rejectToData = Symbol('flag')
/**
* 创建请求IO的封装
* @param ioContent {any { url: string method?: string mock?: any apiPrefix?: string}}
}
* @param name mock数据的对应文件去除-mock.json后的
*/
export const createIo = (ioContent, name = '') => {
const content = {}
Object.keys(ioContent).forEach((key) => {
/**
* @param {baseURL?: string, rejectToData?: boolean, params?: {}, query?: {}, timeout?: number, action?(data: any): any, headers?: {}, body?: any, data?: any, mock?: any}
* @returns {message, content, code,success: boolean}
*/
content[key] = async (options = {}) => {
// 这里判断简单请求封装 rejectToData=true 表示复杂封装
if (!options[rejectToData]) {
options = {
data: options,
}
}
delete options[rejectToData]
if (
config.debug === false &&
name &&
config.mock &&
config.mock[`${name}.${key}`] &&
mockData[name] &&
mockData[name][key]
) { // 判断是否是生产打包 mock注入到代码中
ioContent[key].mock = JSON.parse(JSON.stringify(mockData[name][key][config.mock[`${name}.${key}`]]))
} else if (name && config.debug === true) { //注入 mock请求头
if (options.headers) {
options.headers['mock-key'] = name
options.headers['mock-method'] = key
} else {
options.headers = {'mock-key': name, 'mock-method': key}
}
}
const option = {...ioContent[key], ...options}
option.url = ((option.apiPrefix ? option.apiPrefix : config.apiPrefix) || '') + option.url
return request(option)
}
})
return content
}这里对request也做进一步的封装，配置项设置了一些默认的处理设置。比如通用的请求响应失败的是否有一个message， 未登录的情况是否有一个弹窗提示点击跳转登陆页。如果你想定义多个通用处理可以再创建一个request2和createIo2。
request封装axios
是基于axios的二次封装， 并不是非常通用，主要是在约定的请求失败和成功的处理有定制，如果需要可以自己修改使用。
import axios from 'axios'
// 配置接口参数
// declare interface Options {
// url: string
// baseURL?: string
// // 默认GET
// method?: Method
// // 标识是否注入到data参数
// rejectToData?: boolean
// // 是否直接弹出message 默认是
// showError?: boolean
// // 指定 回调操作 默认登录处理
// action?(data: any): any
// headers?: {
// [index: string]: string
// }
// timeout?: number
// // 指定路由参数
// params?: {
// [index: string]: string
// }
// // 指定url参数
// query?: any
// // 指定body 参数
// body?: any
// // 混合处理 Get到url, delete post 到body, 也替换路由参数 在createIo封装
// data?: any
// mock?: any
// }
// ajax 请求的统一封装
// TODO 1. 对jsonp请求的封装 2. 重复请求
/**
* 返回ajax 请求的统一封装
* @param Object option 请求配置
* @param {boolean} opts.showError 是否错误调用message的error方法
* @param {object} opts.message 包含 .error方法 showError true的时候调用
* @param {boolean} opts.throwError 是否出错抛出异常
* @param {function} opts.action 包含 自定义默认处理 比如未登录的处理
* @param {object} opts.headers 请求头默认content-type: application/json
* @param {number} opts.timeout 超时 默认60秒
* @param {number} opts.delay mock请求延迟
* @returns {function} {params, url, headers, query, data, mock} data混合处理 Get到url, delete post 到body, 也替换路由参数 在createIo封装
*/
export default function request(option = {}) {
return async (optionData) => {
const options = {
url: '',
method: 'GET',
showError: option.showError !== false,
timeout: option.timeout || 60 * 1000,
action: option.action,
...optionData,
headers: {'X-Requested-With': 'XMLHttpRequest', ...option.headers, ...optionData.headers},
}
// 简单请求处理
if (options.data) {
if (typeof options.data === 'object') {
Object.keys(options.data).forEach((key) => {
if (key[0] === ':' && options.data) {
options.url = options.url.replace(key, encodeURIComponent(options.data[key]))
delete options.data[key]
}
})
}
if ((options.method || '').toLowerCase() === 'get' || (options.method || '').toLowerCase() === 'head') {
options.query = Object.assign(options.data, options.query)
} else {
options.body = Object.assign(options.data, options.body)
}
}
// 路由参数处理
if (typeof options.params === 'object') {
Object.keys(options.params).forEach((key) => {
if (key[0] === ':' && options.params) {
options.url = options.url.replace(key, encodeURIComponent(options.params[key]))
}
})
}
// query 参数处理
if (options.query) {
const paramsArray = []
Object.keys(options.query).forEach((key) => {
if (options.query[key] !== undefined) {
paramsArray.push(`${key}=${encodeURIComponent(options.query[key])}`)
}
})
if (paramsArray.length > 0 && options.url.search(/\?/) === -1) {
options.url += `?${paramsArray.join('&')}`
} else if (paramsArray.length > 0) {
options.url += `&${paramsArray.join('&')}`
}
}
if (option.log) {
option.log('request options', options.method, options.url)
option.log(options)
}
if (options.headers['Content-Type'] === 'application/json' && options.body && typeof options.body !== 'string') {
options.body = JSON.stringify(options.body)
}
let retData = {success: false}
// mock 处理
if (options.mock) {
retData = await new Promise((resolve) =>
setTimeout(() => {
resolve(options.mock)
}, option.delay || 500),
)
} else {
try {
const opts = {
url: options.url,
baseURL: options.baseURL,
params: options.params,
method: options.method,
headers: options.headers,
data: options.body,
timeout: options.timeout,
}
const {data} = await axios(opts)
retData = data
} catch (err) {
retData.success = false
retData.message = err.message
if (err.response) {
retData.status = err.response.status
retData.content = err.response.data
retData.message = `浏览器请求非正常返回: 状态码 ${retData.status}`
}
}
}
// 自动处理错误消息
if (options.showError && retData.success === false && retData.message && option.message) {
option.message.error(retData.message)
}
// 处理Action
if (options.action) {
options.action(retData)
}
if (option.log && options.mock) {
option.log('request response:', JSON.stringify(retData))
}
if (option.throwError && !retData.success) {
const err = new Error(retData.message)
err.code = retData.code
err.content = retData.content
err.status = retData.status
throw err
}
return retData
}
}一键生成mock
根据api-cache下的接口缓存和定义的xxx-mock.json文件来生成。
# "build-mock": "node ./scripts/build-mock.js"
# 所有：
npm run build-mock mockAll
# 单个mock文件：
npm run build-mock login
# 单个mock接口：
npm run build-mock login.logout
# 复杂
npm run build-mock login.logout user具体代码参考build-mock.js
mock.json文件生成
为了在build打包的时候把mock数据注入到前端代码中去，使得mock.json文件内容尽可能的小，会根据conf.json的配置项来动态生成mock.json的内容，如果build里面没有开启mock项，内容就会是一个空json数据。 当然后端接口代理处理内存中也映射了一份该mock.json的内容。这里需要做几个事情：
- 根据配置动态生成mock.json的内容
- 监听config文件夹 判断关于mock的配置项是否有改变重新生成mock.json
// scripts/webpack-init.js 在wenpack配置文件中初始化
const path = require('path')
const fs = require('fs')
const {syncWalkDir} = require('./util')
let confGlobal = {}
let mockJsonData = {}
exports.getConf = () => confGlobal
exports.getMockJson =() => mockJsonData
/**
* 初始化项目的配置 动态生成mock.json和config/conf.json
* @param {string} env dev|build
*/
exports.init = (env = process.env.BUILD_ENV ? 'build' : 'dev') => {
delete require.cache[require.resolve('../config')]
const config = require('../config')
const confJson = env === 'build' ? config.conf.build : config.conf.dev
confGlobal = confJson
// 1.根据环境变量来生成
fs.writeFileSync(path.join(__dirname, '../config/conf.json'), JSON.stringify(confGlobal, null, '\t'))
buildMock(confJson)
}
// 生成mock文件数据
const buildMock = (conf) => {
// 2.动态生成mock数据 读取src文件夹下面所有以 -mock.json结尾的文件 存储到io/index.json文件当中
let mockJson = {}
const mockFiles = syncWalkDir(path.join(__dirname, '../src'), (file) => /-mock.json$/.test(file))
console.log('build mocks: ->>>>>>>>>>>>>>>>>>>>>>>')
mockFiles.forEach((filePath) => {
const p = path.parse(filePath)
const mockKey = p.name.substr(0, p.name.length - 5)
console.log(mockKey, filePath)
if (mockJson[mockKey]) {
console.error(`有相同的mock文件名称${p.name} 存在`, filePath)
}
delete require.cache[require.resolve(filePath)]
mockJson[mockKey] = require(filePath)
})
// 如果是打包环境， 最小化mock资源数据
const mockMap = conf.mock || {}
const buildMockJson = {}
Object.keys(mockMap).forEach((key) => {
const [name, method] = key.split('.')
if (mockJson[name][method] && mockJson[name][method][mockMap[key]]) {
if (!buildMockJson[name]) buildMockJson[name] = {}
if (!buildMockJson[name][method]) buildMockJson[name][method] = {}
buildMockJson[name][method][mockMap[key]] = mockJson[name][method][mockMap[key]]
}
})
mockJsonData = buildMockJson
fs.writeFileSync(path.join(__dirname, '../mock.json'), JSON.stringify(buildMockJson, null, '\t'))
}
// 监听配置文件目录下的config.js和config_default.js
const confPath = path.join(__dirname, '../config')
if ((env = process.env.BUILD_ENV ? 'build' : 'dev') === 'dev') {
fs.watch(confPath, async (event, filename) => {
if (filename === 'config.js' || filename === 'config_default.js') {
delete require.cache[path.join(confPath, filename)]
delete require.cache[require.resolve('../config')]
const config = require('../config')
// console.log('config', JSON.stringify(config))
const env = process.env.BUILD_ENV ? 'build' : 'dev'
const confJson = env === 'build' ? config.conf.build : config.conf.dev
if (JSON.stringify(confJson) !== JSON.stringify(confGlobal)) {
this.init()
}
}
});
}接口代理处理
onProxyReq和onProxyRes
实现上面思路里面说的onProxyReq和onProxyRes 响应处理
// scripts/api-proxy-cache
const fs = require('fs')
const path = require('path')
const moment = require('moment')
const {getConf, getMockJson} = require('./webpack-init')
const API_CACHE_DIR = path.join(__dirname, '../api-cache')
const {jsonParse, getBody} = require('./util')
fs.mkdirSync(API_CACHE_DIR,{recursive: true})
module.exports = {
// 代理前处理
onProxyReq: async (_, req, res) => {
req.reqBody = await getBody(req)
const {'mock-method': mockMethod, 'mock-key': mockKey} = req.headers
// eslint-disable-next-line no-console
console.log(`Ajax 请求: ${mockKey}.${mockMethod}`,req.method, req.url)
// eslint-disable-next-line no-console
req.reqBody && console.log(JSON.stringify(req.reqBody, null, '\t'))
if (mockKey && mockMethod) {
req.mockKey = mockKey
req.mockMethod = mockMethod
const conf = getConf()
const mockJson = getMockJson()
if (conf.mock && conf.mock[`${mockKey}.${mockMethod}`] && mockJson[mockKey] && mockJson[mockKey][mockMethod]) {
// eslint-disable-next-line no-console
console.log(`use mock data ${mockKey}.${mockMethod}:`, conf.mock[`${mockKey}.${mockMethod}`], 'color: green')
res.mock = true
res.append('isMock','yes')
res.send(mockJson[mockKey][mockMethod][conf.mock[`${mockKey}.${mockMethod}`]])
}
}
},
// 响应缓存接口
onProxyRes: async (res, req) => {
const {method, url, query, path: reqPath, mockKey, mockMethod} = req
if (mockKey && mockMethod && res.statusCode === 200) {
let resBody = await getBody(res)
resBody = jsonParse(resBody)
const filePath = path.join(API_CACHE_DIR, `${mockKey}.${mockMethod}.json`)
let data = {}
if (fs.existsSync(filePath)) {
data = jsonParse(fs.readFileSync(filePath).toString())
}
const cacheObj = {
date: moment().format('YYYY-MM-DD hh:mm:ss'),
method,
path: reqPath,
url,
resHeader: res.headers,
reqHeader: req.headers,
query,
reqBody: await jsonParse(req.reqBody),
resBody: resBody
}
if (resBody.success === false) {
data.failed = cacheObj
} else {
data.success = cacheObj
}
// eslint-disable-next-line no-console
fs.writeFile(filePath, JSON.stringify(data,'', '\t'), (err) => { err && console.log('writeFile', err)})
}
},
// 后端服务没启的异常处理
onError(err, req, res) {
setTimeout(() => {
if (!res.mock) {
res.writeHead(500, {
'Content-Type': 'text/plain',
});
res.end('Something went wrong. And we are reporting a custom error message.');
}
}, 10)
}
}webpack配置
在webpack配置中引入使用
const config = require('.')
// config/webpack.config.js
const {init} = require('../scripts/webpack-init');
init();
// 接口请求本地缓存
const apiProxyCache = require('../scripts/api-proxy-cache')
for(let key in config.proxy) {
config.proxy[key] = Object.assign(config.proxy[key], apiProxyCache);
}
const webpackConf = {
devServer: {
contentBase: path.join(__dirname, '..'), // 本地服务器所加载的页面所在的目录
inline: true,
port: config.port,
publicPath: '/',
historyApiFallback: {
disableDotRule: true,
// 指明哪些路径映射到哪个html
rewrites: config.rewrites,
},
host: '127.0.0.1',
hot: true,
proxy: config.proxy,
},
}
总结
mock做好其实在我们前端实际中还是很有必要的，做过的项目如果后端被铲除了想要回忆就可以使用mock让项目跑起来，可以寻找一些实现的效果来进行代码复用。当前介绍的mock流程实现有很多定制的开发，但是真正完成后，团队中的成员只是使用还是比较简单配置即可。
关于前端项目部署我也分享了一个BFF 层，当前做的还不是很完善，也分享给大家参考
Render-Server 主要功能包含：
- 一键部署 npm run deploy
- 支持集群部署配置
- 是一个文件服务
- 是一个静态资源服务
- 在线可视化部署前端项目
- 配置热更新
- 在线Postman及接口文档
- 支持前端路由渲染， 支持模板
- 接口代理及路径替换
- Web安全支持 Ajax请求验证，Referer 校验
- 支持插件开发和在线配置 可实现： 前端模板参数注入、请求头注入、IP白名单、接口mock、会话、第三方登陆等等
赞 19 收藏 14 评论 6
rebareba 收藏了文章 · 2019-10-22
详细判断浏览器运行环境
作者：JowayYoung
仓库：Github、CodePen
博客：掘金、思否、知乎、简书、头条、CSDN
公众号：IQ前端
联系我：关注公众号后有我的微信哟
特别声明：原创不易，未经授权不得对此文章进行转载或抄袭，否则按侵权处理，如需转载或开通公众号白名单可联系我，希望各位尊重原创的知识产权
前言
看到标题，大家就能想起这个需求在很多项目上都能用到。我们部署在Web服务器上的前端应用，既可以用PC浏览器访问，也可以用手机浏览器访问，再加上现在智能设备的推广，我们甚至能在车载系统、穿戴设备和电视平台上访问。
设备的多样化让用户无处不在，有时候我们需要根据不同的浏览器运行环境做出对应的处理。浏览器是JavaScript的承载体，我们可以从浏览器上获取相关的信息，来进一步处理我们的业务逻辑。
然而浏览器品牌众多，有些浏览器使用的标准也不太一样，造就了难以统一的判断。下面我大概罗列一下常用的浏览器品牌和在什么情况下使用浏览器运行环境判断。浏览器相关统计数据可以参考这里。
国际五大浏览器品牌：按照全球使用率降序排列
- Google Chrome：
Windows、MacOS、Linux、Android、iOS - Apple Safari：
MacOS、iOS - Mozilla Firefox：
Windows、MacOS、Linux、Android、iOS - ASA Opera：
Windows、MacOS、Linux、Android、iOS - Microsoft Internet Explorer或Microsoft Edge：
Windows
国产常用浏览器品牌：按照国内使用率降序排列，普遍基于开源项目Chromium进行开发- 微信浏览器
- QQ浏览器
- UC浏览器
- 360浏览器
- 2345浏览器
- 搜狗浏览器
- 猎豹浏览器
- 遨游浏览器
- 其他浏览器：很多很多，数不清，我就不列出来了
顺便吐槽一下这个不要脸的红芯浏览器，明明就是基于Chromium进行二次开发再套多一层外壳，还非得说自己开发的浏览器是世界第五大浏览器，偷吃不抹嘴，还是被眼尖的网友发现了。详情请戳one、two、three。。。。
使用场景
- 判断用户浏览器是桌面端还是移动端，显示对应的主题样式
- 判断用户浏览器是Android端还是iOS端，跳转到对应的App下载链接
- 判断用户浏览器是微信端还是H5端，调用微信分享或当前浏览器分享
- 获取用户浏览器的内核和载体，用于统计用户设备平台分布区间
- 获取用户浏览器的载体版本，用于提示更新信息
- 其实还有很多使用场景，就不一一举例了
原理
针对处理一个这样的使用场景，其实有一个比较专业的名字，叫做浏览器指纹。我们上面谈到的需求也只是浏览器指纹方案里面的一小部分，而我们需要使用到的浏览器指纹就是UserAgent。
这个UserAgent是何方神圣呢，中文翻译过来就是用户代理。引用百度的定义，就是一个特殊字符串头，使得服务器能够识别客户使用的操作系统及版本、CPU类型、浏览器载体及版本、浏览器渲染引擎、浏览器语言、浏览器插件等。而这些信息也足够我们去判断浏览器运行环境了。
准备
目前网上很多解决方法都只是针对系统是否是桌面端还是移动端，Android端还是iOS端，部分浏览器载体的判断和获取等等，没有一个比较完美或者终极的解决方案。
因此我用了很多测试平台整理出一个比较全面的解决方案。这个方案包含浏览器系统及版本、浏览器平台、浏览器内核及版本、浏览器载体及版本、浏览器外壳及版本。
而此方案也是基于navigator.userAgent获取相关浏览器信息(如下)，再通过系统、平台、内核、载体、外壳的特有字段进行归类统一，整理出一个完整的浏览器运行环境。
const ua = navigator.userAgent.toLowerCase();
// 输出
"mozilla/5.0 (iphone; cpu iphone os 11_0 like mac os x) applewebkit/604.1.38 (khtml, like gecko) version/11.0 mobile/15a372 safari/604.1"浏览器信息：权重按照以下降序排列
- 浏览器系统：所运行的操作系统，包含
Windows、MacOS、Linux、Android、iOS - 浏览器平台：所运行的设备平台，包含
Desktop桌面端、Mobile移动端 - 浏览器内核：浏览器渲染引擎，包含
Webkit、Gecko、Presto、Trident - 浏览器载体：五大浏览器品牌，包含
Chrome、Safari、Firefox、Opera、IExplore/Edge - 浏览器外壳：基于五大浏览器品牌的内核进行开发，再套一层自研技术的外壳，如国内众多浏览器品牌
获取UserAgent是否包含字段：判断是否包含系统、平台、内核、载体、外壳的特有字段
const testUa = regexp => regexp.test(ua);获取UserAgent对应字段的版本
const testVs = regexp => ua.match(regexp).toString().replace(/[^0-9|_.]/g, "").replace(/_/g, ".");方案
上述准备工作完成后，我们就按照权重(系统 + 系统版本 > 平台 > 内核 + 载体 + 内核版本 + 载体版本 > 外壳 + 外壳版本)根据系统、平台、内核、载体、外壳的特有字段来归类统一浏览器运行环境。
系统+系统版本
// 系统
let system = "unknow";
if (testUa(/windows|win32|win64|wow32|wow64/g)) {
system = "windows"; // windows系统
} else if (testUa(/macintosh|macintel/g)) {
system = "macos"; // macos系统
} else if (testUa(/x11/g)) {
system = "linux"; // linux系统
} else if (testUa(/android|adr/g)) {
system = "android"; // android系统
} else if (testUa(/ios|iphone|ipad|ipod|iwatch/g)) {
system = "ios"; // ios系统
}
// 系统版本
let systemVs = "unknow";
if (system === "windows") {
if (testUa(/windows nt 5.0|windows 2000/g)) {
systemVs = "2000";
} else if (testUa(/windows nt 5.1|windows xp/g)) {
systemVs = "xp";
} else if (testUa(/windows nt 5.2|windows 2003/g)) {
systemVs = "2003";
} else if (testUa(/windows nt 6.0|windows vista/g)) {
systemVs = "vista";
} else if (testUa(/windows nt 6.1|windows 7/g)) {
systemVs = "7";
} else if (testUa(/windows nt 6.2|windows 8/g)) {
systemVs = "8";
} else if (testUa(/windows nt 6.3|windows 8.1/g)) {
systemVs = "8.1";
} else if (testUa(/windows nt 10.0|windows 10/g)) {
systemVs = "10";
}
} else if (system === "macos") {
systemVs = testVs(/os x [\d._]+/g);
} else if (system === "android") {
systemVs = testVs(/android [\d._]+/g);
} else if (system === "ios") {
systemVs = testVs(/os [\d._]+/g);
}平台
let platform = "unknow";
if (system === "windows" || system === "macos" || system === "linux") {
platform = "desktop"; // 桌面端
} else if (system === "android" || system === "ios" || testUa(/mobile/g)) {
platform = "mobile"; // 移动端
}内核+载体
let engine = "unknow";
let supporter = "unknow";
if (testUa(/applewebkit/g)) {
engine = "webkit"; // webkit内核
if (testUa(/edge/g)) {
supporter = "edge"; // edge浏览器
} else if (testUa(/opr/g)) {
supporter = "opera"; // opera浏览器
} else if (testUa(/chrome/g)) {
supporter = "chrome"; // chrome浏览器
} else if (testUa(/safari/g)) {
supporter = "safari"; // safari浏览器
}
} else if (testUa(/gecko/g) && testUa(/firefox/g)) {
engine = "gecko"; // gecko内核
supporter = "firefox"; // firefox浏览器
} else if (testUa(/presto/g)) {
engine = "presto"; // presto内核
supporter = "opera"; // opera浏览器
} else if (testUa(/trident|compatible|msie/g)) {
engine = "trident"; // trident内核
supporter = "iexplore"; // iexplore浏览器
}内核版本+载体版本
// 内核版本
let engineVs = "unknow";
if (engine === "webkit") {
engineVs = testVs(/applewebkit\/[\d._]+/g);
} else if (engine === "gecko") {
engineVs = testVs(/gecko\/[\d._]+/g);
} else if (engine === "presto") {
engineVs = testVs(/presto\/[\d._]+/g);
} else if (engine === "trident") {
engineVs = testVs(/trident\/[\d._]+/g);
}
// 载体版本
let supporterVs = "unknow";
if (supporter === "chrome") {
supporterVs = testVs(/chrome\/[\d._]+/g);
} else if (supporter === "safari") {
supporterVs = testVs(/version\/[\d._]+/g);
} else if (supporter === "firefox") {
supporterVs = testVs(/firefox\/[\d._]+/g);
} else if (supporter === "opera") {
supporterVs = testVs(/opr\/[\d._]+/g);
} else if (supporter === "iexplore") {
supporterVs = testVs(/(msie [\d._]+)|(rv:[\d._]+)/g);
} else if (supporter === "edge") {
supporterVs = testVs(/edge\/[\d._]+/g);
}外壳+外壳版本
let shell = "none";
let shellVs = "unknow";
if (testUa(/micromessenger/g)) {
shell = "wechat"; // 微信浏览器
shellVs = testVs(/micromessenger\/[\d._]+/g);
} else if (testUa(/qqbrowser/g)) {
shell = "qq"; // QQ浏览器
shellVs = testVs(/qqbrowser\/[\d._]+/g);
} else if (testUa(/ucbrowser/g)) {
shell = "uc"; // UC浏览器
shellVs = testVs(/ucbrowser\/[\d._]+/g);
} else if (testUa(/qihu 360se/g)) {
shell = "360"; // 360浏览器(无版本)
} else if (testUa(/2345explorer/g)) {
shell = "2345"; // 2345浏览器
shellVs = testVs(/2345explorer\/[\d._]+/g);
} else if (testUa(/metasr/g)) {
shell = "sougou"; // 搜狗浏览器(无版本)
} else if (testUa(/lbbrowser/g)) {
shell = "liebao"; // 猎豹浏览器(无版本)
} else if (testUa(/maxthon/g)) {
shell = "maxthon"; // 遨游浏览器
shellVs = testVs(/maxthon\/[\d._]+/g);
}终极合体
根据以上的条件判断获得的变量如下，我们可以把它们合并成一个对象输出。这样就可以输出一个清晰的浏览器运行环境，后面想干嘛就干嘛了，多方便。
本文重点探究方案的可行性，没有过多考虑到代码的优化，所以条件判断使用得有些多，如果有什么方法能优化下代码，减少条件判断，可以在下方评论提个建议哟。
- system：系统
- systemVs：系统版本
- platform：平台
- engine：内核
- engineVs：内核版本
- supporter：载体
- supporterVs：载体版本
- shell：外壳
- shellVs：外壳版本
function BrowserType() {
const ua = navigator.userAgent.toLowerCase();
const testUa = regexp => regexp.test(ua);
const testVs = regexp => ua.match(regexp).toString().replace(/[^0-9|_.]/g, "").replace(/_/g, ".");
// 接上以上if...else条件判断
// ......
// 获取到system、systemVs、platform、engine、engineVs、supporter、supporterVs、shell、shellVs
return Object.assign({
engine, // webkit gecko presto trident
engineVs,
platform, // desktop mobile
supporter, // chrome safari firefox opera iexplore edge
supporterVs,
system, // windows macos linux android ios
systemVs
}, shell === "none" ? {} : {
shell, // wechat qq uc 360 2345 sougou liebao maxthon
shellVs
});
}在控制台执行BrowserType()，该有的都出来了，哈哈！源码详情请戳这里，喜欢的可以点个赞支持下，谢谢。
结语
❤️关注+点赞+收藏+评论+转发❤️，原创不易，鼓励笔者创作更好的文章
关注公众号IQ前端，一个专注于CSS/JS开发技巧的前端公众号，更多前端小干货等着你喔
- 关注后回复
关键词免费领取视频教程 - 关注后添加
我微信拉你进技术交流群 - 欢迎关注
IQ前端，更多CSS/JS开发技巧只在公众号推送
rebareba 收藏了文章 · 2019-10-22
Kubernetes+Docker+Istio 容器云实践
随着社会的进步与技术的发展，人们对资源的高效利用有了更为迫切的需求。近年来，互联网、移动互联网的高速发展与成熟，大应用的微服务化也引起了企业的热情关注，而基于Kubernetes+Docker的容器云方案也随之进入了大众的视野。开普勒云是一个基于Kubernetes+Docker+Istio的微服务治理解决方案。
一、Microservices
1.1 解决大应用微服务化后的问题
现在各大企业都在谈论微服务，在微服务的大趋势之下技术圈里逢人必谈微服务，及微服务化后的各种解决方案。
1.2 当我们在讨论微服务的时候我们在讨论什么？
使用微服务架构有很多充分的理由，但天下没有免费的午餐，微服务虽有诸多优势，同时也增加了复杂性。团队应该积极应对这种复杂性，前提是应用能够受益于微服务。
1.2.1 如何微服务化的问题
- 微服务要如何拆分
- 业务API规则
- 数据一致性保证
- 后期可扩展性考虑
当然这不是本文主要讨论的问题，我不讲微服务具体要如何拆分，每个企业每个应用的情况都不太一样，适合自己的方案就是最好的拆分方案。我们主要来解决微服务化后所带来的一些问题。
1.2.2 微服务化后带来的问题
- 环境一致性
- 如何对资源快速分配
- 如何快速度部署
- 怎么做基本监控
- 服务注册与发现
- 负载均衡如何做
以上都是大应用微服务化所需要解决的基础问题，如果还按照传统的方式使用虚拟机来实现，资源开支将会非常大。那么这些问题要怎么解决呢？比如:
- 流量管理
- 服务降级
- 认证、授权
当然面对上述这些问题我们广大的猿友们肯定是有解决方案的。
1.3 Service governance
1.3.1 Java 体系
假设我们是Java体系的应用，那解决起来就很方便了，比如我们可以考虑使用SpringCloud全家桶系列。也可以拆分使用:
- Eureka
- Hystrix
- Zuul
- Spring-cloud
- Spring-boot
- ZipKin
Java体系下能很方便的做以我们微服务化后的基础部分，但依然不能非常舒服地解决环境一致性，并且如果有其他语系的服务将很难融入进去。
我们来看基础编程语言一般有什么组合方式来解决基础问题。
1.3.2 其他体系
- Consul
- Kong
- Go-kit
- Jaeger/Zipkin
假设我们是使用Golang语言，这里再捧一下Golang语言。go语言简直就是天生为微服务而生的语言，实在不要太方便了。高效的开发速度及相当不错的性能，简单精悍。
跑题了~我们使用上面这些工具也可以组成一套还不错的微服务架构。
- Consul: 当作服务发现及配置中心来使
- Kong: 作为服务网关
- Jaeger: 作为链路追踪来使
- Go-kit: 开发组件
但是这种方案也有问题，对服务的侵入性太强了，每个服务都需要嵌入大量代码，这还是很头疼的。
二、Docker & Kubernetes
基于Docker+k8s搭建平台的实践方案。
2.1 Docker
Docker 是一个非常强大的容器。
- 资源利用率的提升
- 环境一致性、可移植性
- 快速度扩容伸缩
- 版本控制
使用了Docker之后，我们发现可玩的东西变多了，更加灵活了。不仅仅是资源利用率提升、环境一致性得到了保证，版本控制也变得更加方便了。
以前我们使用Jenkins进行构建，需要回滚时，又需要重新走一次jenkins Build过程，非常麻烦。如果是Java应用，它的构建时间将会变得非常长。
使用了Docker之后，这一切都变得简单了，只需要把某个版本的镜像拉下来启动就完事了(如果本地有缓存直接启动某个版本就行了)，这个提升是非常高效的。
(图片来源网络)
既然使用了Docker容器作为服务的基础，那我们肯定需要对容器进行编排，如果没有编排那将是非常可怕的。而对于Docker容器的编排，我们有多种选择：Docker Swarm、Apache Mesos、Kubernetes，在这些编排工具之中，我们选择了服务编排王者Kubernetes。
2.1.1 Docker VS VM
- VM: 创建虚拟机需要1分钟，部署环境3分钟，部署代码2分钟。
- Docker: 启动容器30秒内。
2.2 Why choose Kubernetes
我们来对比这三个容器编排工具。
2.2.1 Apache Mesos
Mesos的目的是建立一个高效可扩展的系统，并且这个系统能够支持各种各样的框架，不管是现在的还是未来的框架，它都能支持。这也是现今一个比较大的问题：类似Hadoop和MPI这些框架都是独立开的，这导致想要在框架之间做一些细粒度的分享是不可能的。
但它的基础语言不是Golang，不在我们的技术栈里，我们对它的维护成本将会增高，所以我们首先排除了它。
2.2.2 Docker Swarm
Docker Swarm是一个由Docker开发的调度框架。由Docker自身开发的好处之一就是标准Docker API的使用。Swarm的架构由两部分组成：
(图片来源网络)
它的使用，这里不再具体进行介绍。
2.2.3 Kubernetes
Kubernetes是一个Docker容器的编排系统，它使用label和pod的概念来将容器换分为逻辑单元。Pods是同地协作（co-located）容器的集合，这些容器被共同部署和调度，形成了一个服务，这是Kubernetes和其他两个框架的主要区别。相比于基于相似度的容器调度方式（就像Swarm和Mesos），这个方法简化了对集群的管理.
不仅如此，它还提供了非常丰富的API，方便我们对它进行操作，及玩出更多花样。其实还有一大重点就是符合我们的Golang技术栈，并且有大厂支持。
Kubernetes 的具体使用这里也不再过多介绍，网站上有大把资料可以参考。
2.3 Kubernetes in kubernetes
kubernetes（k8s）是自动化容器操作的开源平台，这些操作包括部署、调度和节点集群间扩展。
- 自动化容器的部署和复制
- 随时扩展或收缩容器规模
- 将容器组织成组，并且提供容器间的负载均衡
- 很容易地升级应用程序容器的新版本
- 提供容器弹性，如果容器失效就替换它，等等...
2.4 Kubernetes is not enough either
到这里我们解决了以下问题:
- Docker: 环境一致性、快速度部署。
- Kubernetes: 服务注册与发现、负载均衡、对资源快速分配。
当然还有监控，这个我们后面再说。我们先来看要解决一些更高层次的问题该怎么办呢？
在不对服务进行侵入性的代码修改的情况下，服务认证、链路追踪、日志管理、断路器、流量管理、错误注入等等问题要怎么解决呢？
这两年非常流行一种解决方案：Service Mesh。
三、Service Mesh
处理服务间通信的基础设施层，用于在云原生应用复杂的服务拓扑中实现可靠的请求传递。
- 用来处理服务间通讯的专用基础设施层，通过复杂的拓扑结构让请求传递的过程变得更可靠。
- 作为一组轻量级高性能网络代理，和程序部署在一起，应用程序不需要知道它的存在。
在云原生应用中可靠地传递请求可能非常复杂，通过一系列强大技术来管理这种复杂性: 链路熔断、延迟感知、负载均衡，服务发现、服务续约及下线与剔除。
市面上的ServiceMesh框架有很多，我们选择了站在风口的Istio。
3.1 Istio
连接、管理和保护微服务的开放平台。
- 平台支持: Kubernetes, Mesos, Cloud Foundry。
- 可观察性:Metrics, logs, traces, dependency 。visualisation。
- Service Identity & Security: 为服务、服务到服务的身份验证提供可验证的标识。
- Traffic 管理: 动态控制服务之间的通信、入口/出口路由、故障注入。
- Policy 执行: 前提检查，服务之间的配额管理。
3.2 我们为什么选择Istio？
因为有大厂支持~其实主要还是它的理念是相当好的。
虽然它才到1.0版本，我们是从 0.6 版本开始尝试体验，测试环境跑，然后0.7.1版本出了，我们升级到0.7.1版本跑，后来0.8.0LTS出了，我们开始正式使用0.8.0版本，并且做了一套升级方案。
目前最新版已经到了1.0.4, 但我们并不准备升级，我想等到它升级到1.2之后，再开始正式大规模应用。0.8.0LTS在现在来看小规模还是可以的。
3.3 Istio 架构
我们先来看一下Istio的架构。
其中Istio控制面板主要分为三大块，Pilot、Mixer、Istio-Auth。
- Pilot: 主要作为服务发现和路由规则，并且管理着所有Envoy，它对资源的消耗是非常大的。
- Mixer: 主要负责策略请求和配额管理，还有Tracing，所有的请求都会上报到Mixer。
- Istio-Auth: 升级流量、身份验证等等功能，目前我们暂时没有启用此功能，需求并不是特别大，因为集群本身就是对外部隔离的。
每个Pod都会被注入一个Sidecar，容器里的流量通过iptables全部转到Envoy进行处理。
四、Kubernetes & Istio
Istio可以独立部署，但显然它与Kuberntes结合是更好的选择。基于Kubernetes的小规模架构。有人担心它的性能，其实经过生产测试，上万的QPS是完全没有问题的。
4.1 Kubernetes Cluster
在资源紧缺的情况下，我们的k8s集群是怎么样的？
4.1.1 Master集群
Master Cluster:
- ETCD、Kube-apiserver、kubelet、Docker、kube-proxy、kube-scheduler、kube-controller-manager、Calico、 keepalived、 IPVS。
4.1.2 Node节点
Node:
- Kubelet、 kube-proxy 、Docker、Calico、IPVS。
(图片来源网络)
我们所调用的Master的API都是通过 keepalived 进行管理，某一master发生故障，能保证顺滑的飘到其他master的API，不影响整个集群的运行。
当然我们还配置了两个边缘节点。
4.1.3 Edge Node
- 边缘节点
- 流量入口
边缘节点的主要功能是让集群提供对外暴露服务能力的节点，所以它也不需要稳定，我们的IngressGateway 就是部署在这两个边缘节点上面，并且通过Keeplived进行管理。
4.2 外部服务请求流程
最外层是DNS，通过泛解析到Nginx，Nginx将流量转到集群的VIP，VIP再到集群的HAproxy，将外部流量发到我们的边缘节点Gateway。
每个VirtualService都会绑定到Gateway上，通过VirtualService可以进行服务的负载、限流、故障处理、路由规则及金丝雀部署。再通过Service最终到服务所在的Pods上。
这是在没有进行Mixer跟策略检测的情况下的过程，只使用了Istio-IngressGateway。如果使用全部Istio组件将有所变化，但主流程还是这样的。
4.3 Logging
日志收集我们采用的是低耦合、扩展性强、方便维护和升级的方案。
- 节点Filebeat收集宿主机日志。
- 每个Pods注入Filebeat容器收集业务日志。
Filebeat会跟应用容器部署在一起，应用也不需要知道它的存在，只需要指定日志输入的目录就可以了。Filebeat所使用的配置是从ConfigMap读取，只需要维护好收集日志的规则。
上图是我们可以从Kibana上看到所采集到的日志。
4.4 Prometheus + Kubernetes
- 基于时间序列的监控系统。
- 与kubernetes无缝集成基础设施和应用等级。
- 具有强大功能的键值数据模型。
- 大厂支持。
4.4.1 Grafana
4.4.2 Alarm
目前我们支持的报警有Wechat、kplcloud、Email、IM。所有报警都可在平台上配置发送到各个地方。
4.4.3 整体架构
整个架构由外围服务及集群内的基础服务组成，外围服务有:
- Consul作为配置中心来使用。
- Prometheus+Grafana用来监控K8s集群。
- Zipkin提供自己定义的链路追踪。
- ELK日志收集、分析，我们集群内的所有日志会推送到这里。
- Gitlab代码仓库。
- Jenkins用来构建代码及打包成Docker镜像并且上传到仓库。
- Repository 镜像仓库。
集群有:
- HAProxy+keeprlived 负责流量转发。
- 网络是Calico, Calico对kube-proxy的ipvs代理模式有beta级支持。如果Calico检测到kube-proxy正在该模式下运行，则会自动激活Calico ipvs支持，所以我们启用了IPVS。
- 集群内部的DNS是 CoreDNS。
- 我们部署了两个网关，主要使用的是Istio的 IngressGateway，TraefikIngress备用。一旦IngressGateway挂了我们可以快速切换到TraefikIngress。
- 上面是Istio的相关组件。
- 最后是我们的APP服务。
- 集群通过Filebeat收集日志发到外部的ES。
集群内部的监控有：
- State-Metrics 主要用来自动伸缩的监控组件
- Mail&Wechat 自研的报警服务
- Prometheus+Grafana+AlertManager 集群内部的监控，主要监控服务及相关基础组件
- InfluxDB+Heapster 流数据库存储着所有服务的监控信息
4.5 有了Kubernetes那怎么部署应用呢？
4.5.1 研发打包成镜像、传仓库、管理版本
- 学习Docker。
- 学习配置仓库、手动打包上传麻烦。
- 学习k8s相关知识。
4.5.2 用Jenkins来负责打包、传镜像、更新版本
- 运维工作增加了不少，应用需要进行配置、服务需要做变更都得找运维。
- 需要管理一堆的YAML文件。
有没有一种傻瓜式的，不需要学习太多的技术，可以方便使用的解决方案？
五、Kplcloud platform
5.1 开普勒云平台
开普勒云平台是一个轻量级的PaaS平台。
- 为微服务化的项目提供一个可控的管理平台。
- 实现每个服务独立部署、维护、扩展。
- 简化流程，不再需要繁琐的申请流程，最大限度的自动化处理。
- 实现微服务的快速发布、独立监控、配置。
- 实现对微服务项目的零侵入式的服务发现、服务网关、链路追踪等功能。
- 提供配置中心，统一管理配置。
- 研发、产品、测试、运维甚至是老板都可以自己发布应用。
5.2 在开普勒平台部署服务
为了降低学习成本及部署难度，在开普勒平台上部署应用很简单，只需要增加一个Dockerfile 就好了。
Dockerfile 参考：
以上是普通模式，Jenkins代码Build及Docker build。
这是一种相对自由的部署方式，可以根据自己的需求进行定制，当然有学习成本。
5.2.1 为什么不自动生成Dockerfile呢？
其实完全可以做到自动生成Dockerfile，但每个服务的要求可能不一样，有些需要增加文件、有些在Build时需要增加参数等等。我们不能要求所有的项目都是一样的，这会阻碍技术的发展。所以退而求其次，我们给出模版，研发根据自己的需求调整。
5.3 工具整合
- 开普勒云平台整合了 gitlab，Jenkins，repo，k8s，istio，promtheus，email，WeChat 等API。
- 实现对服务的整个生命周期的管理。
- 提供服务管理、创建、发布、版本、监控、报警、日志已及一些周边附加功能，消息中心、配置中心、还能登陆到容器，服务下线等等。
- 可对服务进行一健调整服务模式、服务类型、一键扩容伸缩，回滚服务API管理以及存储的管理等操作。
5.4 发布流程
用户把自己的Dockerfile跟代码提交到Gitlab，然后在开普勒云平台填写一些参数创建自己的应用。
应用创建完后会在Jenkins创建一个Job，把代码拉取下来并执行Docker build（如果没有选择多阶构建会先执行go build或mvn），再把打包好的Docker image推送到镜像仓库，最后回调平台API或调用k8s通知拉取最新的版本。
用户只需要在开普勒云平台上管理好自己的应用就可以，其他的全部自动化处理。
5.5 从创建一个服务开始
我们从创建一个服务开始介绍平台。
平台主界面:
点击“创建服务”后进入创建页面。
填写基本信息:
填写详细信息:
基本信息以Golang为例，当选择其他语言时所需填写的参数会略有不同。
如果选择了对外提供服务的话，会进入第三步，第三步是填写路由规则，如没有特殊需求直接默认提交就行了。
5.5.1 服务详情
Build 升级应用版本:
调用服务模式，可以在普通跟服务网格之间调整。
服务是否提供对外服务的能力:
扩容调整CPU、内存：
调整启动的Pod数量：
网页版本的终端：
5.5.2 定时任务
5.5.3 持久化存储
管理员创建StorageClass跟PersistentVolumeClaim，用户只需要在自己服务选择相关的PVC进行绑写就行了。
存储使用的是NFS。
5.5.4 Tracing
5.5.5 Consul
Consul当作配置中心来使用，并且我们提供Golang的客户端。
$ go get github.com/lattecake/consul-kv-client它会自动同步consul的目录配置存在内存，获取配置只需要直接从内存拿就行了。
5.5.6 Repository
- Github: https://github.com/kplcloud/kplcloud
- Document: https://docs.nsini.com
- Demo: https://kplcloud.nsini.com
作者：王聪查看原文首发：宜技之长
rebareba 收藏了文章 · 2018-09-13
fetch使用的常见问题及其解决办法
首先声明一下，本文不是要讲解fetch的具体用法，不清楚的可以参考MDN fetch教程。
引言
说道fetch就不得不提XMLHttpRequest了，XHR在发送web请求时需要开发者配置相关请求信息和成功后的回调，尽管开发者只关心请求成功后的业务处理，但是也要配置其他繁琐内容，导致配置和调用比较混乱，也不符合关注分离的原则；fetch的出现正是为了解决XHR存在的这些问题。例如下面代码：
fetch(url).then(function(response) {
return response.json();
}).then(function(data) {
console.log(data);
}).catch(function(e) {
console.log("Oops, error");
});上面这段代码让开发者只关注请求成功后的业务逻辑处理，其他的不用关心，相当简单；也比较符合现代Promise形式，比较友好。
fetch是基于Promise设计的，从上面代码也能看得出来，这就要求fetch要配合Promise一起使用。正是这种设计，fetch所带来的优点正如传统 Ajax 已死，Fetch 永生总结的一样：
语法简单，更加语义化
基于标准的Promise实现，支持async/await
使用
isomorphic-fetch可以方便同构
不过话说回来，fetch虽然有很多优点，但是使用fetch来进行项目开发时，也是有一些常见问题的，下面就来说说fetch使用的常见问题。
fetch兼容性
fetch是相对较新的技术，当然就会存在浏览器兼容性的问题，借用上面应用文章的一幅图加以说明fetch在各种浏览器的原生支持情况：
从上图可以看出，在各个浏览器低版本的情况下都是不被支持的。
那么问题来了，如何在所有浏览器中通用fetch呢，当然就要考虑fetch的polyfill了。
上面说过，fetch是基于Promise来实现的，所以在低版本浏览器中Promise可能也未被原生支持，所以还需要Promise的polyfill；大多数情况下，实现fetch的polyfill需要涉及到的：
promise的polyfill，例如es6-promise、babel-polyfill提供的promise实现。
fetch的polyfill实现，例如isomorphic-fetch和whatwg-fetch
这样是否就可以安全的使用fetch来进行前后端通信了？上面说了在大多数情况下是这样，但是IE8/9则比较特殊：IE8它使用的是ES3，而IE9则对ES5部分支持。这种情况下还需要ES5的polyfilles5-shim支持了。
上述有关promise的polyfill实现，需要说明的是：
babel-runtime是不能作为Promise的polyfill的实现的，否则在IE8/9下使用fetch会报
Promise未定义。为什么？我想大家猜到了，因为babel-runtime实现的polyfill是局部实现而不是全局实现，fetch底层实现用到Promise就是从全局中去取的，拿不到这报上述错误。
另外，顺便补充一下fetch的polyfill实现思路是：
首先判断浏览器是否原生支持fetch，否则结合Promise使用XMLHttpRequest的方式来实现；这正是
whatwg-fetch的实现思路，而同构应用中使用的isomorphic-fetch，其客户端fetch的实现是直接require whatwg-fetch来实现的。
fetch默认不携带cookie
fetch发送请求默认是不发送cookie的，不管是同域还是跨域；那么问题就来了，对于那些需要权限验证的请求就可能无法正常获取数据，这时可以配置其credentials项，其有3个值：
omit: 默认值，忽略cookie的发送same-origin: 表示cookie只能同域发送，不能跨域发送include: cookie既可以同域发送，也可以跨域发送
credentials所表达的含义，其实与XHR2中的withCredentials属性类似，表示请求是否携带cookie；具体可以参考阮一峰老师的跨域资源共享 CORS 详解中withCredentials一节的介绍；
这样，若要fetch请求携带cookie信息，只需设置一下credentials选项即可，例如fetch(url, {credentials: 'include'});
另外补充一点：
fetch默认对服务端通过
Set-Cookie头设置的cookie也会忽略，若想选择接受来自服务端的cookie信息，也必须要配置credentials选项；
fetch请求对某些错误http状态不会reject
这主要是由fetch返回promise导致的，因为fetch返回的promise在某些错误的http状态下如400、500等不会reject，相反它会被resolve；只有网络错误会导致请求不能完成时，fetch 才会被 reject；所以一般会对fetch请求做一层封装，例如下面代码所示：
function checkStatus(response) {
if (response.status >= 200 && response.status < 300) {
return response;
}
const error = new Error(response.statusText);
error.response = response;
throw error;
}
function parseJSON(response) {
return response.json();
}
export default function request(url, options) {
let opt = options||{};
return fetch(url, {credentials: 'include', ...opt})
.then(checkStatus)
.then(parseJSON)
.then((data) => ( data ))
.catch((err) => ( err ));
}fetch不支持超时timeout处理
用过fetch的都知道，fetch不像大多数ajax库那样对请求设置超时timeout，它没有有关请求超时的feature，这一点比较蛋疼。所以在fetch标准添加超时feature之前，都需要polyfill该特性。
实际上，我们真正需要的是abort()， timeout可以通过timeout+abort方式来实现，起到真正超时丢弃当前的请求。
而在目前的fetch指导规范中，fetch并不是一个具体实例，而只是一个方法；其返回的promise实例根据Promise指导规范标准是不能abort的，也不能手动改变promise实例的状态，只能由内部来根据请求结果来改变promise的状态。
既然不能手动控制fetch方法执行后返回的promise实例状态，那么是不是可以创建一个可以手动控制状态的新Promise实例呢。所以：
实现fetch的timeout功能，其思想就是新创建一个可以手动控制promise状态的实例，根据不同情况来对新promise实例进行resolve或者reject，从而达到实现timeout的功能；
根据github上timeout handling上的讨论，目前可以有两种不同的解决方法：
方法一：单纯setTimeout方式
var oldFetchfn = fetch; //拦截原始的fetch方法
window.fetch = function(input, opts){//定义新的fetch方法，封装原有的fetch方法
return new Promise(function(resolve, reject){
var timeoutId = setTimeout(function(){
reject(new Error("fetch timeout"))
}, opts.timeout);
oldFetchfn(input, opts).then(
res=>{
clearTimeout(timeoutId);
resolve(res)
},
err=>{
clearTimeout(timeoutId);
reject(err)
}
)
})
}当然在上面基础上可以模拟类似XHR的abort功能：
var oldFetchfn = fetch;
window.fetch = function(input, opts){
return new Promise(function(resolve, reject){
var abort_promise = function(){
reject(new Error("fetch abort"))
};
var p = oldFetchfn(input, opts).then(resolve, reject);
p.abort = abort_promise;
return p;
})
}方法二：利用Promise.race方法
Promise.race方法接受一个promise实例数组参数，表示多个promise实例中任何一个最先改变状态，那么race方法返回的promise实例状态就跟着改变，具体可以参考这里。
var oldFetchfn = fetch; //拦截原始的fetch方法
window.fetch = function(input, opts){//定义新的fetch方法，封装原有的fetch方法
var fetchPromise = oldFetchfn(input, opts);
var timeoutPromise = new Promise(function(resolve, reject){
setTimeout(()=>{
reject(new Error("fetch timeout"))
}, opts.timeout)
});
retrun Promise.race([fetchPromise, timeoutPromise])
}最后，对fetch的timeout的上述实现方式补充几点：
timeout不是请求连接超时的含义，它表示请求的response时间，包括请求的连接、服务器处理及服务器响应回来的时间；
fetch的timeout即使超时发生了，本次请求也不会被abort丢弃掉，它在后台仍然会发送到服务器端，只是本次请求的响应内容被丢弃而已；
fetch不支持JSONP
fetch是与服务器端进行异步交互的，而JSONP是外链一个javascript资源，并不是真正ajax，所以fetch与JSONP没有什么直接关联，当然至少目前是不支持JSONP的。
这里我们把JSONP与fetch关联在一起有点差强人意，fetch只是一个ajax库，我们不可能使fetch支持JSONP；只是我们要实现一个JSONP，只不过这个JSONP的实现要与fetch的实现类似，即基于Promise来实现一个JSONP；而其外在表现给人感觉是fetch支持JSONP一样；
目前比较成熟的开源JSONP实现fetch-jsonp给我们提供了解决方案，想了解可以自行前往。不过再次想唠叨一下其JSONP的实现步骤，因为在本人面试的前端候选人中大部分人对JSONP的实现语焉不详；
使用它非常简单，首先需要用npm安装fetch-jsonp
npm install fetch-jsonp --save-dev然后在像下面一样使用：
fetchJsonp('/users.jsonp', {
timeout: 3000,
jsonpCallback: 'custom_callback'
})
.then(function(response) {
return response.json()
}).catch(function(ex) {
console.log('parsing failed', ex)
})fetch不支持progress事件
XHR是原生支持progress事件的，例如下面代码这样：
var xhr = new XMLHttpRequest()
xhr.open('POST', '/uploads')
xhr.onload = function() {}
xhr.onerror = function() {}
function updateProgress (event) {
if (event.lengthComputable) {
var percent = Math.round((event.loaded / event.total) * 100)
console.log(percent)
}
xhr.upload.onprogress =updateProgress; //上传的progress事件
xhr.onprogress = updateProgress; //下载的progress事件
}
xhr.send();但是fetch是不支持有关progress事件的；不过可喜的是，根据fetch的指导规范标准，其内部设计实现了Request和Response类；其中Response封装一些方法和属性，通过Response实例可以访问这些方法和属性，例如response.json()、response.body等等；
值得关注的地方是，response.body是一个可读字节流对象，其实现了一个getRender()方法，其具体作用是：
getRender()方法用于读取响应的原始字节流，该字节流是可以循环读取的，直至body内容传输完成；
因此，利用到这点可以模拟出fetch的progress，具体可以参考这篇文章2016 - the year of web streams。
代码实现如下，在线demo请参考fetch progress demo。
// fetch() returns a promise that resolves once headers have been received
fetch(url).then(response => {
// response.body is a readable stream.
// Calling getReader() gives us exclusive access to the stream's content
var reader = response.body.getReader();
var bytesReceived = 0;
// read() returns a promise that resolves when a value has been received
reader.read().then(function processResult(result) {
// Result objects contain two properties:
// done - true if the stream has already given you all its data.
// value - some data. Always undefined when done is true.
if (result.done) {
console.log("Fetch complete");
return;
}
// result.value for fetch streams is a Uint8Array
bytesReceived += result.value.length;
console.log('Received', bytesReceived, 'bytes of data so far');
// Read some more, and call this function again
return reader.read().then(processResult);
});
});另外，github上也有使用Promise+XHR结合的方式实现类fetch的progress效果(当然这跟fetch完全不搭边）可以参考这里，具体代码如下：
function fetchProgress(url, opts={}, onProgress){
return new Promise(funciton(resolve, reject){
var xhr = new XMLHttpRequest();
xhr.open(opts.method || 'get', url);
for(var key in opts.headers || {}){
xhr.setRequestHeader(key, opts.headers[key]);
}
xhr.onload = e => resolve(e.target.responseText)
xhr.onerror = reject;
if (xhr.upload && onProgress){
xhr.upload.onprogress = onProgress; //上传
}
if ('onprogerss' in xhr && onProgress){
xhr.onprogress = onProgress; //下载
}
xhr.send(opts.body)
})
}
fetchProgress('/upload').then(console.log)fetch跨域问题
既然是ajax库，就不可避免与跨域扯上关系；XHR2是支持跨域请求的，只不过要满足浏览器端支持CORS，服务器通过Access-Control-Allow-Origin来允许指定的源进行跨域，仅此一种方式。
与XHR2一样，fetch也是支持跨域请求的，只不过其跨域请求做法与XHR2一样，需要客户端与服务端支持；另外，fetch还支持一种跨域，不需要服务器支持的形式，具体可以通过其mode的配置项来说明。
fetch的mode配置项有3个值，如下：
same-origin：该模式是不允许跨域的，它需要遵守同源策略，否则浏览器会返回一个error告知不能跨域；其对应的response type为basic。cors: 该模式支持跨域请求，顾名思义它是以CORS的形式跨域；当然该模式也可以同域请求不需要后端额外的CORS支持；其对应的response type为cors。no-cors: 该模式用于跨域请求但是服务器不带CORS响应头，也就是服务端不支持CORS；这也是fetch的特殊跨域请求方式；其对应的response type为opaque。
针对跨域请求，cors模式是常见跨域请求实现，但是fetch自带的no-cors跨域请求模式则较为陌生，该模式有一个比较明显的特点：
该模式允许浏览器发送本次跨域请求，但是不能访问响应返回的内容，这也是其response type为opaque透明的原因。
这与<img/>发送的请求类似，只是该模式不能访问响应的内容信息；但是它可以被其他APIs进行处理，例如ServiceWorker。另外，该模式返回的repsonse可以在Cache API中被存储起来以便后续的对它的使用，这点对script、css和图片的CDN资源是非常合适的，因为这些资源响应头中都没有CORS头。
总的来说，fetch的跨域请求是使用CORS方式，需要浏览器和服务端的支持。
参考文献
查看原文rebareba 收藏了文章 · 2018-09-08
没有了CommonsChunkPlugin，咱拿什么来分包（译）
webpack 4 移除 CommonsChunkPlugin，取而代之的是两个新的配置项（optimization.splitChunks 和 optimization.runtimeChunk），下面介绍一下用法和机制。
默认方式
webpack模式模式现在已经做了一些通用性优化，适用于多数使用者。
需要注意的是：默认模式只影响按需(on-demand)加载的代码块(chunk)，因为改变初始代码块会影响声明在HTML的script标签。如果可以处理好这些（比如，从打包状态里面读取并动态生成script标签到HTML），你可以通过设置optimization.splitChunks.chunks: "all"，应用这些优化模式到初始代码块(initial chunk)。
webpack根据下述条件自动进行代码块分割：
- 新代码块可以被共享引用，OR这些模块都是来自
node_modules文件夹里面 - 新代码块大于30kb（min+gziped之前的体积）
- 按需加载的代码块，最大数量应该小于或者等于5
- 初始加载的代码块，最大数量应该小于或等于3
为了满足后面两个条件，webpack有可能受限于包的最大数量值，生成的代码体积往上增加。
我们来看一下一些例子：
Example 1
// entry.js
import("./a");// a.js
import "react-dom";
// ...结果：webpack会创建一个包含react-dom的分离代码块。当import调用时候，这个代码块就会与./a代码被并行加载。
为什么会这样打包：
- 条件1：这个代码块是从
node_modules来的 - 条件2：react-dom大于30kb
- 条件3：按需请求的数量是2（小于5）
- 条件4：不会影响初始代码请求数量
这样打包有什么好处呢？
对比起你的应用代码，react-dom可能不会经常变动。通过将它分割至另外一个代码块，这个代码块可以被独立缓存起来（假设你在用的是长期缓存策略：chunkhash，records，Cache-Control）
Example 2
// entry.js
import("./a");
import("./b");// a.js
import "./helpers"; // helpers is 40kb in size
// ...// b.js
import "./helpers";
import "./more-helpers"; // more-helpers is also 40kb in size
// ...结果：webpack会创建一个包含./helpers的独立代码块，其他模块会依赖于它。在import被调用时候，这个代码块会跟原始的代码并行加载（译注：它会跟a.js和b.js并行加载）。
为什么会这样打包：
- 条件1：这个代码块会被两个导入(
import)调用依赖（指的是a.js和b.js） - 条件2：
helpers体积大于30kb - 条件3：按需请求的数量是2（小于5）
- 条件4：不会影响初始代码请求数量
这样打包有什么好处呢？
将helpers代码放在每一个依赖的块里，可能就意味着，用户重复会下载它两次。通过用一个独立的代码块分割，它只需要被下载一次。实际上，这只是一种折衷方案，因为我们为此需要付出额外的一次请求的代价。这就是为什么默认webpack将最小代码块分割体积设置成30kb（译注：太小体积的代码块被分割，可能还会因为额外的请求，拖慢加载性能）。
通过optimizations.splitChunks.chunks: "all"，上面的策略也可以应用到初始代码块上(inital chunks)。代码代码块也会被多个入口共享&按需加载（译注：以往我们使用CommonsChunkPlugin最通常的目的）。
配置
如果想要更深入控制这个按需分块的功能，这里提供很多选项来满足你的需求。
Disclaimer：不要在没有实践测量的情况下，尝试手动优化这些参数。默认模式是经过千挑万选的，可以用于满足最佳web性能的策略。
缓存组（Cache Group）
这项优化可以用于将模块分配到对应的Cache group。
默认模式会将所有来自node_modules的模块分配到一个叫vendors的缓存组；所有重复引用至少两次的代码，会被分配到default的缓存组。
一个模块可以被分配到多个缓存组，优化策略会将模块分配至跟高优先级别（priority）的缓存组，或者会分配至可以形成更大体积代码块的组里。
Conditions
在满足下述所有条件时，那些从相同代码块和缓存组来的模块，会形成一个新的代码块（译注：比如，在满足条件下，一个vendoer可能会被分割成两个，以充分利用并行请求性能）。
有四个选项可以用于配置这些条件：
minSize(默认是30000)：形成一个新代码块最小的体积minChunks（默认是1）：在分割之前，这个代码块最小应该被引用的次数（译注：保证代码块复用性，默认配置的策略是不需要多次引用也可以被分割）maxInitialRequests（默认是3）：一个入口最大的并行请求数maxAsyncRequests（默认是5）：按需加载时候最大的并行请求数。
Naming
要控制代码块的命名，可以用name参数来配置。
注意：当不同分割代码块被赋予相同名称时候，他们会被合并在一起。这个可以用于在：比如将那些多个入口/分割点的共享模块(vendor)合并在一起，不过不推荐这样做。这可能会导致加载额外的代码。
如果赋予一个神奇的值true，webpack会基于代码块和缓存组的key自动选择一个名称。除此之外，可以使用字符串或者函数作为参数值。
当一个名称匹配到相应的入口名称，这个入口会被移除。
Select chunks
通过chunks选项，可以配置控制webpack选择哪些代码块用于分割（译注：其他类型代码块按默认方式打包）。有3个可选的值：initial、async和all。webpack将会只对配置所对应的代码块应用这些策略。
reuseExistingChunk选项允许复用已经存在的代码块，而不是新建一个新的，需要在精确匹配到对应模块时候才会生效。
这个选项可以在每个缓存组（Cache Group）里面做配置。
Select modules
test选项用于控制哪些模块被这个缓存组匹配到。原封不动传递出去的话，它默认会选择所有的模块。可以传递的值类型：RegExp、String和Function
通过这个选项，可以通过绝对资源路径（absolute modules resource path）或者代码块名称(chunk names)来匹配对应模块。当一个代码块名称(chunk name)被匹配到，这个代码块的所有模块都会被选中。
配置缓存组(Configurate cache group)
这是默认的配置：
splitChunks: {
chunks: "async",
minSize: 30000,
minChunks: 1,
maxAsyncRequests: 5,
maxInitialRequests: 3,
name: true,
cacheGroups: {
default: {
minChunks: 2,
priority: -20,
reuseExistingChunk: true,
},
vendors: {
test: /[\\/]node_modules[\\/]/,
priority: -10
}
}
}默认来说，缓存组会继承splitChunks的配置，但是test、priorty和reuseExistingChunk只能用于配置缓存组。
cacheGroups是一个对象，按上述介绍的键值对方式来配置即可，值代表对应的选项：
除此之外，所有上面列出的选择都是可以用在缓存组里的：chunks, minSize, minChunks, maxAsyncRequests, maxInitialRequests, name。
可以通过optimization.splitChunks.cacheGroups.default: false禁用default缓存组。
default缓存组的优先级(priotity)是负数，因此所有自定义缓存组都可以有比它更高优先级（译注：更高优先级的缓存组可以优先打包所选择的模块）（默认自定义缓存组优先级为0）
可以用一些例子来说明：
Example 1
splitChunks: {
cacheGroups: {
commons: {
name: "commons",
chunks: "initial",
minChunks: 2
}
}
}这会创建一个commons代码块，这个代码块包含所有被其他入口(entrypoints)共享的代码。
注意：这可能会导致下载额外的代码。
Example 2
splitChunks: {
cacheGroups: {
commons: {
test: /[\\/]node_modules[\\/]/,
name: "vendors",
chunks: "all"
}
}
}这会创建一个名为vendors的代码块，它会包含整个应用所有来自node_modules的代码。
注意：这可能会导致下载额外的代码。
optimization.runtimeChunk
通过optimization.runtimeChunk: true选项，webpack会添加一个只包含运行时(runtime)额外代码块到每一个入口。（译注：这个需要看场景使用，会导致每个入口都加载多一份运行时代码）
rebareba 发布了文章 · 2018-03-28
一篇搞懂TCP、HTTP、Socket、Socket连接池
前言
作为一名开发人员我们经常会听到HTTP协议、TCP/IP协议、UDP协议、Socket、Socket长连接、Socket连接池等字眼，然而它们之间的关系、区别及原理并不是所有人都能理解清楚，这篇文章就从网络协议基础开始到Socket连接池，一步一步解释他们之间的关系。
七层网络模型
首先从网络通信的分层模型讲起：七层模型，亦称OSI(Open System Interconnection)模型。自下往上分为：物理层、数据链路层、网络层、传输层、会话层、表示层和应用层。所有有关通信的都离不开它，下面这张图片介绍了各层所对应的一些协议和硬件
通过上图，我知道IP协议对应于网络层，TCP、UDP协议对应于传输层，而HTTP协议对应于应用层，OSI并没有Socket，那什么是Socket，后面我们将结合代码具体详细介绍。
TCP和UDP连接
关于传输层TCP、UDP协议可能我们平时遇见的会比较多，有人说TCP是安全的，UDP是不安全的，UDP传输比TCP快，那为什么呢，我们先从TCP的连接建立的过程开始分析，然后解释UDP和TCP的区别。
TCP的三次握手和四次分手
我们知道TCP建立连接需要经过三次握手，而断开连接需要经过四次分手，那三次握手和四次分手分别做了什么和如何进行的。
第一次握手：建立连接。客户端发送连接请求报文段，将SYN位置为1，Sequence Number为x；然后，客户端进入SYN_SEND状态，等待服务器的确认；
第二次握手：服务器收到客户端的SYN报文段，需要对这个SYN报文段进行确认，设置Acknowledgment Number为x+1(Sequence Number+1)；同时，自己自己还要发送SYN请求信息，将SYN位置为1，Sequence Number为y；服务器端将上述所有信息放到一个报文段（即SYN+ACK报文段）中，一并发送给客户端，此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN+ACK报文段。然后将Acknowledgment Number设置为y+1，向服务器发送ACK报文段，这个报文段发送完毕以后，客户端和服务器端都进入ESTABLISHED状态，完成TCP三次握手。
完成了三次握手，客户端和服务器端就可以开始传送数据。以上就是TCP三次握手的总体介绍。通信结束客户端和服务端就断开连接，需要经过四次分手确认。
第一次分手：主机1（可以使客户端，也可以是服务器端），设置Sequence Number和Acknowledgment Number，向主机2发送一个FIN报文段；此时，主机1进入FIN_WAIT_1状态；这表示主机1没有数据要发送给主机2了；
第二次分手：主机2收到了主机1发送的FIN报文段，向主机1回一个ACK报文段，Acknowledgment Number为Sequence Number加1；主机1进入FIN_WAIT_2状态；主机2告诉主机1，我“同意”你的关闭请求；
第三次分手：主机2向主机1发送FIN报文段，请求关闭连接，同时主机2进入LAST_ACK状态；
第四次分手：主机1收到主机2发送的FIN报文段，向主机2发送ACK报文段，然后主机1进入TIME_WAIT状态；主机2收到主机1的ACK报文段以后，就关闭连接；此时，主机1等待2MSL后依然没有收到回复，则证明Server端已正常关闭，那好，主机1也可以关闭连接了。
可以看到一次tcp请求的建立及关闭至少进行7次通信，这还不包过数据的通信，而UDP不需3次握手和4次分手。
TCP和UDP的区别
1、TCP是面向链接的，虽然说网络的不安全不稳定特性决定了多少次握手都不能保证连接的可靠性，但TCP的三次握手在最低限度上(实际上也很大程度上保证了)保证了连接的可靠性;而UDP不是面向连接的，UDP传送数据前并不与对方建立连接，对接收到的数据也不发送确认信号，发送端不知道数据是否会正确接收，当然也不用重发，所以说UDP是无连接的、不可靠的一种数据传输协议。
2、也正由于1所说的特点，使得UDP的开销更小数据传输速率更高，因为不必进行收发数据的确认，所以UDP的实时性更好。知道了TCP和UDP的区别，就不难理解为何采用TCP传输协议的MSN比采用UDP的QQ传输文件慢了，但并不能说QQ的通信是不安全的，因为程序员可以手动对UDP的数据收发进行验证，比如发送方对每个数据包进行编号然后由接收方进行验证啊什么的，即使是这样，UDP因为在底层协议的封装上没有采用类似TCP的“三次握手”而实现了TCP所无法达到的传输效率。
问题
关于传输层我们会经常听到一些问题
1．TCP服务器最大并发连接数是多少？
关于TCP服务器最大并发连接数有一种误解就是“因为端口号上限为65535,所以TCP服务器理论上的可承载的最大并发连接数也是65535”。首先需要理解一条TCP连接的组成部分：客户端IP、客户端端口、服务端IP、服务端端口。所以对于TCP服务端进程来说，他可以同时连接的客户端数量并不受限于可用端口号，理论上一个服务器的一个端口能建立的连接数是全球的IP数*每台机器的端口数。实际并发连接数受限于linux可打开文件数，这个数是可以配置的，可以非常大，所以实际上受限于系统性能。通过#ulimit -n 查看服务的最大文件句柄数，通过ulimit -n xxx 修改 xxx是你想要能打开的数量。也可以通过修改系统参数：
#vi /etc/security/limits.conf
* soft nofile 65536
* hard nofile 655362．为什么TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状态？
这是因为虽然双方都同意关闭连接了，而且握手的4个报文也都协调和发送完毕，按理可以直接回到CLOSED状态（就好比从SYN_SEND状态到ESTABLISH状态那样）；但是因为我们必须要假想网络是不可靠的，你无法保证你最后发送的ACK报文会一定被对方收到，因此对方处于LAST_ACK状态下的Socket可能会因为超时未收到ACK报文，而重发FIN报文，所以这个TIME_WAIT状态的作用就是用来重发可能丢失的ACK报文。
3．TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状态会产生什么问题
通信双方建立TCP连接后，主动关闭连接的一方就会进入TIME_WAIT状态，TIME_WAIT状态维持时间是两个MSL时间长度，也就是在1-4分钟，Windows操作系统就是4分钟。进入TIME_WAIT状态的一般情况下是客户端，一个TIME_WAIT状态的连接就占用了一个本地端口。一台机器上端口号数量的上限是65536个，如果在同一台机器上进行压力测试模拟上万的客户请求，并且循环与服务端进行短连接通信，那么这台机器将产生4000个左右的TIME_WAIT Socket，后续的短连接就会产生address already in use : connect的异常，如果使用Nginx作为方向代理也需要考虑TIME_WAIT状态，发现系统存在大量TIME_WAIT状态的连接，通过调整内核参数解决。
vi /etc/sysctl.conf编辑文件，加入以下内容：
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = 30然后执行 /sbin/sysctl -p 让参数生效。
net.ipv4.tcp_syncookies = 1 表示开启SYN Cookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击，默认为0，表示关闭；
net.ipv4.tcp_tw_reuse = 1 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭；
net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。
net.ipv4.tcp_fin_timeout 修改系統默认的TIMEOUT时间
HTTP协议
关于TCP/IP和HTTP协议的关系，网络有一段比较容易理解的介绍：“我们在传输数据时，可以只使用(传输层)TCP/IP协议，但是那样的话，如果没有应用层，便无法识别数据内容。如果想要使传输的数据有意义，则必须使用到应用层协议。应用层协议有很多，比如HTTP、FTP、TELNET等，也可以自己定义应用层协议。
HTTP协议即超文本传送协议(Hypertext Transfer Protocol )，是Web联网的基础，也是手机联网常用的协议之一，WEB使用HTTP协议作应用层协议，以封装HTTP文本信息，然后使用TCP/IP做传输层协议将它发到网络上。
由于HTTP在每次请求结束后都会主动释放连接，因此HTTP连接是一种“短连接”，要保持客户端程序的在线状态，需要不断地向服务器发起连接请求。通常 的做法是即时不需要获得任何数据，客户端也保持每隔一段固定的时间向服务器发送一次“保持连接”的请求，服务器在收到该请求后对客户端进行回复，表明知道 客户端“在线”。若服务器长时间无法收到客户端的请求，则认为客户端“下线”，若客户端长时间无法收到服务器的回复，则认为网络已经断开。
下面是一个简单的HTTP Post application/json数据内容的请求：
POST HTTP/1.1
Host: 127.0.0.1:9017
Content-Type: application/json
Cache-Control: no-cache
{"a":"a"}关于Socket（套接字）
现在我们了解到TCP/IP只是一个协议栈，就像操作系统的运行机制一样，必须要具体实现，同时还要提供对外的操作接口。就像操作系统会提供标准的编程接口，比如Win32编程接口一样，TCP/IP也必须对外提供编程接口，这就是Socket。现在我们知道，Socket跟TCP/IP并没有必然的联系。Socket编程接口在设计的时候，就希望也能适应其他的网络协议。所以，Socket的出现只是可以更方便的使用TCP/IP协议栈而已，其对TCP/IP进行了抽象，形成了几个最基本的函数接口。比如create，listen，accept，connect，read和write等等。
不同语言都有对应的建立Socket服务端和客户端的库，下面举例Nodejs如何创建服务端和客户端：
服务端：
const net = require('net');
const server = net.createServer();
server.on('connection', (client) => {
client.write('Hi!\n'); // 服务端向客户端输出信息，使用 write() 方法
client.write('Bye!\n');
//client.end(); // 服务端结束该次会话
});
server.listen(9000);服务监听9000端口
下面使用命令行发送http请求和telnet
$ curl http://127.0.0.1:9000
Bye!
$telnet 127.0.0.1 9000
Trying 192.168.1.21...
Connected to 192.168.1.21.
Escape character is '^]'.
Hi!
Bye!
Connection closed by foreign host.注意到curl只处理了一次报文。
客户端
const client = new net.Socket();
client.connect(9000, '127.0.0.1', function () {
});
client.on('data', (chunk) => {
console.log('data', chunk.toString())
//data Hi!
//Bye!
});Socket长连接
所谓长连接，指在一个TCP连接上可以连续发送多个数据包，在TCP连接保持期间，如果没有数据包发送，需要双方发检测包以维持此连接(心跳包)，一般需要自己做在线维持。 短连接是指通信双方有数据交互时，就建立一个TCP连接，数据发送完成后，则断开此TCP连接。比如Http的，只是连接、请求、关闭，过程时间较短,服务器若是一段时间内没有收到请求即可关闭连接。其实长连接是相对于通常的短连接而说的，也就是长时间保持客户端与服务端的连接状态。
通常的短连接操作步骤是：
连接→数据传输→关闭连接；
而长连接通常就是：
连接→数据传输→保持连接(心跳)→数据传输→保持连接(心跳)→……→关闭连接；
什么时候用长连接，短连接？
长连接多用于操作频繁，点对点的通讯，而且连接数不能太多情况，。每个TCP连接都需要三步握手，这需要时间，如果每个操作都是先连接，再操作的话那么处理 速度会降低很多，所以每个操作完后都不断开，次处理时直接发送数据包就OK了，不用建立TCP连接。例如：数据库的连接用长连接， 如果用短连接频繁的通信会造成Socket错误，而且频繁的Socket创建也是对资源的浪费。
什么是心跳包为什么需要：
心跳包就是在客户端和服务端间定时通知对方自己状态的一个自己定义的命令字，按照一定的时间间隔发送，类似于心跳，所以叫做心跳包。网络中的接收和发送数据都是使用Socket进行实现。但是如果此套接字已经断开（比如一方断网了），那发送数据和接收数据的时候就一定会有问题。可是如何判断这个套接字是否还可以使用呢？这个就需要在系统中创建心跳机制。其实TCP中已经为我们实现了一个叫做心跳的机制。如果你设置了心跳，那TCP就会在一定的时间（比如你设置的是3秒钟）内发送你设置的次数的心跳（比如说2次），并且此信息不会影响你自己定义的协议。也可以自己定义，所谓“心跳”就是定时发送一个自定义的结构体（心跳包或心跳帧），让对方知道自己“在线”,以确保链接的有效性。
实现：
服务端：
const net = require('net');
let clientList = [];
const heartbeat = 'HEARTBEAT'; // 定义心跳包内容确保和平时发送的数据不会冲突
const server = net.createServer();
server.on('connection', (client) => {
console.log('客户端建立连接:', client.remoteAddress + ':' + client.remotePort);
clientList.push(client);
client.on('data', (chunk) => {
let content = chunk.toString();
if (content === heartbeat) {
console.log('收到客户端发过来的一个心跳包');
} else {
console.log('收到客户端发过来的数据:', content);
client.write('服务端的数据:' + content);
}
});
client.on('end', () => {
console.log('收到客户端end');
clientList.splice(clientList.indexOf(client), 1);
});
client.on('error', () => {
clientList.splice(clientList.indexOf(client), 1);
})
});
server.listen(9000);
setInterval(broadcast, 10000); // 定时发送心跳包
function broadcast() {
console.log('broadcast heartbeat', clientList.length);
let cleanup = []
for (let i=0;i<clientList.length;i+=1) {
if (clientList[i].writable) { // 先检查 sockets 是否可写
clientList[i].write(heartbeat);
} else {
console.log('一个无效的客户端');
cleanup.push(clientList[i]); // 如果不可写，收集起来销毁。销毁之前要 Socket.destroy() 用 API 的方法销毁。
clientList[i].destroy();
}
}
//Remove dead Nodes out of write loop to avoid trashing loop index
for (let i=0; i<cleanup.length; i+=1) {
console.log('删除无效的客户端:', cleanup[i].name);
clientList.splice(clientList.indexOf(cleanup[i]), 1);
}
}服务端输出结果：
客户端建立连接: ::ffff:127.0.0.1:57125
broadcast heartbeat 1
收到客户端发过来的数据: Thu, 29 Mar 2018 03:45:15 GMT
收到客户端发过来的一个心跳包
收到客户端发过来的数据: Thu, 29 Mar 2018 03:45:20 GMT
broadcast heartbeat 1
收到客户端发过来的数据: Thu, 29 Mar 2018 03:45:25 GMT
收到客户端发过来的一个心跳包
客户端建立连接: ::ffff:127.0.0.1:57129
收到客户端发过来的一个心跳包
收到客户端发过来的数据: Thu, 29 Mar 2018 03:46:00 GMT
收到客户端发过来的数据: Thu, 29 Mar 2018 03:46:04 GMT
broadcast heartbeat 2
收到客户端发过来的数据: Thu, 29 Mar 2018 03:46:05 GMT
收到客户端发过来的一个心跳包客户端代码：
const net = require('net');
const heartbeat = 'HEARTBEAT';
const client = new net.Socket();
client.connect(9000, '127.0.0.1', () => {});
client.on('data', (chunk) => {
let content = chunk.toString();
if (content === heartbeat) {
console.log('收到心跳包：', content);
} else {
console.log('收到数据：', content);
}
});
// 定时发送数据
setInterval(() => {
console.log('发送数据', new Date().toUTCString());
client.write(new Date().toUTCString());
}, 5000);
// 定时发送心跳包
setInterval(function () {
client.write(heartbeat);
}, 10000);客户端输出结果：
发送数据 Thu, 29 Mar 2018 03:46:04 GMT
收到数据： 服务端的数据:Thu, 29 Mar 2018 03:46:04 GMT
收到心跳包： HEARTBEAT
发送数据 Thu, 29 Mar 2018 03:46:09 GMT
收到数据： 服务端的数据:Thu, 29 Mar 2018 03:46:09 GMT
发送数据 Thu, 29 Mar 2018 03:46:14 GMT
收到数据： 服务端的数据:Thu, 29 Mar 2018 03:46:14 GMT
收到心跳包： HEARTBEAT
发送数据 Thu, 29 Mar 2018 03:46:19 GMT
收到数据： 服务端的数据:Thu, 29 Mar 2018 03:46:19 GMT
发送数据 Thu, 29 Mar 2018 03:46:24 GMT
收到数据： 服务端的数据:Thu, 29 Mar 2018 03:46:24 GMT
收到心跳包： HEARTBEAT定义自己的协议
如果想要使传输的数据有意义，则必须使用到应用层协议比如Http、Mqtt、Dubbo等。基于TCP协议上自定义自己的应用层的协议需要解决的几个问题：
- 心跳包格式的定义及处理
- 报文头的定义，就是你发送数据的时候需要先发送报文头，报文里面能解析出你将要发送的数据长度
- 你发送数据包的格式，是json的还是其他序列化的方式
下面我们就一起来定义自己的协议，并编写服务的和客户端进行调用：
定义报文头格式： length:000000000xxxx; xxxx代表数据的长度，总长度20,举例子不严谨。
数据表的格式: Json
服务端:
const net = require('net');
const server = net.createServer();
let clientList = [];
const heartBeat = 'HeartBeat'; // 定义心跳包内容确保和平时发送的数据不会冲突
const getHeader = (num) => {
return 'length:' + (Array(13).join(0) + num).slice(-13);
}
server.on('connection', (client) => {
client.name = client.remoteAddress + ':' + client.remotePort
// client.write('Hi ' + client.name + '!\n');
console.log('客户端建立连接', client.name);
clientList.push(client)
let chunks = [];
let length = 0;
client.on('data', (chunk) => {
let content = chunk.toString();
console.log("content:", content, content.length);
if (content === heartBeat) {
console.log('收到客户端发过来的一个心跳包');
} else {
if (content.indexOf('length:') === 0){
length = parseInt(content.substring(7,20));
console.log('length', length);
chunks =[chunk.slice(20, chunk.length)];
} else {
chunks.push(chunk);
}
let heap = Buffer.concat(chunks);
console.log('heap.length', heap.length)
if (heap.length >= length) {
try {
console.log('收到数据', JSON.parse(heap.toString()));
let data = '服务端的数据数据:' + heap.toString();;
let dataBuff = Buffer.from(JSON.stringify(data));
let header = getHeader(dataBuff.length)
client.write(header);
client.write(dataBuff);
} catch (err) {
console.log('数据解析失败');
}
}
}
})
client.on('end', () => {
console.log('收到客户端end');
clientList.splice(clientList.indexOf(client), 1);
});
client.on('error', () => {
clientList.splice(clientList.indexOf(client), 1);
})
});
server.listen(9000);
setInterval(broadcast, 10000); // 定时检查客户端 并发送心跳包
function broadcast() {
console.log('broadcast heartbeat', clientList.length);
let cleanup = []
for(var i=0;i<clientList.length;i+=1) {
if(clientList[i].writable) { // 先检查 sockets 是否可写
// clientList[i].write(heartBeat); // 发送心跳数据
} else {
console.log('一个无效的客户端')
cleanup.push(clientList[i]) // 如果不可写，收集起来销毁。销毁之前要 Socket.destroy() 用 API 的方法销毁。
clientList[i].destroy();
}
}
// 删除无效的客户端
for(i=0; i<cleanup.length; i+=1) {
console.log('删除无效的客户端:', cleanup[i].name);
clientList.splice(clientList.indexOf(cleanup[i]), 1)
}
}日志打印：
客户端建立连接 ::ffff:127.0.0.1:50178
content: length:0000000000031 20
length 31
heap.length 0
content: "Tue, 03 Apr 2018 06:12:37 GMT" 31
heap.length 31
收到数据 Tue, 03 Apr 2018 06:12:37 GMT
broadcast heartbeat 1
content: HeartBeat 9
收到客户端发过来的一个心跳包
content: length:0000000000031"Tue, 03 Apr 2018 06:12:42 GMT" 51
length 31
heap.length 31
收到数据 Tue, 03 Apr 2018 06:12:42 GMT客户端
const net = require('net');
const client = new net.Socket();
const heartBeat = 'HeartBeat'; // 定义心跳包内容确保和平时发送的数据不会冲突
const getHeader = (num) => {
return 'length:' + (Array(13).join(0) + num).slice(-13);
}
client.connect(9000, '127.0.0.1', function () {});
let chunks = [];
let length = 0;
client.on('data', (chunk) => {
let content = chunk.toString();
console.log("content:", content, content.length);
if (content === heartBeat) {
console.log('收到服务端发过来的一个心跳包');
} else {
if (content.indexOf('length:') === 0){
length = parseInt(content.substring(7,20));
console.log('length', length);
chunks =[chunk.slice(20, chunk.length)];
} else {
chunks.push(chunk);
}
let heap = Buffer.concat(chunks);
console.log('heap.length', heap.length)
if (heap.length >= length) {
try {
console.log('收到数据', JSON.parse(heap.toString()));
} catch (err) {
console.log('数据解析失败');
}
}
}
});
// 定时发送数据
setInterval(function () {
let data = new Date().toUTCString();
let dataBuff = Buffer.from(JSON.stringify(data));
let header =getHeader(dataBuff.length);
client.write(header);
client.write(dataBuff);
}, 5000);
// 定时发送心跳包
setInterval(function () {
client.write(heartBeat);
}, 10000);日志打印：
content: length:0000000000060 20
length 60
heap.length 0
content: "服务端的数据数据:\"Tue, 03 Apr 2018 06:12:37 GMT\"" 44
heap.length 60
收到数据 服务端的数据数据:"Tue, 03 Apr 2018 06:12:37 GMT"
content: length:0000000000060"服务端的数据数据:\"Tue, 03 Apr 2018 06:12:42 GMT\"" 64
length 60
heap.length 60
收到数据 服务端的数据数据:"Tue, 03 Apr 2018 06:12:42 GMT"客户端定时发送自定义协议数据到服务端，先发送头数据，在发送内容数据，另外一个定时器发送心跳数据，服务端判断是心跳数据，再判断是不是头数据，再是内容数据，然后解析后再发送数据给客户端。从日志的打印可以看出客户端先后writeheader和data数据，服务端可能在一个data事件里面接收到。
这里可以看到一个客户端在同一个时间内处理一个请求可以很好的工作，但是想象这么一个场景，如果同一时间内让同一个客户端去多次调用服务端请求，发送多次头数据和内容数据，服务端的data事件收到的数据就很难区别哪些数据是哪次请求的，比如两次头数据同时到达服务端，服务端就会忽略其中一次，而后面的内容数据也不一定就对应于这个头的。所以想复用长连接并能很好的高并发处理服务端请求，就需要连接池这种方式了。
Socket连接池
什么是Socket连接池,池的概念可以联想到是一种资源的集合，所以Socket连接池，就是维护着一定数量Socket长连接的集合。它能自动检测Socket长连接的有效性，剔除无效的连接，补充连接池的长连接的数量。从代码层次上其实是人为实现这种功能的类，一般一个连接池包含下面几个属性：
- 空闲可使用的长连接队列
- 正在运行的通信的长连接队列
- 等待去获取一个空闲长连接的请求的队列
- 无效长连接的剔除功能
- 长连接资源池的数量配置
- 长连接资源的新建功能
场景： 一个请求过来，首先去资源池要求获取一个长连接资源，如果空闲队列里面有长连接，就获取到这个长连接Socket,并把这个Socket移到正在运行的长连接队列。如果空闲队列里面没有，且正在运行的队列长度小于配置的连接池资源的数量，就新建一个长连接到正在运行的队列去，如果正在运行的不下于配置的资源池长度，则这个请求进入到等待队列去。当一个正在运行的Socket完成了请求，就从正在运行的队列移到空闲的队列，并触发等待请求队列去获取空闲资源，如果有等待的情况。
这里简单介绍Nodejs的Socket连接池generic-pool模块的源码。
主要文件目录结构
.
|————lib ------------------------- 代码库
| |————DefaultEvictor.js ----------
| |————Deferred.js ----------------
| |————Deque.js -------------------
| |————DequeIterator.js -----------
| |————DoublyLinkedList.js --------
| |————DoublyLinkedListIterator.js-
| |————factoryValidator.js --------
| |————Pool.js -------------------- 连接池主要代码
| |————PoolDefaults.js ------------
| |————PooledResource.js ----------
| |————Queue.js ------------------- 队列
| |————ResourceLoan.js ------------
| |————ResourceRequest.js ---------
| |————utils.js ------------------- 工具
|————test ------------------------- 测试目录
|————README.md ------------------- 项目描述文件
|————.eslintrc ------------------- eslint静态检查配置文件
|————.eslintignore --------------- eslint静态检查忽略的文件
|————package.json ----------------- npm包依赖配置下面介绍库的使用：
初始化连接池
'use strict';
const net = require('net');
const genericPool = require('generic-pool');
function createPool(conifg) {
let options = Object.assign({
fifo: true, // 是否优先使用老的资源
priorityRange: 1, // 优先级
testOnBorrow: true, // 是否开启获取验证
// acquireTimeoutMillis: 10 * 1000, // 获取的超时时间
autostart: true, // 自动初始化和释放调度启用
min: 10, // 初始化连接池保持的长连接最小数量
max: 0, // 最大连接池保持的长连接数量
evictionRunIntervalMillis: 0, // 资源释放检验间隔检查 设置了下面几个参数才起效果
numTestsPerEvictionRun: 3, // 每次释放资源数量
softIdleTimeoutMillis: -1, // 可用的超过了最小的min 且空闲时间时间 达到释放
idleTimeoutMillis: 30000 // 强制释放
// maxWaitingClients: 50 // 最大等待
}, conifg.options);
const factory = {
create: function () {
return new Promise((resolve, reject) => {
let socket = new net.Socket();
socket.setKeepAlive(true);
socket.connect(conifg.port, conifg.host);
// TODO 心跳包的处理逻辑
socket.on('connect', () => {
console.log('socket_pool', conifg.host, conifg.port, 'connect' );
resolve(socket);
});
socket.on('close', (err) => { // 先end 事件再close事件
console.log('socket_pool', conifg.host, conifg.port, 'close', err);
});
socket.on('error', (err) => {
console.log('socket_pool', conifg.host, conifg.port, 'error', err);
reject(err);
});
});
},
//销毁连接
destroy: function (socket) {
return new Promise((resolve) => {
socket.destroy(); // 不会触发end 事件 第一次会触发发close事件 如果有message会触发error事件
resolve();
});
},
validate: function (socket) { //获取资源池校验资源有效性
return new Promise((resolve) => {
// console.log('socket.destroyed:', socket.destroyed, 'socket.readable:', socket.readable, 'socket.writable:', socket.writable);
if (socket.destroyed || !socket.readable || !socket.writable) {
return resolve(false);
} else {
return resolve(true);
}
});
}
};
const pool = genericPool.createPool(factory, options);
pool.on('factoryCreateError', (err) => { // 监听新建长连接出错 让请求直接返回错误
const clientResourceRequest = pool._waitingClientsQueue.dequeue();
if (clientResourceRequest) {
clientResourceRequest.reject(err);
}
});
return pool;
};
let pool = createPool({
port: 9000,
host: '127.0.0.1',
options: {min: 0, max: 10}
});使用连接池
下面连接池的使用，使用的协议是我们之前自定义的协议。
let pool = createPool({
port: 9000,
host: '127.0.0.1',
options: {min: 0, max: 10}
});
const getHeader = (num) => {
return 'length:' + (Array(13).join(0) + num).slice(-13);
}
const request = async (requestDataBuff) => {
let client;
try {
client = await pool.acquire();
} catch (e) {
console.log('acquire socket client failed: ', e);
throw e;
}
let timeout = 10000;
return new Promise((resolve, reject) => {
let chunks = [];
let length = 0;
client.setTimeout(timeout);
client.removeAllListeners('error');
client.on('error', (err) => {
client.removeAllListeners('error');
client.removeAllListeners('data');
client.removeAllListeners('timeout');
pool.destroyed(client);
reject(err);
});
client.on('timeout', () => {
client.removeAllListeners('error');
client.removeAllListeners('data');
client.removeAllListeners('timeout');
// 应该销毁以防下一个req的data事件监听才返回数据
pool.destroy(client);
// pool.release(client);
reject(`socket connect timeout set ${timeout}`);
});
let header = getHeader(requestDataBuff.length);
client.write(header);
client.write(requestDataBuff);
client.on('data', (chunk) => {
let content = chunk.toString();
console.log('content', content, content.length);
// TODO 过滤心跳包
if (content.indexOf('length:') === 0){
length = parseInt(content.substring(7,20));
console.log('length', length);
chunks =[chunk.slice(20, chunk.length)];
} else {
chunks.push(chunk);
}
let heap = Buffer.concat(chunks);
console.log('heap.length', heap.length);
if (heap.length >= length) {
pool.release(client);
client.removeAllListeners('error');
client.removeAllListeners('data');
client.removeAllListeners('timeout');
try {
// console.log('收到数据', JSON.parse(heap.toString()));
resolve(JSON.parse(heap.toString()));
} catch (err) {
reject(err);
console.log('数据解析失败');
}
}
});
});
}
request(Buffer.from(JSON.stringify({a: 'a'})))
.then((data) => {
console.log('收到服务的数据',data)
}).catch(err => {
console.log(err);
});
request(Buffer.from(JSON.stringify({b: 'b'})))
.then((data) => {
console.log('收到服务的数据',data)
}).catch(err => {
console.log(err);
});
setTimeout(function () { //查看是否会复用Socket 有没有建立新的连接
request(Buffer.from(JSON.stringify({c: 'c'})))
.then((data) => {
console.log('收到服务的数据',data)
}).catch(err => {
console.log(err);
});
request(Buffer.from(JSON.stringify({d: 'd'})))
.then((data) => {
console.log('收到服务的数据',data)
}).catch(err => {
console.log(err);
});
}, 1000)日志打印：
socket_pool 127.0.0.1 9000 connect
socket_pool 127.0.0.1 9000 connect
content length:0000000000040"服务端的数据数据:{\"a\":\"a\"}" 44
length 40
heap.length 40
收到服务的数据 服务端的数据数据:{"a":"a"}
content length:0000000000040"服务端的数据数据:{\"b\":\"b\"}" 44
length 40
heap.length 40
收到服务的数据 服务端的数据数据:{"b":"b"}
content length:0000000000040 20
length 40
heap.length 0
content "服务端的数据数据:{\"c\":\"c\"}" 24
heap.length 40
收到服务的数据 服务端的数据数据:{"c":"c"}
content length:0000000000040"服务端的数据数据:{\"d\":\"d\"}" 44
length 40
heap.length 40
收到服务的数据 服务端的数据数据:{"d":"d"}这里看到前面两个请求都建立了新的Socket连接 socket_pool 127.0.0.1 9000 connect，定时器结束后重新发起两个请求就没有建立新的Socket连接了，直接从连接池里面获取Socket连接资源。
源码分析
发现主要的代码就位于lib文件夹中的Pool.js
构造函数：lib/Pool.js
/**
* Generate an Object pool with a specified `factory` and `config`.
*
* @param {typeof DefaultEvictor} Evictor
* @param {typeof Deque} Deque
* @param {typeof PriorityQueue} PriorityQueue
* @param {Object} factory
* Factory to be used for generating and destroying the items.
* @param {Function} factory.create
* Should create the item to be acquired,
* and call it's first callback argument with the generated item as it's argument.
* @param {Function} factory.destroy
* Should gently close any resources that the item is using.
* Called before the items is destroyed.
* @param {Function} factory.validate
* Test if a resource is still valid .Should return a promise that resolves to a boolean, true if resource is still valid and false
* If it should be removed from pool.
* @param {Object} options
*/
constructor(Evictor, Deque, PriorityQueue, factory, options) {
super();
factoryValidator(factory); // 检验我们定义的factory的有效性包含create destroy validate
this._config = new PoolOptions(options); // 连接池配置
// TODO: fix up this ugly glue-ing
this._Promise = this._config.Promise;
this._factory = factory;
this._draining = false;
this._started = false;
/**
* Holds waiting clients
* @type {PriorityQueue}
*/
this._waitingClientsQueue = new PriorityQueue(this._config.priorityRange); // 请求的对象管管理队列queue 初始化queue的size 1 { _size: 1, _slots: [ Queue { _list: [Object] } ] }
/**
* Collection of promises for resource creation calls made by the pool to factory.create
* @type {Set}
*/
this._factoryCreateOperations = new Set(); // 正在创建的长连接
/**
* Collection of promises for resource destruction calls made by the pool to factory.destroy
* @type {Set}
*/
this._factoryDestroyOperations = new Set(); // 正在销毁的长连接
/**
* A queue/stack of pooledResources awaiting acquisition
* TODO: replace with LinkedList backed array
* @type {Deque}
*/
this._availableObjects = new Deque(); // 空闲的资源长连接
/**
* Collection of references for any resource that are undergoing validation before being acquired
* @type {Set}
*/
this._testOnBorrowResources = new Set(); // 正在检验有效性的资源
/**
* Collection of references for any resource that are undergoing validation before being returned
* @type {Set}
*/
this._testOnReturnResources = new Set();
/**
* Collection of promises for any validations currently in process
* @type {Set}
*/
this._validationOperations = new Set();// 正在校验的中间temp
/**
* All objects associated with this pool in any state (except destroyed)
* @type {Set}
*/
this._allObjects = new Set(); // 所有的链接资源 是一个 PooledResource对象
/**
* Loans keyed by the borrowed resource
* @type {Map}
*/
this._resourceLoans = new Map(); // 被借用的对象的map release的时候用到
/**
* Infinitely looping iterator over available object
* @type {DequeIterator}
*/
this._evictionIterator = this._availableObjects.iterator(); // 一个迭代器
this._evictor = new Evictor();
/**
* handle for setTimeout for next eviction run
* @type {(number|null)}
*/
this._scheduledEviction = null;
// create initial resources (if factory.min > 0)
if (this._config.autostart === true) { // 初始化最小的连接数量
this.start();
}
}可以看到包含之前说的空闲的资源队列，正在请求的资源队列，正在等待的请求队列等。
下面查看 Pool.acquire 方法lib/Pool.js
/**
* Request a new resource. The callback will be called,
* when a new resource is available, passing the resource to the callback.
* TODO: should we add a seperate "acquireWithPriority" function
*
* @param {Number} [priority=0]
* Optional. Integer between 0 and (priorityRange - 1). Specifies the priority
* of the caller if there are no available resources. Lower numbers mean higher
* priority.
*
* @returns {Promise}
*/
acquire(priority) { // 空闲资源队列资源是有优先等级的
if (this._started === false && this._config.autostart === false) {
this.start(); // 会在this._allObjects 添加min的连接对象数
}
if (this._draining) { // 如果是在资源释放阶段就不能再请求资源了
return this._Promise.reject(
new Error("pool is draining and cannot accept work")
);
}
// 如果要设置了等待队列的长度且要等待 如果超过了就返回资源不可获取
// TODO: should we defer this check till after this event loop incase "the situation" changes in the meantime
if (
this._config.maxWaitingClients !== undefined &&
this._waitingClientsQueue.length >= this._config.maxWaitingClients
) {
return this._Promise.reject(
new Error("max waitingClients count exceeded")
);
}
const resourceRequest = new ResourceRequest(
this._config.acquireTimeoutMillis, // 对象里面的超时配置 表示等待时间 会启动一个定时 超时了就触发resourceRequest.promise 的reject触发
this._Promise
);
// console.log(resourceRequest)
this._waitingClientsQueue.enqueue(resourceRequest, priority); // 请求进入等待请求队列
this._dispense(); // 进行资源分发 最终会触发resourceRequest.promise的resolve(client)
return resourceRequest.promise; // 返回的是一个promise对象resolve却是在其他地方触发
} /**
* Attempt to resolve an outstanding resource request using an available resource from
* the pool, or creating new ones
*
* @private
*/
_dispense() {
/**
* Local variables for ease of reading/writing
* these don't (shouldn't) change across the execution of this fn
*/
const numWaitingClients = this._waitingClientsQueue.length; // 正在等待的请求的队列长度 各个优先级的总和
console.log('numWaitingClients', numWaitingClients) // 1
// If there aren't any waiting requests then there is nothing to do
// so lets short-circuit
if (numWaitingClients < 1) {
return;
}
// max: 10, min: 4
console.log('_potentiallyAllocableResourceCount', this._potentiallyAllocableResourceCount) // 目前潜在空闲可用的连接数量
const resourceShortfall =
numWaitingClients - this._potentiallyAllocableResourceCount; // 还差几个可用的 小于零表示不需要 大于0表示需要新建长连接的数量
console.log('spareResourceCapacity', this.spareResourceCapacity) // 距离max数量的还有几个没有创建
const actualNumberOfResourcesToCreate = Math.min(
this.spareResourceCapacity, // -6
resourceShortfall // 这个是 -3
); // 如果resourceShortfall>0 表示需要新建但是这新建的数量不能超过spareResourceCapacity最多可创建的
console.log('actualNumberOfResourcesToCreate', actualNumberOfResourcesToCreate) // 如果actualNumberOfResourcesToCreate >0 表示需要创建连接
for (let i = 0; actualNumberOfResourcesToCreate > i; i++) {
this._createResource(); // 新增新的长连接
}
// If we are doing test-on-borrow see how many more resources need to be moved into test
// to help satisfy waitingClients
if (this._config.testOnBorrow === true) { // 如果开启了使用前校验资源的有效性
// how many available resources do we need to shift into test
const desiredNumberOfResourcesToMoveIntoTest =
numWaitingClients - this._testOnBorrowResources.size;// 1
const actualNumberOfResourcesToMoveIntoTest = Math.min(
this._availableObjects.length, // 3
desiredNumberOfResourcesToMoveIntoTest // 1
);
for (let i = 0; actualNumberOfResourcesToMoveIntoTest > i; i++) { // 需要有效性校验的数量 至少满足最小的waiting clinet
this._testOnBorrow(); // 资源有效校验后再分发
}
}
// if we aren't testing-on-borrow then lets try to allocate what we can
if (this._config.testOnBorrow === false) { // 如果没有开启有效性校验 就开启有效资源的分发
const actualNumberOfResourcesToDispatch = Math.min(
this._availableObjects.length,
numWaitingClients
);
for (let i = 0; actualNumberOfResourcesToDispatch > i; i++) { // 开始分发资源
this._dispatchResource();
}
}
}
/**
* Attempt to move an available resource to a waiting client
* @return {Boolean} [description]
*/
_dispatchResource() {
if (this._availableObjects.length < 1) {
return false;
}
const pooledResource = this._availableObjects.shift(); // 从可以资源池里面取出一个
this._dispatchPooledResourceToNextWaitingClient(pooledResource); // 分发
return false;
}
/**
* Dispatches a pooledResource to the next waiting client (if any) else
* puts the PooledResource back on the available list
* @param {PooledResource} pooledResource [description]
* @return {Boolean} [description]
*/
_dispatchPooledResourceToNextWaitingClient(pooledResource) {
const clientResourceRequest = this._waitingClientsQueue.dequeue(); // 可能是undefined 取出一个等待的quene
console.log('clientResourceRequest.state', clientResourceRequest.state);
if (clientResourceRequest === undefined ||
clientResourceRequest.state !== Deferred.PENDING) {
console.log('没有等待的')
// While we were away either all the waiting clients timed out
// or were somehow fulfilled. put our pooledResource back.
this._addPooledResourceToAvailableObjects(pooledResource); // 在可用的资源里面添加一个
// TODO: do need to trigger anything before we leave?
return false;
}
// TODO clientResourceRequest 的state是否需要判断 如果已经是resolve的状态 已经超时回去了 这个是否有问题
const loan = new ResourceLoan(pooledResource, this._Promise);
this._resourceLoans.set(pooledResource.obj, loan); // _resourceLoans 是个map k=>value pooledResource.obj 就是socket本身
pooledResource.allocate(); // 标识资源的状态是正在被使用
clientResourceRequest.resolve(pooledResource.obj); // acquire方法返回的promise对象的resolve在这里执行的
return true;
}上面的代码就按种情况一直走下到最终获取到长连接的资源，其他更多代码大家可以自己去深入了解。
查看原文赞 95 收藏 66 评论 0
rebareba 关注了标签 · 2018-03-26
docker
an open source project to pack, ship and run any application as a lightweight container ! By Lock !
关注 35582
rebareba 关注了用户 · 2018-03-26
flayPig @clm960227
attemp to do something that is defferent.
关注 381
rebareba 关注了用户 · 2018-03-26
搜云库技术团队 @souyunku
关注公众号「搜云库技术团队」
内容涵盖Java后端技术、Spring Boot、Spring Cloud、微服务架构、大数据、云计算、运维开发、系统监控等相关的研究与知识分享。
关注 6508
换一批
推荐关注