简介

我叫XXX，毕业于电子科技大学成都学院，专业方向是软件工程

有过两段工作经历，

最近一份工作是百度云监控私有云项目的维护与开发

云监控的项目背景是百度智能云上有各种各样的云产品，例如云服务器、云磁盘等。需要实时监控记录产品的使用状态以及各项关联指标，状态异常要能够发出告警。

平台需要同时收集所有云产品的指标信息，采用集群架构，便于适配各个项目上不同使用量(单节点承受大概每秒一百多并发)，扩展节点数量维持服务稳定，主要的负载均衡依靠另外一个平台noah管理。

服务间调用使用域名，就不是使用一般微服务注册中心那一套。在noah均衡流量。使用spring-cloud-starter-sleuth + logback实现链路跟踪。请求检查header是否携带requestId，

生成requestId并打印在日志中。

使用kafka解耦第三方计算服务，平台处理(模型转换)完指标数据发送到kafka，flink消费计算后再发送到kafka由云监控组件消费再写入tsdb中。

使用ES存储报警历史信息。

系统架构主要是springboot处理复杂的业务逻辑(鉴权、模型转换，缓存)。部分组件使用go语言开发，例如告警信息写入查询。用于处理高并发请求

数据收集这块提供了百度虚机专用的agent，采集cpu使用率、网络流量、磁盘使用率等指标。以及提供通用接口供其他各个产品推送各自的指标数据。

服务收到数据处理后分别存入tsdb以及发送kakfa。汇聚计算服务消费kafka数据做汇聚计算以及告警判断。

我主要负责的是私有云侧的项目维护以及定制需求开发。

上份工作是银行项目开发，主要内容是文件管理系统和信息安全管理平台的部分组件。

熟悉的技术方向是springcloud相关生态，以及es，kafka，redis，tsdb等中间件使用。

1.其中文件管理系统是因为银行有多个网络环境，并且各个网络环境之间网络不互通，有时候需要进行跨网络环境传输文件

这个系统采用springcloud微服务架构，系统包含文件、用户、通知等服务，使用mysql存储文件信息，例如文件存储相对路径，所属用户、文件大小等等。redis缓存用户登录token以及登陆时的验证码，便于管理过期时间。

feign进行服务间接口调用，服务端编写好feign调用依赖，打包发布到maven仓库，客户端拉取依赖进行调用。

使用mybatisplus作为对象关系映射框架，减少xml中sql编写，提高开发效率。

解决的问题:出现过一些问题，系统有时被用于传输5-10G的大文件，但系统设计时文件并非接到网络输入流后直接写到实际存储位置，而是临时位置，临时文件转移到最终目录后才写入数据库。

刚开始系统使用IO流程进行，大文件转移很慢，导致前端显示文件上传完成，但文件列表延迟很久才显示出来，最后发现文件转移是最耗时的操作，于是改为NIO转移文件:

传统io操作是面向流的，io是用户态，首先将文件从硬盘拷贝到内核空间的一个缓冲区，再将这些数据拷贝到用户空间，实际上进行了两次数据拷贝,

磁盘操作是用户态和内核态频繁切换，nio是面向缓冲区的，使用内存映射，直接将文件从硬盘拷贝到用户空间，避免了用户态和内核态的频繁切换，可以减少一次数据拷贝

--但也存在一些问题，如内存占用、文件关闭不确定，被其打开的文件只有在垃圾回收的才会被关闭，而且这个时间点是不确定的。

2.审批流程管理系统是银行需要一个定制的流程管理系统，支持隐藏流程图中的某些节点，流程抄送等功能

此系统基于activity7开发，通过feign依赖提供通用接口调用，例如流程查询、发起、审批等接口。在原有表上新增3张表以实现扩展功能。基于javax的tools工具包实现类的动态编译加载以及卸载，

将动态加载的类的实例注入spring的IOC容器中，供流程引擎监听器调用

3.信息安全管理平台的项目背景是银行接入很多安全设备，平时安全设备爆出问题都要到特定主机上查询并做相关处理，设备一多就需要有一个平台来统一管理

系统采用springcloud微服务架构，包含用户管理、网关、报表、日志解析、数据监控等十多个子服务，使用nacos作为注册中心以及配置中心。使用docker进行服务部署。

例如认证、灰度、数据源等，公共依赖包含依赖版本管理、统一响应对象以及异常处理。使子服务更关注业务实现。

公共依赖中实现了一些业务的默认处理方法，例如认证依赖中使用aop拦截带有特定注解的控制层接口，检查请求用户的权限信息。

灰度依赖中检查是否配置灰度版本，有则重新注入nacos配置对象，写入版本号后将服务注册到注册中心。

网关路由时也将检查请求是否带有灰度版本，从注册中心拉取匹配灰度版本的服务节点进行路由

日志解析服务负责从kafka中读取安全设备写入的syslog日志并解析，然后将解析后的格式化日志写入到elasticsearch中供后续查询使用。使用kafka和es的原因是:kafka能承受较大吞吐量，符合安全设备随时输出大量日志的条件。

并且kafka便于后期横向扩展，在创建topic时，多指定几个分区，后期消费能力不足时可以通过向消费者组里增加消费者来提高消费能力

es则在面对大量数据时，能提供高效实时搜索，并且他的聚合查询非常适合用于报表统计接口。

解决的问题:

es副本在其他节点，分片则可在本节点和其他节点同时存在，分片的意义在于提高写入性能

kafka保证一致性:

producer 级别：acks=all（或者 request.required.acks=-1），发生模式为同步 producer.type=sync

acks = 0意味着如果生产者能够通过网络把消息发送出去，那么就认为消息已成功写入 Kafka ,

acks = 1：意味若Leader在收到消息并把它写入到分区数据文件,在这个模式下，如果发生正常的Leader选举,生产者会在选举时收到一个异常

项目亮点：

云监控主要是维护和二次开发，无太多挑战和亮点，多在运维能力的提升，提高异常处理能力，日志排查能力。像使用top分析cpu使用率，df -h查看磁盘使用率。du -sh 不显示子目录，已合适单位显示

文件管理系统方面，一开始设计单请求上传文件，没考虑后期有大文件上传需求，后面上传大文件，前端页面就会卡住，而且没有进度条，升级为大文件分片上传

文件上传完成后最后一个请求响应很慢，这里会校验文件完整性以及入库，文件转移等操作。优化文件MD5计算，不在最后统一校验，改为每个分片请求接收时校验，结果还是慢，后面发现是大文件转移慢(缺乏大文件处理经验)

转移文件慢-原本是二进制流读入并写出到指定位置。改为NIO(零拷贝)实现，FileChannel