容器化技术与微服务结合---SpringCloud框架与阿里云serverless k8s的结合(六)
目录系列写在前面Serverless K8S概念创建集群微服务搭建项目地址环境区分以及dockerFile注意阿里云日志接入创建阿里云日志project配置测试Kubernetes配置deployment及pod配置Service配置eurekagateway查看日志问题结尾系列容器化技术与微服务结合—docker(一)容器化技术与微服务结合—Kubernetes基本介绍(二)容器化技术与...
目录
系列
容器化技术与微服务结合—docker(一)
容器化技术与微服务结合—Kubernetes基本介绍(二)
容器化技术与微服务结合—Pod详解(三)
容器化技术与微服务结合—实操service并部署一个简单对外开放的springboot HelloWord服务(四)
容器化技术与微服务结合—结合springcloud微服务框架进行部署(含切换成阿里云docker仓库)(五)
容器化技术与微服务结合—SpringCloud框架与阿里云serverless k8s的结合(六)
写在前面
博主保留cloud微服务及eureka的体系。k8s作为快速部署编排的设施。这样在本地开发的时候会方便一些。
如上图(本偏因为应用少,暂时不用Ingress,直接使用slb做对外负载均衡)
- 针对网关层面,抛出对外service
- 保留eureka服务注册,使用PrivateZone域名解析服务(在内部k8s内部之间使用servicename的host方式通信),这个东西有坑,下面会讲到
- sdk等信息自己接入即可, 参考博主框架项目:https://gitee.com/_madi/codemperor.git (cloud-k8s分支)
- 采用博主编写的sdk方便统计日志,并无缝接入阿里云日志系统,方便快速检索
- 采用钉钉机器人消息(博主sdk中有封装)发送核心业务、报错等信息
Serverless K8S
概念
让用户不在关注服务器与应用环境,仅仅只关注应用及其运维。减少了服务器与环境等底层的运维成本
如上图所示,阿里云的serverless,可以直接将pod(结合镜像)与cpu及内存结合,直接运行,当你不想运行这个pod或者应用的时候,停止即可,底层的服务器资源已经完全屏蔽。这样的情形会对很多热插拔式的应用有极大节省(省钱呀~)
举个例子:你想玩lol,会启动lol的应用,这个时候,应用开始消耗cpu、内存等,当你不想玩的时候,会关掉lol的应用,这个时候就释放了cpu和内存。
创建集群
直接创建serverkess k8s集群:
下面图中:
-选择对外开放,如果你的整个集群是用来内部使用,比如计算大数据,算完就删,这个时候可以不对外开放,如果是一个对外业务性质的集群,选择对外开放,否则整个集群将无法对外提供服务
-选择PrivateZone,这个是个很大的坑,如果你不选择,那么整个集群内不允许使用ServiceName进行通信,只能对想要通信的服务开启内部SLB并绑定固定的EIP,通过这样方式通信,这样会有比较大的运维成本
点击创建之后,稍等几分钟:
发现已经创建完毕
微服务搭建
项目地址
微服务简单的框架搭建,前面博主已经写过了,这里参考博主的git项目:
https://gitee.com/_madi/codemperor.git (cloud-k8s分支)
分为:网关、auth、eureka、常用sdk等
环境区分以及dockerFile注意
通常环境区分为:dev(研发)、qa(测试)、demo(预发)、prod(生产)
这里博主使用application的配置区分环境,然后java -jar --spring.profiles.active=qa的方式来确认环境并启动
项目中有个empr-k8s目录,其中目前是qa环境的打包,在这个目录下,执行:
docker build -f …/empr-k8s/docker/qa-gateway-docker-file -t 镜像名称:标记 …/…/empr-gateway
- 注意-f后面跟的是dockerfile的路径
- 最后结尾不再是以 . (点)结尾,而是一个路径。最后的 . 其实是docker编译时候的运行环境,…/…/empr-gateway 代表让dockerfile在网关项目下执行,这样才可以将网关项目下面的东西全部打包,或者在target下面执行也行,这样直达包了jar,东西会少一些
阿里云日志接入
创建阿里云日志project
配置好后会提示你进行数据接入,也可以选择project进入页面接入:
选择logback的方式:
然后完成~
配置
为了更好查看日志,我们将日志直接接入阿里云日志系统,我们使用logback方式接入:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<property name="logPath" value="/emper/app/logs"/>
<property name="pattern" value='%d ~ AUTH-%thread ~ %-5level ~ %logger{0} ~ %msg%n'/>
<!-- 这里暂时用prod-buy-order服务器-->
<property name="remote" value="10.0.7.52"/>
<!-- %m输出的信息,%p日志级别,%t线程名,%d日期,%c类的全名,%i索引【从数字0开始递增】,,, -->
<!-- appender是configuration的子节点,是负责写日志的组件。 -->
<!-- ConsoleAppender:把日志输出到控制台 ch.qos.logback.core.ConsoleAppender-->
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
<encoder>
<pattern>${pattern}</pattern>
<!-- 控制台也要使用UTF-8,不要使用GBK,否则会中文乱码 -->
<charset>UTF-8</charset>
</encoder>
</appender>
<!-- RollingFileAppender:滚动记录文件,先将日志记录到指定文件,当符合某个条件时,将日志记录到其他文件 -->
<!-- 以下的大概意思是:1.先按日期存日志,日期变了,将前一天的日志文件名重命名为XXX%日期%索引,新的日志仍然是demo.log -->
<!-- 2.如果日期没有发生变化,但是当前日志的文件大小超过1KB时,对当前日志进行分割 重命名-->
<appender name="story" class="ch.qos.logback.core.rolling.RollingFileAppender">
<!--如果只是想要 Error 级别的日志,那么需要过滤一下,默认是 info 级别的,ThresholdFilter-->
<filter class="ch.qos.logback.classic.filter.ThresholdFilter">
<level>INFO</level>
</filter>
<File>${logPath}/auth.log</File>
<!-- rollingPolicy:当发生滚动时,决定 RollingFileAppender 的行为,涉及文件移动和重命名。 -->
<!-- TimeBasedRollingPolicy: 最常用的滚动策略,它根据时间来制定滚动策略,既负责滚动也负责出发滚动 -->
<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
<!-- 活动文件的名字会根据fileNamePattern的值,每隔一段时间改变一次 -->
<!-- 文件名:log/demo.2018-06-23.0.log -->
<fileNamePattern>${logPath}/auth.%d.%i.log</fileNamePattern>
<!-- 每产生一个日志文件,该日志文件的保存期限为30天 -->
<maxHistory>30</maxHistory>
<timeBasedFileNamingAndTriggeringPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP">
<!-- maxFileSize:这是活动文件的大小,默认值是10MB,测试时可改成1KB看效果 -->
<maxFileSize>50MB</maxFileSize>
</timeBasedFileNamingAndTriggeringPolicy>
</rollingPolicy>
<encoder>
<!-- pattern节点,用来设置日志的输入格式 -->
<pattern>
${pattern}
</pattern>
<!-- 记录日志的编码:此处设置字符集 - -->
<charset>UTF-8</charset>
</encoder>
</appender>
<!-- 这是同步,如果接受方挂了,会直接影响服务,卡死cpu,建议不使用,除非接收方永不宕机-->
<appender name="SOCKET" class="ch.qos.logback.classic.net.SocketAppender">
<remoteHost>${remote}</remoteHost>
<port>9100</port>
<!-- 重连延时millis,如果设置成“10 seconds”,就会在连接u武器失败后,等待10秒,再连接。默认值:“30 seconds”。如果设置成0,则关闭重连功能。-->
<reconnectionDelay>5000</reconnectionDelay>
<!--设置日志超时丢弃时间millis。当设置“10 seconds”类似的值,如果日志队列已满,而服务器长时间来不及接收,当滞留时间超过10 seconds,日志就会被丢弃。-->
<eventDelayLimit>600000</eventDelayLimit>
<!-- 是否包含调用者的信息-->
<includeCallerData>false</includeCallerData>
<!-- 设置缓冲日志数,如果设置成0,日志发送是同步的,如果设置成大于0的值,会将日志放入队列,队列长度到达指定值,在统一发送。可以加大服务吞吐量。 -->
<!-- <queueSize>50</queueSize>-->
</appender>
<!--异步发送, 配合socket-->
<appender name="ASYNC" class="ch.qos.logback.classic.AsyncAppender">
<queueSize>5000</queueSize>
<!-- 下面一行配置可以获取caller data,但是会极大印象打印效率,和不开启的性能相差大约360倍左右-->
<includeCallerData>false</includeCallerData>
<!-- false,如果队列被填满,为了处理所有日志,就会阻塞的应用。如果为true,为了不阻塞你的应用,也会选择抛弃一些message-->
<neverBlock>true</neverBlock>
<appender-ref ref="SOCKET"/>
</appender>
<!-- ======================= 阿里云日志相关start ======================= -->
<!-- 阿里云日志-->
<appender name="aliyunLogEs" class="com.aliyun.openservices.log.logback.LoghubAppender">
<!--必选项-->
<!-- 账号及网络配置 -->
<endpoint></endpoint>
<accessKeyId></accessKeyId>
<accessKeySecret></accessKeySecret>
<!-- sls 项目配置 -->
<project>emper-test</project>
<logStore>emper-test-store</logStore>
<!--必选项 (end)-->
<!-- 可选项 -->
<topic>empr-auth</topic>
<!-- <source>source1</source>-->
<!-- 可选项 详见 '参数说明'-->
<totalSizeInBytes>104857600</totalSizeInBytes>
<maxBlockMs>60000</maxBlockMs>
<ioThreadCount>8</ioThreadCount>
<batchSizeThresholdInBytes>524288</batchSizeThresholdInBytes>
<batchCountThreshold>4096</batchCountThreshold>
<lingerMs>2000</lingerMs>
<retries>10</retries>
<baseRetryBackoffMs>100</baseRetryBackoffMs>
<maxRetryBackoffMs>100</maxRetryBackoffMs>
<!-- 可选项 通过配置 encoder 的 pattern 自定义 log 的格式 -->
<encoder>
<pattern>${pattern}</pattern>
</encoder>
<!-- 可选项 设置时间格式 -->
<timeFormat>yyyy-MM-dd'T'HH:mmZ</timeFormat>
<!-- 可选项 设置时区 -->
<timeZone>Asia/Shanghai</timeZone>
<filter class="ch.qos.logback.classic.filter.LevelFilter"><!-- 打印WARN,ERROR级别的日志 -->
<level>INFO</level>
</filter>
</appender>
<!-- 可用来获取StatusManager中的状态 -->
<statusListener class="ch.qos.logback.core.status.OnConsoleStatusListener"/>
<!-- 解决debug模式下循环发送的问题 -->
<logger name="org.apache.http.impl.conn.Wire" level="WARN"/>
<!--为了防止进程退出时,内存中的数据丢失,请加上此选项-->
<shutdownHook class="ch.qos.logback.core.hook.DelayingShutdownHook"/>
<!-- ======================= 阿里云日志相关end ======================= -->
<!-- 控制台输出日志级别 -->
<root level="INFO">
<appender-ref ref="STDOUT"/>
<appender-ref ref="story"/>
<appender-ref ref="ASYNC"/>
<appender-ref ref="aliyunLogEs"/>
</root>
</configuration>
- 配置好我们刚才的project以及store,然后配置好阿里云的accessKey
- STDOUT代表输出控制台,这样docker logs -f可以实时查看
- story是本地存储一份,如果挂在硬盘,可以直接看到日志文件(以防万一)
- ASYNC 这个是博主自己编写的日志小平台,用于直接将日志传送给这个平台,然后实时统计存入habase(这个可以忽略)
- aliyunLogEs 这个就是阿里云的日志配置,利用日志自定义Appender来实现自己的日志处理(博主的数据小平台也是这么做的)
测试
启动我们的服务,然后登陆阿里云查看日志,发现:
已经成功打印到阿里云日志服务中
Kubernetes配置
deployment及pod配置
我们这里第一次创建,所以就使用镜像直接创建了
下面,选择这个应用需要的机器配置(这里不会启动一台ecs),记得加入端口配置
这里就成功创建了,查看:
查看容器信息:
点击进入后,下方有容器日志:
可以看到正常启动。
另外gateway以及auth类似,选择镜像后启动即可,这里博主的应用配置是:
- eureka:8761
- gateway:9001,转发/api以及/crm接口到auth服务,所有/crm开头的api都需要进行鉴权
- auth:9002
最终启动完毕之后:
原谅博主写错名字了: k8s-test-deployment是eureka
Service配置
我们使用http://eureka-server:8761/eureka的方式来连接eureka
- 创建eureka两个service,一个以eureka-server为名称,用于内部通信,一个对外开放,用于我们看一下webUI
- 创建gateway对外的service,来调用接口做尝试
eureka
如下图,创建一个对内的eureka service用于通信(这样的方式必须开启privateZone,前面有说过,这个是个坑)
注意,端口下面名称,必须以协议开头,不可以随便写,如:http、https、udp等
创建一个对外开放的,用于访问web
最终如下:
我们来查看一下eureka的web:
发现都已经注册上去了
gateway
和上面eureka对外是一样的:
创建完毕之后,可以看到对外ip,我们来访问提前做好的接口:
- http://ip:9001/api/auth/hello, 得到:open hello wordqa
- http://ip:9001/crm/auth/hello, 得到:{“code”:403,“resultMessage”:“需要重新登陆”,“success”:false}
- http://ip:9001/hello, 得到:gateway-qa: inner hello wordqa
调用成功
查看
我们看一下负载均衡:
原来,即使使用k8s,依然要启动负载均衡器的。
日志问题
我们发现日志服务没通,进去查看容器,发现日志服务域名掉不通
这一定是内部服务器无法访问外网导致的。我们需要配置nat网关,参考博主这个博客:
架构系列(三)VPC、弹性IP以及NAT网关的妙用,划分子网,我们来搭建自己的私有云机房
申请一个弹性ip:
绑定在Nat上:
并设定交换机级别的,通过这个ip访问外网:
等待片刻,调用接口并查看容器日志:
再去看下阿里云日志:
发现日志成功打印,搞定收工~
结尾
博主的框架项目连接:
https://gitee.com/_madi/codemperor.git (cloud-k8s分支)
后续可能会完善framework 微服务系列文章,欢迎关注(包括jdk11搭配webflux异步使用,博主早期团队已经全面落地)
关于vpc等云组件只是,可以查看博主的之前架构系列文章
更多推荐
所有评论(0)