consul

首届云原生编程挑战赛正在报名中，初赛共有三个赛道，题目如下： 赛道一：实现一个分布式统计和过滤的链路追踪 赛道二：实现规模化容器静态布局和动态迁移 赛道三：服务网格控制面分治体系构建 立即报名 （报名时间即日起至06/29）： https://tianchi.aliyun.com/specials/promotion/cloudnative#problem-definition 本文主要针对赛道三题目做出剖析，帮助选手更高效的解题。 背景知识 “服务网格” 是近年来非常火热的技术，其全托管的思维非常适合云原生场景。“服务网格” 核心分为控制面与数据面：数据面主要是一个名为 Sidecar 的代理组件，它通过接收控制面发送的路由与控制信息来定向转发或处理数据。这样一些坐落在服务网格里的应用就将整个分布式逻辑交给了底层，自己不用关心了。一旦与底层解耦，灵活性大大增加，更符合云原生的标准。 题目解析 本题的核心考查点还是如何让服务网格的控制面支撑大规模的 Sidecar 实例。为什么会产生这个问题呢？因为在目前服务网格影响最广的实现 Istio 架构中，控制平面 Pilot 负责整个系统的路由转译工作，也就是说所有服务的实例信息都需要通过 Pilot 下发给每一个 Sidecar，当然用户可以通过 SidecarScope 来设置个别 Sidecar 对于系统服务的可见性，但这只会影响到

#Spring Boot Admin简介及实践 ##来源背景 codecentric的Spring Boot Admin是一个社区项目， 用于管理和监视您的Spring Boot®应用程序。这些应用程序在我们的 Spring Boot Admin Client中注册（通过HTTP），或者是通过Spring Cloud® （例如Eureka，Consul）发现的。 UI只是Spring Boot Actuator端点之上的Vue.js应用程序。 ##功能介绍 Spring Boot Admin提供了很多服务治理方面的功能，利用它能节省我们很多在治理服务方面的时间和精力。 Spring Boot Admin提供了如下功能（包括但不限于）： 显示健康状态及详细信息，如JVM和内存指标、数据源指标、缓存指标 跟踪并下载日志文件 查看jvm系统-和环境属性 查看Spring启动配置属性 方便loglevel管理 查看线程转储 视图http-traces 查看http端点 查看计划任务 查看和删除活动会话(使用spring-session) 状态更改通知(通过电子邮件、Slack、Hipchat…) 状态变化的事件日志(非持久性) ##搭建Spring Boot Admin Server 在编写本文的时候，Spring Boot Admin的最新版本为： 2.2.7

介绍 微服务中有关键的几项技术，其中网关和服务服务发现，服务注册相辅相成。 首先解释几个本次教程中需要的术语 网关 Gateway（API GW / API 网关），顾名思义，是企业 IT 在系统边界上提供给外部访问内部接口服务的统一入口，简化了外部由于多服务协同完成任务时的繁琐配置。网关组件有Kong，ocelot, 服务发现 ：通过网关访问内部各个微服务，网关要找到所需服务的过程称为服务发现 服务注册 ：既然有服务发现，前提是要把所需服务提前“录入”，这个录入的过程称为服务注册。服务注册可配置文件（人肉方式不推荐），也可用服务注册组件如Consul或者Eureka等等（推荐） 搭建Consul集群(Windows) 官网下载Consul程序，https://www.consul.io/downloads.html 下载下来就是一个可执行文件Consul.exe Consul有两种代理模式，一种server,一种client,官方建议Server端达到3台以上才可高可用，但不要太多，太多会给集群间数据同步造成压力，client数量不限。 多个server端之间会选择出一个leader,当一个server的leader宕机则会从其他server端”投票“选择新的leader 实践 这里server我们用2台实验 192.168.74.55 192.168.74.54

变化 变化项 类型 1.6(.3) 1.5或之前 意义 移除 组件 Citadel、Sidecar Injector、Galley 1.5为完成的收尾 强化 功能项 删减的功能，合并入 Istiod 替换 安装 增加： istioctl install； 替换 manifest apply 移除 配置 废弃的 Helm charts、istio-pilot 的配置 增加 功能项 虚拟机支持（WorkloadEntry） 独立于K8S的准备？ 移除 组件 Envoy proxy Mixer Mixer的功能已经被移入Envoy proxy，目前为 废弃&未移除状态，1.7后会彻底移除 增加 功能项 Envoy，将 Wasm/WebAssembly 功能移除 代码目录说明 基于 v1.6.3 (2020.06.22) bin/：二进制生成脚本等 common/： 少量编译处理 一些依赖处理 common-protos/：大量proto文件，用于内部各组件(包括第三方组件)高效RPC docker/：ca证书 & Dockerfile.base，顾名思义 galley/：没有变化，独立组件，负责配置管理，包括 验证配置信息格式和内容正确性 屏蔽配置的底层处理细节 将配置提供给其他组件用 install/：安装？ consul/：安装和consul的支持 gcp/：安装对Google

在我接触互联网的最初几年，总会在技术论坛上看到有人宣称：技术是没有国界的，我深信不疑！ 做程序员之后，我慢慢接触到了很多很多的开源软件，我真的无比的感慨：开源是人类最伟大的发明。 那时候国内的开源项目还很少， 不像现在 BAT 等等国内一线公司，也都热衷于开源建设，到了后面我也有幸在开源有了一丁点的贡献。 但是近2年，突然觉得“技术无国界”就是一句笑话！ 1、HashiCorp 昨天（2020-05-29）大批 Terraform 用户表示，Terraform 软件在中国境内不能使用了！ Terraform 是一种安全有效地构建、更改和版本控制基础设施的工具(基础架构自动化的编排工具)，Terraform 几乎可以支持所有市面上能见到的云服务。 Terraform 是 HashiCorp 公司的产品，HashiCorp 公司旗下有很多著名的开源软件，比如：Consul、Vault、Nomad 等。 HashiCorp 成立于2012年，是一家企业级服务公司，总部位于旧金山，有85%的员工分部在全球各地进行远程工作。 因为之前使用 Spring Cloud 比较多，因此对 Consul 了解多一些，也写过几篇关于 Consul 使用的文章，因此也被拉进了他们官方群里。 私下员工的回复是： 公司不允许卖一些产品到国内，主要原因可能是无法满足国内的法律要求， 他们也在等待法务的具体消息。

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

背景 前段时间有新闻报道，国外HashiCorp在官网宣布：不允许中国境内使用、部署和安装该企业旗下的企业版产品和软件。 其中Consul是Java的spring cloud开发者非常熟悉的一个服务发现和配置中心的中间件，很多人担心是否Consul会受到影响，目前来看HashiCorp只是对商业版进行了禁止使用，还没有对开源版本进行限制，所以使用Consul的小伙伴不用担心。但是随着时间的发展，不同地区的对抗会不断的升级，说不定有一天开源的版本会被也会被宣布禁用，所以我们需要知道如何去替代Consul。 在2008年的时候，那个时候zk还没出来，阿里巴巴当时内部需要做服务发现，于是自研了ConfigServer，过了十年，在2018年7月的时候，阿里发布了Nacos（ConfigServer开源实现）0.1.0版本，到现在快两年了已经到了1.3.0版本，现在已经可以支持很多功能了： 服务注册和发现：nacos和很多rpc框架已经做了集成，比如dubbo,SpringCloud等，方便我们拿来即用，同时也开放了比较简易的api方便我们对自己的rpc进行定制。 配置管理：类似apllo的一个配置管理中心，让我们不用把配置写在文件中了，在后台进行统一的管理。 地址服务器: 方便我们对不同环境不同隔离场景的nacos进行寻址。 安全与稳定性: 性能监控，加密传输，权限控制管理等等。

生产环境Kubernetes Consul最佳实践 本指南为Consul agent在K8s中的运行方式，Server端建议运行在物理机上。 Consul的安装方式请参考本人的另一篇博文 Consul集群安装 ，这里不做过多描述。 本方案已在生产环境中经过验证，暂时没有发现使用问题。 Kubernetes中运行Consul agent的问题及应对方法 问题 业务如何去连接Consul agent。(Consul有一个特性为从哪台客户端注册的服务就要从哪台客户端反注销)。 Consul agent启动的时候会根据主机名、IP等信息在data目录下生成自己的node-id等元数据。如果未持久化data目录，未使用主机网络，当Pod更新的时候，主机名和IP地址会改变。导致在Consul中出现同一个IP地址对应两个主机名的情况。服务注册就会出现问题。 第2中情况在生产环境中已遇到多次，同事更改了主机名称就导致在Consul集群中同一个IP对应两个主机名的情况。导致服务运行异常。 解决方法 Consul-agent以DaemonSet的方式运行，通过使用主机网络(hostNetwork)。保持主机名和IP地址不变。将Consul的元数据持久化到宿主机的目录，这样Consul更新的时候，重新读取这个目录。不会重新生成node-id等元数据。

配置中心作用 分布式系统中，项目越来越大，子项目越来越多，配置文件也协同零零散散的子项目星罗棋布，往往更改一个基础服务的配置要导致一些列重启，造成运维困难，维护成本高而且容易出错。为了解决这一问题，配置中心应运而生。配置中心开源项目比较多，这里主要介绍Cloud全家桶的Spring Cloud Config。 Consul Consul也可以作为配置中心，之前文章有介绍： Spring Cloud: 注册中心Consul使用 ， 但是功能较少，没有远程服务 Spring Cloud Config SpringCloud Config是一套为分布式系统中的基础设施和微服务应用提供集中化配置的管理方案，分为服务端与客户端两个部分。基于Config服务器，就可以集中管理各种环境下的各种应用的配置信息。客户端和服务器端与Spring中的Environment和PropertySource概念相匹配，所以这不仅适用于所有的Spring应用，而且对于任意语言的应用都能够适用。一个应用可能有多个环境，从开发到测试，再到生产环境，开发者可以管理这些不同环境下的配置，而且能够确保应用在环境迁移后有完整的配置能够正常运行。Config服务端默认的存储实现是Git，这能够很容易地支持配置环境的标签版本，而且有各种工具方便地管理这些配置内容。 配置中心实践 服务器端 1. 创建consul-config

。。。。。 来源： oschina 链接： https://my.oschina.net/u/4419233/blog/4280808