nodejs微服务健康检查方案

1. 前言

针对目前云平台方案,因为网络、主机状态等诸多因素,单台主机上的服务出现问题的几率大大增加。这就要求我们能够监控每台主机、每个微服务实例的健康状态。因此对于nodejs相关项目需要做相关的微服务健康检查接口。

在不改动原有express框架的基础上,我在express官方网站上查找到相应的健康检查的样例,做成demo供大家参考。

(链接https://expressjs.com/en/advanced/healthcheck-graceful-shutdown.html)

2. 方案实现demo

我是以agent做的demo,以下是我修改的app.js代码:红色代码为我添加的的部分。为容器提供对应的健康检查端口。

var express = require(‘express‘);

var path = require(‘path‘);

var favicon = require(‘serve-favicon‘);

var logger = require(‘morgan‘);

var cookieParser = require(‘cookie-parser‘);

var bodyParser = require(‘body-parser‘);

var session = require(‘express-session‘);

var RedisStore = require(‘connect-redis‘)(session);

var config = require(‘./config/config‘).getInstance().config;

var logg = config.logger;

var moment = require(‘moment‘);

var comm = require(‘./middlewares/comm‘);

var routes = require(‘./routes/index‘);

 var app = express();

app.set(‘env‘, config.debug ? ‘development‘ : ‘production‘);

app.set(‘port‘, process.env.PORT || config.port);

app.set(‘trust proxy‘, config.proxy); // 指定子网和 IP 地址

app.set(‘views‘, path.join(__dirname, ‘views‘));

app.set(‘view engine‘, ‘ejs‘);

app.use(favicon(path.join(__dirname, ‘public‘, ‘favicon.ico‘)));

app.use(logger(‘dev‘));

app.use(bodyParser.json());

app.use(bodyParser.urlencoded({extended: false}));

app.use(cookieParser());

app.use(express.static(path.join(__dirname, ‘public‘)));

//session redis存储

const store = new RedisStore({

    host: config.redis.host,

    port: config.redis.port,

    pass: config.redis.passwd,

});

//设置session

app.use(session({

    store: store,

    name: ‘ghjhgz‘,

    secret: ‘dfgdfgfdgdfgdfgderte435sd‘,

    resave: true,

    rolling: true,

    saveUninitialized: false,

    cookie: {domain: config.domain}

}));

// 添加模板必需的变量

app.use(function (req, res, next) {

    res.locals.user = ‘‘;   

    next();

});

routes(app);

// error handler

app.use(function (err, req, res, next) {

    // set locals, only providing error in development

    logg.error(err);

    res.locals.message = err.message;

    res.locals.error = req.app.get(‘env‘) === ‘development‘ ? err : {};

    // render the error page

    res.status(err.status || 500);

    if(config.debug){

        res.render(‘error‘);

    }else{

        res.render(‘404‘);

    } 

});

/* istanbul ignore next */

if (!module.parent) {

    app.listen(config.port, function () {

        console.log(‘listening on port: ‘ + config.port);

    });

}

 module.exports = app;

 1 const http = require(‘http‘);
 2
 3  const terminus = require(‘@godaddy/terminus‘);
 4
 5  const server = http.createServer(app);
 6
 7  function onSignal() {
 8
 9   console.log(‘server is starting cleanup‘);
10
11   // start cleanup of resource, like databases or file descriptors
12
13 }
14
15 async function onHealthCheck() {
16
17   // checks if the system is healthy, like the db connection is live
18
19   // resolves, if health, rejects if not
20
21   console.log(‘HealthCheck is starting‘);
22
23 }
24 terminus(server, {
25
26   signal: ‘SIGINT‘,
27
28    healthChecks: {
29
30     ‘/healthcheck‘: onHealthCheck,
31
32   },
33
34   onSignal
35
36 });
37
38 server.listen(3000);

目前,只需要修改一下app.js,onHealthCheck函数接口为健康检查接口,后续可以提供检查对应的系统健康,比如数据库或者redis链接状态等。

2.1 依赖库terminus

npm i @godaddy/terminus –save 安装依赖

Terminus是一个开放源代码项目,它将健康检查和正常关闭添加到您的应用程序中,从而无需编写样板代码。您只需提供用于正常关闭的清理逻辑和用于运行状况检查的运行状况检查逻辑,而终点则处理其余部分。

2.2 有限的Windows支持

由于固有的平台限制,terminus对Windows的支持有限。你可以期望SIGINT工作,以及在SIGBREAK某种程度上SIGHUP。但是,SIGTERM在Windows上永远不会工作,因为在任务管理器中查杀进程是无条件的,也就是说,应用程序无法检测或阻止进程。

2.3 Terminus源码GitHub地址

https://github.com/godaddy/terminus

3. Kubernetes对应的接口

使用livenessProbe探针对开放的端口进行检测。

livenessProbe:
          httpGet:
            path: /healthcheck      #对应应用的健康路径
            port: 3000                   #统一的健康检查端口,在云平台内部不会出现端口冲突
          initialDelaySeconds: 15
          periodSeconds: 5
          timeoutSeconds: 1

原文地址:https://www.cnblogs.com/w-jinfeng/p/9054672.html

时间: 2024-10-02 03:12:16

nodejs微服务健康检查方案的相关文章

微服务高可用方案

一.微服务的高可用 在注册中心.配置中心高可用方案之前,了解一下注册中心的工作原理,下面分为两个部分来解释,一是注册中心和各个微服务的注册表的获取与同步,二是注册中心如何去维护注册表. 1.1.注册表的获取与同步 Eureka Server和Eureka Client之间的关系,通过注册表来维护,而注册表的通过Eureka Server集中化管理,每个Client在本地进行注册表的缓存,通过周期性的任务拉取最新的注册表信息.简单的示例图如下. 根据上图所展示的流程,可以了解到注册中心与微服务之间

如何一步步设计一款微服务的补偿方案

背景随着微服务化的系统越来越多,系统间的交互也呈现几何倍增的趋势,系统间面临一致性问题越来越突出.为了保障服务提供方与服务消费方的一致性,特别是面临最大努力通知型或补偿性的技术需求,服务化前做法是服务提供方需手写重试策略及各种配置->持久化消息->定时去处理消息等.它带来的以下问题是:1.客户端(新微服务)要做的重复性工作越来越多?需每个开发者熟悉它,去实现它:2.这个为什么这样个性化?标准不统一,出错率上升:3.说好的快速响应呢?我要做的狠简单,最好一行代码就可以实现它:4.维护成本上升:接

《微服务设计》笔记-微服务集成推荐方案

为前端服务的后端 BFF(Backends For Frontends,为前端服务的后端)它允许团队在专注于给定UI的同时,也会处理与之相关的服务端组件.后端虽然嵌入在服务器,但它也是用户界面的组成部分.一些类型的UI只需要服务端的最小化足迹(footprint)即可,而其他一些可能需要的更多.API认证和授权层可以处在BFF和UI之间. 与第三方软件集成方案

MySQL服务健康检查脚本

#!/bin/sh#date:2015-12-07#filename:check_mysql.sh#作者:linuxzkq #Email:[email protected]#version:v1.0 #port=`netstat -tunlp|grep 3306|wc -l`#process=`ps -ef|grep mysqld|grep -v grep|wc -l`value=`/application/mysql/bin/mysql -u root -poldboy -e "select

告别“臃肿”,选择微服务(文末福利)

点击标题下「异步社区」可快速关注 参与文末话题讨论,每周赠送异步图书 --异步小编 一直以来,系统的架构设计是IT领域经久不衰的话题,也是构建每一个系统最核心且重要的部分之一.它决定了系统能否满足业务.技术.组织.灵活.可扩展性等多种要求,同时肩负起了解放程序员生产力的作用. 2016年底,由于业务的不断发展,我所在公司维护的项目也越来越"臃肿".随着无数个版本的迭代,以及开发人员的不断增加,开发效率越来越低,每次投产的人力成本和时间成本都逐渐增加,我们一直在思索如何能破局.评估了各种

微服务全流程分析

转眼已经2020,距离微服务这个词落地已经过去好多年!(我记得2017年就听过这个词).然而今天我想想什么是微服务,其实并没有一个很好的定义.为什么这样说,按照微服务的定义: 微服务架构就是将一个庞大的业务系统按照业务模块拆分成若干个独立的子系统,每个子系统都是一个独立的应用,它是一种将应用构建成一系列按业务领域划分模块的,小的自治服务的软件架构方式,倡导将复杂的单体应用拆分成若干个功能单一.松偶合的服务,这样可以降低开发难度.增强扩展性.便于敏捷开发,及持续集成与交付活动. 根据这个定义,不难

微服务之springcloud技术栈

一.微服务架构图: 二.技术介绍:(技术选型随着代码的编写会完成) 关于技术选型,我盗了一张微服务技术栈的图,如下:原文:http://www.jianshu.com/p/2da6becfb019 我将会用到上图中的如下技术 服务注册和服务发现:consul 服务健康检查:consul 配置管理:consul.archaius 集群容错:hystrix 计数监控:codahale-metrics.java-statsd-client.hystrix-dashboard.turbine.stats

企业级工作流解决方案(二)--微服务总体介绍

微服务好处和概念性的东西就不介绍了,对于微服务,个人认为并不是越复杂就越好,相反要结合自己公司的现状,适当的做一些裁剪,比如对于规模和业务量不是特别大的企业,就没有必要把服务总线,服务健康检查,服务路由选择,熔断等等加进来,相反,这一部分职责可以通过配置文件,nginx代理,api网关等等外围的技术来控制,当企业达到一定的规模之后,再来完善这部分内容,但是对于微服务处理过程来说,没有任何影响. 我这里根据json-rpc 2.0标准,结合网上一些开源的微服务架构思想,采用dotnetty技术,搭

企业级工作流解决方案(五)--微服务消息处理模型之客户端端处理

微服务的服务端已经启动起来了,服务消费者怎么知道服务在哪个地方,通过什么方式调用呢,分布式如何选择正确的服务器调用服务? 这个就涉及到服务发现.服务健康检查的问题了,很多微服务架构的做法都是通过消息队列来实现的,消息队列天生就支持发布订阅功能,服务有变化之后,发布通知,每个消费者更新状态,还涉及到更新服务的metadata信息,同时还涉及到服务健康检查等等一系列功能,其实这些地方是非常容易出问题的地方,但是对于规模流量不是特别巨大的企业,这部分职责可以进行转移,服务的发现就直接通过配置文件实现,