微服务之初识Spring Cloud(一)

什么是微服务?

微服务的概念源于2014年3月Martin Fowler所写的一篇文章“Microservices”。微服务架构是一种架构模式,它提倡将单一应用程序划分成一组小的服务,服务之间互相协调、互相配合,为用户提供最终价值。每个服务运行在其独立的进程中,服务与服务间采用轻量级的通信机制互相沟通(通常是基于HTTP的RESTful API)。每个服务都围绕着具体业务进行构建,并且能够被独立地部署到生产环境、类生产环境等。另外,应尽量避免统一的、集中式的服务管理机制,对具体的一个服务而言,应根据业务上下文,选择合适的语言、工具对其进行构建。
微服务是一种架构风格,一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署,各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下,每个任务代表着一个小的业务能力。
开发原则:高内聚低耦合。

微服务之初识Spring Cloud(一)_第1张图片

微服务的优势

  • 复杂度可控:

在将应用分解的同时,规避了原本复杂度无止境的积累。每一个 微服务专注于单一功能,并通过定义良好的接口清晰表述 服务边 界。由于体积小、复杂度低,每个微服务可由一个小规模开发团 队完全掌控,易于保持高可维护性和开发效率。

  • 独立部署:

由于微服务具备独立的运行进程,所以每个微服务也可以独立部 署。当某个微服务发生变更时无需编译、部署整个应用。由微服 务组成的应用相当于具备一系列可并行的发布流程,使得发布更 加高效,同时降低对生产环境所造成的风险,最终缩短应用交付 周期。

  • 技术选型灵活:

微服务架构下,技术选型是去中心化的。每个团队可以根据自身 服务的需求和行业发展的现状,自由选择最适合的技术栈。由于 每个微服务相对简单,故需要对技术栈进行升级时所面临的风险 就较低,甚至完全重构一个微服务也是可行的。

  • 容错:

当某一组建发生故障时,在单一进程的传统架构下,故障很有可 能在进程内扩散,形成应用全局性的不可用。在微服务架构下, 故障会被隔离在单个服务中。若设计良好,其他服务可通过重试、 平稳退化等机制实现应用层面的容错。

  • 扩展:

单块架构应用也可以实现横向扩展,就是将整个应用完整的复制 到不同的节点。当应用的不同组件在扩展需求上存在差异时,微 服务架构便体现出其灵活性,因为每个服务可以根据实际需求独 立进行扩展。

微服务架构示例

图片来源网络
微服务之初识Spring Cloud(一)_第2张图片

传统开发与微服务的区别

  1. 分工不同
    传统我们可能是一个一个模块,现在可能是一人一个系统。
  2. 架构不同
    服务的拆分是一个技术含量很高的问题,拆分是否合理对以后发展影响巨大。
  3. 部署方法不同
    如果还像以前一样部署估计累死了,自动化运维不可不上。
  4. 容灾不同
    好的微服务可以隔离故障避免服务整体down掉,坏的微服务设计仍然可以因 为一个子服务出现问题导致连锁反应。

spring cloud

官方地址:Spring Cloud
Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发,如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等,都可以用Spring Boot的开发风格做到一键启动和部署。Spring并没有重复制造轮子,它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来,通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理,最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。

核心组件

  1. 服务发现——Netflix Eureka
    服务治理是微服务架构中最为核心和基础的模块,它主要用来实现各个微服务实例的自动化注册、发现和管理。Spring Cloud Eureka就是这样一个服务治理框架
  2. 客服端负载均衡——Netflix Ribbon
    Ribbon,主要提供客户侧的软件负载均衡算法。
    Ribbon客户端组件提供一系列完善的配置选项,比如连接超时、重试、重试算法等。Ribbon内置可插拔、可定制的负载均衡组件。
  3. 断路器——Netflix Hystrix
    断路器可以防止一个应用程序多次试图执行一个操作,即很可能失败,允许它继续而不等待故障恢复或者浪费 CPU 周期,而它确定该故障是持久的。断路器模式也使应用程序能够检测故障是否已经解决。如果问题似乎已经得到纠正,应用程序可以尝试调用操作。断路器增加了稳定性和灵活性,以一个系统,提供稳定性,而系统从故障中恢复,并尽量减少此故障的对性能的影响。它可以帮助快速地拒绝对一个操作,即很可能失败,而不是等待操作超时(或者不返回)的请求,以保持系统的响应时间。如果断路器提高每次改变状态的时间的事件,该信息可以被用来监测由断路器保护系统的部件的健康状况,或以提醒管理员当断路器跳闸,以在打开状态。
  4. 服务网关——Netflix Zuul
    为了解决多次请求访问不同微服务,请求不统一增加了客户端的复杂度和暴露了服务器IP+端口号容易遭受到攻击行为等问题,springcloud同样继承了Zuul网关;类似nginx,Zuul也支持反向代理的功能,不过netflix自己增加了一些配合其他组件的特性。
  5. 分布式配置——Spring Cloud Config
    这个还是静态的,得配合Spring Cloud Bus实现动态的配置更新。

架构流程

图片来源于网络
微服务之初识Spring Cloud(一)_第3张图片
通过这张图,我们来了解一下各组件配置使用运行流程:

1.请求统一通过API网关(Zuul)来访问内部服务.
2.网关接收到请求后,从注册中心(Eureka)获取可用服务
3.由Ribbon进行均衡负载后,分发到后端具体实例
4.微服务之间通过Feign进行通信处理业务
5.Hystrix负责处理服务超时熔断
Turbine监控服务间的调用和熔断相关指标

说明

我也是个刚接触微服务架构的小白,这篇帖子也是看了网上的许多文章以后加以我自己的理解,最终才写下来的。以前也写过有个spring cloud的一个小demo,下篇帖子我就来写一写如何初步搭建微服务架构。

本人才疏学浅,若有写错的地方,欢迎指正哦!

你可能感兴趣的:(java,笔记,java,spring)