整个的实习经历可以分为五大框架：对部门产品的熟悉和对linux常用指令的熟悉，根据单子修改产品代码，开发产品工具类，整合微服务，抽象dmq公共逻辑
横向来说，包括难点，解决方案，收获了什么
1. 熟悉部门产品和常用linux指令
对部门的产品有了一个宏观的认识，对微服务，分布式环境，以及熟练的掌握了将一个服务器节点从划分CNA，到装虚拟机，再到部署产品的整个操作流程，熟悉了相关linux指令
2. 根据单子修改产品代码
改单流程：
- 首先根据测试单子中报的错误自己在环境上复现一下，然后F12打开开发者工具查看错误点向后台传的接口是什么，根据接口定位对应微服务中获取请求的方法。
- 首先可以通过后台服务器节点的日志信息定位问题，如果找不到报错的日志，就需要通过定位代码找问题
- 通过idea远程调试的方式将出错误的功能模块逐步走代码，定位出现错误的具体语句
- 通过具体语句定位错误，修改代码
改过的单子类型：
配置文件类：
比如操作日志转义符未正常转换，需要修改日志的相关配置文件
比如引入的配置文件过多，需要根据微服务中是否存在依赖精简引入的配置文件
比如排查TLS1.1在微服务中的应用，需要去修改相关配置文件中关于TLS网络协议的配置
Java参数类：
比如因为前端ui界面请求的参数和后端dto参数不一致而导致的排序功能失效
比如参数的get方法获取的途径不对导致相应的属性传值为null
接口类：
比如为了能在云龙上统一配置接口，需要将原先由Dto文件提供的接口改为由yaml文件反编译所提供的接口
改单难点总结：
修改接口的单子，首先需要根据已有的dto文件接口转换为一个yaml文件提供的接口，然后将dto文件提供的接口转换为yaml的接口，同时还有一些与原来接口耦合的一些参数需要抽象出来另外创建一个类来生成
排序功能失效的单子，是因为前端传来的请求中的参数与dto中的参数不同，而底层代码实现是根据前端传参的名字进行匹配的，另外去测试的时候需要使用postman模拟前端请求进行测试
属性传值为null的单子，是因为get方法获取的参数并没有获取到数据库传来的值，需要根据接口信息找到获取到数据库数据的参数进行传参
3. 开发产品工具类
需求：开发出一个可以模拟设备发送报文到控制器的工具类
难点：
如何获取报文并将报文转换为需要的格式
如何根据不同报文的要求生成不同的加工方法
如何控制多台设备同时发送报文
4. 整合微服务
需求：将两个紧耦合的微服务整合为一个微服务，省去了同时挂起两个微服务的内存
难点：
定位两个微服务之间的联系
将两个微服务提供功能的部分合并
比对两个微服务的一些接口和安装、部署方面的配置文件，合并公共项，对非公共项进行代码整合
5. 抽象dmq消费者公共逻辑
需求：dmq的消费逻辑相似度太高，代码重复，每个微服务都写来一份，难以维护，需要抽象出dmq消费的公共逻辑，业务聚焦于业务逻辑本身
难点：
发现不同微服务dmq消费代码中的公共逻辑部分并抽象出来
将抽象出来的逻辑代码整合到公共代码仓并提供接口给其他微服务，微服务中的公共逻辑部分要转换为提供的接口
