1、关于Hystrix中fallbackMethod方法写得太简单中,书中只提到了简单的查询异常,多表数据插入及多表数据编辑的业务场景没有涉及,不知是否有比较简单可靠的解决方案。
2、SpringCloud与历史系统的整合,若企业中打算把原来系统的核心业务逻辑层由原来的webservice或http接口架构改为使用SpringCloud框架框架,应该怎么去做才能使现在系统的展现层内容改动最小。
3、缺少使用SpringCloud大型企业的案例,哪怕国外的公司也行,目前国内看到的案例都是一些比较小的公司在使用。
4、大型企业级应用SpringCloud框架的内容涉及的比较少,比如微服务集群生产环境版本的发布,如果不使用Docker技术,微服务提供者集群各个节点的版本怎么快速发布升级新版本。
5、SpringCloud框架的性能情况没有提到。
6、没有提到SpringCloud与Dubbo的对比,序言中有说到要把Dubbo迁移到SpringCloud,但没有提到原因。
1、每个微服务可独立运行在自己的进程中。2、一系列独立运行的微服务共同构建起整个系统。3、每个服务为独立的业务开发,一个微服务只关注某个特定的功能,如订单管理、用户管理等。4、微服务之间通过一些轻量的通信机制进行通信,如RESTfulAPI进行调用。5、可以使用不同的语言与数据存储技术。6、全自动的部署机制。
1、单一职责原则
2、服务自治原则
3、轻量级通信机制(REST、AMQP、STOMP、MQTT)
4、微服务粒度(领域驱动设计原则)
支持微服务的主流架构有:SpringCloud、Dubbo、Dropwiz-ard、Armada。
与之前整理的资料类似。
1、SpringCloud是在SpringBoot基础上构建的,用于快速构建分布式系统的通用模式的工具集。是一个搭建分布式系统的生态环境。后续需要重点了解一下SpringBoot。
2、SpringCloud开发的应用程序非常适合在Docker或PaaS层上部署,所以又叫云原生应用(Cloud Native Application),是面向云环境的软件架构。
3、云原生《十二要素应用宣言(12-factor Apps)》参考附录。
1、特点
适合于各种环境。开发、部署在PCServer或各种云环境(例如阿里云、AWS等)。
选型中立、丰富。如可支持Eureka、Zookeepter或Consul实现服务发现。
还有其它特点之前资料已整理。
2、版本命名
Spring Cloud是一个拥有诸多子项目的大型综合项目,原则上其子项目也都维护着自己的发布版本号。那么每一个Spring Cloud的版本都会包含不同的子项目版本,为了要管理每个版本的子项目清单,避免版本名与子项目的发布号混淆,所以没有采用版本号的方式,而是通过命名的方式。这些版本名字采用了伦敦地铁站的名字,根据字母表的顺序来对应版本时间顺序,比如:最早的Release版本:Angel,第二个Release版本:Brixton,以此类推……。
Angel.SR6,Brixton.SR5中的SR6、SR5就是表示BUG版本修复次数。
3、SpringCloud/SpringBoot版本兼容性
Angel版本基于SpringBoot1.2.x构建,与SpringBoot1.3.x及以上版本不太兼容。
Brixton基于SpringBoot1.3.x构建,兼容1.4.x,不兼容1.2.x。
Camden基于1.4.x构建,也可使用1.5.x进行测试。
4、JDK版本
官方建议使用1.8版本,也通过配置支持1.7版本。
5、IDE
官方提供了:SpringToolSuite3.8.X的IDE,这是基于Eclipse的IDE,也可以使用Intellij IDEA等IDE。
6、Maven
3.3.x版本默认运行在JDK1.8之上,1.8以下版本要做额外配置。
1、开发编码
编码很简单,只需要引入springboot的依赖包、springcloud的依赖包、springMVC及maven包即可。其它代码与传统springMVC架构开发流程一样。
本书详细代码可参考(下同):http://www.itmuch.com/advertisment/my-spring-book-code/
1、开发编码
与服务提供者开发类似。
SpringcloudActuator提供了很多监控端口,可以使用http://IP:port/endpoint的形式访问这些端点,可以实时了解应用程序的运行状况。整合Actuator功能只需要在项目添加一个依赖即可。然后可以通过http://IP:port/health、http://IP:port/info方式监控。如果项目中整合了Hystrix断路器组件,也可监控Hystrix状态。
http://img.blog.csdn.net/20170614104413370?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvRGVscGhpYW5kbGl1/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center
1、Application Service 服务提供者。
2、Application Client 服务消费者。
3、Make Remote Call 调用RESTfulAPI的行为。
4、Us-east-1c、Us-east-1d等都在一个物理机房(zone)Eureka集群中,它们都属于us-east-1这个Region(Region可理解为跨机房的Eureka集群)
5、Eureka包含两个组件:EurekaServer与EurekaClient,采用C/S架构:
EurekaServer:提供服务发现,各个微服务启动时,会向EurekaServer注册自己的信息(IP、端口、微服务名称等),EurekaServer会存储这些信息。
EurekaClient:是一个java客户端,用于简化与EurekaServer的交互。
6、微服务启动后,会同期性的(默认30秒)地向EurekaServer发送心跳以续约自己的“租期”。
7、如果EurekaServer在一定时间没有接收到某个微服务实例的心跳,EurekaServer会注销该实例(默认90秒)。
8、默认情况下EurekaServer同时也是EurekaClient,多个EurekaServer实例,互相之间通过复制的方式,来实现服务注册表中数据的同步。
9、EurekaClient会缓存服务注册表中的信息,减少EurekaServer的压力。
添加spring-cloud-starter-eureka-server的依赖,然后在启动类添加EurekaServer注解即可。
添加spring-cloud-starter-eureka的依赖,然后在启动类添加EurekaClient注解即可。
疑问:一个EurekaServer既是S又是C,启动方法名上注解的内容不是很多?
可通过运行多个实例并互相注册的方式实现高可用部署,EurekaServer实例会彼此增量地同步信息,从而确保所有节点数据的一致性。
在项目中引入3.3.2.编写spring-cloud-starter-security的依赖,然后在配置文件中增加用户名与密码,则客户端口在注册的时候需提供用户认证信息才可访问。
作用是提供给其它语言编写的EurekaClient注册到EurekaServer,为整合历史系统提供了接口。
Ribbon是Netflix发布的负载均衡器,有助于控制http与tcp客户端的行为,为Ribbon配置服务提供者地址列表后,它就可基于某种负载均衡算法自动地帮消费者去请求。它提供了多种常用算法,也可以自定义算法。此组件是实现服务消费者端的负载均衡。
在SpringCloud中,当Ribbon与Eureka配合使用时,Ribbon可自动从EurekaServer获取服务提供者地址列表,并基于负载均衡算法请求其中一个服务提供者实例。它也可脱离Eureka单独使用。
在服务消费者项目中加入spring-cloud-starter-ribbon的依赖,并在调用处RestTempLate添加@LoadBalanced注解即可。
Feign是Netflix开发的声明、模板化的HTTP客户端,可以帮助服务消费者便捷、优雅的调用HTTPAPI。可以支持对请求的数据压缩操作。并可以创建完整的客户端日志信息。
在服务消费者项目中加入spring-cloud-starter-feign的依赖,创建一个Feign接口,并添加@FeignClient注解即可。
1、雪崩效应
常把“基础服务故障”导致“级联故障”的现象称为雪崩效应,它描述的是服务提供者不可用导致消费者不可用,并将不可用逐渐放大的过程。
2、容错方法论
为网络请求设置超时、使用断路器模式
它是Netfilx开源的一个延迟和容错库,用于隔离访问远程系统、服务或第三方库、为防止级联失败,从而提升系统的可用性与容错性。实现机制如下:
1、包裹请求:使用HystrixCommand包裹对依赖的调用逻辑,每个命令在独立线程中执行。
2、跳闸机制:错误率超过一定阀值可自动或手动跳闸,停止请示该服务一段时间。
3、资源隔离:为每个依赖维护一个小型线程池(或者信号量),如果该线程池已满,发往该依赖的请求就被立即拒绝,是排队等待。
4、监控:可近乎实时的监控运行指标和配置的变化。
5、回退机制:当请求失败、超时、被拒绝或断路器打开时,执行回退逻辑。回退逻辑可由开人员自行提供,例如返回一个缺省值。
目前来看这种机制在调用多个服务时的开发工作量比较大。
6、自我修复:断路器打开一段时间后,会自动进入”半开“状态。
在服务消费者项目中加入spring-cloud-starter-hystrix的依赖,在启动类上添加@EnableCircuitBreaker或@EnableHystrix注解即可。
监控失败阀值默认为:5秒钟内20次失败,达到值后断路器才会打开。执行回退逻辑并不代表断路器已经打开,请求失败、超时、被拒绝以及断路器打开时等都会执行自定的回退逻辑。
它除了容错,还提供了近乎实时的监控,HystrixCommand和HystrixOberverableCommand在执行地,会生成执行结果和运行指标,比如每秒执行的请求数、成功数等。同时还可以支持可视化监控数据。
1、springcloudSleuth为SpringCloud提供了分布式跟踪的解决方案,大量借用了Google Dapper、Twitter Zipkin和Apache HTrace的设计。能够跟踪每个请求,了解请求经过哪些微服务、请求耗时时间、网络延迟、业务逻辑耗费时间等指标,有助于分析系统瓶颈、解决系统问题。
2、Sleuth术语
Span(跨度):基本工作单元。用一个64位的ID唯一标识,span被启动或停止时,记录了时间信息。初始化span为称为“root span”,该span的id与trace的ID相等。
Trace(跟踪):一组共享”root span”的span组成的树状结构称为”trace”,tarce也用一个64位的ID唯一标识。
Annotation(标注):用来记录事件的存在,其中核心annotation用来定义请求的开始与结束,包括:
CS(客户端发送):客户端发起一个请求,描述了span的开始。
SR(服务器接收端):服务器端获得请求并准备处理它,如果用SR减去CS时间戳,就能得到网络延迟。
SS(服务器端发送):表明完成请求处理(当响应发回客户端时),如果用SS减去SR时间戳,就能得到服务端处理请求所需时间。
CR(客户端接收):span结束的标识,客户端成功接收到服务器端的响应,如果CR减去CS时间戳,就能得到从客户端发送请求到服务器响应的所需时间。
添加spring-cloud-starter-sleuth的依赖,然后在配置文件中增加日志显示的级别即可。
Zipkin提供一个非常友好的界面来帮助分析追踪数据。
1、编写ZipkinServer
2、微服务整合Zipkin
可支持:configserver可以统一管理微服务的配置、配置内容的加解密、自动或手动刷新配置信息、与Eureka配合一起使用、用户认证、集群高可用等 。详细内容待补充。
可支持服务安全、文件上传、容错与回退、自定义过滤器、聚合微服务、集群高可用、使用
Sidecar整合非JVM微服务等。详细内容待补充。
1、Eureka注册服务慢,因为心跳时间默认为30秒。
2、已停止的微服务节点注销慢或不注销,清理同期为90秒,
3、微服务的IntanceID可以通过配置文件自定义。
4、Hystrix/Feign整合Hystrix后首次请求失败原因:Hystrix默认超时时间1秒,如果1秒内得不到响应,就会进入fallback逻辑,由于Spring的懒加载机制,首次请求比较慢,可以修改默认时间来解决。
可支持:将微服务运行在docker上、使用DockerCompose编排微服务(编排Springcloud微服务、编排高可用的EurekaServer、编排高可用SpringCloud微服务集群及动态伸缩)等。详细内容待补充。