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