微服务的配置文档怎么管理

1. 微服务入门这一篇就够了

刚开始进入软件行业时还是单体应用的时代，前后端分离的概念都还没普及，开发的时候需要花大量的时间在“强大”的JSP上面，那时候SOA已经算是新技术了。现在，微服务已经大行其道，有哪个互联网产品不说自己是微服务架构呢？

但是，对于微服务的理解每个人都不太一样，这篇文章主要是聊一聊我对微服务的理解以及如何搭建经典的微服务架构，目的是梳理一下自己的一些想法，如果存在不同看法的欢迎指正！

首先，什么是微服务呢？

相对的，要理解什么是微服务，那么可以先理解什么是单体应用，在没有提出微服务的概念的“远古”年代，一个软件应用，往往会将应用所有功能都开发和打包在一起，那时候的一个B/S应用架构往往是这样的：

但是，当用户访问量变大导致一台服务器无法支撑时怎么办呢？加服务器加负载均衡，架构就变成这样了：

后面发现把静态文件独立出来，通过CDN等手段进行加速，可以提升应用的整体相应，单体应用的架构就变成：

上面3中架构都还是单体应用，只是在部署方面进行了优化，所以避免不了单体应用的根本的缺点：

我认为任何技术的演进都是有迹可循的，任何新技术的出现都是为了解决原有技术无法解决的需求，所以，微服务的出现就是因为原来单体应用架构已经无法满足当前互联网产品的技术需求。

在微服务架构之前还有一个概念：SOA（Service-Oriented Architecture）-面向服务的体系架构。我认为的SOA只是一个架构模型的方法论，并不是一个明确而严谨的架构标准，只是后面很多人将SOA与The Open Group的SOA参考模型等同了，认为严格按照TOG-SOA标准的才算真正的SOA架构。SOA就已经提出的面向服务的架构思想，所以微服务应该算是SOA的一种演进吧。

撇开架构先不说，什么样的服务才算微服务呢？

微服务架构，核心是为了解决应用微服务化之后的服务治理问题。

应用微服务化之后，首先遇到的第一个问题就是服务发现问题，一个微服务如何发现其他微服务呢？最简单的方式就是每个微服务里面配置其他微服务的地址，但是当微服务数量众多的时候，这样做明显不现实。所以需要使用到微服务架构中的一个最重要的组件： 服务注册中心 ，所有服务都注册到服务注册中心，同时也可以从服务注册中心获取当前可用的服务清单：

解决服务发现问题后，接着需要解决微服务分布式部署带来的第二个问题：服务配置管理的问题。当服务数量超过一定程度之后，如果需要在每个服务里面分别维护每一个服务的配置文件，运维人员估计要哭了。那么，就需要用到微服务架构里面第二个重要的组件： 配置中心 ，微服务架构就变成下面这样了：

以上应用内部的服务治理，当客户端或外部应用调用服务的时候怎么处理呢？服务A可能有多个节点，服务A、服务B和服务C的服务地址都不同，服务授权验证在哪里做？这时，就需要使用到服务网关提供统一的服务入口，最终形成典型微服务架构：

上面是一个典型的微服务架构，当然微服务的服务治理还涉及很多内容，比如：

目前国内企业使用的微服务框架主要是Spring Cloud和Dubbo（或者DubboX），但是Dubbo那两年的停更严重打击了开发人员对它的信心，Spring Cloud已经逐渐成为主流，比较两个框架的优劣势的文章在网上有很多，这里就不重复了，选择什么框架还是按业务需求来吧，业务框架决定技术框架。
Spring Cloud全家桶提供了各种各样的组件，基本可以覆盖微服务的服务治理的方方面面，以下列出了Spring Cloud一些常用组件：

本章节主要介绍如何基于Spring Cloud相关组件搭建一个典型的微服务架构。
首先，创建一个Maven父项目 spring-cloud-examples ，用于管理项目依赖包版本。由于Spring Cloud组件很多，为保证不同组件之间的兼容性，一般通过 spring-cloud-dependencies 统一管理Spring Cloud组件版本，而非每个组件单独引入。

pom.xml配置如下：

参考上面业务服务A搭建另外一个业务服务B。

目前网上很多说是下一代微服务架构就是Service Mesh，Service Mesh主流框架有Linkerd和Istio，其中Istio有大厂加持所以呼声更高。Service Mesh我接触还不多，但是个人感觉并不一定能称为下一代微服务架构，可能认为是服务治理的另外一种解决方案更合适，是否能够取代当前的微服务架构还需要持续观察。

2. 微服务架构 | 2.1 使用 Spring Cloud Config 管理服务配置项

参考资料 ：
《Spring Microservices in Action》
《Spring Cloud Alibaba 微服务原理与实战》
《B站 尚硅谷 SpringCloud 框架开发教程 周阳》

SpringCloud Config 为微服务架构中的微服务提供集中化的外部配置支持，配置服务器为各个不同微服务应用的所有环境提供了一个中心化的外部配置；

特点 ：

@EnableConfigServer ：表明该服务是个 config 配置服务器；

@SpringBootApplication ：表明是一个 Spring Boot 应用；

3. 微服务初体验（二）：使用Nacos作为配置中心并集成Dubbo

首先启动Nacos，按照上篇文章的步骤，启动Nacos服务和项目，访问Nacos的web页面。确保项目中的服务都注册到注册中心当中了。在application.yml同级目录下添加bootstrap.yml，在Spring boot项目中bootstrap.yml会比application.yml优先初始化，所以我们需要在bootstrap.yml中引入Nacos官方指定的配置文件即可（上篇文章中已经把Nacos作为配置中心的配置写入了application.yml，现在只需要把它从applicaiton.yml中剪切出来即可， 其中的spring:application:name会作为Nacos中新增配置时的Data ID，需要留意 ），再新增属性gorup进行分组测试，如下图

接着打开Nacos的服务的web页面，打开配置管理->配置列表，点击右侧新增按钮，进行新增。
Data ID： bootstrap.yml配置文件中spring:application:name对应的名称 ；
Group：指定分组（便于不同环境下的项目配置管理，因为笔者这里属于测试，所以填写的是和上文中的配置文件中group对应的test一致）；
描述：针对于该配置的描述；
配置格式：配置文件的格式，要和Data ID中的后缀格式一致（这里笔者用的是yml，那么下面就选择yaml，注意该位置也可以选择properties，但是必须和上面bootstrap.yml文件中的file-extension的值相匹配）；
配置内容：具体的配置内容（这里笔者将项目中的application.yml中的配置全部拷贝至其中）；

测试启动consumer服务，在application.yml中为空的时候，项目启动端口还是如Nacos配置中的9011，说明项目依赖Nacos的配置中心成功，其他服务如法炮制即可：

新增一个测试Controller，然后加上@RefreshScope注解，表明该Controller中的配置数据为自动刷新 。

编辑Nacos中的配置文件consumer新增相关参数type: test，访问Controller，返回test。效果如下图：

将Nacos中consumer.yml文件的type: test修改为type: prod，在不重启项目的情况下重新访问对应的controller，效果如下图：

因为Dubbo是属于各个服务之间都要公用的依赖，所以将其引入cloud-common当中，详细的版本可以去 mvnrepository 搜索合适自己项目的

引入依赖后需要编写消费者服务中的配置文件，将Dubbo服务注册至Nacos，新增如下内容，其中subscribed-services指的是生产者服务，prot：-1指的是端口随机，registry:address:指的是Dubbo对应的注册中心那这里就应该设置为Nacos

接下来新增接口服务，项目类型为Maven项目，在项目中新增一个接口。并在cloud-provider（生产者）和cloud-consumer（消费者）pom.xml文件中都引入该模块

在生产者实际服务中实现该接口对应的方法

在服务消费者的Controller中引入该Service，并在该Service上加入@Reference注解，注意在引入jar包的时候选择带有Dubbo的，不要使用Jdk原生的

编写消费者服务中测试Dubbo调用的接口，进行测试，测试结果如下图：

4. 微服务中如何获取配置文件以及多环境切换配置

同关闭系统还原没有关系！同AVAST有关系！ windows xp 速度提升和优化指南 Win XP以其华丽的操作画面和稳定的性能成为不少电脑玩家的首选操作系统，但在使用Windows XP的过程中你会发现，随着时间的推移操作系统在速度上是越来越慢了。

5. Spring Cloud 微服务实战

阅读《Spring微服务实战》笔记

项目地址： https://gitee.com/liaozb1996/spring-cloud-in-action

配置管理原则：

Spring Cloud Config 后端存储：文件系统、Git

标注引导类：

配置服务器配置：

创建配置文件：

访问配置：

客户端配置：

spring-cloud-config-client 依赖

boostrap.properties

刷新属性：

服务发现至关重要的原因：

传统服务位置解析（DNS+负载均衡器）的缺点：

服务发现实现组件：

构建 Eureka 服务：

标注引导类：

单机模式配置 ：

每次注册服务都需要等待30秒，因为 eureka 需要连续接收 3 个心跳包才能使用该服务。

缓存注册表后，客户端每隔30秒会重新到 eureka 刷新注册表。

服务注册：

解决多网卡问题：

通过API获取注册表信息：（设置请求头 Accept:application/json ）

http://localhost:8761/eureka/apps

http://localhost:8761/eureka/apps/organization

与 Ribbon 交互的客户端：

当使用二方包时需要在引导类添加 @EntityScan ：

配置 RestTemplate：

DiscoveryClient：

支持 Ribbon 的 RestTemplate：

Feign：

OpenFeign 依赖：

Feign 会在运行时动态生成代理对象：

远程调用包括对远程资源和远程服务的调用。

远程调用会遇到两个问题：

四种客户端弹性模式：

为什么客户端弹性模式很重要：

客户端弹性模式提供了三种构建能力：

在引导类启动断路器：

配置属性手册： https://github.com/Netflix/Hystrix/wiki/Configuration

使用 Hystrix 默认配置对远程调用进行管理：

超时配置： execution.isolation.thread.timeoutInMilliseconds

配置后备策略：后备方法必须在同一类中并且具有相同的方法签名

配置舱壁：

Hystrix 断路的策略：

Hystrix 有三个级别的配置：

类级别配置：

Hystrix 有两个隔离策略：

如果使用 TREAD 策略，并且要将父线程的上下文传递到子线程中，需要自定义 HystrixConcurrencyStrategy

Zuul 提供的功能：路由映射、构建过滤器

依赖：zuul、eureka-client

标注引导类：

zuul 配置：

​

Zuul路由映射机制：

查询路由： http://localhost:8080/actuator/routes

调用服务： http://localhost:8080/license/license/1 （第一个 license 是服务ID，/license/1 是请求路径）

使用服务发现手动映射路由：

添加前缀：

手动配置静态路由：前面都是基于 eureka 上的服务id进行路由映射的，而这里是直接配置URL

Git + http://localhost:8080/actuator/refresh （POST）

Zuul 使用 Hystrix 和 Ribbon

Zuul 支持三种过滤器类型：前置过滤器、后置过滤器、路由过滤器

前置过滤器：向通过网关的请求添加 tracking-id

这里使用了 Zuul 的 RequestContext：

Zuul 不允许直接修改请求头部，这里通过 addZuulRequestHeader 添加头部信息，在调用远程服务会自动合并

为了方便应用获取 tracking-id，这里使用 Filter 获取请求头信息并映射到 UserContext 中：

为了在服务间调用传播 tracking-id 这里需要定义一个 和 RestTemplate：

项目中 license 会远程调用 orgnization，这里需要在两个微服务配置 Filter

6. 微服务SpringCloudAlibaba配置汇总

在 pom.xml 中添加 spring-cloud-alibaba-dependencies 统一管理版本:

Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。

通过 @EnableDiscoveryClient 注解表明是一个 Nacos 客户端，该注解是 Spring Cloud 提供的原生注解

注：server-addr为Nacos Server 网址

Sentinel 以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。

Sentinel 以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。

使用 Spring Cloud Alibaba Nacos Config，您可以在 Nacos Server 集中管理你 Spring Cloud 应用的外部属性配置。

注意：Spring Boot 配置文件的加载顺序，依次为 bootstrap.properties -> bootstrap.yml -> application.properties -> application.yml ，其中 bootstrap.properties 配置为最高优先级

RocketMQ 是一款开源的分布式消息系统，基于高可用分布式集群技术，提供低延时的、高可靠的消息发布与订阅服务。

配置 Output(Source.class) 的 Binding 信息并配合 @EnableBinding 注解使其生效

运行成功后即可在 RocketMQ 控制台的 消息 列表中选择 test-topic 主题即可看到发送的消息

配置 Input(Sink.class) 的 Binding 信息并配合 @EnableBinding 注解使其生效

RPC框架分为提供方和消费方，提供方提供服务，消费方消费服务。这里采用nacos注册中心和Dubbo框架配置。