SpringCloud使用总结

前言
最近把以前的项目拆改造成了微服务架构，于是有感而发，总结一下在改造中的自己的一些经验，以及自己在其中遇见的一些问题

首先我们学一个东西就要知道为什么学它，微服务框架相对于我们的之前的单体项目有什么优势呢？
优势

1. 服务的稳定性更高（有集群做支撑，一个服务宕机了轮询还能继续跑），有着很好的熔断机制，一个服务的故障不会影响其他服务。
2. 代码的耦合度大大降低了，服务之间的通信让很多业务代码解耦，实现异步处理。
3. 每个服务都有健康检测、集中监控的平台，时刻检测服务的状态，增强维护方法
4. 服务网关隐藏了边界服务的细节增强了安全性，并且还能提供身份认证、路由服务等功能
5. 更加方便我们的维护拓展，一个项目中可以沿用多个框架技术，这个是单体项目完全不能想的
6. SpringCloud开发便捷的很大一个原因是因为它是基于Springboot这个一站式开发的框架，与很多技术集成十分便捷
7. …还有其他妙用小弟暂时还未感受得到，请大哥门指点

当然我觉得一个技术有优点不可能没有缺点，而它的缺点也挺明显的
弱势

1. 开发成本比单体项目高很多，项目不是很大完全用不上
2. 毋庸置疑项目部署也是十分繁琐，并且成本也高（当然有了docker可能小了不少）
3. 每个模块拆成一个项目，它的性能也是一个很大问题，性能需要优化
4. 最后项目完工测试阶段也增加了不少痛苦，错误比较难以排查

SpringCloud技术总结

在一次经历过一次项目拆分后，对SpringCloud的架构也是比较熟悉了
图就不花了，我觉得网上大佬画的比我的质量高多了，我就选了一张，觉得最能体现我理解的一张图，然后照着这图来说一下我的理解吧

1、zuul网关，这是web请求经过的第一个服务，它具有拦截器和隐藏我们边界服务地址的功能，并且zuul能搭建集群，并且自带ribbon负载均衡，拦截器能很好的帮我们进行身份认证，能隐藏服务地址又极大的提高了安全性，zuul毋庸是一个比较好的’过滤者’

2、eureka注册中心，它能搭建一个高可用的集群，并能够检测我们服务的一些状态，多久刷新列表一次，多久监测心跳什么的

3、Spring Admin,可以集成turbine断路器监控器,可以对我们的服务进行实时的监控

4、Rabbion提供的负载均衡很大程度的提交我们服务提供者的高可用性，而Feign提供的网络请求方便了我们服务之间的调用，并且还能简化我们很多代码

5、config注册中心，把项目的配置文件交给git集中统一管理，既方便了修改，又能够不重启服务即时跟新配置文件

6、消息队列，用来处理消息缓存，实现业务的异步、解耦、削峰

小小BUG
1、在使用Feign调用服务的时候，是不能同时传递两个实体类的，Feign请求只支持单个反应，所以这个时候我们要么用Map解决，要么用VO类来解决这个问题

2、项目中性能如果没有优化肯定会导致请求时间过长，这个时候一定要非常注意Rabbin和Feign的超时时长

3、最后在使用docker部署时，如果本地项目没有什么问题，打成jar包就有问题了的时候，请检测可能在你打jar的时候你的配置文件丢失了，你可用解析一下你打的jar看看

end…