咱们在 ifconfig 查看网卡配置时或者嵌入式开发的时候，常常会看到rx/tx缩写。 或者在大打印机或者很多网络设备上都会看到这 2 个字符。 RX==receive，接管，从开启到当初接管封包的状况，是上行流量（Downlink）。TX==Transmit，发送，从开启到当初发送封包的状况，是上行流量（Uplink）。 其实也十分好了解，R 是单词 receive 的结尾字母，T 是单词 Transmit 的结尾字母。 这个是针对你以后所在的设施上说的，对应的的设施就正好是反过来的。 https://www.ossez.com/t/rx-tx...
简介：本文作者【紫极zj】，本篇将次要介绍通过配置审计的自定义规定等服务，对负载平衡进行预警行为的相干介绍。 前言配置审计（Config）将您扩散在各地区的资源整合为全局资源列表，可便捷地搜寻全局资源，并通过规定对资源配置进行评估，过滤出不合乎业务要求的资源变配操作。本文为您介绍如何通过配置审计（Config）的自定义规定和日志服务（SLS）报警配合，对指定的负载平衡（SLB）变配进行报警，帮忙企业疾速感知变配内容并及时做出相应对策。 背景云上账号次要有阿里云主账号、RAM子账号、RAM角色，阿里云主账号对所有资源都有残缺的控制能力，一些被赋予高级权限的RAM子账号、RAM角色等也同样能够管制资源。如何在变更操作之前阻断该行为，是服务控制策略（SCP）的领域（该服务限度只能是企业认证账户，并且开明了资源目录（Resource Directory）才可施行），本文暂不探讨。如何在变配后疾速感知到变动也十分重要。公司A的运维同学向咱们提了一个问题：公司的外围业务部署在阿里云上，采纳的架构是弹性计算ECS+负载平衡（SLB）+关系型数据库RDS，每天都放心外围服务异样变配导致业务中断，心愿变配后及时收到音讯告诉，想问问有没有什么计划。咱们为他们举荐了配置审计（Config）联合日志服务（SLS）的报警。那这个产品组合是如何实现以上指标的呢？ 流程图 整个计划的流程图如上所示。员工A批改了企业某外围业务负载平衡（SLB）的配置。资源变配数据会被配置审计（Config）感知并存储，同时会触发监听该类资源变动的规定进行评估。规定引擎接管的入参蕴含了资源变动的 Diff 数据，如果该规定为自定义规定，规定引擎会执行配置好的函数计算（FC）的函数。函数过滤出指标资源的变更，并将变更数据写入日志服务（SLS）中。日志服务通过配置告警策略，触发告警并告诉管理员。另外两条实线示意管理员能够返回配置审计（Config）查看资源工夫线以及通过日志服务（SLS）查看资源具体的配置变更信息。 新建一个日志库（logstore） 新建日志库（logstore），用于存储指标资源的变配数据，同时咱们能够基于这个日志库（logstore）配置告警策略；具体如何创立日志我的项目（project）及日志库（logstore），这里我就不再赘述，您可参考日志服务的文档进行操作。本案例对应的日志我的项目为: aliyun-fc-cn-hangzhou-26064c43-65dc-5734-8175-3c0fdfc784df ，日志库为: specific-config-alert 。 新建函数计算（FC）的函数 配置审计（Config）的自定义规定是基于函数计算（FC）实现的。函数所属的地区是不受限制的。本案例抉择地区为华东1（杭州）。 我是基于 alimebot-nodejs 模板创立的函数。 咱们在 ConfigService 这个服务上面新建一个名为 specific-config-change-alert 的函数。 函数的外部的业务逻辑，咱们进行如下设计： 反对用户额定指定一个参数 arn ，不便咱们对某一个特定的资源进行报警；如果不指定 arn，则示意对该类型的资源变更都进行告警；调用日志服务（SLS）的SDK，将日志存入日志库（logstore）；代码逻辑如下 const ALY = require('aliyun-sdk'); // 日志服务Nodejs SDKexports.handler = function (event, context, callback) { const sls = new ALY.SLS({ "accessKeyId": context.credentials.accessKeyId, //阿里云拜访密钥AccessKey ID。更多信息，请参见拜访密钥。阿里云主账号AccessKey领有所有API的拜访权限，危险很高。强烈建议您创立并应用RAM账号进行API拜访或日常运维。 "secretAccessKey": context.credentials.accessKeySecret, //阿里云拜访密钥AccessKey Secret。 "securityToken": context.credentials.securityToken, //RAM角色额定输出的securityToken endpoint: 'http://cn-hangzhou.log.aliyuncs.com', //日志服务的域名。更多信息，请参见服务入口。此处以杭州为例，其它地区请依据理论状况填写。 apiVersion: '2015-06-01' //SDK版本号，固定值。 }); // ------------------------------- // put logs // ------------------------------- const projectName = "aliyun-fc-cn-hangzhou-26064c43-65dc-5734-8175-3c0fdfc784df"; //刚刚创立的日志我的项目 const logStoreName = "specific-config-alert"; //刚刚创立的日志库 const parsed = JSON.parse(event); //将入参转化为js对象 if (!parsed || !parsed.invokingEvent) { //配置审计调用时传入的参蕴含: invokingEvent(变更数据), ruleParameters(函数规定额定传入的用户自定义参数), resultToken callback(null, event); return; } const specificArn = parsed.ruleParameters && parsed.ruleParameters.arn; //函数规定容许用户传入的自定义的资源arn const transformData = Object.keys(parsed.invokingEvent).map(function(k) { return { key: k, value: JSON.stringify(parsed.invokingEvent[k])}}); // 日志服务须要的格局 const logGroup = { logs : [{ time: Math.floor(new Date().getTime()/1000), contents: transformData }], topic: 'special-config-change' }; const resourceArn = parsed.invokingEvent && parsed.invokingEvent.configurationItem && parsed.invokingEvent.configurationItem.arn; if (!specificArn || specificArn === resourceArn) { // 如果规定中未指定具体资源arn，则默认所有过滤到的资源类型都写到日志服务（SLS） sls.putLogs({ projectName: projectName, logStoreName: logStoreName, logGroup: logGroup }, function (err, data) { if (err) { callback(err); return; } callback(null, data); }); } else { callback(null); }}函数是以指定的RAM角色来执行的，所以须要给指定的RAM角色进行受权，本案例须要给RAM角色受权可能写指定日志库的权限。 ...
config概述配置核心提供了一个中心化的内部配置，默认应用git存储配置信息，这样就能够对配置信息进行版本治理，下边配置核心的搭建就是以git为根底进行的。配置核心是独自作为一个服务运行的。 spring cloud 容许运行时动静刷新配置，能够从新从配置核心获取新的配置信息。bootstrap.yml疏导配置文件，先于 application.yml 加载。 config实现第一步：新建java我的项目config当作一个文件夹，用来寄存配置文件。 第二步：赋值sp02、03、04、11的配置文件至config，并重命名spring的profile文件阐明： #item-service.yml - 主配置#item-service-dev.yml - 开发 开发时启动，主+开发合并，同时启动。#item-service-test.yml - 测试#item-service-dev.prod - 生产#item-service-xxx.yml -第三步：config中的4个配置文件均增加配置并正文sp02、sp03、sp04、sp11的配置文件 #增加配置，当近程仓库的配置与本地仓库的配置抵触时，以本地仓库的配置为主cloud:config:override-none: true别离创立配置文件item-service-dev.yml： # item-service-dev.yml#给利用起个名，向注册核心注册时用这个名称注册#注册信息：item-service ----->localhost:spring: application: name: item-service #设置禁止配置核心的配置将客户端配置笼罩掉 cloud: config: override-none: trueserver: port: 8001eureka: client: service-url: defaultZone: http://eureka1:2001/eureka,http://eureka2:2002/eureka正文sp02、sp03、sp04、sp11的配置文件： ## application.yml###给利用起个名，向注册核心注册时用这个名称注册##注册信息：item-service ----->localhost:#spring:# application:# name: item-service##server:# port: 8001##eureka:# client:# service-url:# defaultZone: http://eureka1:2001/eureka,http://eureka2:2002/eureka第四步：创立本地仓库抉择本地仓库目录和文件第五步：把本地仓库提交推送到gitee近程仓库1.点击commit2.勾选要提交的文件，填写提交信息，进行提交点击commit，提交文件至本地仓库3.gitee上创立仓库springcloud1复制仓库地址4.点击push，开始从本地仓库推送至近程仓库。填写链接点击okpush推送查看是否推送胜利第六步：创立springboot我的项目sp12-config第七步：增加config server、eureka依赖 <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-config-server</artifactId></dependency><dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId></dependency>第八步：配置pom文件 spring: application: name: config-server cloud: config: server: git: uri: https://github.com/duchaosa/springcloud1 searchPaths: config #username: your-username #password: your-passwordserver: port: 6001eureka: client: service-url: defaultZone: http://eureka1:2001/eureka, http://eureka2:2002/eureka第九步：主程序增加注解@EnableConfigServer 和 @EnableDiscoveryClient ...
前言在现如今的应用中，日志已经成为了一个非常重要的工具。通过系统打印的日志，可以监测系统的运行情况，排查系统错误的原因。日志从最早期的System.out.print到如今各种成熟的框架，使得日志打印更加规范化和清晰化。尤其是SLF4J的出现，为日志框架定义了通用的FACADE接口和能力。只需要在应用中引入SLF4J包和具体实现该FACADE的日志包，上层应用就可以只需要面向SLF4J接口编程，而无需关心具体的底层的日志框架，实现了上层应用和底层日志框架的解耦。Logback作为一个支持SLF4J通用能力的框架，成为了炙手可热的日志框架之一。今天就来稍微了解一下Logback日志的一些基础能力以及配置文件。 快速上手Logback引入MAVEN依赖logback主要由三个模块组成，分别是logback-core,logback-classic和logback-access。其中logback-core是整个Logback的核型模块，logback-classic支持了SLF4J FACADE，而logback-access则集成了Servlet容齐来提供HTTP日志功能，适用于web应用。下面主要是基于logback-classic来进行介绍。 引入logback-classic的包如下： <dependency> <groupId>ch.qos.logback</groupId> <artifactId>logback-classic</artifactId> <version>1.3.0-alpha5</version></dependency>上面拉取的Maven包基于传递性远离，会自动拉取logback-classic，logback-core和slf4j-api.jar，因此无需在项目中再额外声明SLF4J和logback-core的依赖。 使用Logback因为logback-classic实现了SLF4J FACADE，所以上层应用只需要面向SLF4J的调用语法即可。下面代码展示了如何获取到Logger对象用来打印日志。 import org.slf4j.Logger;import org.slf4j.LoggerFactory;import ch.qos.logback.classic.LoggerContext;import ch.qos.logback.core.util.StatusPrinter;public class HelloWorld2 { public static void main(String[] args) { //这里的Logger和LoggerFactory均为SLF4J的类，真正调用时会使用Logback的日志能力 //getLogger方法中传入的是Logger的名称，这个名称在后面讲解配置文件中的<logger>时会继续提到 Logger logger = LoggerFactory.getLogger("chapters.introduction.HelloWorld2"); //打印一条Debug级别的日志 logger.debug("Hello world."); //获取根Logger，使用场景比较少 Logger rootLogger = LoggerFactory.getLogger(org.slf4j.Logger.ROOT_LOGGER_NAME); }}日志级别Logback中每一个Logger都有对应的日志级别，该日志级别可以是Logger自己定义的，也可以是从父Logger上继承下来的。Logback一共支持5个日志级别，从高到低分别是ERROR，WARN，INFO，DEBUG，TRACE。Logger的日志级别决定了哪些级别的日志可以被输出。只有大于等于该Logger级别的日志才会被打印出来。比如假设上文中获取的名为"chapters.introduction.HelloWorld2"的Logger日志级别为INFO，则调用logger.debug("xxx")不会输出日志内容，因为DEBUG日志级别低于INFO日志级别。 日志级别可以帮助我们控制日志打印的粒度，比如在开发环境可以将日志级别设置到DEBUG帮助排查问题，而在生产环境则可以将日志级别设置到INFO，从而减少不必要的打印日志带来的性能影响。 参数化输出有时候我们往往并不只是打印出一条完整的日志，而是希望在日志中附带一些运行中参数，如下： Logger logger = LoggerFactory.getLogger("chapters.introduction.HelloWorld2");logger.debug("Hello World To " + username);上文的日志中除了打印了一些结构化的语句，还拼接了运行时执行这段逻辑的用户的名称。这里就会带来一个问题，即字符串拼接的问题。虽然JVM对String字符串的拼接已经进行了优化，但是假如当前的日志级别为INFO，那么这段代码所执行字符串拼接操作就是完全不必要的。因此，建议在代码加上一行日志级别的判断进行优化，如下： //非debug级别不会执行字符串拼接操作，但是debug级别会执行两次isDebugEnabled操作，性能影响不大if(logger.isDebugEnabled()) { logger.debug("Hello World To " + username);}但是，logback并不推荐在系统中使用字符串拼接的方式来输出日志，而是提倡使用参数传递的方式，由logback自己来执行日志的序列化。如下： //logger方法会判断是否为debug级别，再决定将entry序列化拼接如字符串logger.debug("The entry is {}.", entry);这种日志输出方式就无需额外包一层日志级别的判断，因为logger.debug方法内部自己会判断一次日志级别，再去执行日志内容转码的操作。注意，传入的参数必须实现了toString方法，不然日志在对对象进行转码时，只会打印出对象的内存地址，而不是对象中的具体内容 整体架构前文已经简单介绍了logback包含的三个主要模块，以及如何在代码中基于SLF4J FACADE自由的使用日志框架。下面开始从配置文件的角度来了解如何配置Logback。Logback主要支持XML和groovy结构的配置文件，下文中将以XML结构为基础进行介绍。 上图为官网中对Logback配置文件整体结构的描述。配置文件以<configuration>作为根元素，其下包含1个<root>元素用于定义根日志的配置信息，还有0到多个<logger>元素以及0到多个<appender>元素。其中<logger>元素对应了应用中通过LoggerFactory.getLogger()获取到的日志工具，<appender>元素定义了日志的输出目的地，一个<logger>可以关联多个<appender>，即允许将同样的一行日志输出到多个目的地。 ...
SpringCloud系列教程 | 第六篇：Spring Cloud Config Github配置中心Springboot: 2.1.6.RELEASESpringCloud: Greenwich.SR1 如无特殊说明，本系列教程全采用以上版本 随着分布式项目越来越大，勤劳的程序猿们会开始面临一个挑战，配置文件会越来越繁杂，虽然spring提供了一个鸡肋版的解决方案，spring.profiles.active，在大型的分布式项目体系中，聊胜于无吧，手动维护配置文件的痛苦，生产，UAT，测试，开发环境的隔离，额外的配置文件，如：logback.xml日志的配置文件，bootstrap.properties配置文件，当系统中有几十个服务，相应的会有上百个配置文件，简直就是史诗级的灾难大片，每次发布上线，都要手动去检查配置文件，相应的服务都需要重启，那么，有没有一种方案，可以自动更新配置，并且对版本做出相应的控制，恰好，springcloud为我们提供了这样一种工具，虽然很多方面都还不完善，配置能力比较弱，但是也给我们提供了一种思路。 市面上有很多配置中心，BAT每家都出过，360的QConf、淘宝的diamond、百度的disconf都是解决这类问题。国外也有很多开源的配置中心Apache Commons Configuration、owner、cfg4j等等。这些开源的软件以及解决方案都很优秀，也存在这样或者那样的缺陷。今天我们要了解的Spring Cloud Config，可以无缝的和spring体系相结合，够方便够简单颜值高。 1. Spring Cloud Config在介绍Spring Cloud Config之前，我们可以先凭空想一下一个配置中心需要提供的核心功能有哪些： 提供客户端和服务端的支持提供各个环境的配置配置文件修改后可以快速生效可以提供不同版本的管理可以支持不同的语言（java、.Net、Delphi、node等）支持一定数量的并发高可用（防止意外宕机导致配置不可用）Spring Cloud Config项目是一个解决分布式系统的配置管理方案。它包含了Client和Server两个部分，server提供配置文件的存储、以接口的形式将配置文件的内容提供出去，client通过接口获取数据、并依据此数据初始化自己的应用。Spring cloud使用git或svn存放配置文件，默认情况下使用git，我们先以git为例做一套示例。 首先在github上面创建了一个文件夹springcloud-config用来存放配置文件，为了模拟生产环境，我们创建以下三个配置文件： // 开发环境springcloud-config-dev.properties// 测试环境springcloud-config-test.properties// 生产环境springcloud-config-pro.properties每个配置文件中都写一个属性springcloud.hello,属性值分别是 hello dev/test/pro。下面我们开始配置server端 2. Server端1. pom.xml<?xml version="1.0" encoding="UTF-8"?><project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.1.6.RELEASE</version> <relativePath/> <!-- lookup parent from repository --> </parent> <groupId>com.springcloud</groupId> <artifactId>config-server</artifactId> <version>0.0.1-SNAPSHOT</version> <name>config-server</name> <description>Demo project for Spring Boot</description> <properties> <java.version>1.8</java.version> <spring-cloud.version>Greenwich.SR1</spring-cloud.version> </properties> <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-config-server</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope> </dependency> </dependencies> <dependencyManagement> <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-dependencies</artifactId> <version>${spring-cloud.version}</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement> <build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> </plugin> </plugins> </build></project>2. 配置文件server: port: 8080spring: application: name: spring-cloud-config-server cloud: config: server: git: uri: https://github.com/meteor1993/SpringCloudLearning # git仓库的地址 search-paths: chapter6/springcloud-config # git仓库地址下的相对地址，可以配置多个，用,分割。 username: #Git仓库用户名 password: #Git仓库密码Spring Cloud Config也提供本地存储配置的方式。我们只需要设置属性spring.profiles.active=native，Config Server会默认从应用的src/main/resource目录下检索配置文件。也可以通过spring.cloud.config.server.native.searchLocations=file:E:/properties/属性来指定配置文件的位置。虽然Spring Cloud Config提供了这样的功能，但是为了支持更好的管理内容和版本控制的功能，还是推荐使用git的方式。 ...
gitgit是一个分布式版本控制软件，最初由林纳斯·托瓦兹创作，于2005年以GPL发布。最初目的是为更好地管理Linux内核开发而设计。应注意的是，这与GNU Interactive Tools（一个类似Norton Commander界面的文件管理器）有所不同。git最初的开发动力来自于BitKeeper和Monotone。git最初只是作为一个可以被其他前端（比如Cogito或Stgit）包装的后端而开发的，但后来git内核已经成熟到可以独立地用作版本控制。很多著名的软件都使用git进行版本控制，其中包括Linux内核、X.Org服务器和OLPC内核等项目的开发流程。更多相关介绍可以查看百科 git的基本使用主要是指一下基本操作： 安装ssh登入配置命令使用安装根据自己的系统进行选择安装方式，可以使用命令行安装，也可以使用安装包安装，git官方安装包地址 ssh登入配置安装完成之后，需要考虑和远程的仓库建立连接，就需要账号和密码，无论是github、gitlab等，都需要一个账户名，可以注册完成，然后设置： git config --global user.name "yourName"git config --global user.email "yourEmail"为了避免每次push代码都需要密码之类的，我们通过ssh来配置；执行： ssh-keygen一路enter即可，在~/.ssh/下会生成两个文件，复制其中的公钥： pbcopy < ~/.ssh/id_rsa.pub进入远程仓库的个人中心，https://github.com/settings/profile；会找到关于SSH and GPG keys，有一个New SSH key的按钮，点击后，可以黏贴上刚复制的公钥，然后Add SSH key即可； 可以pull和push代码测试是否成功。 git命令使用对于win10系统，推荐升级后使用好的官方新出的终端，Windows Terminal，需要当前最新的win10版本，用起来挺好的，可以再Microsoft的官方商城下载体验。对于mac或者linux用户，推荐配置 oh-my-zsh, 这个oh-my-zsh默认安装上了git plugin在~/.zshrc配置文件中，可以使用很多的简洁命令，git简写命令集合多用户配置git-config的官网巨长文档，开发人员经常遇到这样的问题，我们的公司仓库和个人仓库的用户名和邮箱配置是有区别的，为了能够很好地区分工程上传到不同的远程仓库，我们需要分别处理，保证在不同的工程使用不同的账户 按工程配置多用户按目录配置多用户按工程配置多用户目前git的配置变量可以放在三个地方： /etc/gitconfig 系统配置,对所有用户都生效。~/.gitconfig 用户配置，仅对当前用户生效。 git config --global user.name "yourName"git config --global user.email "yourEmail"projectRootPath/.git/config 项目根目录配置，仅对当前项目生效。对应：进入工程根目录执行 git config user.name "yourName"git config user.email "yourEmail"三层是从3-2-1的优先级处理的，这样我们可以对不同工程完成不同的配置，这个在工程数量多的时候简直不忍直视，所以需要寻找更好的方法。 按目录配置多用户在2017年，git新发布的版本2.13.0包含了一个新的功能includeIf配置，可以把匹配的路径使用对应的配置用户名和邮箱； 在~/目录下面存在三个配置文件， .gitconfig // 全局通用配置文件.gitconfig-self // 个人工程配置文件.gitconfig-work // 公司工程配置文件全局通用配置文件~/.gitconfig里面的内容是：主要是通过includeIf配置匹配不用的目录映射到不同配置文件上， [includeIf "gitdir:~/self-workspace/"] path = .gitconfig-self[includeIf "gitdir:~/workspace/"] path = .gitconfig-work个人工程配置文件~/.gitconfig-self： ...
每个小人物的心中都有一个成为大人物的梦想，配置文件也不例外。当我们还是编程新手的时候，经常会有一些前辈告诉我们：软件开发中要将一些可能变动的参数放到配置文件中，这样就可以在不改变代码且无需重新部署程序的情况下改变程序行为。1、软件实践中的配置文件正如前辈告诫我们的那样，『将一些可能变动的参数放到配置文件中』，可以使得程序更加灵活，适应多种业务场景。于是我们谨遵他们的教诲，在日常的开发过程中，将数据库连接参数，日志路径等线上环境相关的易变值加入配置文件。的确好用，当我们的DB想要扩容，当我们的日志存储想要变更，仅需修改配置文件即可。如此好用，某一天我们可能也会将软件中的某一个功能特性开关移步到配置文件中。不止于此，我们开始将更多的可变参数写在配置文件中，已达到更高的灵活度，更有甚者将一些业务逻辑操作从代码中挪到配置文件中。于是，某一天我们突然发现自己大部分的时间并不是在写代码，而是写配置文件。2、每一个配置文件都想成为一个DSL每个工具都想发展成为一个平台，无独有偶，每一个配置文件都想成为一个DSL（Domain Specific Language，领域专用语言）。正如第一部分描述的那样，起初配置文件中只是一些与代码执行环境有关的参数配置（供系统管理员使用），到最后，随着一些『业务行为』也被加入到配置文件中，它则慢慢地进化成为了一种DSL。但并不是每一个软件系统都需要一套自己的DSL，也不是每一个DSL都会被设计地那么易懂与易用。有些仅仅是增加了复杂度。有人发明了『配置文件复杂读时钟』的概念来描述配置文件这样的一个发展过程，十分贴切。12点：所有逻辑均是写在代码里，有些甚至是硬编码 - 对应业务起步期。3点：前辈们告诉我们，将一些可能变动的参数放到配置文件中 - 业务发展早期6点：需求快速变化，业务逻辑越来越复杂，配置文件也越来越复杂，引入一些条件判断，异常处理等- 业务发展中期。9点：有一些定制化的需求开始出现，为了应对这种变化，配置文件开始走向大量定义软件行为的方向，并且与业务规则紧密耦合在一起 - 业务发展顶峰期12点：最后的最后又回到原点，所以的业务逻辑均写在配置文件中，包括硬编码 - 业务发展瓶颈期。于是，软件开发人员从面向代码编程变成了面向配置文件编程。其实，这个时期，配置文件俨然已变成了一种编程语言。那么回过头来想一想，在业务发展过程中，衍生出了一门配置编程语言，这有必要嘛？配置文件有时候的确很好用，可以帮助软件开发人员快速应对一些变化。但是如果过度依赖配置文件，却不得不提它带来的缺陷：不通用：配置文件引入了非通用的语法、语义，这对项目项目新人来说，无疑增加了学习难度，也降低了团队的合作效率。调试困难：不像代码，配置文件无法在软件系统发生异常时进行有效地调试，致使无法快速定位问题，修复问题，降低了软件系统的健壮性。可维护性差：每一门编程语言都基本上有一套自身的通用编码规范，并随着开发者社区而得到进一步的完善，而配置文件，大多数软件系统都会定义一套自己特殊的语义。相对而言一份使用通用编程语言编写代码的项目比软件自带配置文件要更好维护。高度耦合：配置文件就如同系统对外API，一旦对外暴露就很难收回。作为模块的API，应该尽可能地小而窄，保持高内聚，低耦合图灵完备性：很多带有『行为』的配置文件根本不是图灵完备的（即无法表达出计算机的所有行为），而基本上所有的编程语言都是图灵完备的。本质上：配置文件与代码代表了两种编程范式：声明式（Declarative programming）与命令式（Imperative programming）。当前，几乎所有计算机的硬件工作都是命令式的，也几乎所有计算机的硬件都是设计来运行机器代码，使用命令式的风格来写的。从这点来讲，大部分场景使用代码实现业务逻辑要优于配置文件。3、代码 OR 配置文件要回答这个问题，需要对配置文件的目的作出一个定义。对于大部分的软件系统而言，配置文件是为软件系统的管理员而准备的，方便他们正确而高效地使用软件系统。这样的场景下，应强于代码而弱于配置文件。这里总结了一些tips，仅供参考：应当仅将简单的key-value配置放到配置文件中。如果允许非开发人员快速改变程序行为，那么可以考虑配置文件。任何涉及业务逻辑的地方都应该放到代码里实现，配置文件不建议加入业务『行为』。如果配置改变需要代码改变，那么需要谨慎使用。如果配置项仅仅是开发者理解的数据结构，那么需要谨慎使用。使用者为配置负责，开发者为代码负责。凡事终有例外。如这样的一个场景：应用程序需要允许用户（使用者）动态地配置复杂的规则（邮件用户想要定义复杂的邮件过滤规则），另外一些成熟的商业规则系统中也常用配置文件（作为DSL）解决一些特定领域的问题。REFERENCEShttps://stackoverflow.com/que…https://zh.wikipedia.org/wiki...https://zh.wikipedia.org/wiki...https://blog.urth.org/2011/01...http://mikehadlow.blogspot.co...https://hackernoon.com/config...http://taint.org/2011/02/18/0…
Profile配置1.Profile是什么很多时候，我们项目在开发环境和生成环境的环境配置是不一样的，例如，数据库配置，在开发的时候，我们一般用测试数据库，而在生产环境的时候，我们是用正式的数据，这时候，我们可以利用profile在不同的环境下配置用不同的配置文件或者不同的配置。spring boot允许你通过命名约定按照一定的格式(application-{profile}.properties)来定义多个配置文件，然后通过在application.properyies通过spring.profiles.active来具体激活一个或者多个配置文件，如果没有没有指定任何profile的配置文件的话，spring boot默认会启动application-default.properties。2.基于properties文件类型假如有开发、测试、生产三个不同的环境，需要定义三个不同环境下的配置。你可以另外建立3个环境下的配置文件：applcation.propertiesapplication-dev.propertiesapplication-test.propertiesapplication-prod.properties然后在applcation.properties文件中指定当前的环境： spring.profiles.active=test这时候读取的就是application-test.properties文件。server.port=8001# 激活哪个配置文件spring.profiles.active=devspring.profiles.include=prod可以包含其他的配置文件信息3.基于yml文件类型只需要一个applcation.yml文件就能搞定，推荐此方式。spring: profiles: active: prod—spring: profiles: dev server: port: 8080 —spring: profiles: test server: port: 8081 —spring.profiles: prodspring.profiles.include: - proddb - prodmq server: port: 8082 —spring: profiles: proddb db: name: mysql —spring: profiles: prodmq mq: address: localhost此时读取的就是prod的配置，prod包含proddb,prodmq，此时可以读取proddb,prodmq下的配置也可以同时激活三个配置spring.profiles.active: prod,proddb,prodmq3.基于Java代码在JAVA配置代码中也可以加不同Profile下定义不同的配置文件，@Profile注解只能组合使用@Configuration和@Component注解。@Configuration@Profile(“prod”)public class ProductionConfiguration { // …}4.指定Profile不适用配置文件，而是在启动的时候进行指定的写法4.1 main方法启动方式：// 在IDE Arguments里面添加–spring.profiles.active=prod优先级高于在配置文件里面的激活的4.2 JVM启动方式-Dspring.profiles.active=dev4.3 插件启动方式spring-boot:run -Drun.profiles=prod4.4 jar运行方式java -jar xx.jar –spring.profiles.active=prod除了在配置文件和命令行中指定Profile，还可以在启动类中写死指定，通过SpringApplication.setAdditionalProfiles方法public void setAdditionalProfiles(String… profiles) { this.additionalProfiles = new LinkedHashSet<String>(Arrays.asList(profiles));}配置文件加载位置spring boot 启动会扫描以下位置的application.properties或者application.yml文件作为Spring boot的默认配置文件：file:./config/ - 优先级最高（项目根路径下的config）file:./ - 优先级第二 -（项目根路径下）classpath:/config/ - 优先级第三（项目resources/config下）classpath:/ - 优先级第四（项目resources根目录）重要的规则，跟我们之前学过的不太一样高优先级配置会覆盖低优先级配置多个配置文件互补比如，两个同名文件里面有相同的配置，相同的配置会被高优先级的配置覆盖A配置优先级大于B配置server: port: 8080B配置优先级小于A配置server: port: 8081 context-path: /hanpang项目启动后访问地址为：http://127.0.0.1:8080/hanpang，这就是所谓的互补通过配置spring.config.location来改变默认配置java -jar demo-xxx.jar –spring.config.location=C:/application.properties这对于运维来说非常方便，在不破坏原配置情况下轻松修改少量配置就可以达到想要的效果外部配置加载顺序来自于网路，个人没有进行相关的测试SpringBoot也可以从以下位置加载配置：优先级从高到低；高优先级的配置覆盖低优先级的配置，所有的配置会形成互补配置。命令行参数所有的配置都可以在命令行上进行指定；多个配置用空格分开； –配置项=值java -jar spring-boot-02-config-02-0.0.1-SNAPSHOT.jar –server.port=8087 –server.context-path=/abc来自java:comp/env的JNDI属性Java系统属性（System.getProperties()）操作系统环境变量RandomValuePropertySource配置的random.*属性值jar包外部的application-{profile}.properties或application.yml(带spring.profile)配置文件jar包内部的application-{profile}.properties或application.yml(带spring.profile)配置文件.jar包外部的application.properties或application.yml(不带spring.profile)配置文件jar包内部的application.properties或application.yml(不带spring.profile)配置文件由jar包外向jar包内进行寻找，优先加载待profile的，再加载不带profile的。@Configuration注解类上的@PropertySource通过SpringApplication.setDefaultProperties指定的默认属性加载配置文件方式参考官网地址 ...
面试要套路，也要技巧。别被背题目的兄弟们给忽悠了。【你来发挥】你比较喜欢什么技术，哪一种最熟？一般自信的面试官都喜欢问这个问题，这次面试的小伙比较年轻，咱也装回B，不然都对不起自己。答： 我比较喜欢Spring，比较有趣。目的： 希望应聘者能够有广度且有深度。如果最感兴趣的是Spring本身，而不是其上的解决方案，那顶多会承担被分解后的编码工作。巧了，咱也熟。【工作经验】SpringBoot相比较SpringMVC，有什么优缺点？答： 有很多方面。觉得最好的就是不用写那么多配置文件了，直接写个注解，通过自动配置，就完成了初始化。目的： 说什么无所谓，主要看有没有总结能力。判断是否用过早期的Spring版本，经历过版本更新更能了解软件开发之痛，接受新知识会考虑兼容和迭代。【实现原理】我想要SpringBoot自动读取我的自定义配置，该做哪些事情？答： 写一个相应的starter目的： 判断是否了解和写过Spring Boot Starter，主要是META-INF目录下的spring.factories文件和AutoConfiguration。了解AOP更佳。【烟幕弹】配置文件是yml格式，这种格式你喜欢么？答： 比较喜欢properties格式，感觉yml格式的配置文件缩进比较难处理。比如当我从网上拷贝一些别人长长的配置文件，可能要花较多时间整理文件格式。目的 此问题没有具体的意图，主要是过渡用。【动手能力】这么喜欢properties方式，能够写一段代码，将yml翻译成properties么? 要是回答相反则反着来。目的 通过简单的伪代码，判断应聘者的动手能力和编码风格。是喜欢问题抽象化还是喜欢立刻动手去写。我希望回答能够有条理，而且能够考虑各种异常情况，比如把自己判断不了的配置交给用户处理；比如空格和<TAB>的处理。【提示】提示一下，你用什么数据结构进行存储？目的 假如应聘者在一段时间内不能有任何产出，会给出简单的提示。找准了存储结构，你就基本完成了工作，此问题还判断了应聘者的培养成本和价值。【基础算法】哦，是树结构，遍历方式是怎样的？前序，后序，中序？目的 判断是否有基础的算法知识。做工程先不要求会什么动态规划或者贪心算法，但起码的数据结构是要了解的。【基础知识】你用到了Map？Java中如何做可排序的Map？目的 是否对java的基础集合类熟悉，期望回答TreeMap，如果回答上来，可能会追问它是什么数据结构（红黑树）。【知识广度】你还接触过哪些配置方式？比较喜欢那种？目的 了解应聘者的知识广度，说不出来也无所谓，了解的多会加分。比如ini、cfg、json、toml、序列化等。【项目规模】我想要把我的配置放在云端，比如数据库密码等，改怎么做？目的 是否了解SpringBoot的组件SpringConfig，或者了解一些其他的开源组件如携程的apollo等。【知识广度】我想要配置文件改动的时候，所有机器自动更新，该怎么办？目的 了解是否知晓常用的同步方式。有两种：一种是定时去轮询更新；一种是使用zk或者etcd这种主动通知的组件。【实现细节】Spring是如何进行配置文件刷新的？目的 这个可真是没写过就真不知道了，主要是org.springframework.cloud.context.scope.refresh.RefreshScope这个类【架构能力】现在我想要将配置文件分发到一部分机器，也就是带有版本的灰度概念，你该如何处理？目的 如果能够从网关、微服务约定，后台操作原型方面去多方位描述一下，更佳。这样筛选的小伙伴，都很棒！能力多少，心中有数。
前言：想实现通过不同的命令，打包调用不同环境的API，实现实现前端自动化部署。前端自动化部署工程比较复杂，这里只介绍通过不同的命令，打包的时候调用不同环境的API，例如：npm run build 调用开发环境接口，打包开发环境npm run build:test 调用测试环境接口，打包测试环境npm run build:prod 调用生产环境接口，打包生产环境vue项目用vue-cli脚手架安装完成之后，生成的项目中会有build,config这两个文件夹1、在build文件下新建webpack.test.conf.js在build文件下新建webpack.test.conf.js，将webpack.prod.conf.js内容复制过来。修改webpack.test.conf.js文件将const env = require(’../config/prod.env’)；修改为：const env = require(’../config/test.env’)；2、在config文件下新建test.env.js在config文件下新建test.env.js，将prod.env.js内容复制过来；分别在dev.env.js,test.env.js,prod.env.js中定义变量API_ROOT，dev.env.jstest.env.jsprod.env.js3、在build文件下新建test.js把build.js 内容复制到test.js将const webpackConfig = require(’./webpack.prod.conf’)修改为：const webpackConfig = require(’./webpack.test.conf’)4、修改package.json配置axios请求的时候，接口地址直接调用 process.env.API_ROOT 就好了，打包的时候执行 npm run build:test就是调用的测试接口地址