consul

#程序员薪资揭榜#你做程序员几年了？月薪多少？发量还在么？>>> 国外HashiCorp在官网宣布：不允许中国境内使用、部署和安装该企业旗下的产品和软件。 消息来源hashicorp官网: https://www.hashicorp.com/terms-of-evaluation Terraform ：Terraform 是一种安全有效地构建、更改和版本控制基础设施的开源工具(基础架构自动化的编排工具)。它的目标是 "Write, Plan, and create Infrastructure as Code", 基础架构即代码，Terraform也提供了Kubernetes应用程序的完整生命周期管理，包含Pod的创建、删除以及副本控制等。国内众多公有云都支持Terraform。 Consul ：是一个支持多数据中心分布式高可用的服务发现和配置共享的服务软件,由 HashiCorp 公司用 Go 语言开发，目前在国内也有大量的使用和落地案例。 Vagrant ：也是一个比较流行的虚拟机管理软件，使用Vagrant 可以让我们用命令直接从云上下载虚拟机的镜像，然后进行创建和管理等。 国产加油！ 中国加油！ 来源： oschina 链接： https://my.oschina.net/u/4364212/blog/4297773

配置中心预研 概述 随着程序功能的日益复杂，程序的配置日益增多：各种功能的开关、参数的配置、服务器的地址…… 对程序配置的期望值也越来越高：配置修改后实时生效，分环境、分集群管理配置，代码安全、审核机制…… 在这样的大环境下，传统的通过配置文件、数据库等方式已经越来越无法满足开发人员对配置管理的需求。 所以，配置中心应运而生。 选型思路 1、询问几个道友（多询问几个不同的群的道友，防止人云亦云） 2、百度大范围搜大致的看 选中几个使用广、文档多的 3、github对比issues、pull requests、insights、commits、branches、tags 4、语言对比、性能对比(通过CNCF对比) 询问道友 大致得出的可选组件为：apollo nacos eureka zk consul 百度大范围搜索 名词解释 CAP理论： CAP理论是分布式架构中重要理论 一致性(Consistency) (所有节点在同一时间具有相同的数据) 可用性(Availability) (保证每个请求不管成功或者失败都有响应) 分隔容忍(Partition tolerance) (系统中任意信息的丢失或失败不会影响系统的继续运作) CAP 不可能都取，只能取其中2个 原因是 如果C是第一需求的话，那么会影响A的性能，因为要数据同步，不然请求结果会有差异，但是数据同步会消耗时间

可以看到，在 Targets 中能够成功的自动发现 Consul 中的 Services 信息，后期需要添加新的 Targets 时，只需要通过 API 往 Consul 中注册服务即可，Prometheus 就能自动发现该服务，是不是很方便。 不过，我们会发现有如下几个问题： 会发现 Prometheus 同时加载出来了默认服务 consul，这个是不需要的。 默认只显示 job 及 instance 两个标签，其他标签都默认属于 before relabeling 下，有些必要的服务信息，也想要在标签中展示，该如何操作呢？ 如果需要自定义一些标签，例如 team、group、project 等关键分组信息，方便后边 alertmanager 进行告警规则匹配，该如何处理呢？ 所有 Consul 中注册的 Service 都会默认加载到 Prometheus 下配置的 consul_prometheus 组，如果有多种类型的 exporter，如何在 Prometheus 中配置分配给指定类型的组，方便直观的区别它们？ 以上问题，我们可以通过 Prometheus 配置中的 relabel_configs 参数来解决 我们先来普及一下 relabel_configs 的功能， Prometheus 允许用户在采集任务设置中，通过 relabel_configs 来添加自定义的

Consul服务器配置 微服务带来最大的好处就是把整个大项目分割成不同的服务，运行在不同服务器上，实现解耦和分布式处理。微服务虽然有很多好处，但是也会有不好的一方面。任何事物都会有两面性，在微服务里面运维会是一个很大的难题，如果有一天我们的服务数量非常的多，然后我们又不知道哪一个服务在什么机器上。 可能会有人说这部分直接写在程序的配置里面就好了，当我们服务少的时候是可以这么做的，也允许这么做，但是在实际当中我们要尽量避免这么做，比如说我们某一个服务，地址换了，那么我们设计的相关代码就得修改重新部署；又或者说我们有一天上线一个新服务或者下线一个服务，这时候我们又得修改程序代码，这是非常不合理的做法。那么有没有什么可以解决这样的问题呢？这里就需要用到我们的服务注册和发现了。 结构对比 没有服务注册发现的结构 <center>没有服务发现的架构</center> 上面图片我们可以看到在没有服务注册发现的时候一个调用者需要维护多个服务的ip和端口，这是非常不好的做法，当我们服务进行调整的时候就有可能导致服务调用失败，还有服务器更换服务器，上下新服务，都会受到影响。将来某一个服务节点出现问题，排查对于程序和运维人员来说都是一场很大的灾难，因为不知道哪一个节点出了问题，需要每一台服务器的去排查。 而当我们有使用服务注册发现之后的结构体是什么样子的呢？ 有服务注册发现的结构 <center

阅读时长：3分钟 操作系统：Windows10 一、consul的安装 首先在consul.exe文件目录下的地址栏中输入cmd。 接着输入consul指令，敲击回车安装consul。 安装成功后会有如下指令提示。 二、consul的启动 输入consul agent -dev指令，敲击回车启动consul。 启动后输入如下地址： http://localhost:8500 ，看是否能显示如下页面。可以则成功。 三、环境变量的配置 Windows+R打开运行输入sysdm.cpl指令打开系统属性面板。按照如图步骤新建consul路径的环境变量。成功后可直接在命令提示符面板中输入consul命令了。 四、资源分享 consul 1.7.2 Windows版本（微云网盘）： https://share.weiyun.com/lSje6nxR 密码：c5x4xx 如果有帮助到你，请点个赞哦。如果有什么问题，请评论，一起探讨一下。共同进步！如有什么需要与作者联系的，直接私信SCscHero即可。 来源： oschina 链接： https://my.oschina.net/u/4341499/blog/4314226

consul+upsync+nginx实现动态负载均衡 原理： 将upstream配置与Nginx本身解耦，实现在线修改upstream信息nginx动态生效。 优势：1、无需登录服务器配置 2、避免nginx进行reload 3、在线配置，后期更容易实现蓝绿。与Apollo这种类似，但需要借助upsync模块 安装nginx支持upsync： 测试: nginx version: nginx/1.12.2 可行 --add-module=/tmp/nginx-upsync-module cd /tmp/ git clone https://github.com/weibocom/nginx-upsync-module.git ./configure --prefix=/data1/nginx/release/{{dir_date}} --conf-path=/data1/nginx/release/{{dir_date}}/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --user=nginx --group

集成.NET Core+Swagger+Consul+Polly+Ocelot+IdentityServer4+Exceptionless+Apollo的微服务开发框架 Github源代码地址 https://github.com/PeyShine/Demo.MicroServer Apollo配置中心 Apollo（阿波罗）是携程框架部门研发的分布式配置中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。 由于各个项目配置都需要读取基础的配置信息，这边在内网的Centos(101)上部署了Apollo的环境，并为项目添加了一些基础配置信息，配置如图 Consul Consul是一种服务网格解决方案，提供具有服务发现，健康检查，Key/Value存储，多数据中心等功能。 在内网101启动Consul服务，这里为了测试，直接在本地将用户服务实例分别在三个端口启动起来，实际生产中这些服务可能部署在不同的机房不同的机器，他们之间组成一个服务的集群，服务提供一个心跳检测的方法，用于consul定时检测服务实例是否健康，启动时在consul中进行一次注册，这个就是经常说的‘服务注册与发现’中的服务注册，三个服务实例截图如下 注册完成之后打开consul的ui界面可以看到

OAuth2 OAuth2是当前授权的行业标准，其重点在于为Web应用程序、桌面应用程序、移动设备以及室内设备的授权流程提供简单的客户端开发方式。它为第三方应用提供对HTTP服务的有限访问，既可以是资源拥有者通过授权允许第三方应用获取HTTP服务，也可以是第三方以自己的名义获取访问权限。 角色 OAuth2中主要分为了4种角色： Resource Owner（资源所有者），是能够对受保护的资源授予访问权限的实体，可以是一个用户，这时会称为终端用户（end-user）。 Resource Server（资源服务器），持有受保护的资源，允许持有访问令牌（Access Token）的请求访问受保护资源。 Client（客户端），持有资源所有者的授权，代表资源所有者对受保护资源进行访问。 Authorization Server（授权服务器），对资源所有者的授权进行认证，成功后向客户端发送访问令牌。 很多时候，资源服务器和授权服务器是合二为一的，在授权交互的时候作为授权服务器，在请求资源交互时作为资源服务器 Resource Server的配置 Resource Server（可以是授权服务器，也可以是其他的资源服务）提供了受OAuth2保护的资源，这些资源为API接口、Html页面、Js文件等.Spring OAuth2提供了实现此保护功能的Spring Security认证过滤器

前言 昨天HashiCorp突然发布一则消息，禁止在中国使用Vault软件的企业版本，官方申明是这样的： HashiCorp的解释是因为中国的出口管制的原因导致无法出售HASHICORP软件或者使用企业版的Vault。所以在没有取得HashiCorp书面协议的前提下，不得在中国境内使用，部署和安装HashiCorp的Vault企业版本软件。 注意，这里只是禁止使用企业版本的Vault软件，个人版本和HashiCorp公司的其他软件并不在此限制之内。大家不要被网络上面的谣言所迷惑，一定要勇于探索真理。 HashiCorp公司介绍 那么这个影响到底对我们有多大呢？我们先看下HashiCorp公司的成长史。 更多精彩内容且看： 区块链从入门到放弃系列教程-涵盖密码学,超级账本,以太坊,Libra,比特币等持续更新 Spring Boot 2.X系列教程:七天从无到有掌握Spring Boot-持续更新 Spring 5.X系列教程:满足你对Spring5的一切想象-持续更新 java程序员从小工到专家成神之路（2020版）-持续更新中,附详细文章教程 HashiCorp于2012年成立，由Mitchell Hashimoto和Armon Dadgar创办，并陆续推出了Vagrant、Packer 、 Terraform、Consul , Vault 和 Nomad以满足不同的需求。

本文源码： GitHub·点这里 || GitEE·点这里 一、注册中心简介 1、基础概念 在分布式架构的系统中注册中心这个概念就已经被提出了，最经典的就是Zookeeper中间件。 微服务架构中，注册中心是最核心的基础服务之一，注册中心可以看做是微服务架构中的通信中心，当一个服务去请求另一个服务时，通过注册中心可以获取该服务的状态，地址等核心信息。 服务注册主要关系到三大角色：服务提供者、服务消费者、注册中心。 2、流程和原理 基础流程 服务启动时，将自身的网络地址等信息注册到注册中心，注册中心记录服务注册数据。 服务消费者从注册中心获取服务提供者的地址，并通过地址和基于特定的方式调用服务提供者的接口。 各个服务与注册中心使用一定机制通信。如果注册中心与服务长时间无法通信，就会注销该实例，这也称为服务下线，当服务重新连接之后，会基于一定的策略在线上线。 服务地址相关信息发生变化时，会重新注册到注册中心。这样，服务消费者就无需手工维护提供者的相关配置。 核心功能 通过上面的基本流程，不难发现一个注册中心需要具备哪些核心功能： 服务发现 服务发现是指服务在启动后，注册到注册中心，服务方提供自身的元数据，比如IP地址、端口、运行状况指标的Uri 、主页地址等信息。 服务记录 记录注册中心的服务的信息，例如服务名称、IP地址、端口等。服务消费方基于查询获取可用的服务实例列表。