SpringCloud（一）浅谈SpringCloud
本文内容纲要：
-前言
-一、SpringCloud的架构设计
-1.1SpringCloud架构图细解
-1.2两个总结
-二、SpringCloud常用组件介绍
-2.1Eureka
-2.2Ribbon
-2.3Hystrix
-2.4Zuul
-2.5SpringCloudConfig
前言
现在微服务实在是太火了，所以我们必不可少的是要学习一下SpringCloud了，服务化的核心就是将传统的一站式应用
根据业务拆分成一个一个的服务，而微服务在这个基础上要更彻底地去耦合（不再共享DB、KV，去掉重量级ESB），并
且强调DevOps和快速演化。
springcloud中常用的组件：
- 服务发现——NetflixEureka
- 客户端负载均衡——NetflixRibbon
- 断路器——NetflixHystrix
- 服务网关——NetflixZuul
- 分布式配置——SpringCloudConfig
一、SpringCloud的架构设计
1.1SpringCloud架构图细解
上面的SpirngCloud的架构图，分层概述一下。
- web服务器的选型，这个我选择的是nginx+keepalived，haproxy也是一个选择，但是haproxy在反向代理处理跨域
访问的时候问题很多。所以我们nginx有些地方做了keep-alive模式处理，减少了三次握手的次数，提高了连接效率。
keepalived做nginx的负载，虚拟一个vip对外，两个nginx做高可用，nginx本身反向代理zuul集群。 - apigateway，这里的zuul很多人诟病，说是速度慢推荐直接用nginx，这里我还是推荐使用zuul的，毕竟zuul含有
拦截器和反向代理，在权限管理、单点登录、用户认证时候还是很有用的，而且zuul自带ribbon负载均衡，如果你直接用
nginx，还需要单独做一个feign或者ribbon层，用来做业务集群的负载层，毕竟直接把接口暴露给web服务器太危险了。
这里zuul带有ribbon负载均衡和hystrix断路器，直接反向代理serviceId就可以代理整个集群了。 - 业务集群，这一层我有些项目是分两层的，就是上面加了一个负载层，下面是从service开始的，底层只是单纯的接口，
controller是单独一层由feign实现，然后内部不同业务服务接口互调，直接调用controller层，只能说效果一般，多
了一次tcp连接。所以我推荐合并起来，因为做过springcloud项目的都知道，feign是含有ribbon的，而zuul也含有
ribbon，这样的话zuul调用服务集群，和服务集群间接口的互调都是高可用的，保证了通讯的稳定性。Hystrix还是要有
的，没有断路器很难实现服务降级，会出现大量请求发送到不可用的节点。当然service是可以改造的，如果改造成rpc方
式，那服务之间互调又是另外一种情况了，那就要做成负载池和接口服务池的形式了，负载池调用接口池，接口池互相rpc
调用，feignclient只是通过实现接口达到了仿rpc的形式，不过速度表现还是不错的。 - redis缓存池，这个用来做session共享，分布式系统session共享是一个大问题。同时呢，redis做二级缓存对降低整个
服务的响应时间，并且减少数据库的访问次数是很有帮助的。当然rediscluster还是redissentinel自己选择。 - eureak注册中心这个高可用集群，这里有很多细节，比如多久刷新列表一次，多久监测心跳什么的，都很重要。
- springadmin，这个是很推荐的，这个功能很强大，可以集成turbine断路器监控器，而且可以定义所有类的log等级，
不用单独去配置，还可以查看本地log日志文件，监控不同服务的机器参数及性能，非常强大。它加上elk动态日志收集系
统，对于项目运维非常方便。 - zipkin，这个有两种方式，直接用它自己的功能界面查看方式，或者用stream流的方式，由elk动态日志系统收集。但
是我必须要说，这个对系统的性能损害非常大，因为链路追踪的时候会造成响应等待，而且等待时间非常长接近1秒，这在
生产环境是不能忍受的，所以生产环境最好关掉，有问题调试的时候再打开。 - 消息队列，这个必须的，分布式系统不可能所有场景都满足强一致性，这里只能由消息队列来作为缓冲，这里我用的是
Kafka。 - 分布式事物，我认为这是分布式最困难的，因为不同的业务集群都对应自己的数据库，互相数据库不是互通的，互相服
务调用只能是相互接口，有些甚至是异地的，这样造成的结果就是网络延迟造成的请求等待，网络抖动造成的数据丢失，
这些都是很可怕的问题，所以必须要处理分布式事物。我推荐的是利用消息队列，采取二阶段提交协议配合事物补偿机制，
具体的实现需要结合业务，这里篇幅有限就不展开说了。 - config配置中心，这是很有必要的，因为服务太多配置文件太多，没有这个很难运维。这个一般利用消息队列建立一个
springcloudbus，由git存储配置文件，利用bus总线动态更新配置文件信息。 - 实时分布式日志系统，logstash收集本地的log文件流，传输给elasticsearch，logstash有两种方式，1、是每一台
机器启动一个logstash服务，读取本地的日志文件，生成流传给elasticsearch。2、logback引入logstash包，然后直
接生产json流传给一个中心的logstash服务器，它再传给elasticsearch。elasticsearch再将流传给kibana，动态查
看日志，甚至zipkin的流也可以直接传给elasticsearch。这个配合springadmin，一个查看动态日志，一个查看本地
日志，同时还能远程管理不同类的日志级别，对集成和运维非常有利。
1.2两个总结
- springcloud的很多东西都比较精确，比如断路器触发时间、事物补偿时间、http响应时间等，这些都需要好好的设计，
而且可以优化的点非常多。比如：http通讯可以使用okhttp，jvm优化，nio模式，数据连接池等等，都可以很大的提高
性能。 - docker问题，很多人说不用docker就不算微服务。其实我个人意见，springcloud本身就是微服务的，只需要jdk环境
即可。编写dockerfile也无非是集成jdk、添加jar包、执行jar而已，或者用dockercompose，将多个不同服务的image
组合run成容器而已。但是带来的问题很多，比如通讯问题、服务器性能损耗问题、容器进程崩溃问题，当然如果你有一套成
熟的基于k8s的容器管理平台，这个是没问题的，如果没有可能就要斟酌了。而springcloud本身就是微服务分布式的架构
，所以个人还是推荐直接机器部署的，当然好的DevOps工具将会方便很多。
二、SpringCloud常用组件介绍
2.1Eureka
一个RESTful服务，用来定位运行在AWS地区（Region）中的中间层服务。由两个组件组成：Eureka服务器和Eureka客户端。
Eureka服务器用作服务注册服务器。Eureka客户端是一个java客户端，用来简化与服务器的交互、作为轮询负载均衡器，并
提供服务的故障切换支持。Netflix在其生产环境中使用的是另外的客户端，它提供基于流量、资源利用率以及出错状态的
加权负载均衡。
2.2Ribbon
Ribbon，远程过程调用，包含软件负载均衡算法。
Ribbon客户端组件提供一系列完善的配置选项，比如连接超时、重试、重试算法等。Ribbon内置可插拔、可定制的负载均衡组件。
下面是用到的一些负载均衡策略：
- 简单轮询负载均衡
- 加权响应时间负载均衡
- 区域感知轮询负载均衡
- 随机负载均衡
Ribbon中还包括以下功能：
- 易于与服务发现组件（比如Netflix的Eureka）集成
- 使用Archaius完成运行时配置
- 使用JMX暴露运维指标，使用Servo发布
- 多种可插拔的序列化选择
- 异步和批处理操作
- 自动SLA框架
- 系统管理/指标控制台
2.3Hystrix
断路器可以防止一个应用程序多次试图执行一个操作，即很可能失败，允许它继续而不等待故障恢复或者浪费CPU周期，而它
确定该故障是持久的。断路器模式也使应用程序能够检测故障是否已经解决。如果问题似乎已经得到纠正，应用程序可以尝试调
用操作。
断路器增加了稳定性和灵活性，以一个系统，提供稳定性，而系统从故障中恢复，并尽量减少此故障的对性能的影响。它可以帮助
快速地拒绝对一个操作，即很可能失败，而不是等待操作超时（或者不返回）的请求，以保持系统的响应时间。如果断路器提高
每次改变状态的时间的事件，该信息可以被用来监测由断路器保护系统的部件的健康状况，或以提醒管理员当断路器跳闸，以在
打开状态。
流程图:
2.4Zuul
类似nginx，反向代理的功能，不过netflix自己增加了一些配合其他组件的特性。
2.5SpringCloudConfig
当一个系统中的配置文件发生改变的时候，我们需要重新启动该服务，才能使得新的配置文件生效，springcloudconfig可以实
现微服务中的所有系统的配置文件的统一管理，而且还可以实现当配置文件发生变化的时候，系统会自动更新获取新的配置
本文内容总结：前言，一、SpringCloud的架构设计，1.1SpringCloud架构图细解，1.2两个总结，二、SpringCloud常用组件介绍，2.1Eureka，2.2Ribbon，2.3Hystrix，2.4Zuul，2.5SpringCloudConfig，
原文链接：https://www.cnblogs.com/zhangyinhua/p/9291790.html