Health Check in eShop -- 解析微软微服务架构Demo(五)

转载 2017年07月21日 18:17:20

What is the Health Check

    Health Check(健康状态检查)不仅是对自己应用程序内部检测各个项目之间的健康状态(各项目的运行情况、项目之间的连接情况等),还包括了应用程序对外部或者第三方依赖库的状态检测。

Why use Health Check

    现在我们的项目越来越多的从单体多层架构转换成多项目多层架构即现在流行的微服务架构。

    原来我们的App把各个模块分层分项目处理,比如Users项目仅仅处理User的一些业务需求,但在整个项目使用的时候,我们仅仅需要引用其类库即可,不用担心项目与类库之间的不兼容问题,如果不兼容在编译期已经会有提示。但如今,业务规模越来越庞大的时候,我们单独把Users作为一个service来做,所有一切都在其内部处理,对于外部来说仅仅公开几个api即可,但与项目之间的连接就从单纯的物理引用关系转换成了网络调用关系。

    当我们架构从单体架构到微服务架构的时候,我们会发现越来越多的引用从物理转向了网络,在原来我们不需要考虑之间是否调用成功,但现在我们必须考虑进去,网络因素、服务器因素、其他因素等都会影响各服务之间的调用,因此Health Check孕育而生,它在微服务架构中是举足轻重的。

Health Check’s Feathure

    Health Check的功能有哪些?在微服务架构中很简单,就是检查各services的运行状态是否正常。在微服务的架构中,所有的一切都是service,db is service,rabbitmq is service,auth is service, shoppingcart is server……我们的架构能够根据业务需求,横向的扩容,多个db,多个rabbitmq,多个auth,多个shoppingcart。我们总结下,微服务架构下的Health Check是通过网络检查各services是否正常运行,它的功能是:

1、提供外部调用Health Check接口,反馈自身状态

2、检测相关service状态是否正常(比如db server,能否连接到db,能否打开数据库等)

3、UnHealthly时处理机制

Health Check in eShop

Why in eShop?

    之前我们一直都在介绍eShop是微软基于微服务架构的.Net Core Demo,为了保障各个services之间的调用正常,所以Health Check是必不可少的。

Where is it?

    在Demo中,我们可以在各个services中都能看到HealthCheck,可以说是无处不在,在系列【】和【】中我们都有见过。在eShop项目中,我们可以看到有个HealthChecks目录,其中包含了与HealthChecks相关的几个项目:

image

Microsoft.Extensions.HealthChecks   ------------     Health Check的核心代码

Microsoft.AspNetCore.HealthChecks   ------------     Asp.Net Core注册扩展类库

Microsoft.Extensions.HealthChecks.AzureStorage ----- 扩展对Azure Blob Storage的支持

Microsoft.Extensions.HealthChecks.SqlServer ------   扩展对MsSql Server的支持

    通过代码了解,在eShop中实现了对各Api的通讯检测和SqlServer、AzureBlobStorage的检测,但其中并没有看到对重试机制和UnHealthy时的处理,相信以后会加入这些,目前微软已经单独为HealthChecks开了一个Repository,这样你就可以单独引用到自己的项目中,非常棒的东西。

    在项目中,我们一般只会在Program.cs和Startup.cs看到跟HealthChecks相关的代码。目前仅在客户端(其他service或者我们的app)请求我们的HealthChecks的时候,我们会进行相关service的检测,然后再返回自身的一个状态码。

How use the Healthchecks?

    接下来我们看下在eShop中代码是如何使用的,我们以Identity.Api为例,在之前的文章中我们提到过,在Program.cs中,有一段UseHealthChecks("/hc"),我们跟踪下代码,你会看到它会先判断path是否负责规则,如果符合的话就会通过IWebHostBuilder注册一个HealthCheckStartupFilter,Filter则会把相应的HealthCheckMiddleware注册到管道中,我们看下主要源码:

复制代码
public async Task Invoke(HttpContext context)
{
    if (IsHealthCheckRequest(context))
    {
        var timeoutTokenSource = new CancellationTokenSource(_timeout);
        var result = await _service.CheckHealthAsync(timeoutTokenSource.Token);
        var status = result.CheckStatus;

        if (status != CheckStatus.Healthy)
            context.Response.StatusCode = 503;

        context.Response.Headers.Add("content-type", "application/json");
        await context.Response.WriteAsync(JsonConvert.SerializeObject(new { status = status.ToString() }));
        return;
    }
    else
    {
        await _next.Invoke(context);
    }
}

private bool IsHealthCheckRequest(HttpContext context)
{
    if (_port.HasValue)
    {
        var connInfo = context.Features.Get<IHttpConnectionFeature>();
        if (connInfo.LocalPort == _port)
            return true;
    }

    if (context.Request.Path == _path)
    {
        return true;
    }

    return false;
}
复制代码

它会先检测这个请求是不是HealthCheck请求,如果不是则走下面的步骤,如果是,则会进一步进行对相关service的HealthChecks。对相关service的Config实在Startup.cs中进行的:

复制代码
services.AddHealthChecks(checks =>
{
    var minutes = 1;
    if (int.TryParse(Configuration["HealthCheck:Timeout"], out var minutesParsed))
    {
        minutes = minutesParsed;
    }
    checks.AddSqlCheck("Identity_Db", Configuration.GetConnectionString("DefaultConnection"), TimeSpan.FromMinutes(minutes));
});
复制代码

这里可以看到,在Identity.Api中,仅仅配置了对数据库的检测。

ok,我们非常简单的在项目中引用了HealthCheck,当我们的api运行后,我们只需要通过 http://xxx/hc 就能对这个api进行Health Check了。

写在最后

    今天我们了解了Health Check,并简单看了它在eShop中的使用。目前看来还不是很完善,只在其他service或者app调用其Health Check接口的时候才能进行检测,当然我们可以改造下,使其在程序运行的时候先检测一次。在eShop中我们并没有看到在UnHealth的时候的处理,这个扩展起来很简单,你可以通过自身需求,进行日志,email,短信都可以,后面可以找机会实现下。

【微服务干货系列】使用微服务架构之前,你必须知道的

正如敏捷之父MartinFowler所说的那样,单体架构和微服务并不是简单的二选一,两者都是模糊的定义,这就意味着大多数系统都将在一个模糊的边界区域。很多开发团队已经认识到微服务架构比单体架构更优越,...
  • goodraincloud
  • goodraincloud
  • 2016年02月23日 17:00
  • 5059

小程聊微服务-基于dubbo的mock测试系统

一、说在前面 基于微服务或者SOA的自动化测试系统每个公司都有自己的特有的,我今天就主要介绍一下,我们研发的一套mock测试系统。 二、目前面临的问题 1、测试人员面临的测试问题 我公司目前用的是...
  • u013970991
  • u013970991
  • 2017年02月04日 14:10
  • 5784

从理论到实践落地「微服务

从理论到实践落地「微服务」 作者|程超编辑|小智若论近年来大热的技术名词,微服务必定有一席之地。对于微服务的阐述已有很多,但很多不过流于框架、架构介绍,恍若空中楼阁。这是一篇理论与实践结合谈微服务的...
  • u010412301
  • u010412301
  • 2017年10月10日 09:35
  • 4961

微服务架构与实践学习笔记

摘要微服务,持续集成(Jenkins),构建(Maven,Gradle),部署(Docker),持续交付(Jenkins),日志聚合(ELK),运维(监控警告Zabbix) 本内容为学习(王磊 著)...
  • bobshute
  • bobshute
  • 2017年04月09日 15:39
  • 1326

Spring Cloud Netflix 微服务压力测试

对微服务的提供者和消费者组建的集合进行压力测试,以发现可能的问题和解决的方法。...
  • ClementAD
  • ClementAD
  • 2017年01月10日 17:26
  • 7113

微服务架构选型实践

背景随着公司一年多的成长,我们已经开发了数十个项目了,后台有 JAVA 的有 PHP 的,为了更好地提升开发与管理效率,各技术大牛小牛们时常进行激烈的 PK,碰撞出了许许多多爱的火花,比如其中之一:微...
  • t4i2b10X4c22nF6A
  • t4i2b10X4c22nF6A
  • 2018年01月12日 00:00
  • 437

微服务架构下的测试之道

作者:袁慎建,崇尚简约,热爱编程 && 运动健身 && 知识分享,擅长敏捷开发实践,持续集成 && 持续交付,关注代码整洁 && TDD,关注软件质量来自:sjyuan.cc1.系统架构的演变伴随着互...
  • g6U8W7p06dCO99fQ3
  • g6U8W7p06dCO99fQ3
  • 2018年02月01日 00:00
  • 219

微服务

1. 简介微服务的概念最初由Martin Fowler与James Lewis于2014年共同提出,微服务架构风格是一种使用一套小服务来开发单个应用的方式途径,每个服务运行在自己的进程中,并使用轻量级...
  • zhufenglonglove
  • zhufenglonglove
  • 2016年07月18日 19:11
  • 1495

微服务以及测试必要性

在微服务的时代中,你就不用费心测试微服务了,自带一套完整的监测体系,所哟在微服务的时代,只有用/不用两个选项,你用,你就符合标准来使用,你不用,那就不存在测试 micro Service,p...
  • gnicky
  • gnicky
  • 2016年05月25日 08:42
  • 794

微服务与持续交付

编者按:InfoQ开设新栏目“品味书香”, 精选技术书籍的精彩章节,以及分享看完书留下的思考和收获,欢迎大家关注。本文节选自王磊著《微服务架构与实践》中的章节“微服务与持续交付”,介绍了持续交付是什么...
  • xuguokun1986
  • xuguokun1986
  • 2017年02月10日 14:44
  • 371
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:Health Check in eShop -- 解析微软微服务架构Demo(五)
举报原因:
原因补充:

(最多只允许输入30个字)