Spring Cloud微服务介绍
/**
* 1.3 什么是微服务?
* 微服务架构是一种将一个单一应用程序开发为一组小型服务的方法,每个服务运行在自己的进程中
* 通信:服务间采用轻量级通信机制,(通常采用HTTP资源API)
* 特色:服务可用不同的语言开发,使用不同的数据存储技术
* 特性: 1.每个微服务可独立运行在自己的进程里
* 2.一系列独立运行的微服务共同构建整个系统
* 3.每个服务为独立的业务开发,一个微服务只关注某个特定的功能,如订单管理,用户管理
* 4.微服务之间通过一些轻量级通信机制进行通信,例如通过Resetful API进行调用
* 5.可以使用不同的语言与数据存储技术
* 6.全自动的部署机制
*
* 1.4 优势:
* 1.易于开发和维护:一个微服务只关注特定的功能,所以它业务清晰,代码量较少。开发和维护单个微服务相对简单
* 。而整个应用由若干个微服务构建而成,所以整个应用也会被维持在一个可控状态。
* 2.单个微服务启动较快:单个微服务代码量较少,所以启动很快
* 3.局部修改容易部署:单体应用只要有修改,就得重新部署整个应用,微服务解决了这样的问题。一般来说,
* 对某个微服务进行修改,只需要重新部署这个服务就可
* 4.技术不受限:在微服务架构中,可以结合项目业务及团队的特点,合理地选择技术栈。例如某些微服务可使用
* 关系型数据库MYSQL,某些微服务有图形计算的需求,可以使用Neo4j,甚至可根据需要,部分微服务使用JAVA开发,
* 部分微服务使用Node.js开发。
* 5.按需伸缩:可根据需求,实现细粒度的扩展。例如,系统中的某个微服务遇到了瓶颈,可以结合这个微服务的业务特点,
* 增加内存,升级CPU或者是增加节点。
*
* ··挑战:
* 1.运维要求较高,更多的服务,意味着更多的运维投入。在单体架构中,只需要保证一个应用的正常运行。在微服务中,
* 需要保证几十,甚至几百个服务的正常运行与协作,这给运维带来了很大的挑战。
* 2.分布式固有的复杂性:使用微服务构建的是分布式系统。对于一个分布式系统,系统容错,网络延迟,分布式事务
* 等都会带来巨大的挑战。
* 3.接口调整成本高:微服务之间通过接口进行通信。如果修改某一个服务的API,可能所有使用了该接口的的微服务都需要调整。
* 4.重复劳动:很多服务可能都会使用到相同的功能,而这个功能并没有达到分解为一个微服务的程度。这个时候,可能各个服务
* 都会开发这一功能,从而导致代码重复。尽管可以使用共享来解决这个问题,(可以将这个功能封装成公共组件,该服务的微服务引用该组件),
* 但共享在多语言环境下就不一定行的通了。
*
*
* 1.5 微服务设计原则
* 1.单一职责原则:单一职责原则指的是一个单元(类,方法或者服务等),只应关注整个系统功能中单独,有界限的一部分。单一职责原则可以帮助我们更敏捷地开发,更优雅的交互。
* 单一职责原则是SOLID原则之一,
* 2.服务自治原则:服务自治是指每个微服务应具备独立的业务能力,依赖与运行环境,在微服务架构中,服务是独立的业务单元,应该与其他的服务高度解耦,每个微服务从开发,测试,构建,部署都应当可以独立运行。而不应该依赖其他的服务。
* 3.轻量级通信机制:微服务之间应该通过轻量级的通信机制,进行交互。笔者认为,轻量级的通信机制,应具备两点:首先它的体量较轻,其次,他应该是跨语言,跨平台的。例如我们所熟悉的REST协议,就是一个典型的“轻量级通信机制”;而例如JAVA的RMI协议则不大符合
* 轻量级的通信机制的要求,因为它绑定了JAVA语言。
* 微服务架构中,常用的协议有REST,AMQP,STOMP,MQTT等。
* 4.微服务粒度:微服务的粒度是难点,也常常是争论的焦点。应当使用合理的粒度划分微服务,而不是一味的把服务做小。代码量的多少不能作为微服务划分的依据。因为不同的微服务本身的业务复杂性不同,代码量也不同。
* 在微服务设计阶段,就应确定其边界。微服务之间相对独立并保持松耦合,领域驱动设计中的“限界上下文”可作为划分微服务边界,确定为服务粒度的重要依据。
*
*
* 1.6 如何实现微服务架构
* 开发框架的选择:可以使用Spring Cloud作为微服务开发框架,首先,Spring Cloud具有开箱即用的生产特性,可大大提升开发效率。再者,Spring Cloud的文档丰富,社区活跃,遇到问题比较容易获得支持。更为可贵的是,Spring Cloud为微服务提供了完整的解决方案。
* 当然也可以使用其他的开发框架,或者解决方案来实现微服务,例如Dubbo,Dropwiz-ard,Armada等。
* 运行平台:微服务并不绑定运行平台,将微服务部署在PC Server,或者阿里云,AWS等云计算平台都是可以的。出于轻量,灵活,应用支撑等方面的考虑,选择在Docker上部署微服务。
*
*
* 2.微服务开发框架-Spring Cloud
*
* 2.1 了解Spring Cloud
* Spring Cloud是在Sprig Boot基础上构建的,用于快速构建分布式系统的通用模式的工具集。
* 使用Spring Cloud开发的应用程序非常适合在Docker或者Paas上部署,所以叫做云原生应用。
* 云原生可以简单理解为面向云环境的软件架构。
*
* 2.2 Spring Cloud的特点
* 1.约定优于配置。
* 2.适用于各种环境。开发部署在PC Server或各种云环境。
* 3.隐藏了组建的复杂性,并提供了声明式,无XML的配置方式。
* 4.开箱即用,快速启动。
* 5.轻量级的组件。Spring Cloud为微服务架构提供了非常完整的支持。例如配置管理,服务发现,断路器,微服务网管等。
* 6.选型中立,丰富。例如:Spring Cloud支持使用Eureka,ZooKeeper或Consul实现服务发现。
* 7.灵活。Spring Cloud的组成部分是解耦的。开发人员可按需灵活挑选技术选型。
*
* 2.3 Spring Cloud版本
* Spring Cloud是一个综合项目。它包含很多的子项目。由于子项目也维护着自己的版本号,Spring Cloud
* 采用了这种版本命名方式。从而避免了与子项目的版本混淆。其中,英文单词叫做release train,Camden,Dalston,
* Edgware等都是伦敦地铁站的名称,它们按照字母顺序发行,可将其理解为主版本的演进。SR表示“Server Release”
* ,一般表示Bug修复。在SR版本发布之前,会先发布一个RELEASE版本,例如,在发布Edgware SR1之前,会先发布Edgware
* RELEASE。
* Spring Cloud/Spring Boot版本兼容性
* Angel版本基于Spring Boot 1.2X构建,在一些场景下,与Spring Boot 1.3x及以上版本不兼容。
* Brixton版本基于Spring Boot 1.3x构建,也可以使用1.4x进行测试,与Spring Boot1.2x不兼容。
* Camden版本基于Spring Boot 1.4x构建,亦可以使用1.5x进行测试。
* Dalston版本基于Spring Boot 1.5构建,不兼容Spring Boot 2.0x
* Edrware版本基于Spring Boot 1.5x构建,不兼容Spring Boot2.0x
* Finchley版本基于Spring Boot 2.0构建,不兼容Spring Boot1.x
*
* *
*3.开始使用Spring Cloud实战微服务
*
* 3.1.1 技术储备
* Spring Cloud并不面向零基础开发人员,它有一定的学习曲线。
* 1.语言基础:Spring Cloud是一个基于JAVA语言的工具套件,所以学习它需要一定Java基础,
* 当然,Spring Cloud同样也支持使用Scala,Groovy等语言进行开发。
* 2.Spring Boot:Spring Cloud是基于Spring Boot构建的,因此它延续了Spring Boot的契约模式与开发方式。
* 3.项目管理与构建工具:目前业界比较主流的项目管理与构建工具有Maven和Gradle等。Maven和Gradle可以互相转换,
* 使用以下命令即可将maven项目转换为Gradle项目
* gradle init --type pom
*
* 3.2 服务提供者与服务消费者
* 使用微服务构建的是分布式系统,微服务之间通过网络进行通信。我们可以使用服务提供者与服务消费者来描述微服务之间的调用关系。
*
* 服务提供者:服务的被调用方(类似于服务器)
* 服务消费者:服务的调用方(类似于以来服务器的客户端)
*
* 模拟电影售票系统:用户向电影微服务发起了一个购票请求。在进行购票业务的操作前,电影微服务需要调用用户微服务的接口,查询当前用户的余额是多少,
* 是不是符合购票标准。在这种场景下,用户微服务就是一个服务提供者,电影微服务则是一个服务消费者。
*
*3.3.1 手动编写项目
* one
* 3.3.2 使用Spring Initializr 快速创建Spring Boot项目
*
* Spring Initializr不能生成应用程序的业务代码,但它可生成基本的项目结构。这样就可以把更多的精力放在具体的
* 业务代码上,而无须过分关注项目搭建的过程。
* Spring Initializr有以下几种用法:
* 1.通过网页使用
* 2.通过Spring Tool Suite使用
* 3.通过IntelliJ IDEA使用
* 4.通过Spring Boot CLI使用
*
* 1.访问http://start.spring.io/
* 2.按照需求,选择项目类型(Maven,Gradle),Spring Boot的版本,并填写项目元数据以及所需依赖,单击Switch
* to the full version按钮,还可指定额外的信息,例如Java版本,打包方式等。
* 3.单击Generate Project按钮,就能获得一个名为microservice-simple-provider-user.zip的压缩包文件。
* 4.项目解压过后,将项目导入到IDE,就可以开发Spring Boot/Spring Cloud项目了。
* 3.4 编写服务消费者
* two
*
* 3.5 为项目整合Spring Boot Actuator
* Spring Boot Actuator提供了很多监控端点。可使用http://{ip}:{port}/actuator/{endpoint}的形式
* 访问这些端点,从而了解应用程序的运行状况。
*
* Spring Boot Actuator常用端点
*
* autoconfig 显示自动配置的信息
* beans 显示应用程序上下文所有的Spring Bean
* configprops 显示所有@ConfigurationProperties的配置属性列表
* dump 显示线程活动的快照
* env 显示应用的环境变量
* health 显示应用程序的健康指标,这些值由HealthIndiator的实现类提供,当应用开启安全保护时,
* 对于未经用户认证的请求,只会显示简单的状态,如已认证,则会展示健康详情
* info 显示应用的信息,可使用info.*属性自定义info端点公开的数据
* mappings 显示所有@RequestMapping的路径列表
* metrics 显示应用的度量标准信息
* shutdown 关闭应用(默认情况下不启用,如需启用,需设置end-points.shutdown.enable=true)
* trace 显示跟踪信息(默认情况下为最近100个HTTP请求)
*
* 为项目整合Acturator
* 1.添加spring-boot-starter-acturator依赖
* 测试helath
* http://localhost:8010/acturator/health
* 为info添加公开数据
* info:
* APP:
* name: @project.artifactId@
* encoding: @project.build.sourceEncoding@
* java:
* source: @java.version@
* target:@java.version@
* SpringBoot出于安全考虑,从SpringBoot1.5开始,对于敏感路径,默认不允许访问(直接访问将
* 看到错误页面)
* HTTP错误码为401)。可设置Management.security.enabled=false,关闭Spring Boot
* Acturator的安全措施,也可添加
* spring-boot-starter-security,这样Spring Boot Acturator将允许有ACTURATOR的角色的用
*户访问。
*/