蓝色清新phpcms企业网站模板,最好装修公司排名,wordpress图片备份,网站服务器有哪些类型一、分布式服务框架的发展
1.1 第一代服务框架 代表#xff1a;Dubbo(Java)、Orleans(.Net)等
特点#xff1a;和语言绑定紧密
1.2 第二代服务框架 代表#xff1a;Spring Cloud等
现状#xff1a;适合混合式开发#xff08;例如借助Steeltoe OSS可以让ASP.Ne…一、分布式服务框架的发展
1.1 第一代服务框架 代表Dubbo(Java)、Orleans(.Net)等
特点和语言绑定紧密
1.2 第二代服务框架 代表Spring Cloud等
现状适合混合式开发例如借助Steeltoe OSS可以让ASP.Net Core与Spring Cloud集成正值当年
1.3 第三代服务框架 代表Service Mesh服务网格 例如Service Fabric、lstio、Linkerd、Conduit等
现状在快速发展中更新迭代比较快
1.4 未来目测不久主流的服务架构和技术栈 基础的云平台为微服务提供了资源能力计算、存储和网络等容器作为最小工作单元被Kubernetes调度和编排Service Mesh服务网格管理微服务的服务通信最后通过API Gateway向外暴露微服务的业务接口。
目前我所在的项目组已经在采用这种技术架构了服务网格采用的是Linkerd容器编排采用的是K8SSpring Cloud已经没用了。But不代表Spring Cloud没有学习的意义对于中小型项目团队Spring Cloud仍然是快速首选。
二、Spring Cloud 简介
2.1 Spring Cloud极简介绍 首先尽管Spring Cloud带有“Cloud”这个单词但它并不是云计算解决方案而是在Spring Boot基础之上构建的用于快速构建分布式系统的通用模式的工具集。
其次使用Spring Cloud开发的应用程序非常适合在Docker和PaaS比如Pivotal Cloud Foundry上部署所以又叫做云原生应用Cloud Native Application。云原生可以简单地理解为面向云环境的软件架构。 总结 Spring Cloud是一个基于Spring Boot实现的云原生应用开发工具它为基于JVM的云原生应用开发中涉及的配置管理、服务发现、熔断器、智能路由、微代理、控制总线、分布式会话和集群状态管理等操作提供了一种简单的开发方式。 Spring Cloud具有如下特点
约定大于配置 适用于各种环境 隐藏了组件的复杂性并提供声明式、无XML式的配置方式 开箱即用快速启动 组件丰富功能齐全 … Spring Cloud作为第二代微服务的代表性框架已经在国内众多大中小型的公司有实际应用案例。许多公司的业务线全部拥抱Spring Cloud部分公司选择部分拥抱Spring Cloud。例如拍拍贷资深架构师杨波老师就根据自己的实际经验以及对Spring Cloud的深入调研并结合国内一线互联网大厂的开源项目应用实践结果认为Spring Cloud技术栈中的有些组件离生产级开发尚有一定距离最后提出了一个可供中小团队参考的微服务架构技术栈又被称为“中国特色的微服务架构技术栈1.0” 上图中涉及到的组件这里不做具体介绍有兴趣的童鞋可以浏览波波老师的这篇文章《一个可供中小团队参考的微服务架构技术栈》。
2.2 Spring Cloud核心子项目 Spring Cloud Netflix核心组件可以对多个Netflix OSS开源套件进行整合包括以下几个组件 Eureka服务治理组件包含服务注册与发现 Hystrix容错管理组件实现了熔断器 Ribbon客户端负载均衡的服务调用组件 Feign基于Ribbon和Hystrix的声明式服务调用组件 Zuul网关组件提供智能路由、访问过滤等功能 Archaius外部化配置组件 Spring Cloud Config配置管理工具实现应用配置的外部化存储支持客户端配置信息刷新、加密/解密配置内容等。 Spring Cloud Bus事件、消息总线用于传播集群中的状态变化或事件以及触发后续的处理 Spring Cloud Security基于spring security的安全工具包为我们的应用程序添加安全控制 Spring Cloud Consul : 封装了Consul操作Consul是一个服务发现与配置工具与Eureka作用类似与Docker容器可以无缝集成 …
三、参考学习资料
备注下面资料都是我们项目组新同事以及老同事.Net技术背景所采用的学习资料并不保证适合于所有人。本示例主要也主要是基于下面的资料而写的sample code。
1周立《Spring Cloud与Docker 微服务架构实战》 2程序猿DD《Spring Cloud 微服务实战》、《Spring Cloud基础教程Dalston版本强力推荐》 3纯洁的微笑《Spring Cloud系列文章》
四、示例结构说明
4.1 示例环境版本 Java : JDK JRE 1.8 8u151 Spring Boot : 1.5.15.RELEASE Spring Cloud : Edgware.SR3 小贴士Spring Cloud的版本命名是以伦敦地铁站的名字来命名的 4.2 示例地址与结构说明 示例地址https://github.com/EdisonChou/EDC.SpringCloud.Samples
4.2.1 服务注册与发现 - 基于Eureka 此部分示例位于part1_service-register-discovery
此部分示例主要演示了如何基于Eureka实现服务的注册与发现其中包括两个版本
① 单节点版本 开发环境调试用 位于eureka-service-sn (sn代表single node)项目内 这里需要注意的地方是在开发环境需要关闭Eureka的自我保护机制不然你无法轻易看到服务移除的效果需要在application.yml中如下设置
eureka:server:enableSelfPreservation: false # 本地调试环境下关闭自我保护机制这是因为Eureka考虑到生产环境中可能存在的网络分区故障会导致微服务与Eureka Server之间无法正常通信。它的架构哲学是宁可同时保留所有微服务健康的微服务和不健康的微服务都会保留也不盲目注销任何健康的微服务。
关于自我保护机制更多内容可以参考《Spring Cloud Eureka全解之自我保护机制》 ② HA多节点版本 部署/生产环境用 位于eureka-service-ha-1 eureka-service-ha-2这两个项目内
此版本需要注意的是两个节点的application.yml保持一致但由于其中使用了peer1和peer2的hostname在本地开发环境需要给Windows我假设你使用的是Windows系统设置hosts文件如下 127.0.0.1 peer1 peer2扩展除了Eureka之外还可以选择通用型较强的Consul关于Consul的基本概念与服务端的安装配置可以看看我的这一篇《.Net Core微服务之基于Consul实现服务注册于发现》了解一下。最后不得不说Spring Boot 和 Spring Cloud中核心组件封装的注解真的是太强大了很多操作一个注解直接搞定无须过多的coding。 4.2.2 客户端负载均衡 - 基于Ribbon 此部分示例位于part2_client-load-balance
此部分示例主要演示了如何基于Ribbon实现客户端的负载均衡建议启动方式先启动Eureka再启动UserService和MovieService。通过访问MovieService的API接口 /log-instance 进行日志查看测试结果如下图所示 从上图可以看出通过客户端的负载均衡算法依次访问了不同的服务节点。
4.2.3 声明式REST调用 - 基于Feign 此部分示例位于part3_feign 此部分示例主要演示了基于Feign如何实现声明式调用包括以下内容
1基本整合Feign进行单参数与多参数的请求位于movie-service这个项目内
需要注意的就是别忘了在启动类加上EnableFeignClients注解
SpringBootApplication
EnableDiscoveryClient
EnableFeignClients // 要使用Feign需要加上此注解
public class MovieServiceApplication {public static void main(String[] args) {SpringApplication.run(MovieServiceApplication.class, args);}
}2自定义Feign配置的使用位于movie-service-feign-customizing这个项目内
下面的Feign接口就使用了自定义的配置类FeignConfiguration。
FeignClient(name user-service, configuration FeignConfiguration.class)
public interface UserFeignClient {/*** 使用feign自带的注解RequestLine* see https://github.com/OpenFeign/feign* param id 用户id* return 用户信息*/RequestLine(GET /{id})User findById(Param(id) Long id);
}3Feign的日志的使用位于movie-service-feign-logging这个项目内
需要注意的是Feign虽然提供了logger但是其日志打印只会对DEBUG级别做出响应。日志级别一共有4种类型如下所示
Logger.Level 可选值
* NONE: 不记录任何日志默认值
* BASIC: 仅记录请求方法、URL、响应状态码以及执行时间
* HEADERS: 记录BASIC级别的基础之上记录请求和响应的header
* FULL: 记录请求和响应的headerbody和元数据要输出日志打印application.yml内要设置DEBUG级别
logging:level:# 将Feign接口的日志级别设置为DEBUG因为Feign的Logger.Level只针对DEBUG做出响应com.mbps.cd.movieservice.feign.UserFeignClient: DEBUG最后针对FULL级别的日志打印效果如下图所示 4.2.4 容错处理 - 基于Hystrix 此部分示例位于part4_hystrix
此部分示例主要演示如何基于Hystrix实现容错处理主要包括以下内容
1通用方式整合Hystrix此示例位于movie-service项目中
针对普通的方法只需加上HystrixCommand注解及定义回退方法即可例如
HystrixCommand(fallbackMethod findByIdFallback)GetMapping(value /user/{id})public User findById(PathVariable Long id) {return restTemplate.getForObject(http://user-service/ id, User.class);}public User findByIdFallback(Long id){User user new User();user.setId(-1L);user.setUsername(Default User);return user;}2Feign使用Hystrix此示例位于movie-service-feign-hystrix项目中
针对Feign它是以接口形式工作的好在Spring Cloud已默认为Feign整合了Hystrix不过默认是关闭的需要手动在配置文件中开启
feign:hystrix:enabled: true在之前的版本Dalston之前的版本中是默认开启的至于为何要改为默认禁用可以看看这里https://github.com/spring-cloud/spring-cloud-netflix/issues/1277
然后直接在FeignClient注解中加入fallback属性即可例如下面所示
FeignClient(name user-service, fallback FeignClientFallback.class)
public interface UserFeignClient {GetMapping(value /{id})User findById(PathVariable(id) Long id);
}Component
class FeignClientFallback implements UserFeignClient{Overridepublic User findById(Long id) {User user new User();user.setId(-1L);user.setUsername(Default User);return user;}
}如果想要在Feign发生回退时能够留下日志供查看回退原因那么可以使用FallbackFactory示例项目movie-service-feign-fallback-factory.
FeignClient(name user-service, fallbackFactory FeignClientFallbackFactory.class)
public interface UserFeignClient {GetMapping(value /{id})User findById(PathVariable(id) Long id);
}Component
class FeignClientFallbackFactory implements FallbackFactoryUserFeignClient {private static final Logger LOGGER LoggerFactory.getLogger(FeignClientFallbackFactory.class);Overridepublic UserFeignClient create(Throwable cause) {return new UserFeignClient() {Overridepublic User findById(Long id) {/** 日志最好放在各个fallback中而不要直接放在create方法中* 否则在引用启动时就会打印该日志*/FeignClientFallbackFactory.LOGGER.info(sorry, fallback. reason was: , cause);User user new User();user.setId(-1L);user.setUsername(Default Username);return user;}};}
}当发生回退时日志输出信息如下 除此之外关于Hystrix部分还有监控的主题这里由于我所在的项目组的技术架构中不会涉及到也就没有弄有兴趣的童鞋可以关注一下Hystrix自带的监控以及基于Turbine的聚合监控。参考文章《Hystrix监控面板Dalston版》与《Hystrix监控数据聚合》。
4.2.5 API网关 - 基于Zuul 此部分示例位于part5_zuul
此部分示例主要演示如何基于Zuul实现API网关主要包括以下内容
1整合Zuul编写API网关位于zuul-service项目中
可以测试验证的内容
路由规则依次启动eurekauser-servicemovie-servicezuul-service然后通过zuul访问user-service接口 负载均衡依次启动eureka多个user-servicezuul-service然后多次访问user-service最后查看日志信息两个user-service都会打印hibernate日志信息验证是否达到负载均衡的效果。PSZuul内置了Ribbon来实现负载均衡。 路由端点依次启动eurekauser-servicemovie-servicezuul-service然后浏览器访问zuul-servicehttp://localhost:5000/routes可以得到路由端点信息 对于路由端点需要改一下以下配置才能正常显示路由端点信息否则会报401的错误
management:security:enabled: false # 默认为true改为false以便可以看到routes路由配置示例主要演示了路由前缀、全局敏感设置以及路由规则设置 大文件上传设置针对超大文件上传比如500M需要在Zuul中提升超时设置
# 下面的设置针对超大文件上传比如500M提升了超时设置
hystrix:command:default:execution:isolation:thread:timeoutInMillseconds: 60000ribbon:ConnectionTimeout: 3000ReadTimeout: 600002Zuul的过滤器主要位于zuul-service-filter这个项目中
对于Zuul的请求声明周期来说一共有4种标准过滤器类型
PRE在请求被路由之前调用可利用这种过滤器实现身份验证、记录调试信息等操作 ROUTING将请求路由到微服务可利用这种过滤器用于构建发送给微服务的请求 POST在路由到微服务以后执行可用来为响应添加标准的HTTP Header、收集统计信息和指标、将响应从微服务发送给客户端等 ERROR在其他阶段发生错误时执行该过滤器 此示例中演示了PRE类型的过滤器部分场景下想要禁用部分过滤器只需要在配置文件中设置即可例如这里禁用PreRequestLogFilter过滤器
zuul:# 禁用指定过滤器设置PreRequestLogFilter:pre:disable: true # 禁用我们创建的PreRequestLogFilter过滤器3Zuul的容错与回退主要位于zuul-service-fallback这个项目中
Zuul自身就带有Hystrix但是它监控的粒度是微服务级别而不是某个API当某个API不可用时会统一抛500错误码的异常页。我们可以为Zuul添加回退以实现更友好的返回信息。实现也很简单只需要实现FallbackProvider接口即可。这里要注意的是对于Edgware之前的版本即Dalston及更低版本需要实现的是ZuulFallbackProvider接口而Edgware及之后的版本要实现的是FallbackProvider接口。因为FallbackProvider是ZuulFallbackProvider的子接口而它的好处就是多了一个接口可以获取可能造成回退的原因具体可以参考这一篇文章《Spring Cloud Edgware新特性之八Zuul回退的改进》。下面是本示例中访问user-service接口user-service被我手动关闭后的返回结果 4Zuul的高可用架构
生产环境中一般都需要部署高可用的Zuul以避免单点故障实际开发中有两种情况
① Zuul的客户端也注册到了Eureka Server上比如MVC App, SPA 等 此时Zuul的高可用和其他微服务没区别都是借助Eureka和Ribbon来实现负载均衡。
② Zuul的客户端未注册到Eureka Server上比如手机App端等
现实中这种场景或许更常见此时需要借助一个额外的负载均衡器来实现Zuul的高可用比如Nginx、HAProxy以及F5等。 更多Zuul高可用的内容可以浏览周立老师的这一篇《Zuul的高可用》
5使用Zuul聚合微服务此示例位于zuul-service-aggregation项目中
许多场景下可能一个外部请求要查询Zuul后端的多个服务这时可以使用Zuul来聚合服务请求即只需请求一次由Zuul来请求各个服务然后组织好数据发送给客户端比如App客户端。示例中主要基于RxJava与Zuul来结合实现的微服务请求的聚合。
4.2.6 统一配置管理 - 基于Spring Cloud Config Spring Cloud Config为分布式系统外部化配置提供了服务端和客户端的支持包括Config Server和Config Client两部分其架构图如下图所示 其中各个微服务在启动时会请求Config Server以获取所需要的配置属性然后缓存这些属性以提高性能如下图所示 此部分示例位于part6_config
此部分示例主要演示如何基于Spring Cloud Config实现统一配置中心主要包括以下内容
1基本的Config Server与Config Client编写此示例位于config-service与config-client中
此示例需要用到一些已放到git的配置文件这里我已将其放到了github方便大家可以直接拿来测试用仓库地址为https://github.com/EdisonChou/EDC.SpringCloud.Samples.Config
端点与配置文件的映射规则如下/{application}/{profile}[/{label}]/{application}-{profile}.yml/{label}/{application}-{profile}.yml/{application}-{profile}.properties/{label}/{application}-{profile}.properties其中application: 表示微服务的虚拟主机名即配置的spring.application.nameprofile: 表示当前的环境dev, test or production?label: 表示git仓库分支master or relase or others repository name? 默认是master项目中config-service的配置文件如下
server:port: 8080spring:application:name: sampleservice-config-servercloud:config:server:git:# 配置Git仓库地址uri: https://github.com/EdisonChou/EDC.SpringCloud.Samples.Config# Git仓库账号如果需要认证username:# Git仓库密码如果需要认证password:启动顺序先启动config-server再启动config-client因为config-client在启动时就回去config-server获取配置如果这时config-server未启动则会报错。
这里需要注意的就是在config-client中对于spring cloud config的配置应该放在bootstrap.yml中而不是application.yml中否则会不起作用。这里涉及到一个spring cloud的“引导上下文”的概念可以参考这篇《深入理解Spring Cloud引导上下文》来了解一下。
2使用/refresh端点手动刷新配置仍然位于config-client项目中
要想在运行期间刷新配置需要两点改造加上RefreshScope注解
RestController
RefreshScope // RefreshScope注解不能少否则即使调用/refresh配置也不会刷新
public class ConfigClientController {Value(${profile})private String profile;GetMapping(/profile)public String hello(){return this.profile;}
}此外针对Spring Boot 1.5.x还需要给config-client端关闭安全认证否则无法正常refresh
management:security:enabled: false之后就可以通过对config-client发起POST请求刷新配置了 不过如果所有微服务都需要手动刷新配置工作量会很大。所以在实际环境中一般会实现配置的自动刷新。
3使用Spring Cloud Bus自动刷新配置此示例位于config-server-cloud-bus与config-client-cloud-bus项目中
此示例使用到的架构如下图所示它将Config Server加入消息总线之中并使用Config Server的/bus/refersh端点来实现配置的刷新。这样各个微服务只需要关注自身的业务逻辑而无需再自己手动刷新配置。
TipSpring Cloud Bus基于轻量级地消息代理例如RabbitMQ、Kafka等连接分布式系统的节点就可以通过广播的方式来传播状态的更改例如配置的更新或者其他的管理指令。我们可以将Spring Cloud Bus想象成一个分布式的Spring Boot Actuator。
运行顺序先启动config-service-cloud-bus再启动两个config-client-cloud-bus第一个默认端口8081第二个端口改为8082修改github中sampleservice-foo-dev.properties中的profile值后commit push然后POST请求config-service-cloud-bus的/bus/refersh端点最后再次访问两个client的/profile端点进行验证。
如果部分场景想要知道Spring Cloud Bus事件传播的细节可以通过以下设置来跟踪事件总线
spring:cloud:bus:trace:enabled: true # 开启cloud bus跟踪4与Eureka的配合使用此示例位于config-service-eureka与config-client-eureka两个项目中
5Config Server的高可用涉及到Git仓库的高可用、RabbitMQ的高可用以及Config Server自身的高可用。
对于Git仓库的高可用第三方Git仓库类似于GitHub等本身已经实现了高可用而针对自建Git仓库如GitLab可以参考GitLab官方文档搭建高可用https://about.gitlab.com/high-availability/
对于Config Server自身的高可用也可以分为未注册到Eureka和注册到Eureka两种情形具体可以参考Zuul的高可用的架构图。
此外对于配置内容的加密此示例没有涉及它依赖于JCEJava Cryptography Extension可以参考这一篇《Spring Cloud配置文件加密》了解一下。
扩展关于统一配置中心还可以选择更好用的Apollo携程的开源项目可以看看我的这一篇《.Net Core微服务之基于Apollo实现统一配置中心》了解一下。 4.2.7 微服务跟踪 - 基于Spring Cloud Sleuth 首先值得一提的是Spring Cloud Sleuth大量借用了Google DapperTwitter Zipkin和Apache HTrace的设计我们得了解一些术语例如span、trace、annotation等详细可以参考这篇《Spring Cloud系列之分布式链路监控Spring Cloud Sleuth》。
此示例位于part7_sleuth
此部分示例主要演示如何基于Spring Cloud Sleuth实现分布式链路监控主要包括以下内容
1基础整合Spring Cloud Sleuth位于user-service-trace与movie-service-trace项目中主要查看控制台输出日志
2Spring Cloud Sleuth与Zipkin的配合使用位于zipkin-service-server、user-service-trace-zipkin与movie-service-trace-zipkin三个项目中
Zipkin是Twitter开源的分布式跟踪系统基于Dapper论文设计而来主要功能是收集系统的时序数据从而追踪微服务架构的系统延时问题此外还提供了一个非常友好的界面来帮助追踪分析数据。
下图是一个接入Zipkin之后的服务调用简易流程图 运行顺序首先运行zipkin-service-server其次运行user-service-zipkin与movie-service-zipkin然后访问http://localhost:8010/user/1得到数据结果最后访问zipkin server首页填入起始时间、结束时间等筛选条件后点击Find a trace按钮可以看到trace列表如下图所示 点击“依赖分析”可以得到下图有助于我们分析依赖关系 需要注意的是在开发调试时因为默认的采样百分比是10%Sleuth会忽略大量span因此我们可以在开发环境将其设置为100%
spring:sleuth:sampler:# 指定需采样的请求的百分比默认是0.1即10%这里方便查看设为100%实际环境不要这样设置percentage: 1.03使用RabbitMQ收集数据此示例位于zipkin-service-server-stream与user-service-trace-zipkin-stream两个项目中 此外Spring Cloud Sleuth还可以与ELK配合使用不过此示例没有涉及感兴趣的朋友可以参考这一篇《Spring Cloud Sleuth与ELK集成》。当然示例中的跟踪数据都是存放到内存中但是跟踪数据还是建议存放到ElasticSearch中生产环境切莫只存储到内存中。 推荐工具 IDE Intellij Idea Community 2018
(PS: 如果是.Net程序猿背景强烈建议更改快捷键与Visual Studio保持一致这样能加快开发效率如不了解如何修改可以参考邹琼俊《从.Net到Java - Idea and Start Spring Boot》)
