2019.4.11

1.静态资源映射，在配置文件中添加

2.spring cloud bus 已经ok，config客户端和服务端都需要加入mp的依赖，并且在config的服务端做一些配置，具体参见项目，可实现服务无感应刷新！此间，安装mq，已经elang环境。由于需要远程访问mq的服务，出现错误，原因大致是。mq默认的guest用户，只能够本地访问，解决方案参考网络！此间需要注意一些事项！

3.问题描述，因为项目中用到mybatisPlus，用到其中的service中insert方法，数据库id是自增类型，之前是用mp自动生成的的实体类，所以又getset方法，但是随后需求改动，为了省事，直接用@Data注解，然后在插入方法的时候就报错，莫名其妙，报错信息，写blog在复现，原因正在寻找 原因已经找到，id自增需要加注解@TableId(value = "id", type = IdType.AUTO)！

4.随后安排，cloud各组件弄明白原理，给出demo传入git！写启动脚本，kibana，es！分布式事务，事务！

5.maven依赖下载过程中，由于网络中断等情况导致下载不完全，必须从本地maven库中删除重新下载

6.cloud前后端分离，跨域问题，zuul服务熔断统处理

7.bus的远程mq突然连接不上，然后重启远程机器的mq服务，就好了！

8.由于用了蓝灯，导致连不上redis服务器，导致听音乐总是提示海外无版权

9.前后端分离跨域

10.lamada表达是解决操作集合的一些骚操作！

11.遍历集合，删除元素，出现的错误 java.util.ConcurrentModificationException: null ，解决办法用迭代器遍历删除

12.网关所在机器ip和微服务所在机器ip不在同一网段，导致一直会走网关的服务熔断，也就是服务访问不到

13 问题重现，网关和注册中心在1.158机器上，本地ip1.62，启动本地服务，访问没有问题，本机突然换成公司wifi，本机ip被换成62.128，再次去访问本机服务，由于之前服务注册到注册中心的时候告诉注册中心此服务的ip微1.62，当连上公司wifi后本机ip被重新分配，62的ip已经没有机器使用，所以再次访问服务会走服务熔断，服务不可用！

14.如果注册中心和服务不再一个网段是不能完成注册的

15.使用mp，如果实体类中有表中不存在的字段，如果不做处理，在使用MP封装的查询方法时，会报此字段在表中不存在。解决方法：在相应字段上加注解 @TableField(exist = false)

16.激活win10用

17.有些查询统计分组查的时候，有些字段为空，但是这不符合前端的数据要求，可直接在sql中用ifnull函数做处理，不需要java代码中做处理

18 .mysql函数查出函数保留两位小数，round()函数，还有left函数从左边起截取几位，还有substring(b.survey_time, 6,5)  从第6位开始截取，截取5位，包含第6位，下标从一开始数

19.easypoi导入导出excel和导出word，结合模板遍历结合

20.easypoi导出word是，加图片也没问题，模板中的括号，真是坑人，不知道咋回事，是用的英文括号，但有时候就不能行！日了狗(模板中的表达式搞的鬼)！

21. IPage<ProjectAdmission> IPage = projectAdmissionMapper.selectPage(new Page<>(pageNum, pageSize), wrapper);参数pageNum是页码，pageSize每页显示的条数；

22.功能接受图片为base64编码字符串，解码为字节数组，然后导出word。遇到问题，转为图片为空，原因，拿到的编码data:image/jpeg;base64,包含这一部分，但是这并不是图片的base64编码的一部分，所以写不出正确的图片。也有接受64编码，保存为图片的工具类，用起来很方便。

23.一个空格改变一次命运a.real_name like concat( '%' ,#{realName}, '%')

24.easypoi导出word图片导出，图片的比例可以设置，前端可以计算比例

25.zuul 路由规则，

zuul:
 routes:
   api-a:
     path: /clients/**
     serviceId: service-a

api-a这一层可以自定义，下面的路径是指请求路径中带有clients/**所有的请求都会被路由到service-a服务，但是clients后面的路径是，service-a服务中的请求路径比如，服务a中有/clients/hello，如果要通过网关去路由，则路径必须是/clients/clients/hello才能被正确的路由到s服务，并且请求到！

26.上传文件大小设置

在配置文件中添加如下配置

spring.servlet.multipart.max-file-size=100MB
spring.servlet.multipart.max-request-size=1000MB

27.文件的上传工具类

28.开启feign 需要注解@EnableFeignClients  //开启Feign的功能

29.copy C:\"Program Files"\nsoftware\"PowerShell Server 2016"\sftproot\*.jar d:\jarNew cmd 执行命令 如果路径中有空格可以在路径上面加引号来解决

30 .<build>
   <finalName>eureka</finalName>
   <plugins>
       <plugin>
           <groupId>org.springframework.boot</groupId>
           <artifactId>spring-boot-maven-plugin</artifactId>
       </plugin>
   </plugins>
</build>

31jenkins构建boot项目，脚本，配置

32.java 读取shape文件

33.问题外网连接不到es，解决办法，在se的配置文件中network.host: 192.168.1.158，改成本机ip

由图可知，Eureka包含两个组件：Eureka Server 和 Eureka Client，它们的作用如下：

• Eureka Server提供服务发现的能力，各个微服务启动时，会向Eureka Server注册自己的信息（例如IP、端口、微服务名称等），Eureka Server会存储这些信息；
• Eureka Client是一个Java客户端，用于简化与Eureka Server的交互；
• 微服务启动后，会周期性（默认30秒）地向Eureka Server发送心跳以续约自己的“租期”；
• 如果Eureka Server在一定时间内没有接收到某个微服务实例的心跳，Eureka Server将会注销该实例（默认90秒）；
• 默认情况下，Eureka Server同时也是Eureka Client。多个Eureka Server实例，互相之间通过增量复制的方式，来实现服务注册表中数据的同步。Eureka Server默认保证在90秒内，Eureka Server集群内的所有实例中的数据达到一致（从这个架构来看，Eureka Server所有实例所处的角色都是对等的，没有类似Zookeeper、Consul、Etcd等软件的选举过程，也不存在主从，所有的节点都是主节点。Eureka官方将Eureka Server集群中的所有实例称为“对等体（peer）”）
• Eureka Client会缓存服务注册表中的信息。这种方式有一定的优势——首先，微服务无需每次请求都查询Eureka Server，从而降低了Eureka Server的压力；其次，即使Eureka Server所有节点都宕掉，服务消费者依然可以使用缓存中的信息找到服务提供者并完成调用。

综上，Eureka通过心跳检查、客户端缓存等机制，提高了系统的灵活性、可伸缩性和可用性。

ribbon.ReadTimeout， ribbon.SocketTimeout这两个就是ribbon超时时间设置，当在yml写时，应该是没有提示的，给人的感觉好像是不是这么配的一样，其实不用管它，直接配上就生效了。
还有zuul.host.connect-timeout-millis， zuul.host.socket-timeout-millis这两个配置，这两个和上面的ribbon都是配超时的。区别在于，如果路由方式是serviceId的方式，那么ribbon的生效，如果是url的方式，则zuul.host开头的生效。（此处重要！使用serviceId路由和url路由是不一样的超时策略）

#重试机制#该参数用来开启重试机制，默认是关闭spring.cloud.loadbalancer.retry.enabled=true#对所有操作请求都进行重试ribbon.OkToRetryOnAllOperations=true#对当前实例的重试次数ribbon.MaxAutoRetries=1#切换实例的重试次数ribbon.MaxAutoRetriesNextServer=1#根据如上配置，当访问到故障请求的时候，它会再尝试访问一次当前实例（次数由MaxAutoRetries配置），#如果不行，就换一个实例进行访问，如果还是不行，再换一次实例访问（更换次数由MaxAutoRetriesNextServer配置），#如果依然不行，返回失败信息。

开启重试在某些情况下是有问题的，比如当压力过大，一个实例停止响应时，路由将流量转到另一个实例，很有可能导致最终所有的实例全被压垮。说到底，断路器的其中一个作用就是防止故障或者压力扩散。用了retry，断路器就只有在该服务的所有实例都无法运作的情况下才能起作用。这种时候，断路器的形式更像是提供一种友好的错误信息，或者假装服务正常运行的假象给使用者。

不用retry，仅使用负载均衡和熔断，就必须考虑到是否能够接受单个服务实例关闭和eureka刷新服务列表之间带来的短时间的熔断。如果可以接受，就无需使用retry。

为了提高服务的可用性，我们一般会将相同的服务部署多个实例，负载均衡的作用就是使获取服务的请求被均衡的分配到各个实例中。负载均衡一般分为服务端负载均衡和客户端负载均衡，服务端的负载均衡通过硬件（如F5）或者软件（如Nginx）来实现，而Ribbon实现的是客户端负载均衡。服务端负载均衡是在硬件设备或者软件模块中维护一份可用服务清单，然后客户端发送服务请求到这些负载均衡的设备上，这些设备根据一些算法均衡的将请求转发出去。而客户端负载均衡则是客户端自己从服务注册中心（如之前提到的Eureka Server）中获取服务清单缓存到本地，然后通过Ribbon内部算法均衡的去访问这些服务。

Eureka是Netflix开发的服务发现框架，本身是一个基于REST的服务，主要用于定位运行在AWS域中的中间层服务，以达到负载均衡和中间层服务故障转移的目的。SpringCloud将它集成在其子项目spring-cloud-netflix中，以实现SpringCloud的服务发现功能。
Eureka包含两个组件：Eureka Server和Eureka Client。
Eureka Server提供服务注册服务，各个节点启动后，会在Eureka Server中进行注册，这样EurekaServer中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观的看到。
Eureka Client是一个java客户端，用于简化与Eureka Server的交互，客户端同时也就是一个内置的、使用轮询(round-robin)负载算法的负载均衡器。
在应用启动后，将会向Eureka Server发送心跳,默认周期为30秒，如果Eureka Server在多个心跳周期内没有接收到某个节点的心跳，Eureka Server将会从服务注册表中把这个服务节点移除(默认90秒)。
Eureka Server之间通过复制的方式完成数据的同步，Eureka还提供了客户端缓存机制，即使所有的Eureka Server都挂掉，客户端依然可以利用缓存中的信息消费其他服务的API。综上，Eureka通过心跳检查、客户端缓存等机制，确保了系统的高可用性、灵活性和可伸缩性