Spring Boot 1.x 与 2.x 的区别
其实Spring Boot最初使用的是Eureka、Config、Zuul、Ribbon、Feign、Hystrix等。当Spring Boot 2.x 发布时，许多组件开始出现。下面简要列出了这两个版本之间的差异。
在Spring Boot 1.x 中，会话超时为：
服务器.会话.超时=3600
复制代码
在2.x 中：
server.servlet.session.timeout=PT120M
复制代码
Cookie 是相同的，尽管以完全不同的方式编写。
服务器： Servlet : 会话： 超时： PT120M cookie: 名称： ORDER-SERVICE-SESSIONID
复制代码
应用程序的ContextPath 配置属性更改为与上面的会话相同，并添加了servlet。
Spring Boot 2.x 基于Spring 5，而Spring Boot 1.x 基于Spring 4 及更早版本。
基类AbstarctErrorController 已针对集成错误处理进行了修改。
中文配置文件可以直接读取，无需转码。
Acutator 发生了重大变化，默认情况下不再启用所有监控，这同样适用于HealthIndicator 和EndPoint。
从Spring Boot 2.x开始，与1.x不同的是，现在可以结合K8s来实现服务配置管理、负载均衡等。
K8s 的一些资源的介绍
由于我们上面提到Spring Boot 2.x可以与K8s结合作为微服务架构设计，所以我们首先讨论K8s的一些组件。
您可以通过名称来识别ConfigMap。这是一个用于存储配置信息的键值对，可用于存储单个属性或配置文件。对于一些非敏感信息，例如应用程序配置信息，可以使用ConfigMap。
创建ConfigMap 有多种方法：
1. 创建键值字符串
kubectl create configmap test-config –from-literal=baseDir=/usr
复制代码
上面的命令创建一个名为test-config 的文件，其中包含键BaseDir 和值“/usr”的键值对。
2.根据yml描述文件创建
apiVersion: v1kind: ConfigMapmetadata: name: test-configdata: baseDir: /usr
复制代码
yml文件来选择不同的环境并配置不同的信息。
kind: ConfigMapapiVersion: v1metadata: name: cas-serverdata: application.yaml: |-greeting: message: 你好世界— spring: profile: devgreeting: message:greeting dev spring: test profile ing: message:向GreetingsProducts 打个招呼来测试spring: profile: prodgreeting: message:
复制代码
当心：
必须先创建ConfigMap，然后才能在Pod 中使用它。
Pod 只能在同一命名空间内使用ConfigMap。
当然还有其他用途，具体请查看官网。
顾名思义，这是一种什么样的服务呢？这是Pod 的逻辑集合，定义了访问Pod 的服务和策略。
有四种类型的服务：
外部名称：创建指向您的服务名称的DNS 别名。这可以防止服务名称更改，但必须与DNS 插件一起使用。
ClusterIP：默认类型，用于为集群内的pod 访问提供固定的访问地址。默认地址可以是使用ClusterIP 关键字的固定IP。
NodePort：用于为集群外部可访问的服务背后的Pod 提供访问端口，基于ClusterIp。
负载均衡器：基于NodePort。
如何使用 K8s 来实现服务注册与发现
从上面的服务我们可以看到一个场景，如果所有的微服务都在局域网或者K8s集群中，那么就可以使用该服务来访问集群中的pod。这是默认的服务类型。 ClusterIP默认自动分配地址。
那么问题来了，既然通过前面提到的ClusterIp就可以实现对集群内服务的访问，那么我们如何注册服务呢？事实上，K8s并没有引入注册中心，而是使用了K8s的kube-dns组件。然后，K8s 会将服务名称注册为kube-dns 中的域名，并能够访问该服务名称提供的服务。那么，如果你的服务有多个Pod，那么又会出现如何实现LB 的问题。事实上，负载均衡最终是通过kube-proxy来实现的。
说到这里，我们来看看Service的服务发现和负载均衡策略。服务有两种类型的负载平衡策略。
RoundRobin：轮询模式。换句话说，轮询将请求转发到后端的每个Pod。这是默认模式。
SessionAffinity：一种会话持久模式，根据客户端IP地址提供服务的负载均衡，类似于IP哈希。
事实上，K8s就是利用Service来实现服务发现的。其实说白了，我们是通过域名进行层层解析，最终深入到容器内部的IP和端口，找到对应的服务。要求。
这是一个非常简单的例子：
apiVersion: v1kind: Servicemetadata: name: cas-server-service 命名空间：defaultspec: ports: – name: cas-server01 port: 2000 targetPort: cas-server01 选择器： app: cas-server
复制代码
当我运行kubectl apply -f service.yaml 时，我看到以下内容：
root@ubuntu:~$ kubectl get svcNAME 类型CLUSTER-IP 外部IP 端口AGEadmin-web-service ClusterIP 10.16.129.24 无2001/TCP 84dcas-server-service ClusterIP 10.16.230.167 无2000/TCP 67dcloud-admin-service -service ClusterIP 1 0.16 .25.178 无1001/TCP 190d
复制代码
正如您所看到的，当用于访问集群内的Pod 时，默认类型是ClusterIP。您可以先通过域名解析多个服务地址信息，然后选择其中一个作为请求对象。 LB政策。
K8s 如何来处理微服务中常用的配置
上面我们讨论了创建ConfigMap 的几种方法。其中之一在Java中常用来创建yml文件来实现配置管理。
例如：
kind: ConfigMapapiVersion: v1metadata: name: cas-serverdata: application.yaml: |-greeting: message: 你好世界— spring: profile: devgreeting: message:greeting dev spring: test profile ing: message:向GreetingsProducts 打个招呼来测试spring: profile: prodgreeting: message:
复制代码
上面创建了一个yml文件，通过spring.profiles指定了开发、测试、生产等各个环境的配置。
具体代码：
apiVersion: apps/v1kind: Deploymentmetadata: name: cas-server-deployment label: app: cas-serverspec:副本： 1选择器： matchLabels: app: cas-server template:metadata: label3336 0 app 333 60 cas-server spec: nodeSelector: cas-server: \’true\’ 容器： – name: cas-server image: {{ cluster_cfg [ \’cluster\’][\’docker-registry\’][\’prefix\’] }}cas-server imagePullPolicy: 始终ports: – name: cas-server01containerPort: 2000 volumeMounts: – mountPath: /home/cas-server name: cas-server-path args: [ \’ sh \’, \’-c\’, \’nohup java $JAVA_OPTS -jar -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=128m -Xms1024m -Xmx1024m -Xmn256m -Xss256k -XX:SurvivorRatio=8 -XX:+UseConcMarkSo upGC – server.jar –spring.profiles 。 active=dev\’, \’\’] hostAliases: – ip: \’127.0.0.1\’ 主机名： – \’gemantic.localhost\’ – ip: \’0.0.0.0\’ 主机名： – \’gemantic.all\’volume: – name: cas-服务器路径hostPath: /var/pai /cas-服务器
复制代码
这样，在启动容器时，可以使用–spring.profiles.active=dev 指定当前容器的活动环境，并在ConfigMap 中获取相应的配置。听起来有点像Java 的配置多个环境的Config，对吧？但它不必那么复杂。这一切都可以由K8来处理。只需启动此命令即可。是不是很容易呢？
Spring Boot 2.x 的新特性
在第一部分中，我们解释了1.x 和2.x 之间的差异。最显着的区别是Spring Boot 2.x结合K8来实现微服务架构设计。事实上，在K8s 上，更新ConfigMap 后，pod 不会自动更新configMap 更改。您必须重新启动pod 才能获取ConfigMap 中的最新信息。
不过，2.x 提供了自动更新功能。
spring: application: name: cas-server cloud: kubernetes: config:sources: – name: ${spring.application.name} namespace: default discovery: all-namespaces: true reload: enable: true mode: 轮询周期33 360 5 00
复制代码
如上，我打开自动更新设置开关，并将自动更新方式设置为主动拉取，时间间隔为500毫秒。同时我们还提供了另一种方法，——event事件通知模式。这样，当ConfigMap 发生变化时，您无需重启Pod 即可获取最新的数据信息。
同时Spring Boot 2.x结合K8实现服务注册和微服务发现。
依赖项groupIdorg.springframework.cloud/groupId artifactIdspring-cloud-kubernetes-core/artifactId/dependency
依赖项groupIdorg.springframework.cloud/groupId artifactIdspring-cloud-kubernetes-discovery/artifactId/dependency
复制代码
打开服务发现。
spring: cloud: kubernetes: Discovery: all-namespaces: true
复制代码
实际上，最后一步就是向K8s API服务器发起http请求，获取服务资源的数据列表。然后根据底层负载均衡策略发现服务并最终解析到特定的Pod。因此，要使同一服务存在多个pod，您需要执行以下操作：
kubectlscale –replicas=2 部署admin-web-deployment
复制代码
同时，当通过HTTP RestTemplate客户端发出服务请求时，RestTemplate通常与Ribbon结合使用。
client: http: request: connectTimeout: 8000 readTimeout: 3000
后端： 功能区： Eureka : 已启用： false client: 已启用： true ServerListRefreshInterval: 5000
Ribbon: ConnectTimeout: 8000 ReadTimeout: 3000eager-load: Enabled: true client: cas-server-service,admin-web-service MaxAutoRetries: 1 #第一个请求的服务的重试次数MaxAutoRetriesNextServer: 1 #下一个服务重试的最大次数(第一个服务) ListRefreshInterval: 2000 OkToRetryOnAllOperations: 真NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RoundRobinRule #com.damon.config.RibbonConfiguration #分布式负载均衡策略
复制代码
您可以配置一些服务列表，定制一些负载均衡策略。
使用Feign作为LB时，实际上和Ribbon只是略有不同，因为Feign本身就是基于Ribbon实现的。除了添加@EnableFeignClients注解外，还需要配置以下内容：
feign: client: config: default: #provider-service connectTimeout: 8000 #客户端连接超时readTimeout: 3000 #客户端读取超时设置loggerLevel: full
复制代码
其他用户也是一样，因为他们可以根据ribbon自定义负载均衡策略。
以上关于#Spring Cloud和K8s微服务设计的相关内容来源网络（一）仅供参考。相关信息请参见官方公告。
原创文章，作者：CSDN，如若转载，请注明出处：https://www.sudun.com/ask/91496.html
