php 微网站开发,惠州网站建设html5,建设电商网站多少钱,wordpress响应式主题制作教程转载自 微服务为什么选Spring Cloud
现如今微服务架构十分流行#xff0c;而采用微服务构建系统也会带来更清晰的业务划分和可扩展性。同时#xff0c;支持微服务的技术栈也是多种多样的#xff0c;本系列文章主要介绍这些技术中的翘楚——Spring Cloud。这是序篇#x…转载自 微服务为什么选Spring Cloud
现如今微服务架构十分流行而采用微服务构建系统也会带来更清晰的业务划分和可扩展性。同时支持微服务的技术栈也是多种多样的本系列文章主要介绍这些技术中的翘楚——Spring Cloud。这是序篇主要讲述我们为什么选择Spring Cloud和它的技术概览。
1、为什么微服务架构需要Spring Cloud
简单来说服务化的核心就是将传统的一站式应用根据业务拆分成一个一个的服务而微服务在这个基础上要更彻底地去耦合不再共享DB、KV去掉重量级ESB并且强调DevOps和快速演化。这就要求我们必须采用与一站式时代、泛SOA时代不同的技术栈而Spring Cloud就是其中的佼佼者。 DevOps是英文Development和Operations的合体他要求开发、测试、运维进行一体化的合作进行更小、更频繁、更自动化的应用发布以及围绕应用架构来构建基础设施的架构。这就要求应用充分的内聚也方便运维和管理。这个理念与微服务理念不谋而合。 接下来我们从服务化架构演进的角度来看看为什么Spring Cloud更适应微服务架构。点击这里查看Spring系列教程集合。
1.1 从使用nginx说起
最初的服务化解决方案是给提供相同服务提供一个统一的域名然后服务调用者向这个域名发送HTTP请求由Nginx负责请求的分发和跳转。 这种架构存在很多问题 Nginx作为中间层在配置文件中耦合了服务调用的逻辑这削弱了微服务的完整性也使得Nginx在一定程度上变成了一个重量级的ESB。 服务的信息分散在各个系统无法统一管理和维护。每一次的服务调用都是一次尝试服务消费者并不知道有哪些实例在给他们提供服务。这不符合DevOps的理念。 无法直观的看到服务提供者和服务消费者当前的运行状况和通信频率。这也不符合DevOps的理念。 消费者的失败重发负载均衡等都没有统一策略这加大了开发每个服务的难度不利于快速演化。
为了解决上面的问题我们需要一个现成的中心组件对服务进行整合将每个服务的信息汇总包括服务的组件名称、地址、数量等。服务的调用方在请求某项服务时首先通过中心组件获取提供这项服务的实例的信息IP、端口等再通过默认或自定义的策略选择该服务的某一提供者直接进行访问。所以我们引入了Dubbo。 1.2 基于Dubbo实现微服务
Dubbo是阿里开源的一个SOA服务治理解决方案文档丰富在国内的使用度非常高。
使用Dubbo构建的微服务已经可以比较好地解决上面提到的问题 调用中间层变成了可选组件消费者可以直接访问服务提供者。 服务信息被集中到Registry中形成了服务治理的中心组件。 通过Monitor监控系统可以直观地展示服务调用的统计信息。 Consumer可以进行负载均衡、服务降级的选择。 但是对于微服务架构而言Dubbo也并不是十全十美的 Registry严重依赖第三方组件zookeeper或者redis当这些组件出现问题时服务调用很快就会中断。 DUBBO只支持RPC调用。使得服务提供方与调用方在代码上产生了强依赖服务提供者需要不断将包含公共代码的jar包打包出来供消费者使用。一旦打包出现问题就会导致服务调用出错。 最为重要的是DUBBO现在已经重新维护了对于技术发展的新需求需要由开发者自行拓展升级。这对于很多想要采用微服务架构的中小软件组织显然是相当合适的。 目前Github社区上有一个DUBBO的升级版叫DUBBOX提供了更高效的RPC序列化方式和REST调用方式。但是该项目也基本停止维护了。 1.3 新的选择——Spring Cloud
作为新一代的服务框架Spring Cloud提出的口号是开发“面向云环境的应用程序”它为微服务架构提供了更加全面的技术支持。点击这里查看Spring系列教程集合。结合我们一开始提到的微服务的诉求我们把Spring Cloud与DUBBO进行一番对比
微服务需要的功能 Dubbo Spring Cloud 服务注册和发现 Zookeeper Eureka 服务调用方式 RPC RESTful API 断路器 有 有 负载均衡 有 有 服务路由和过滤 有 有 分布式配置 无 有 分布式锁 无 计划开发 集群选主 无 有 分布式消息 无 有 Spring Cloud抛弃了Dubbo的RPC通信采用的是基于HTTP的REST方式。严格来说这两种方式各有优劣。虽然从一定程度上来说后者牺牲了服务调用的性能但也避免了上面提到的原生RPC带来的问题。而且REST相比RPC更为灵活服务提供方和调用方的依赖只依靠一纸契约不存在代码级别的强依赖这在强调快速演化的微服务环境下显得更加合适。 Eureka相比于zookeeper更加适合于服务发现的场景这点会在下一篇会详细展开。 很明显Spring Cloud的功能比DUBBO更加强大涵盖面更广而且作为Spring的拳头项目它也能够与Spring Framework、Spring Boot、Spring Data、Spring Batch等其他Spring项目完美融合这些对于微服务而言是至关重要的。前面提到微服务背后一个重要的理念就是持续集成、快速交付而在服务内部使用一个统一的技术框架显然比把分散的技术组合到一起更有效率。更重要的是相比于Dubbo它是一个正在持续维护的、社区更加火热的开源项目这就保证使用它构建的系统可以持续地得到开源力量的支持。点击这里查看Spring系列教程集合。 2、Spring Cloud技术概览 下图展示了Spring Cloud的完整技术组成 服务治理这是Spring Cloud的核心。目前Spring Cloud主要通过整合Netflix的相关产品来实现这方面的功能Spring Cloud Netflix包括用于服务注册和发现的Eureka调用断路器Hystrix调用端负载均衡RibbonRest客户端Feign智能服务路由Zuul用于监控数据收集和展示的Spectator、Servo、Atlas用于配置读取的Archaius和提供Controller层Reactive封装的RxJava。除此之外针对 Feign和RxJava并不是Netiflix的产品但是被整合到了Spring Cloud Netflix中。 对于服务的注册和发现除了EurekaSpring Cloud也整合了Consul和Zookeeper作为备选但是因为这两个方案在CAP理论上都遵循CP而不是AP下一篇会详细介绍这点所以官方并没有推荐使用。 分布式链路监控Spring Cloud Sleuth提供了全自动、可配置的数据埋点以收集微服务调用链路上的性能数据并发送给Zipkin进行存储、统计和展示。 消息组件Spring Cloud Stream对于分布式消息的各种需求进行了抽象包括发布订阅、分组消费、消息分片等功能实现了微服务之间的异步通信。Spring Cloud Stream也集成了第三方的RabbitMQ和Apache Kafka作为消息队列的实现。而Spring Cloud Bus基于Spring Cloud Stream主要提供了服务间的事件通信比如刷新配置。 配置中心基于Spring Cloud Netflix和Spring Cloud BusSpring又提供了Spring Cloud Config实现了配置集中管理、动态刷新的配置中心概念。配置通过Git或者简单文件来存储支持加解密。 安全控制Spring Cloud Security基于OAUTH2这个开放网络的安全标准提供了微服务环境下的单点登录、资源授权、令牌管理等功能。 命令行工具Spring Cloud Cli提供了以命令行和脚本的方式来管理微服务及Spring Cloud组件的方式。 集群工具Spring Cloud Cluster提供了集群选主、分布式锁暂未实现、一次性令牌暂未实现等分布式集群需要的技术组件。
