.NET Core微服务之路:基于Consul最少集群实现服务的注册与发现(二)

简介: 重温Consul最少化集群的搭建     我们再复习一下上一篇的内容,先建立三台consul server节点,两个consul client节点,分别在每个节点上跑不同(名称不同而已)的实例。

重温Consul最少化集群的搭建

 
  我们再复习一下上一篇的内容,先建立三台consul server节点,两个consul client节点,分别在每个节点上跑不同(名称不同而已)的实例。我们先通过vmware启动这五个节点,并且能成功访问这个两个client节点的实例。(具体配置可以见上一篇)
 
  通过配置文件自动生成服务
{
  "services": [
    {
      "id": "CLIENT_SERVICE_01",
      "name": "CAS Client Service",
      "tags": [
        "urlprefix-/ClientService01"
      ],
      "address": "192.168.153.132",
      "port": 5000,
      "checks": [
        {
          "name": "clientservice_check01",
          "http": "http://192.168.53.132:5000/api/health",
          "interval": "10s",
          "timeout": "5s"
        }
      ]
    },
    {
      "id": "CLIENT_SERVICE_02",
      "name": "CAS Client Service",
      "tags": [
        "urlprefix-/ClientService02"
      ],
      "address": "192.168.153.132",
      "port": 5001,
      "checks": [
        {
          "name": "clientservice_check02",
          "http": "http://192.168.153.132:5001/api/health",
          "interval": "10s",
          "timeout": "5s"
        }
      ]
    }
  ]
}

 

添加KEY/VALUE  

curl -X PUT -d 'edisonchou' http://192.168.80.100:8500/v1/kv/web/vhallaccount
  我们通过 http://192.168.153.129:8500/v1/kv/?recurse来查看这个值是否添加到Consul中
   再验证是否已经同步到其他Consul服务端,先看129,注意加粗字体
[root@localhost ~]# ./consul kv get web/vhallaccount
stevelee
[root@localhost ~]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens32: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether 00:0c:29:a6:a1:1c brd ff:ff:ff:ff:ff:ff
3: ens34: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:0c:29:a6:a1:26 brd ff:ff:ff:ff:ff:ff
    inet 192.168.153.129/24 brd 192.168.153.255 scope global noprefixroute ens34
       valid_lft forever preferred_lft forever
    inet6 fe80::6d21:aa51:2262:b80f/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

   再看130的Consul服务端

[root@localhost ~]# ./consul kv get web/vhallaccount
stevelee
[root@localhost ~]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens32: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:0c:29:2c:c2:fc brd ff:ff:ff:ff:ff:ff
    inet 192.168.153.130/24 brd 192.168.153.255 scope global noprefixroute ens32
       valid_lft forever preferred_lft forever
    inet6 fe80::6114:ed9c:c49d:649b/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
3: ens34: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:0c:29:2c:c2:06 brd ff:ff:ff:ff:ff:ff
    inet 192.168.153.170/24 brd 192.168.153.255 scope global noprefixroute dynamic ens34
       valid_lft 1216sec preferred_lft 1216sec
    inet6 fe80::a67c:7966:8767:27fb/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

 

   我们也可以通过Consul WEB UI来编辑KV值。

 

 Consul服务的Watch机制

   熔断保护在Consul和Ocelot中都有实现,意思就是当一个服务不正常时(比如我们的一个服务实例挂了,Consul的健康检查机制检测到了),应该给系统维护人员给以告警。在Consul中,服务告警也是通过配置文件来实现的。

{
  "watches": [
    {
      "type": "checks",
      "handler_type": "http",
      "state": "critical",
      "http_handler_config": {
        "path": "http://192.168.153.132:9000/notice",
        "method": "POST",
        "timeout": "10s",
        "header": { "Authorization": [ "token" ] }
      }
    }
  ]
}

  我们再新建一个项目,建立一个控制器,用默认的HomController控制器也可以,键入如下代码:

[Produces("application/json")]
public class HomeController : Controller
{
    [HttpPost]
    [Route("/notice")]
    public IActionResult Notice()
    {
        var stream = HttpContext.Request.Body;
        if (HttpContext.Request.ContentLength != null)
        {
            var buffer = new byte[HttpContext.Request.ContentLength.Value];
            stream.Read(buffer, 0, buffer.Length);
            var content = Encoding.UTF8.GetString(buffer);

            var path = $"{AppDomain.CurrentDomain.BaseDirectory}{DateTime.Now:hh_mm_ss_ffff}.log";
            if (!System.IO.File.Exists(path))
            {
                System.IO.File.Create(path).Close();
            }

            using (var sw = new StreamWriter(path))
            {
                sw.Write(content);
                sw.Flush();
                sw.Close();
            }

            return Ok();
        }

        throw new Exception("post is null");
    }
}
  功能很简单,做一个接受消息的客户端,POST方法,代码不解释。
  当我们把5000端口上的服务停掉,会出现什么样的情况呢?132Consul的客户端服务器就会出现:5000/api/health无法访问的问题。
2018/10/17 04:03:10 [WARN] agent: Check "service:CLIENT_SERVICE_01" HTTP request failed: Get http://192.168.153.132:5000/api/health: dial tcp 192.168.153.132:5000: connect: connection refused
2018/10/17 04:03:10 [INFO] agent: Synced check "service:CLIENT_SERVICE_01"
2018/10/17 04:03:20 [WARN] agent: Check "service:CLIENT_SERVICE_01" HTTP request failed: Get http://192.168.153.132:5000/api/health: dial tcp 192.168.153.132:5000: connect: connection refused
2018/10/17 04:03:30 [WARN] agent: Check "service:CLIENT_SERVICE_01" HTTP request failed: Get http://192.168.153.132:5000/api/health: dial tcp 192.168.153.132:5000: connect: connection refused
2018/10/17 04:03:40 [WARN] agent: Check "service:CLIENT_SERVICE_01" HTTP request failed: Get http://192.168.153.132:5000/api/health: dial tcp 192.168.153.132:5000: connect: connection refused
2018/10/17 04:03:50 [WARN] agent: Check "service:CLIENT_SERVICE_01" HTTP request failed: Get http://192.168.153.132:5000/api/health: dial tcp 192.168.153.132:5000: connect: connection refused
2018/10/17 04:04:00 [WARN] agent: Check "service:CLIENT_SERVICE_01" HTTP request failed: Get http://192.168.153.132:5000/api/health: dial tcp 192.168.153.132:5000: connect: connection refused

  Watch机制会每隔10s向http://192.168.153.132:9000/notice发送一组json格式的消息,内容如下

[{
    "Node": "LZZ.DEV.WebServer",
    "CheckID": "service:CLIENT_SERVICE_01",
    "Name": "clientservice_check01",
    "Status": "critical",
    "Notes": "",
    "Output": "Get http://192.168.153.132:5000/api/health: dial tcp 192.168.153.132:5000: connect: connection refused",
    "ServiceID": "CLIENT_SERVICE_01",
    "ServiceName": "CAS Client Service",
    "ServiceTags": ["urlprefix-/ClientService01"],
    "Definition": {
        "HTTP": "",
        "Header": null,
        "Method": "",
        "TLSSkipVerify": false,
        "TCP": "",
        "Interval": "0s",
        "Timeout": "0s",
        "DeregisterCriticalServiceAfter": "0s"
    }
}]
  你也可以将上面的notice方法替换为其他消息通知的方法,比如邮件,比如短信,我更推荐用短信模式,这样能马上告诉运维人员,有节点挂了,该去加班了。
  综合之前上一篇的介绍,目前看Consul的Web控制台,已经出现了10个微服务了(不包括系统)!

 

 

相关文章
|
运维 监控 负载均衡
动态服务管理平台:驱动微服务架构的高效引擎
动态服务管理平台:驱动微服务架构的高效引擎
291 17
|
弹性计算 API 持续交付
后端服务架构的微服务化转型
本文旨在探讨后端服务从单体架构向微服务架构转型的过程,分析微服务架构的优势和面临的挑战。文章首先介绍单体架构的局限性,然后详细阐述微服务架构的核心概念及其在现代软件开发中的应用。通过对比两种架构,指出微服务化转型的必要性和实施策略。最后,讨论了微服务架构实施过程中可能遇到的问题及解决方案。
|
运维 监控 负载均衡
探索微服务架构下的服务治理:动态服务管理平台深度解析
探索微服务架构下的服务治理:动态服务管理平台深度解析
|
运维 监控 安全
探索微服务架构下的服务治理:动态服务管理平台的力量
探索微服务架构下的服务治理:动态服务管理平台的力量
|
Cloud Native Java API
聊聊从单体到微服务架构服务演化过程
本文介绍了从单体应用到微服务再到云原生架构的演进过程。单体应用虽易于搭建和部署,但难以局部更新;面向服务架构(SOA)通过模块化和服务总线提升了组件复用性和分布式部署能力;微服务则进一步实现了服务的独立开发与部署,提高了灵活性;云原生架构则利用容器化、微服务和自动化工具,实现了应用在动态环境中的弹性扩展与高效管理。这一演进体现了软件架构向着更灵活、更高效的方向发展。
|
弹性计算 Kubernetes API
构建高效后端服务:微服务架构的深度剖析与实践####
本文深入探讨了微服务架构的核心理念、设计原则及实现策略,旨在为开发者提供一套系统化的方法论,助力其构建灵活、可扩展且易于维护的后端服务体系。通过案例分析与实战经验分享,揭示了微服务在提升开发效率、优化资源利用及增强系统稳定性方面的关键作用。文章首先概述了微服务架构的基本概念,随后详细阐述了其在后端开发中的应用优势与面临的挑战,最后结合具体实例,展示了如何从零开始规划并实施一个基于微服务的后端项目。 ####
|
NoSQL 前端开发 测试技术
👀探秘微服务:从零开启网关 SSO 服务搭建之旅
单点登录(Single Sign-On,简称SSO)是一种认证机制,它允许用户只需一次登录就可以访问多个应用程序或系统。本文结合网关和SaToken快速搭建可用的Session管理服务。
1218 8
|
弹性计算 持续交付 API
构建高效后端服务:微服务架构的深度解析与实践
在当今快速发展的软件行业中,构建高效、可扩展且易于维护的后端服务是每个技术团队的追求。本文将深入探讨微服务架构的核心概念、设计原则及其在实际项目中的应用,通过具体案例分析,展示如何利用微服务架构解决传统单体应用面临的挑战,提升系统的灵活性和响应速度。我们将从微服务的拆分策略、通信机制、服务发现、配置管理、以及持续集成/持续部署(CI/CD)等方面进行全面剖析,旨在为读者提供一套实用的微服务实施指南。
|
机器学习/深度学习 运维 监控
动态服务管理平台:构建高效、灵活的微服务架构基石
动态服务管理平台:构建高效、灵活的微服务架构基石
263 17
|
Kubernetes 负载均衡 Docker
构建高效后端服务:微服务架构的探索与实践
【10月更文挑战第20天】 在数字化时代,后端服务的构建对于任何在线业务的成功至关重要。本文将深入探讨微服务架构的概念、优势以及如何在实际项目中有效实施。我们将从微服务的基本理念出发,逐步解析其在提高系统可维护性、扩展性和敏捷性方面的作用。通过实际案例分析,揭示微服务架构在不同场景下的应用策略和最佳实践。无论你是后端开发新手还是经验丰富的工程师,本文都将为你提供宝贵的见解和实用的指导。
181 27