1.Spring Cloud 构建微服务应用程序之概览

Spring Cloud Netflix 专栏收录该内容
1 篇文章 0 订阅

时隔多日,终于决定要开始写Spring Cloud 系列了,欢迎各位道友点赞关注评论和转发。

在开始学习Spring Cloud 之前,我们先来了解下微服务的发展历史。

1.1 微服务发展史

  • 微服务定义
    2014年3月,Martin Fowler在其博客上发表了Microservices(微服务一文,)对过去几年逐渐开始流行的微服务架构开发模式给出了正式的定义。
  • Netflix 公司将微服务基础组件开源
    同年,Netflix将自己多年来在实际开发中所使用的微服务基础组件通过Netflix OSS(Open Source Software)进行开源.
  • Spring 官方团队Pivotal 对Netflix 公司开源的微服务组件进行封装简化,推出Spring Cloud.
    随后,PivotalNetflix OSSNetFlix OSS的基础上对这些组件进行了封装和集成,推出了Spring Cloud.

上面我们已经知道,Spring cloud 其实是对开源的微服务基础组件进行了封装,简化了微服务应用的开发.

因此,如果我们学会了Spring Cloud,就可以帮助我们快速地开发微服务应用。

1.2 为什么要学习微服务应用开发?

等等,为什么要学习微服务应用开发呢?

在Java开发中,一个典型的单体架构应用就是将一个应用中所有的功能都打包在一个war中,并部署在应用服务器(如Tomcat)中运行。
在这里插入图片描述

  • 简单来说,微服务的出现,解决了单体架构的痛点,易于扩展和独立部署。
  • 但是 微服务和分布式技术不是银弹,不是所有的单体应用程序都适合改造成微服务应用的。
  • 选择微服务通常意味着需要解决分布式架构的各种难题。
  • 更多请参考我在云栖社区写的另外一篇博文 为什么会出现微服务和分布式?

博主语:

  • 个人感觉,微服务和分布式技术一般适用于需要灵活扩容,比较复杂,庞大且可以拆分的系统。

1.3 微服务和分布式之间的关系

我们在学习的过程中,可能有时候我们听到说微服务,有时候又听到说分布式。

那么微服务和分布式之间是什么关系呢?

术语解释作用
分布式一个业务分拆多个子业务,部署在不同的服务器上,分布式是指将不同的业务分布在不同的地方分布式解决网站高并发带来问题
集群同一个业务,部署在多个服务器上。集群指的是将几台服务器集中在一起,实现同一业务通过负载均衡设备共同对外提供服务
SOA业务系统分解为多个组件,让每个组件都独立提供离散,自治,可复用的服务能力;通过服务的组合和编排来实现上层的业务流程简化维护,降低整体风险,伸缩灵活
微服务各服务间隔离(分布式也是隔离),自治(分布式依赖整体组合)其它特性(单一职责,边界,异步通信,独立部署)是分布式概念的跟严格执行各服务可独立应用,组合服务也可系统应用(巨石应用[monolith]的简化实现策略-平台思想)

我的理解:

  • 微服务和分布式是从不同层面和方向上来分的。
  • 微服务是架构设计方式,是将系统按照功能模块进行拆分成单个独立的应用程序。
  • 分布式是指不同模块部署在不同服务器上,部署方式是分散部署的,微服务可能部署在不同的服务器上。
  • Spring Boot/Cloud是目前较为流行的微服务框架
  • 微服务架构下,部署和运维都面临着新的挑战,选择微服务通常意味着需要解决分布式架构的各种难题。

1.4 微服务架构下构建分布式系统带来了哪些问题?

当一个单体应用程序被拆分成微服务之后,将会面临着很多新的问题。

下图是微服务架构的核心关键点:
微服务架构的核心关键点
接下来我们详细讲解下这张图。

1.4.1 服务治理

  • 问题一:各个微服务之间如何调用?
  • 当单体应用程序拆分成微服务之后,首先面临的第一个问题就是,作为消费者如何访问并调用服务提供者所提供的服务,作为服务提供者如何能让服务消费者知道并进行消费?
  • 在传统的单体应用程序开发中,只需要通过某种方式创建相关类的实例,就可以调它的方法了,因此并不存在这个问题。
  • 但是在微服务架构下,同一个微服务可能同时存在多个实例,也可能部署在不同的机器上,并且这些微服务实例还在不断上线下线,那么它们如何相知相识并进行通信呢?使用物理地址显然不行,因为不知道服务提供者到底在哪一台服务器,服务当前是否在线,如果服务不在线还进行调用岂不是会造成调用失败?
  • 问题二:快速水平扩展
  • 对于微服务架构应用来说还有一个重要因素,快速水平扩展。在进行快速扩展时,我们不可能预先知道所有的服务实例地址并告知服务消费者,而且也无法确定有哪些,有多少消费者回来消费。

解决方案

  • 业界对于此问题的解决方案就是服务治理,
  • 服务治理领域最重要的问题就是服务发现与注册
    在这里插入图片描述

1.4.1.1 服务注册

服务注册机制,可以让服务提供者在上线时将所提供的服务信息注册到服务治理服务器中,供服务消费者使用。
在这里插入图片描述

1.4.1.2 服务发现

通过服务发现,消费者可以在预先不知道服务提供者物理地址的情况下,仅通过相应的服务名称就可以实现服务调用。

1.4.1.3 服务注销

当服务下线时将自己从服务治理服务器中注销,避免服务消费者调用而造成的异常。

1.4.1.4 服务状态监控

服务的状态比如注册和注销,需要对其进行监控,便于更新服务治理服务器数据。

1.4.1.5 负载均衡

存在的问题:

  • 用户入口进行负载均衡? Nginx
  • 对于负载均衡,传统应用通常会在用户请求的入口通过负载均衡设备(如F5等)或通过Ngnix 反向代理方式实现负载均衡。
  • 浏览器的请求一般包括html/css/js和API请求数据库数据,访问量小还好说,但是一旦访问量大了,服务端就会感到压力很大,为了减轻负载的压力,人们思考,将html/css/js 的请求和API的请求进行分离,设计了一个叫做Nginx 的服务器来专门处理html/css/js 的请求。
    常用的软件负载均衡软件有NginxLVSHaProxy等。
  • LVS(Linux Virtual Server),也就是Linux虚拟服务器
  • Nginx
  • HaProxy
  • 微服务之间调用负载均衡-- Open Feign
    • 在微服务架构下的负载均衡不止是用户请求入口,还包含了微服务之间的调用。如果还是用传统的解决方案显然是不合适的。
      • 一方面因为传统的负载均衡设备配置非常复杂,
      • 另一方面是微服务应用实例在快速变化。
  • 怎么办?
    • 业界提出了客户端负载均衡的概念,也称之为软负载均衡。核心思想及时在服务消费者(也就是客户端)保存一份服务者列表,这份服务者列表通常是从服务治理服务器中动态获取,也可以采用固定配置的方式,然后通过某种负载均衡策略来决定每次服务调用时所使用的的具体服务实例,从而实现微服务之间的负载均衡。

1.4.2 微服务监控

  • 存在的问题:微服务架构下调试变得困难!!!
    • 单体架构下由于是单个应用程序,当我们需要调试程序和跟踪分析的时候,十分方便,我们只需要通过日志或Debug 模式等方式寻找系统中存在的问题即可。
    • 但是当放到微服务架构下,虽然微服务让系统变得更加灵活和强大,易于快速水平扩展,但是却也增加了系统调试和跟踪分析的难度。我们需要将分散在不同机器上的日志全部拿到一起看,形成一个完整的请求调用链,这是一个非常大的挑战。
  • 怎么办???
    • 针对这个问题,业界在微服务监控中提供了日志聚合,日志可视化分析,调用链追踪等解决方案,都可以为我们的微服务应用的运维提供强有力的武器。

1.4.3 服务网关

微服务是众多的,大部分都需要对外提供接口,但是我们往往一般不会直接与多个服务地址打交道,而需要通过门户模式,为微服务提供一个统一的入口,并附加一些路由规则,然后就可以不同的微服务通过路由规则提供一致的访问接口。

1.4.4 统一配置

在单体应用程序中,我们可以直接在所开发项目中进行配置管理,而在微服务架构中,一个应用拆分成多个微服务,并且由多个团队负责,而这些微服务会存在一些共同的配置数据,如果还是分散在各个项目中进行管理,那么面对数十个,上百个应用实例,修改配置将会变得非常麻烦。

1.4.5 微服务的容错

我们知道,一个用户的请求,往往会涉及到很多微服务,而微服务与微服务之间,极有可能是部署在不同的几台服务器中,也就是说微服务与微服务之间的相互调用,大多是通过网络来完成,但是网络是不可靠的,当微服务与微服务之间调用,如果其中被调用方服务器宕机了,那么调用失败就可能会引发一系列问题。

接下来我们先来看第一个问题,雪崩。

1.4.5.1 什么是雪崩?

那么什么是雪崩呢?我们来看个例子。
假设当前系统中有A,B,C三个服务,服务A是上游,服务B是中游,服务C是下游。它们的调用链如下
在这里插入图片描述
一旦下游服务C因某些原因变得不可用,积压了大量请求,服务B的请求线程也随之阻塞。线程资源逐渐耗尽,使得服务B也变得不可用。紧接着,服务A也变为不可用,整个调用链路被拖垮。
在这里插入图片描述
像这种调用链路的连锁故障,叫做雪崩。

1.4.5.2 什么是服务熔断?

在这里插入图片描述

了解更多,可参考程序员小灰前辈的公众号博文:漫画:什么是服务熔断?

1.4.6 微服务安全

  • 我们知道一个单体应用程序一旦拆分成多个应用程序,我们不可能为每一个微服务都写一套权限验证逻辑,而且有些微服务比如短信发送微服务必须保护起来不可以裸奔。
  • 为了解决此类问题,业界提出了如下解决方案:
    • 基于Spring Security 实现微服务安全以及单点登录
    • OAuth 认证
    • JWT授权

1.4.7 微服务通信

在分布式系统中,微服务A和微服务B 应用程序可能位于不同的服务器上,微服务A和微服务B发送一个消息,肯定和在同一台服务器上发送消息方式不同。

微服务与微服务之间通信大致可以分为如下几种方式:

  • RPC (Remote Procedure Call): 远程过程调用
  • Restful API
  • 消息中间件,IBM MQ, RabiitMQ,Kafka 等

1.4.8 微服务部署和编排

  • 在微服务架构下,十几个甚至上百个微服务应用实例,可能需要不断上线和下线,我们肯定不愿意手动构建和部署这些实例,因此我们需要自动化工具来帮我们提升工作效率,而且还要保证部署的各个同类型实例之间保持一致或相同的配置。
  • 业界对此,提出了使用Docker来实现快速部署,通过K8S 来帮忙实现自动化部署编排等。

1.5 微服务问题行业解决方案

目前来讲主要服务治理核心框架的选型有三个:spring-clouddubbo以及service mesh

1.5.1 Spring Cloud 简介

  • Spring Cloud它是一个基于Spring的框架,简化了微服务应用的开发。
  • Spring Cloud 是为快速构建分布式系统而生,提供了一系列工具帮助开发人员快速构建分布式系统。
  • Spring Cloud 为开发微服务应用每个组件提供了多个方面的选择和支持,这意味着我们不仅可以灵活选择使用Netflix的服务注册和服务发现组件Eureka,断路器组件Hystrix,智能路由组件Zuul,客户端负载均衡组件Ribbon。我们也可以使用阿里巴巴推出的Spring Cloud Alibaba 等其他一些组件进行开发。

Spring Cloud 包含了 Spring Cloud Common,和Spring Cloud Context.

其中, Spring Cloud Common 为微服务应用开发提供了很好的抽象,Spring Cloud Context 为微服务应用开发提供了上下文支持。

1.5.2 Spring Cloud 子项目

  • 除此之外,Spring Cloud 旗下有很多子项目,共同构成了微服务开发组件。

Spring Cloud 子项目概览表

Spring Cloud 子项目简介
Spring Cloud Eureka提供服务治理,比如服务注册和服务发现等功能。
Spring Cloud Hystrix实现服务降级功能
Spring Cloud Zuul实现API 服务网关
Spring Cloud Config统一配置,配置文件加载和管理
Spring Cloud Sleuth服务链路追踪解决方案。
Spring Cloud Stream提供消息中间件抽象层
Spring Cloud SecurityAPI 权限拦截
Spring Cloud OAuth 2.0授权认证

Spring Cloud 为了简化微服务架构下分布式应用程序的开发,提供了如下工具。

微服务架构下分布式应用程序开发存在的问题Spring Cloud 简化开发解决方案
服务治理如果采用 Spring Cloud 体系,则选择Netflix 公司的Eureka是最佳搭配。如果使用的是Dubbo 则选Zookeeper作为注册中心, 客户端负载均衡可选RibbonOpen Feign可选服务治理解决框架:Netflix Eureka、Consul、Zookeeper
微服务监控Sleuth 链路追踪,Zipkin Client
服务网关如果采用 Spring Cloud 体系,则选择 Zuul 作为微服务网关是最佳搭配
统一配置在分布式部署下,各个微服务可能处于不同服务器,配置更改需要通过git 提交到配置中心实现分布式/版本化配置,Spring Cloud Config
微服务的容错微服务容错/降级使用Spring Cloud Netflix
微服务安全Spring Cloud Security提供了认证和鉴权以及Oauth2.0 单点登录支持 JWT
微服务通信Spring Cloud Stream 简化RabbitMQ 和Kafka 等消息中间件的整合,Spring Cloud Bus 基于Stream扩展,可以作为微服务之间的事件,消息总线。
微服务部署和编排Docker,K8S

2.参考资料

  • 0
    点赞
  • 0
    评论
  • 0
    收藏
  • 一键三连
    一键三连
  • 扫一扫,分享海报

打赏
文章很值,打赏犒劳作者一下
相关推荐
基于简化的服务架构和Docker容器的Microsoft由Microsoft提供的示例.NET Core参考应用程序。   免责声明 重要说明:此示例应用程序的当前状态是ALPHA,认为这是版本0.1版本的基础,因此,很多方面还有待改进和改变显著而重构当前的代码和实现新的功能。对社区的改进和反馈将受到高度的赞赏和接受。 该参考应用程序提出了一个简化的面向服务的体系结构实现,通过综合应用程序引入诸如.NET Core与Docker容器之类的技术。然而,这个引用应用程序并不是要解决大型和关键任务的分布式系统中的所有问题,只是让开发人员轻松开始使用.NET Core的Docker容器和服务器的开始。 例如,在了解Docker容器和使用.NET Core开发服务器之后,下一步(eShopOnContainers还没有涵盖),就是选择像Docker Swarm,Kubernetes或DC / OS(Azure容器服务)或Azure中的服务集群/协调器在大多数情况下,服务结构将需要对应用程序的配置进行额外的部分更改(尽管当前体系结构应适用于大多数具有较小更改的业务流程)。或将数据库移动到HA云服务,或者在Azure Service Bus或任何其他生产就绪的服务总线市场上实施EventBus。 在将来,我们可能会分配此项目,并针对特定的服务集群/协调者加上多个版本,并使用额外的云基础架构。 有关可能的新实施的更多信息,请阅读Wiki中未来版本的eShopOnContainers的计划路线图和里程碑,并在ISSUES部分提供反馈,如果您希望看到任何特定的方案得到实施或改进。此外,请随时讨论任何当前的问题。 架构概述:本参考应用程序是在服务器端和客户端的跨平台两种,由于能够根据您的码头工人主机上的Linux或Windows容器运行的.NET的核心服务,并为Xamarin的Android,iOS或正在运行的移动应用Windows / UWP加上客户端网络应用程序的任何浏览器。该架构提出了一种简化的面向服务的架构实现,其中包含多个自主的服务器(每个拥有自己的数据/ db),并使用Http作为当前的通信协议,在每个服务器(简单的CRUD vs. DDD / CQRS模式)中实现不同的方法。 它还支持异步通信,用于基于集成事件和事件总线以及路线图中定义的其他功能的多个服务的数据更新传播。 服务的类型不同,这意味着不同的内部架构模式取决于其目的,如下图所示。   最终将添加与其他框架和No-SQL数据库的其他miroservice样式。这是一个很好的机会,来自社区的拉动请求,例如使用Nancy的新服务,或者甚至其他语言,如Node,Go,Python或具有MongoDB Azure DocDB兼容性的数据容器,PostgreSQL,RavenDB,Event Store,MySql等。) 数据库服务器/容器的重要说明 在该解决方案当前的开发环境配置中,SQL数据库将自动部署样本数据到单个SQL Server for Linux容器(SQL数据库的单一共享Docker容器),因此整个解决方案可以启动并运行,而无需任何依赖任何云或特定的服务器。每个数据库也可以部署为单个Docker容器,但是在开发机器中,您需要将8GB或更多的内存RAM分配给Docker才能在Docker Linux主机中运行3个SQL Server Docker容器, Docker for Windows“或”Docker for Mac“开发环境。 在将Redis缓存作为开发环境的容器运行时,定义了类似的情况。 但是,在实际的生产环境中,建议您将数据库(在本例中为SQL Server和Redis)设置为HA(高可用性)服务,如Azure SQL数据库,Redis服务或任何其他集群系统。如果要更改为生产配置,只需在HA云或内部部署服务器后更改连接字符串即可。 相关文档和指导 在开发这个参考应用,我们正在创造一个参考指南/电子书名为“构建和开发集装箱和服务基于.NET应用程序”,其详细阐述了如何开发这种建筑风格(服务,多克尔容器,领域驱动设计某些服务)以及其他更简单的架构风格,如可以作为Docker容器生活的单片应用程序。 还有其他电子书专注于容器/ Docker生命周期(DevOps,CI / CD等)与Microsoft Tools,已经发布,另外还有一本关于使用Xamarin.Forms的企业应用程序模式的电子书。您可以下载它们,并在这里开始审查这些指南/电子书:   建筑与发展 集装箱生命周期和CI / CD 应用程序模式与Xamarin.Forms 下载(初稿,在进行的工作) 下载(自2016年后期第一版) 下载(初稿,在进行的工作) 发送反馈给cesardl@microsoft.com 然而,我们鼓励下载和审查“架构与开发电子书”,因为在指导中解释的架构风格和架构模式和技术在解释许多模式实现时使用此参考应用程序,因此您将更好地了解上下文,设计以及在当前架构和内部设计中采取的决策。 应用程序代码概述 在这种回购,你可以找到一个样本参考应用,将帮助您了解如何实现用服务架构的应用.NET的核心和多克。 示例业务域或场景基于作为多容器应用实现的eShop或电子商务。每个容器都是使用.NET Core运行的ASP.NET Core开发的一个服务部署(如basket-microservice,catalog-microservice,ordering-microservice和identity-microservice),因此可以在Linux Containers和Windows Containers 。下面的屏幕截图显示了这些服务器/容器和客户端应用程序的VS Solution结构。 (推荐入门时)开放eShopOnContainers-ServicesAndWebApps.sln为仅包含相关的服务和Web应用程序服务器端项目的解决方案。 开放eShopOnContainers-MobileApps.sln为仅包含所述客户端的移动应用项目的解决方案(仅Xamarin移动应用)。它也是基于mocks独立工作的。 打开eShopOnContainers.sln包含所有项目(所有的客户端应用和服务)的解决方案。 最后,这些服务由多个客户端网络和移动应用程序消耗,如下所述。 MVC应用程序(ASP.NET核心):它的一个MVC应用程序,你可以找到关于如何消费有趣的场景基于HTTP的从C#在服务器端运行的服务,因为它是一个典型的ASP.NET MVC的核心应用。由于它是一个服务器端应用程序,因此内部Docker Host网络内部名称解析可以访问其他容器/服务器。 SPA(单页应用):提供了类似的“网上商店的业务功能”,而是开发了角2,打字稿及轻使用ASP.NET MVC的核心。这是客户端Web应用程序的另一种方法,当您希望拥有更现代的客户端行为时,其行为与每个操作上的典型浏览器往返行为不同,但表现为类似于单页应用程序的单页面应用程序桌面应用使用体验。基于HTTP的服务的消耗由客户端浏览器中的TypeScript / JavaScript完成,因此客户端调用服务器来自Docker Host内部网络(从您的网络甚至从互联网)。 Xamarin移动应用(对于iOS,Android和Windows / UWP) :这是一个客户端移动应用程序支持最常见的移动操作系统平台(的iOS,Android和Windows / UWP)。在这种情况下,服务的消耗是从C#完成的,但是在客户端设备上运行, 为eShopOnContainers设置开发环境 Visual Studio 2017和Windows 这是更直接的入门方式:https://github.com/dotnet/eShopOnContainers/wiki/02.-Setting-eShopOnContainer-solution-up-in-a-Visual-Studio-2017- environment  CLI和Windows 对于喜欢Windows的CLI的用户,使用dotnet CLI,Docker CLI和Windows的VS代码: https://github.com/dotnet/eShopOnContainers/wiki/03.-Setting-the-eShopOnContainers-solution-up-in-a-Windows-CLI-environment-(dotnet-CLI,-Docker-CLI-and-VS-Code) CLI和Mac 对于那些喜欢在Mac上使用CLI的用户,使用dotnet CLI,Docker CLI和VS代码(说明仍然TBD,但类似于Windows CLI):https://github.com/dotnet/eShopOnContainers/wiki/04.-设置eShopOnContainer-in-a-Mac,-VS-Code-and-CLI-environment - (dotnet-CLI,-Docker-CLI-and-VS-Code) 关于测试的Docker容器/图像的注意事项 大部分项目的开发和测试的是(如三月初2017)完成对码头工人的Linux容器在开发机器与“泊坞的Windows”运行,默认是“泊坞的Windows”已安装的Hyper-V的Linux VM(MobiLinuxVM) 。该窗口的容器方案,目前正在实施/测试还没有。应用程序应该能够在基于不同Docker基础映像的Windows Nano Containers上运行,因为.NET Core服务也已经在普通Windows(没有Docker)上运行。该应用程序也使用安装了.NET Core和VS代码的开发MacOS机器在“Docker for Mac”中进行了部分测试,这仍然是使用在Mac上的VM安装程序上运行的Linux容器的“Docker for Windows” 建立。但是,来自社区的Mac环境和Windows Containers的进一步测试和反馈将不胜感激。 发送反馈和建议 如上所述,我们非常感谢您的反馈,改进和想法。您可以在问题部分创建新问题, 或发送电子邮件至eshop_feedback@service.microsoft.com 问题 问题列表:https://github.com/dotnet/eShopOnContainers/issues/107 标签:docker  服务
©️2020 CSDN 皮肤主题: 终极编程指南 设计师:CSDN官方博客 返回首页

打赏

技术宅星云

你的鼓励将是我创作的最大动力

¥2 ¥4 ¥6 ¥10 ¥20
输入1-500的整数
余额支付 (余额:-- )
扫码支付
扫码支付:¥2
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值