在《架构师必须要知道的阿里的中台战略与微服务》 中已经阐明选择 SpringCloud 进行微服务架构实现中台战略, 因此下面介绍 SpringCloud 的一些内容, SpringCloud 已经出来了很多年, 网上资料一大堆, 这里推荐 程序猿 DD 的博客 http://blog.didispace.com/ 关于 SpringCloud 微服务各组件内容等做了非常详细的介绍, 适合入门的来学习.
Spring Cloud 是基于 Spring Boot 的, 因此还在使用 SpringMVC 的同学要先了解 Spring Boot. 先上一段官话, Spring Cloud 是一个基于 Spring Boot 实现的云应用开发工具, 它为基于 JVM 的云应用开发中涉及的配置管理, 服务发现, 断路器, 智能路由, 微代理, 控制总线, 全局锁, 决策竞选, 分布式会话和集群状态管理等操作提供了一种简单的开发框架.
Spring Cloud 并没有重复制造轮子, 它只是将目前各家公司开发的比较成熟, 经得起实际考验的服务框架组合起来, 通过 Spring Boot 风格进行再封装屏蔽掉了复杂的配置和实现原理, 最终给开发者留出了一套简单易懂, 易部署和易维护的分布式系统开发工具包.
Spring Cloud 全家桶
上面的图是 Spring Cloud 的全家桶, 包罗万象, 犹如水电, 涉及到开发的方方页面.
Spring Cloud 从设计之初就考虑了绝大多数互联网公司架构演化所需的功能, 如服务发现注册, 配置中心, 消息总线, 负载均衡, 断路器, 数据监控等.
首先是核心服务治理的组件(服务注册与发现)Spring Cloud Eureka
Eureka 是 Netflix 开源的一款提供服务注册和发现的产品, Eureka 就是一个服务中心, 将所有的可以提供的服务都注册到它这里来管理, 其它各调用者需要的时候去注册中心获取, 然后再进行调用, 避免了服务之间的直接调用, 方便后续的水平扩展, 故障转移等. 如下图:
当然服务中心这么重要的组件一但挂掉将会影响全部服务, 因此需要搭建 Eureka 集群来保持高可用性, 生产中建议最少两台. 随着系统的流量不断增加, 需要根据情况来扩展某个服务, Eureka 内部已经提供均衡负载的功能, 只需要增加相应的服务端实例既可. 那么在系统的运行期间某个实例挂了怎么办? Eureka 内容有一个心跳检测机制, 如果某个实例在规定的时间内没有进行通讯则会自动被剔除掉, 避免了某个实例挂掉而影响服务.
因此使用了 Eureka 就自动具有了注册中心, 负载均衡, 故障转移的功能.
当然还有另外一个实现组件 Spring Cloud Consul, 这里不做多介绍.
随着微服务不断的增多, 每个微服务都有自己对应的配置文件. 在研发过程中有测试环境, UAT 环境, 生产环境, 因此每个微服务又对应至少三个不同环境的配置文件. 这么多的配置文件, 如果需要修改某个公共服务的配置信息, 如: 缓存, 数据库等, 难免会产生混乱, 这个时候就需要引入 Spring Cloud 另外一个组件: Spring Cloud Config.
Spring Cloud Config
Spring Cloud Config 是一个解决分布式系统的配置管理方案. 它包含了 Client 和 Server 两个部分, 其实就是 Server 端将所有的配置文件服务化, 需要配置文件的服务实例去 Config Server 获取对应的数据. 将所有的配置文件统一整理, 避免了配置文件碎片化.
如果服务运行期间改变配置文件, 服务是不会得到最新的配置信息, 需要解决这个问题就需要引入 Refresh. 可以在服务的运行期间重新加载配置文件, 当所有的配置文件都存储在配置中心的时候, 配置中心就成为了一个非常重要的组件. 如果配置中心出现问题将会导致灾难性的后果, 因此在生产中建议对配置中心做集群, 来支持配置中心高可用性.
Hystrix
在微服务架构中通常会有多个服务层调用, 基础服务的故障可能会导致级联故障, 进而造成整个系统不可用的情况, 这种现象被称为服务雪崩效应.
如下图所示: A 作为服务提供者, B 为 A 的服务消费者, C 和 D 是 B 的服务消费者. A 不可用引起了 B 的不可用, 并将不可用像滚雪球一样放大到 C 和 D 时, 雪崩效应就形成了.
在这种情况下就需要整个服务机构具有故障隔离的功能, 避免某一个服务挂掉影响全局. 在 Spring Cloud 中 Hystrix 组件就扮演这个角色.
Hystrix 会在某个服务连续调用 N 次不响应的情况下, 立即通知调用端调用失败, 避免调用端持续等待而影响了整体服务. Hystrix 间隔时间会再次检查此服务, 如果服务恢复将继续提供服务.
Hystrix Dashboard 和 Turbine
当熔断发生的时候需要迅速的响应来解决问题, 避免故障进一步扩散, 那么对熔断的监控就变得非常重要. 熔断的监控现在有两款工具: Hystrix-dashboard 和 Turbine.
Hystrix-dashboard 是一款针对 Hystrix 进行实时监控的工具, 通过 Hystrix Dashboard 我们可以直观地看到各 Hystrix Command 的请求响应时间, 请求成功率等数据. 但是只使用 Hystrix Dashboard 的话, 你只能看到单个应用内的服务信息, 这明显不够. 我们需要一个工具能让我们汇总系统内多个服务的数据并显示到 Hystrix Dashboard 上, 这个工具就是 Turbine. 监控的效果图如下:
Spring Cloud Bus 消息总线
Refresh 方案虽然可以解决单个微服务运行期间重载配置信息的问题, 但是在真正的实践生产中, 可能会有 N 多的服务需要更新配置, 如果每次依靠手动 Refresh 将是一个巨大的工作量, 这时候 Spring Cloud 提出了另外一个解决方案: Spring Cloud Bus
Spring Cloud Bus 通过轻量消息代理连接各个分布的节点. 这会用在广播状态的变化 (例如配置变化) 或者其它的消息指令中. Spring Cloud Bus 的一个核心思想是通过分布式的启动器对 Spring Boot 应用进行扩展, 也可以用来建立一个或多个应用之间的通信频道. 目前唯一实现的方式是用 AMQP 消息代理作为通道.
Spring Cloud Bus 是轻量级的通讯组件, 也可以用在其它类似的场景中. 有了 Spring Cloud Bus 之后, 当我们改变配置文件提交到版本库中时, 会自动的触发对应实例的 Refresh, 具体的工作流程如下:
服务网关
在微服务架构模式下, 后端服务的实例数一般是动态的, 对于客户端而言很难发现动态改变的服务实例的访问地址信息. 因此在基于微服务的项目中为了简化前端的调用逻辑, 通常会引入 API Gateway 作为轻量级网关, 同时 API Gateway 中也会实现相关的认证逻辑从而简化内部服务之间相互调用的复杂度.
Spring Cloud 体系中支持 API Gateway 落地的技术就是 Zuul.Spring Cloud Zuul 路由是微服务架构中不可或缺的一部分, 提供动态路由, 监控, 弹性, 安全等的边缘服务. Zuul 是 Netflix 出品的一个基于 JVM 路由和服务端的负载均衡器. 它的具体作用就是服务转发, 接收并转发所有内外部的客户端调用. 使用 Zuul 可以作为资源的统一访问入口, 同时也可以在网关做一些权限校验等类似的功能.
链路跟踪
随着服务的越来越多, 对调用链的分析会越来越复杂, 如服务之间的调用关系, 某个请求对应的调用链, 调用之间消费的时间等, 对这些信息进行监控就成为一个问题. 在实际的使用中我们需要监控服务和服务之间通讯的各项指标, 这些数据将是我们改进系统架构的主要依据. 因此分布式的链路跟踪就变的非常重要, Spring Cloud 也给出了具体的解决方案: Spring Cloud Sleuth 和 Zipkin
Spring Cloud Sleuth 为服务之间调用提供链路追踪. 通过 Sleuth 可以很清楚的了解到一个服务请求经过了哪些服务, 每个服务处理花费了多长时间. 从而让我们可以很方便的理清各微服务间的调用关系. 分布式链路跟踪需要 Sleuth+Zipkin 结合来实现, 当然实现链路追踪的还有三方开源方案, 如果 zipkin 实现的功能非常简单, 图形化能力也不强, 所以可以试试其它的方案, 如 pinpoint 较成熟的框架等.
Feign
声明式远程调度组件.
Ribbon
负载均衡组件
Spring Cloud Data Flow
大数据操作组件, 它是 Spring XD 的替代品, 也是一个混合计算模型, 可以通过命令行的方式操作数据流
Spring Cloud Task
组件基于 Spring Tsak, 提供任务调度和任务管理的功能
以上只介绍经常用到非常重要的内容, 一般的技术栈为 SpringCloud +GitLab+Jinkins 进行普通服务的开发持续集成部署 CI, 后面可升级用 SpingCloud +GitLab+Jinkins+Docker 容器化布署, 进一步升级到用 SpingCloud +GitLab+Jinkins+Docker+k8s 自动化容器编排内容, 这里的难度等级就完全不一样了, 而且每一个组件都涉及到很多内容, 传统业务如何进行微服务的拆分下次再进行讨论.
来源: http://www.jianshu.com/p/892aad08c928