前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >SpringCloud(一)浅谈SpringCloud

SpringCloud(一)浅谈SpringCloud

作者头像
用户1195962
发布2018-08-02 15:08:09
1K0
发布2018-08-02 15:08:09
举报
文章被收录于专栏:LanceToBigData

前言

现在微服务实在是太火了,所以我们必不可少的是要学习一下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可以实 现微服务中的所有系统的配置文件的统一管理,而且还可以实现当配置文件发生变化的时候,系统会自动更新获取新的配置

本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2018-07-10 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 前言
  • 一、SpringCloud的架构设计
    • 1.1 SpringCloud架构图细解
      • 1.2 两个总结
      • 二、SpringCloud常用组件介绍
        • 2.1 Eureka
          • 2.2 Ribbon
            • 2.3 Hystrix
              • 2.4 Zuul
                • 2.5 Spring Cloud Config
                相关产品与服务
                负载均衡
                负载均衡(Cloud Load Balancer,CLB)提供安全快捷的流量分发服务,访问流量经由 CLB 可以自动分配到云中的多台后端服务器上,扩展系统的服务能力并消除单点故障。负载均衡支持亿级连接和千万级并发,可轻松应对大流量访问,满足业务需求。
                领券
                问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档