微服务架构与服务治理

Spring Cloud是一个基于Spring Boot实现的云应用开发工具,它为基于JVM的云应用开发中涉及的配置管理、服务发现、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等操作提供了一种简单的开发方式。

Spring Cloud包含了多个子项目(针对分布式系统中涉及的多个不同开源产品),比如:Spring Cloud Config、Spring Cloud Netflix、Spring Cloud0 CloudFoundry、Spring Cloud AWS、Spring Cloud Security、Spring Cloud Commons、Spring Cloud Zookeeper、Spring Cloud CLI等项目。

微服务架构

“微服务架构”在这几年非常的火热,以至于关于微服务架构相关的开源产品被反复的提及(比如:netflix、dubbo),Spring Cloud也因Spring社区的强大知名度和影响力也被广大架构师与开发者备受关注。那么什么是“微服务架构”呢?简单的说,微服务架构就是将一个完整的应用从数据存储开始垂直拆分成多个不同的服务,每个服务都能独立部署、独立维护、独立扩展,服务与服务间通过诸如RESTful API的方式互相调用。对于“微服务架构”,大家在互联网可以搜索到很多相关的介绍和研究文章来进行学习和了解。也可以阅读始祖Martin Fowler的《Microservices》(中文版翻译点击查看),本文不做更多的介绍和描述。

服务治理

在简单介绍了Spring Cloud和微服务架构之后,下面回归本文的主旨内容,如何使用Spring Cloud来实现服务治理。由于Spring Cloud为服务治理做了一层抽象接口,所以在Spring Cloud应用中可以支持多种不同的服务治理框架,比如:Netflix Eureka、Consul、Zookeeper。在Spring Cloud服务治理抽象层的作用下,我们可以无缝地切换服务治理实现,并且不影响任何其他的服务注册、服务发现、服务调用等逻辑。

从现在开始,我这边会将近期研发的springcloud微服务云架构的搭建过程和精髓记录下来,帮助更多有兴趣研发spring cloud框架的朋友,希望可以帮助更多的好学者。大家来一起探讨spring cloud架构的搭建过程及如何运用于企业项目。

原文地址:http://blog.51cto.com/13777880/2129850

时间: 2024-10-08 22:41:17

微服务架构与服务治理的相关文章

应用量化时代 | 微服务架构的服务治理之路

技术随业务而生,业务载技术而行. 近些年来,伴随数字经济的发展,在众多企业的数字化转型之路上,云原生.DevOps.微服务.服务治理等成为行业内不断被探讨的新话题.人们在理解和接受这些新型概念的同时,也不断地思考其可能的落地形态.需求是创造发生的原动力,于是一批代表性的开源技术或者框架涌现而出:Kubernetes,Spring Cloud,Service Mesh,Serverless-- 它们炙手可热,大放异彩.然而在具体落地过程中却步履维艰,磕磕绊绊. 本文试图结合企业业务的核心诉求,以应

浅谈微服务架构与服务治理的Eureka和Dubbo

前言 本来计划周五+周末三天自驾游,谁知人算不如天算,周六恰逢台风来袭,湖州附近的景点全部关停,不得已只能周五玩完之后,于周六踩着台风的边缘逃回上海.周末过得如此艰难,这次就聊点务虚的话题,一是浅谈微服务的架构设计,二是聊聊微服务中广泛用于服务治理的Eureka与RPC框架Dubbo异同点. 一.微服务的架构设计 之所以想聊一下这个话题,主要有感于最近接触的两个新的微服务项目--两个项目的架构设计出自两个人之手,却不约而同的使用了相同的设计理念,项目结构非常类似.又想到就职于上家公司时接触到的项

Spring Cloud构建微服务架构-Hystrix服务降级

在微服务架构中,我们将系统拆分成了一个个的服务单元,各单元应用间通过服务注册与订阅的方式互相依赖.由于每个单元都在不同的进程中运行,依赖通过远程调用的方式执行,这样就有可能因为网络原因或是依赖服务自身问题出现调用故障或延迟,而这些问题会直接导致调用方的对外服务也出现延迟,若此时调用方的请求不断增加,最后就会出现因等待出现故障的依赖方响应而形成任务积压,线程资源无法释放,最终导致自身服务的瘫痪,进一步甚至出现故障的蔓延最终导致整个系统的瘫痪.如果这样的架构存在如此严重的隐患,那么相较传统架构就更加

Spring Cloud构建微服务架构-创建“服务提供方”

下面我们创建提供服务的客户端,并向服务注册中心注册自己.本文我们主要介绍服务的注册与发现,所以我们不妨在服务提供方中尝试着提供一个接口来获取当前所有的服务信息. 首先,创建一个基本的Spring Boot应用.命名为eureka-client,在pom.xml中,加入如下配置: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 <parent> <groupId>org.spr

Spring Cloud构建微服务架构:服务消费(基础)

使用LoadBalancerClient 在Spring Cloud Commons中提供了大量的与服务治理相关的抽象接口,包括DiscoveryClient.这里我们即将介绍的LoadBalancerClient等.对于这些接口的定义我们在上一篇介绍服务注册与发现时已经说过,Spring Cloud做这一层抽象,很好的解耦了服务治理体系,使得我们可以轻易的替换不同的服务治理设施. 从LoadBalancerClient接口的命名中,我们就知道这是一个负载均衡客户端的抽象定义,下面我们就看看如何

Spring Cloud构建微服务架构 分布式服务跟踪(跟踪原理)【Dalston版】

通过上一篇<分布式服务跟踪(入门)>的例子,我们已经通过Spring Cloud Sleuth往微服务应用中添加了实现分布式跟踪具备的基本要素.下面通过本文来详细说说实现分布式服务跟踪的一些要点. 分布式系统中的服务跟踪在理论上并不复杂,它主要包括下面两个关键点: 为了实现请求跟踪,当请求发送到分布式系统的入口端点时,只需要服务跟踪框架为该请求创建一个唯一的跟踪标识,同时在分布式系统内部流转的时候,框架始终保持传递该唯一标识,直到返回给请求方为止,这个唯一标识就是前文中提到的Trace ID.

Spring Cloud构建微服务架构—创建“服务注册中心”

创建一个基础的Spring Boot工程,命名为eureka-server,并在pom.xml中引入需要的依赖内容: <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>1.5.4.RELEASE</version> <relativePath

Spring Cloud构建微服务架构:服务容错保护(Hystrix服务降级)

动手试一试 在开始使用Spring Cloud Hystrix实现断路器之前,我们先拿之前实现的一些内容作为基础,其中包括: eureka-server工程:服务注册中心,端口:1001 eureka-client工程:服务提供者,两个实例启动端口分别为2001 下面我们可以复制一下之前实现的一个服务消费者:eureka-consumer-ribbon,命名为eureka-consumer-ribbon-hystrix.下面我们开始对其进行改在: 第一步:pom.xml的dependencies

Spring Cloud构建微服务架构 分布式服务跟踪(抽样收集)【Dalston版】

通过Trace ID和Span ID已经实现了对分布式系统中的请求跟踪,而这些记录的跟踪信息最终会被分析系统收集起来,并用来实现对分布式系统的监控和分析功能,比如:预警延迟过长的请求链路.查询请求链路的调用明细等.此时,我们在对接分析系统时就会碰到一个问题:分析系统在收集跟踪信息的时候,需要收集多少量的跟踪信息才合适呢? 理论上来说,我们收集的跟踪信息越多就可以更好的反映出系统的实际运行情况,并给出更精准的预警和分析,但是在高并发的分布式系统运行时,大量的请求调用会产生海量的跟踪日志信息,如果我