精华内容
下载资源
问答
  • 为了实现基于微服务开发的产品,或者说为了将单体应用重构为微服务架构时,将面临着众多技术框架的选择。大公司往往会有专门的部门或团队来负责自主研发自己的框架,以满足产品的需要,但是对于一般的中小型企业,...

    在这里插入图片描述
    前期回顾:
    微服务架构下的核心话题 (一):微服务架构下各类项目的顺势崛起
    微服务架构下的核心话题 (二):微服务架构的设计原则和核心话题

    一、前言

    为了实现基于微服务开发的产品,或者说为了将单体应用重构为微服务架构时,将面临着众多技术框架的选择。大公司往往会有专门的部门或团队来负责自主研发自己的框架,以满足产品的需要,但是对于一般的中小型企业,选择合适的开源框架就显得更接地气了。本章将简单介绍微服务中,在技术选型时需要注意哪些原则,一些常用的开源技术框架,希望能够为大家在进行技术选型、调研时提供一些思路方向。

    笔者面试过很多程序员,一提及微服务,就会具体说道Spring Boot、Spring Cloud,然后就是“背诵”各种具体的用法和配置文件。并不是说这样不对,但我们更希望知道的是这些技术框架的原理,为什么选择它,它与其他类似框架又有何不同呢。

    至于一个技术框架该怎么用,它适用于什么场景,笔者建议可以直接阅读官方或对应的github上的文档,有需要时还可以阅读下关注点的源码,这样对正确的理解它,是很有必要的,毕竟官方发布的东西是相对权威的,其他地方的资料或许存在片面性,对大家的使用、理解存在一定的误导。(这只是笔者对大家在技术选型时,查阅资料的一些建议)

    二、选型原则

    在软件开发领域,几乎每天都有新的技术框架诞生、更新,一些新的概念更是层出不穷,技术选型时,难免让人无从抉择。 对于技术选型,我个人有以下几点建议:

    1.有需求,再引入

    在微服务架构中,各类组件/技术很多很多,但并不意味着所有的都应该引入你的项目,倘若单纯为了覆盖全技术栈或组件而全部引入,这将是一种很不明智的选择。后续将会成为你项目的累赘,让你苦不堪言。

    只要你记住这六个字:“有需求,再引入”,就OK了。伴随着项目体系架构的完善、功能的健全,当有某方面的需求时,在逐步考虑是否引入某些技术组件。

    2.选择最熟悉、使用最多的技术

    “一个新项目里最好不要使用超过30%的新技术”,我觉得这句话是有一定道理的。对于你完全不知道、不了解的技术,你是无法预估、掌控在使用过程中会出现的任何风险,一旦出现问题,短时间内解决不了,你将会变得很难堪。

    在这里不是说拒绝使用、接触新技术,新技术是值得大家去追捧、了解、学习,一些新技术在很大程度上能给我们带来前所未有的利处,解决其他技术框架解决不了的问题。这里所说的“新技术”,是指没有经过充分的考察、技术验证、存在种种疑惑的技术,而是一味的拿来主义,这样的风险可想而知。

    确保选择的技术,是业界使用最多的、被大家认可的技术,即使出现了问题,也能应对自如。至少在团队内部小范围是非常认可的。

    3.强大社区支撑的技术

    GitHub上star的数量是一个重要指标,同时参考近年来代码、文档、issues等更新频率,各大技术博客是否有相关技术分享记载,这些都是能够说明该技术是否活跃、受欢迎程度、使用人群多少等。

    拥有强大社区支持的技术,在选型后,倘若使用出现疑问、问题、bug等,能够有地方可提、可修复、可深究探讨,毕竟现在的技术社区都是足够开放的。

    慎选个人开源的技术框架、组件等,里面到底有多少坑,没几个人能说清楚的,况且说不定哪天就不复存在了呢。

    4.从业务、项目规模出发

    任何技术的出发点都是为最终业务而服务的,不同业务、不同项目规模,对技术的要求指标都是不同的。处于初创期的业务,选型的基准是相对灵活,毕竟业务相对简单,支撑业务不是很大,只要够用、开发效率足够高就好。处于复杂业务而重构的项目,选型就需谨慎,往往伴随着一些复杂需求诞生、规模大小的不确定性,不得不考虑选型技术可能伴随着一些小修小补或者螺旋式上升的重构,则需选型便于适配、切换、替换,耦合度低的技术。

    正因为技术选型和业务相关,我们能够观察到一些很明显的现象:新技术往往被早期创业团队或大公司的新兴业务使用;中大型公司的核心业务则更倾向于用一些稳定了几年的技术;一个公司如果长期使用一种技术,就会倾向于一直使用下去,甚至连版本都不更新的使用下去。

    学会从业务端思考。首先我们需要充分地理解业务,理解用户需求,理解当下需要解决的首要问题,以及可能的风险有哪些,再将目标进行分解,进行具体的技术选型、模型设计、架构设计。

    5.先验证后使用

    对于未经验证的新技术、新理念的引入一定要慎重,一定要在全方位的验证过后,再大规模的使用,最终确定选型。新技术、新理念的出现,自然有它的诱惑,慎重并不代表保守,技术总是在不断前进,拥抱变化本身没有问题,但是引入不成熟的技术看似能带来短期的收益,但是它的风险或者是后期的成本可能远远大于收益。

    验证后,才有说服力,用着更放心。

    三、技术选型

    每种技术架构都有其优缺点,存在即合理,不同的业务场景使用不同的应用架构,技术框架,不一定说最新的架构、技术就是最适合你的。

    微服务架构中常提及到的主要技术框架选型如下表所示,本文后面将基于此展开说明对比。

    类型框架
    服务治理Dubbo、Spring Cloud
    API网关Zuul、traefik、OpenResty、Kong
    服务注册与发现Zookeeper、Eureka、Consul、etcd
    配置中心Spring Cloud Config、Apollo、Nacos
    链路追踪、监控Zipkin、CAT

    四、服务治理

    1.Dubbo

    Dubbo是一款高性能、轻量级的开源JAVA RPC框架,以及SOA服务治理方案。简单的说,Dubbo就是个服务框架,说白了就是个远程服务调用的分布式框架。它提供了三大核心能力:面向接口的远程方法调用、智能容错和负载均衡、以及服务自动注册和发现,很容易和Spring框架无缝集成。

    Dubbo逻辑架构如下图所示:
    Dubbo架构图

    • Provider:暴露服务的提供方,可以通过jar或者容器的方式启动服务。
    • Consumer:调用远程服务的服务消费方。
    • Registry:服务注册中心和发现中心。
    • Monitor:统计服务和调用次数,调用时间监控中心。(dubbo的控制台页面中可以显示,目前只有一个简单版本)
    • Container:服务运行的容器。

    Dubbo特点:

    • 远程通讯: 提供对多种基于长连接的NIO框架抽象封装(非阻塞I/O的通信方式,Mina/Netty/Grizzly),包括多种线程模型,序列化(Hessian2/ProtoBuf),以及“请求-响应”模式的信息交换方式。
    • 集群容错: 提供基于接口方法的透明远程过程调用(RPC),包括多协议支持(自定义RPC协议),以及软负载均衡(Random/RoundRobin),失败容错(Failover/Failback),地址路由,动态配置等集群支持。
    • 自动发现: 基于注册中心目录服务,使服务消费方能动态的查找服务提供方,使地址透明,使服务提供方可以平滑增加或减少机器。

    在现有的微服务架构下,Dubbo只能说是一个服务治理框架,或者说是一个RPC框架,是以接口为粒度,一个接口类就就是一个服务。如果直接用Dubbo来实现微服务架构,还缺少以下几个功能:

    • 分布式配置:可以使用Spring Cloud Config、Apollo等来实现。
    • 链路追踪:可以使用Zipkin、CAT等来实现。
    • 批量任务:可以使用当当网开源的Elastic-Job来实现。

    2.Spring Cloud

    Spring Cloud是目前最主流的微服务架构落地首选方案之一,是基于Spring Boot实现的开源框架,是一个全家桶,是微服务的整体技术栈

    Spring Boot是Spring 的一套快速配置脚手架,使用默认大于配置的理念,用于快速开发单个微服务。

    它为服务注册发现动态路由负载均衡配置管理消息总线熔断器分布式链路追踪大数据操作等提供了简单的实现,让我们可以更简洁的使用它。

    正如我们前面说过的,微服务是可以独立部署、水平扩展、独立访问的服务单元,而Spring Cloud就是这些微服务的“大管家”,采用了微服务这种架构之后,项目的数量会非常多,调用链路复杂,从而管理成了很大的问题,而Spring Cloud框架恰恰提供了各种组件用于管理和治理微服务。理所应当的,就成了大家首选框架了。

    Spring Cloud的整体架构如下图所示,提供一站式的微服务架构解决方案。springCloud架构

    使用Spring Cloud来构建微服务架构可以省去你整合各家技术的成本,Spring Cloud为我们构建微服务架构提供了一站式的解决方案,就好比当初Spring诞生是为解决EJB企业应用开发的众多问题而提供的一站式轻量级企业应用开发解决方案一样,随着使用Spring Cloud的产品数量增加,Spring Cloud在微服务架构中已一统江湖。

    下面是Spring Cloud的完整技术栈,看完你就知道它为啥会在微服务架构中一统江湖了。
    在这里插入图片描述

    3.对比、总结

    DubboSpring Cloud
    功能/专注点专注于RPC和服务治理微服务架构生态、技术栈
    通信协议RPC(远程方法调用)协议REST/HTTP(已有组件支持gRPC协议)
    服务注册与发现Zookeeper(CP)Eureka(AP)
    负载均衡软负载均衡(Random/RoundRobin)Ribbon
    容错机制
    熔断机制Hystrix
    配置中心依赖外部组件,如:NacosSpring Cloud Config
    网关zuul,Gateway
    服务监控Dubbo + MonitorHystrix + Turbine、Spring Boot Admin(SBA)
    链路监控Sleuth + Zipkin
    多语言支持只支持JavaREST支持多语言
    社区活跃高(依靠阿里)高(依靠Spring)
    消息总线Spring Cloud Bus
    数据流Spring Cloud Stream
    批量任务Spring Cloud Task
    ………………

    通过上表对比,很容易发现Spring Cloud拥有很多的项目模块,包含了微服务系统的方方面面。Dubbo是一个非常优秀的服务治理和服务调用框架,但缺少很多功能模块,例如网关、链路追踪等。在项目模块上,Spring Cloud占据着更大的优势。对比并不是否定谁,推崇谁,只是说明在不同场景下,有利优劣,需客观来看。

    如果仅关注于服务治理的这个层面,Dubbo其实还优于Spring Cloud很多:

    • 支持多种序列化协议,如Hessian、HTTP、WebService。
    • Dobbo Admin后台管理功能强大,提供了路由规则、动态配置、访问控制、权重调节、均衡负载等功能。
    • 在国内影响力比较大,中文社区文档较为全面。
    • 阿里最近重启维护,成为Apache孵化项目。
    • Dubbo使用RPC协议效率更高,在极端压力测试下,Dubbo的效率会高于Spring Cloud效率一倍多。

    如果对效率有极高的要求建议使用Dubbo,相对比RPC的效率会比Restful高很多,如果选择微服务架构去重构整个技术体系,那么 Spring Cloud是当仁不让之选,它可以说是目前最好的微服务框架没有之一,并且可以断言,将来Dubbo可以很好的整合到Spring Cloud中。

    五、API网关

    API网关作为微服务中所有服务的唯一入口,免得业界各类成熟的技术框架组件,在进行技术选型时,需要特别考虑是否拥有以下特性:

    • 高可用:网关是对外的唯一关口,必须保证 7 * 24小时可用,持续提供稳定可靠的服务。
    • 高性能:所有的请求都会经过网关,它承受的压力是巨大的,所以必须保证它具备良好的性能,以应对高并发请求。
    • 安全性:网关必须能够防止外部的恶意访问,确保内部各个微服务的安全。
    • 扩展性:网关是一个处理非业务功能的绝佳场所,必须能够提供流量管控、协议转发、日志监控等服务,同时能够为以后对非业务功能的扩展提供良好的兼容性。

    1.Zuul

    Zuul作为Spring Cloud中的核心组件之一,充当API网关的重要角色,所有请求都可以通过Zuul达到后端的应用程序、服务。Zuul提供了动态路由、监控、弹性负载和安全等特性,其核心是一系列的Filter,其作用类似于Servlet框架中的Filter,或者AOP。

    Zuul底层利用各种Filter实现了如下功能:

    • 动态路由:根据需要将请求动态路由到后端集群。
    • 身份认证和安全性:识别每个需要认证的资源,拒绝不符合要求的请求,如:鉴权。
    • 统计监测:在服务边界追踪并统计数据,提供精确的统计监测视图。
    • 压力测试:逐渐增加对集群的流量以了解其性能。
    • 负载卸载:预先为每种类型的请求分配容量,当请求超过容量时自动丢弃。
    • 静态资源处理:直接在边界返回某些响应。

    基于上述这些功能特性,使得Zuul作为API网关的不二之选。

    Zuul的逻辑架构如下图所示:
    Zuul的逻辑架构
    Zuul的过滤器之间是不直接通信的,而是通过一个RequestContext的类来进行数据传统,RequestContext继承ConcurrentHashMap,使用ThreadLocal变量来记录每个Request需要传递的数据。

    Zuul的过滤器是由Groovy来实现的,这些过滤器文件被存放在Zuul Server的特定目录下,Zuul会定期轮询这些目录,修改过的过滤器会动态加载到Zuul Server中,以便过滤请求使用。

    Zuul的大部分功能都是通过过滤器来实现的,其中定义了4种标准的过滤器类型(pre、route、post、error),以满足应用于请求的不同阶段。
    (如果想更清晰深入的了解Zuul,可以参考上图的Zuul逻辑架构图,并结合Zuul源码深入研究下。)

    2.traefik

    在了解traefik之前,不妨先看看它的整体架构图,如下所示:
    treakfik架构图

    从上图不难看出,traefik充当了HTTP反向代理的角色,使得发布的服务变得轻松有趣。在微服务中,实质上是一个为了让部署微服务变得更加便捷而诞生的HTTP反向代理、负载均衡工具。,它支持多种后台 (Docker, Swarm, Kubernetes, Marathon, Mesos, Consul, Etcd, Zookeeper, BoltDB, Rest API, file…) 来自动化、动态的应用它的配置文件设置。

    除了众多功能之外,traefik的与众不同之处还在于它会自动发现适合您服务的配置。无需维护和同步单独的配置文件,一切都会自动,实时地进行(无需重新启动,不会中断连接)。使用traefik后,你可以将更多的精力、时间花费在开发和部署上面,而不是在配置和维护其工作状态上。

    特性:

    • 高性能
    • 无需安装其他依赖,通过Go语言编写的单一可执行文件
    • 支持Restful API接口
    • 多种后台支持:Docker, Swarm, Kubernetes, Marathon, Mesos, Consul, Etcd
    • 后台监控, 可以监听后台变化进而自动化应用新的配置文件设置
    • 配置文件热更新。(无需重启)
    • 正常结束http连接
    • 后端断路器
    • 轮询,rebalancer 负载均衡
    • Rest Metrics
    • 支持最小化官方docker镜像
    • 后台支持SSL
    • 前台支持SSL(包括SNI)
    • 清爽的AngularJS前端页面
    • 支持Websocket
    • 支持HTTP/2
    • 网络错误重试
    • 支持Let’s Encrypt (自动更新HTTPS证书)
    • 高可用集群模式

    3.OpenResty

    OpenResty是一个基于Nginx与Lua的高性能Web平台,其内部集成了大量精良的Lua库、第三方模块以及大多数的依赖项。用于方便地搭建能够处理超高并发、扩展性极高的动态Web应用、Web服务和动态网关。

    OpenResty通过汇聚各种设计精良的Nginx模块(主要由OpenResty团队自主开发),从而将Nginx有效地变成一个强大的通用Web应用平台。这样,Web 开发人员和系统工程师可以使用Lua脚本语言调动 Nginx支持的各种C以及Lua模块,快速构造出足以胜任10K乃至 1000K以上单机并发连接的高性能Web应用系统。

    OpenResty的目标是让你的Web服务直接跑在Nginx服务内部,充分利用Nginx的非阻塞I/O模型,不仅仅对HTTP客户端请求,甚至于对远程后端诸如MySQL、PostgreSQL、Memcached以及Redis等都进行一致的高性能响应。

    4.Kong

    Kong是一个在Nginx中运行的Lua应用程序,并且可以通过lua-nginx模块实现,Kong不是用这个模块编译Nginx,而是与OpenResty一起发布,OpenResty已经包含了lua-nginx-module,OpenResty不是 Nginx的分支,而是一组扩展功能的模块。

    是一个Api Gateway,通过插件的形式提供负载均衡,日志记录,身份验证,速率限制,转换等功能。可以很轻松扩展功能,模块化,可以运行在任何基础设施上。

    它的核心是实现数据库抽象,路由和插件管理,插件可以存在于单独的代码库中,并且可以在几行代码中注入到请求生命周期的任何位置。很方便地为路由和服务提供各种插件,网关所需要的基本特性,Kong都如数支持:

    • 云原生:与平台无关,Kong可以从裸机运行到Kubernetes。
    • 动态路由:Kong的背后是OpenResty+Lua,所以从OpenResty继承了动态路由的特性。
    • 熔断
    • 健康检查
    • 日志:可以记录通过Kong的HTTP,TCP,UDP请求和响应。
    • 鉴权:权限控制,IP黑白名单,同样是OpenResty的特性。
    • SSL: 可以为基础服务或API设置特定的SSL证书。
    • 监控:Kong提供了实时监控插件。
    • 认证:如数支持HMAC, JWT, Basic, OAuth2.0等常用协议。
    • 限流
    • REST API:通过Rest API进行配置管理,从繁琐的配置文件中解放。
    • 可用性: 天然支持分布式。
    • 高性能: 背靠非阻塞通信的nginx,性能自不用说。
    • 插件机制: 提供众多开箱即用的插件,且有易于扩展的自定义插件接口,用户可以使用Lua自行开发插件。

    上面这些特性中,反复提及了Kong背后的OpenResty,实际上,使用 Kong之后,Nginx可以完全摒弃,因为Kong的功能是Nginx的父集。

    5.对比、总结

    ZuultraefikOpenRestyKong
    功能/用途Spring Cloud中的核心组件之一,充当API网关的角色支持动态配置的HTTP反向代理和负载均衡器基于Nginx与Lua的高性能Web平台,服务代理/网关企业级API管理
    学习成本简单简单适中适中
    社区开源、活跃开源开源开源/企业版
    扩展性可扩展,自己实现Filter可扩展,自己实现可扩展,插件可扩展, 插件
    服务发现动态动态动态动态
    通信协议Restfulhttp,https,grpc,websockethttp,https,websockethttp,https,websocket
    限流支持不支持支持支持
    熔断支持支持--
    健康检查支持不支持支持支持

    综上对比,从开源社区活跃度和学习成本来看,无疑是Zuul和Traefik较好;从成熟度来看,较好的是Kong、Traefik;从性能角度来看,Kong要比其他几个领先一些,从架构优势的扩展性来看,Kong丰富的插件,而Zuul是完全需要自研各类Filter,但Zuul由于与Spring Cloud深度集成,使用度也很高。

    六、服务注册与发现

    服务注册与发现,是一个古老的话题,当应用开始脱离单机运行和访问时,服务注册与发现就诞生了。目前的网络架构是每个主机都有一个独立的IP地址,那么服务发现基本上都是通过某种方式获取到服务所部署的IP地址。DNS协议是最早将一个网络名称翻译为网络IP的协议,在最初的架构选型中,DNS+LVS+Nginx基本可以满足所有的RESTful服务的发现,此时服务的IP列表通常配置在Nginx或者LVS。后来出现了RPC服务,服务的上下线更加频繁,人们开始寻求一种能够支持动态上下线并且推送IP列表变化的注册中心框架或组件。

    现如今,各类服务注册与发现的框架、组件很多(Zookeeper、Eureka、Consul、etcd等),在选择上更是眼花缭乱。在服务注册与发现的技术选型上,我觉得我们应该还是有一定遵循原则和关注要点的。通常可从以下几个方面出发,进行重点关注、抉择。

    • 数据一致性
    • 负载均衡
    • 健康检查
    • 性能与容量
    • 易用性
    • 集群扩展性
    • 用户扩展性

    七、配置中心

    在微服务架构中,服务的数量以及配置信息的日益增多,比如各种服务器参数配置、各种数据库访问参数配置、各种环境下配置信息的不同、配置信息修改之后实时生效等等,传统的配置文件方式或者将配置信息存放于数据库中的方式已无法满足开发人员对配置管理的要求,如:

    • 安全性:配置跟随源代码保存在代码库中,容易造成配置泄漏。
    • 时效性:修改配置,需要重启服务才能生效。
    • 局限性:无法支持动态调整:例如日志开关、功能开关。

    在微服务架构中,使用配置中心之前,上述的问题或麻烦,你肯定也会遇到过,所以,是否引入配置中心,取决于你是否有下面的需求:

    • 配置集中化统一管理
    • 配置实时生效

    一般完善的配置中心,都会从以下两个方面设计出发,以发挥配置中心的作用。

    1)配置实时生效

    传统的静态配置方式要想修改某个配置只能修改之后重新发布应用,要实现动态性,可以选择使用数据库,通过定时轮询访问数据库来感知配置的变化。轮询频率低感知配置变化的延时就长,轮询频率高,感知配置变化的延时就短,但比较损耗性能,需要在实时性和性能之间做折中。配置中心专门针对这个业务场景,兼顾实时性和一致性来管理动态配置。

    2)配置管理流程

    配置的权限管控、灰度发布、版本管理、格式检验和安全配置等一系列的配置管理相关的特性也是配置中心不可获取的一部分。(这也算是配置中心的高级特性作用)

    1.Spring Cloud Config

    Spring Cloud Config作为Spring Cloud中的一个组件,其功能开放,可开发性强,常是各类配置中心自我研发的基石。

    从Spring Cloud Config的源码(spring-cloud-config-server)中,可以看出目前支持本地存储、Git仓库存储、SVN仓库存储、数据库存储方式,其他存储方式可参考源码自行实现即可。
    在这里插入图片描述

    以Git存储方式为例说明,Spring Cloud Config包含config-server、Git和Spring Cloud Bus三大组件:

    • config-server提供给客户端获取配置。
    • Git用于存储和修改配置。
    • Spring Cloud Bus通知客户端配置变更。

    本地测试模式下,Spring Cloud Bus和config-server需要部署一个节点,Git使用GitHub就可以。在生产环境中,Spring Cloud Config,config-server需要部署至少两个节点。Spring Cloud Bus如果使用RabbitMQ,普通集群模式至少需要两个节点。

    Git服务如果使用GitHub就不用考虑高可用问题,如果考虑到安全性要自建Git私有仓库,整体的成本比较高。Web服务可以部署多节点支持高可用,由于Git有数据的一致性问题,可以通过以下的方式来支持高可用:

    • Git+Keepalived冷备模式,当主Git挂了可以马上切到备Git。
    • Git多节点部署,存储使用网络文件系统或者通过DRBD实现多个Git节点的数据同步。

    2.Apollo

    Apollo(阿波罗)是携程框架部门研发的分布式配置中心,能够集中化管理应用不同环境、不同集群的配置,配置修改后能够实时推送到应用端,并且具备规范的权限、流程治理等特性,适用于微服务配置管理场景。

    Apollo分为MySQL,Config Service,Admin Service,Portal四个模块:

    • MySQL:存储Apollo元数据和用户配置数据。
    • Config Service:提供配置的读取、推送等功能,客户端请求都是落到Config Service上。
    • Admin Service:提供配置的修改、发布等功能,Portal操作的服务就是Admin Service。
    • Portal:提供给用户配置管理界面。

    本地测试Config Service,Admin Service,Portal三个模块可以合并一起部署,MySQL单独安装并创建需要的表结构。在生产环境使用Apollo,Portal可以两个节点单独部署,稳定性要求没那么高的话,Config Service和Admin Service可以部署在一起,数据库支持主备容灾。
    在这里插入图片描述

    3.Nacos

    Nacos是一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。这正是Nacos官方给出的定义:

    an easy-to-use dynamic service discovery, configuration and service management platform for building cloud native applications.

    核心功能:

    • 动态配置服务:
      动态配置服务让您能够以中心化、外部化和动态化的方式管理所有环境的配置。动态配置消除了配置变更时重新部署应用和服务的需要。配置中心化管理让实现无状态服务更简单,也让按需弹性扩展服务更容易。
    • 服务发现及管理:
      动态服务发现对以服务为中心的(例如微服务和云原生)应用架构方式非常关键。Nacos支持DNS-Based和RPC-Based(Dubbo、gRPC)模式的服务发现。Nacos也提供实时健康检查,以防止将请求发往不健康的主机或服务实例。借助Nacos,您可以更容易地为您的服务实现断路器。
    • 动态DNS服务:
      通过支持权重路由,动态DNS服务能让您轻松实现中间层负载均衡、更灵活的路由策略、流量控制以及简单数据中心内网的简单DNS解析服务。动态DNS服务还能让您更容易地实现以DNS协议为基础的服务发现,以消除耦合到厂商私有服务发现API上的风险。

    Nacos部署需要Nacos Service和MySQL:

    • Nacos Service:对外提供服务,支持配置管理和服务发现。
    • MySQL:提供Nacos的数据持久化存储。

    单机模式下,Nacos可以使用嵌入式数据库部署一个节点,就能启动。如果对MySQL比较熟悉,想要了解整体数据流向,可以安装MySQL提供给Nacos数据持久化服务。生产环境使用Nacos,Nacos服务需要至少部署三个节点,再加上MySQL主备。

    4.对比、总结

    整体来看,Nacos的部署结构比较简单,运维成本较低。Apollo部署组件较多,运维成本比Nacos高。Spring Cloud Config易于定制化二次开发,生产高可用的成本最高。

    Spring Cloud ConfigApolloNacos
    开源时间2014.92016.52018.6
    实时生效(推送)基于Spring Cloud Bus完成基于HTTP轮询(1s内)基于HTTP轮询(1s内)
    版本管理支持(Git、SVN)支持支持
    配置回滚支持(Git、SVN)支持支持
    灰度发布支持支持待支持
    权限管理支持支持待支持
    集群支持支持支持
    多环境支持支持支持
    监听查询支持支持支持
    多语言只支持JavaJava、Go、C++、Python、PHPJava、Python、Nodejs
    单机部署Config-Server + Git + Spring Cloud Bus(实时更新推送)Apollo-quickstart + MySQLNacos单节点
    分布式部署Config-Server(2) + Git + MQ (部署复杂)Config(2) + Admin(2) + Portal(2) + MySQL (部署复杂)Nacos(3) + MySQL(部署简单)
    配置格式校验不支持支持支持
    通信协议HTTP、AMQPHTTPHTTP
    数据一致性Git保证数据一致性数据库模拟消息队列,Apollo定时读取HTTP异步通知

    总的来说,Apollo和Nacos相对于Spring Cloud Config的生态支持更广,在配置管理流程上做的更好。Apollo相对于Nacos在配置管理做的更加全面,不过使用起来也要麻烦一些。Nacos使用起来相对比较简洁,在对性能要求比较高的大规模场景更适合。

    未完,更新中……

    参考资料:
    1.http://dubbo.apache.org/zh-cn/
    2.https://my.oschina.net/bigdataer/blog/1859971?from=timeline
    3.https://github.com/Netflix/zuul/wiki
    4.https://traefik.cn/
    5.http://openresty.org/cn/
    6.https://www.cnblogs.com/duanxz/p/9776316.html
    7.https://yq.aliyun.com/articles/698930?utm_content=g_1000053369
    8.https://blog.csdn.net/weixin_44337261/article/details/89426925
    9.https://github.com/ctripcorp/apollo/wiki
    10.https://nacos.io/zh-cn/

    欢迎微信扫码下面二维码,关注微信公众号【程序猿技术大咖】,进行更多交流学习!

    展开全文
  • 微服务:简述Spring Cloud微服务架构

    千次阅读 2019-07-10 13:24:09
    Spring Cloud作为当下主流的微服务框架,可以让我们更简单快捷地实现微服务架构。Spring Cloud并没有重复制造轮子,它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来,通过Spring Boot风格...

    微服务:简述Spring Cloud微服务架构


    Spring Cloud作为当下主流的微服务框架,可以让我们更简单快捷地实现微服务架构。Spring Cloud并没有重复制造轮子,它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来,通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理,最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。

    Spring Cloud 是一个基于 Spring Boot 实现的微服务框架,它包含了实现微服务架构所需的各种组件。Spring Cloud中各个组件在微服务架构中扮演的角色如下图所示:
    在这里插入图片描述
    由上图所示,微服务架构大致由上图的逻辑结构组成,其包括各种微服务、注册发现、服务网关、熔断器、统一配置、跟踪服务等。下面说说Spring Cloud中的组件分别充当其中的什么角色。

    一、Netflix eureka(注册发现)

    微服务模式下,一个大的Web应用通常都被拆分为很多比较小的Web应用(服务),这个时候就需要有一个地方保存这些服务的相关信息,才能让各个小的应用彼此知道对方,这个时候就需要在注册中心进行注册。每个应用启动时向配置的注册中心注册自己的信息(IP地址,端口号, 服务名称等信息),注册中心将他们保存起来,服务间相互调用的时候,通过服务名称就可以到注册中心找到对应的服务信息,从而进行通讯。注册与发现服务为微服务之间的调用带来了方便,解决了硬编码的问题。服务间只通过对方的服务ID,而无需知道其IP和端口即可以获取对方方服务。

    二、Fegin(接口调用)

    微服务之间通过Rest接口通讯,Spring Cloud提供Feign框架来支持Rest的调用,Feign使得不同进程的Rest接口调用得以用优雅的方式进行,这种优雅表现得就像同一个进程调用一样。

    三、Ribbon(负载均衡)

    Ribbon是Netflix发布的负载均衡器,它有助于控制HTTP和TCP客户端的行为。为Ribbon,配置服务提供者的地址列表后,Ribbon就可基于某种负载均衡算法,自动地帮助服务消费者去请求。

    Ribbon默认为我们提供了很多的负载均衡算法,例如轮询、随机等。当然,我们也可为Ribbon实现自定义的负载均衡算法。在Spring Cloud中,当Ribbon与Eureka配合使用时,Ribbon可自动从EurekaServer获取服务提供者的地址列表,并基于负载均衡算法,请求其中一个服务提供者的实例(为了服务的可靠性,一个微服务可能部署多个实例)。

    四、Hystrix(熔断器)

    当服务提供者响应非常缓慢,那么消费者对提供者的请求就会被强制等待,直到提供者响应或超时。在高负载场景下,如果不做任何处理,此类问题可能会导致服务消费者的资源耗竭甚至整个系统的崩溃(雪崩效应)。Hystrix正是为了防止此类问题发生。Hystrix是由Netflix开源的一个延迟和容错库,用于隔离访问远程系统、服务或者第三方库,防止级联失败,从而提升系统的可用性与容错性。

    Hystrix主要通过以下几点实现延迟和容错。

    1. 包裹请求:使用HystrixCommand(或HystrixObservableCommand)包裹对依赖的调用逻辑,每个命令在独立线程中执行。这使用了设计模式中的“命令模式”。
    2. 跳闸机制:当某服务的错误率超过一定阈值时,Hystrix可以自动或者手动跳闸,停止请求该服务一段时间。
    3. 资源隔离:Hystrix为每个依赖都维护了一个小型的线程池(或者信号量)。如果该线程池已满,发往该依赖的请求就被立即拒绝,而不是排队等候,从而加速失败判定。
    4. 监控:Hystrix可以近乎实时地监控运行指标和配置的变化,例如成功、失败、超时和被拒绝的请求等。
    5. 回退机制:当请求失败、超时、被拒绝,或当断路器打开时,执行回退逻辑。回退逻辑可由开发人员指定。

    五、Zuul(微服务网关)

    不同的微服务一般会有不同的网络地址,而外部客户端可能需要调用多个服务的接口才能完成一个业务需求。例如一个电影购票的手机APP,可能调用多个微服务的接口才能完成一次购票的业务流程,如果让客户端直接与各个微服务通信,会有以下的问题:

    1. 客户端会多次请求不同的微服务,增加了客户端的复杂性。
    2. 存在跨域请求,在一定场景下处理相对复杂。
    3. 认证复杂,每个服务都需要独立认证。
    4. 难以重构,随着项目的迭代,可能需要重新划分微服务。例如,可能将多个服务合并成一个或者将一个服务拆分成多个。如果客户端直接与微服务通信,那么重构将很难实施。
    5. 某些微服务可能使用了对防火墙/浏览器不友好的协议,直接访问时会有一定的困难。

    以上问题可借助微服务网关解决。微服务网关是介于客户端和服务器端之间的中间层,所有的外部请求都会先经过微服务网关。使用微服务网关后,微服务网关将封装应用程序的内部结构,客户端只用跟网关交互,而无须直接调用特定微服务的接口。这样,开发就可以得到简化。不仅如此,使用微服务网关还有以下优点:

    1. 易于监控。可在微服务网关收集监控数据并将其推送到外部系统进行分析。
    2. 易于认证。可在微服务网关上进行认证,然后再将请求转发到后端的微服务,而无须在每个微服务中进行认证。
    3. 减少了客户端与各个微服务之间的交互次数。

    六、Spring Cloud Config( 统一配置服务)

    对于传统的单体应用,常使用配置文件管理所有配置。例如一个SpringBoot开发的单体应用,可将配置内容放在application.yml文件中。如果需要切换环境,可设置多个Profile,并在启动应用时指定spring.profiles.active={profile}。然而,在微服务架构中,微服务的配置管理一般有以下需求:

    1. 集中管理配置。一个使用微服务架构的应用系统可能会包含成百上千个微服务,因此集中管理配置是非常有必要的。
    2. 不同环境,不同配置。例如,数据源配置在不同的环境(开发、测试、预发布、生产等)中是不同的。
    3. 运行期间可动态调整。例如,可根据各个微服务的负载情况,动态调整数据源连接池大小或熔断阈值,并且在调整配置时不停止微服务。
    4. 配置修改后可自动更新。如配置内容发生变化,微服务能够自动更新配置。

    综上所述,对于微服务架构而言,一个通用的配置管理机制是必不可少的,常见做法是使用配置服务器管理配置。Spring Cloud Bus利用Git或SVN等管理配置、采用Kafka或者RabbitMQ等消息总线通知所有应用,从而实现配置的自动更新并且刷新所有微服务实例的配置。

    七、Sleuth+ZipKin(跟踪服务)

    Sleuth和Zipkin结合使用可以通过图形化的界面查看微服务请求的延迟情况以及各个微服务的依赖情况。需要注意的是Spring Boot 2及以上不在支持Zipkin的自定义,需要到官方网站下载ZipKin相关的jar包。另外需要提一点的是Spring Boot Actuator,提供了很多监控端点如/actuator/info、/actuator/health、/acutator/refresh等,可以查看微服务的信息、健康状况、刷新配置等。


    参考

    1. https://www.jianshu.com/p/84d2824980fe
    展开全文
  • SpringCloud微服务架构

    2020-07-27 21:46:26
    Spring Cloud作为当下主流微服务架构,可以让我们更简单快捷地实现微服务架构。Spring Cloud并没有重复制造轮子,它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来,通过Spring Boot风格...

    SpringCloud微服务架构

    • 什么是微服务架构
      微服务一词来自Martin Fowler(马丁福勒)和James Lewis的Microservices一文 微服务是一种架构风格,
      将单体应用划分为小型的服务单元 微服务之间采用HTTP的API进行资源访问和操作或者RPC的方式进行
      通信
      点击原文链接
    • 微服务的特点及适用场景
      1、微服务的特点
      围绕业务进行服务拆分 每个服务都是独立进程 服务之间采用轻量级通信协议(HTTP REST通信) 去中心化管理,每个微服务可以采用各自的语言进行开发
      2、微服务不适用的场景
      系统中包含很多强事务场景的(微服务下,是采用柔性事务的方式,即最终一致性实现分布式事务) 业务相对稳定,迭代周期长 访问压力不大,可用性要求不高
    • 什么是Spring Cloud
      SpringCloud是一系列主流框架的集合。 Spring并没有重复造轮子,只是将目前各个成熟,经得起考验的服务框架组合起来,经过封装之后,让用户以SpringBoot的风格进行开发,屏蔽了复杂的配置和实现原理,给用户提供的一套简单易懂,易部署,易维护的分布式系统开发工具集。
      SpringCloud解决了什么问题? 采用SpringBoot的开发便利性,实现了分布式系统基础设施的开发 比如,服务注册与发现中心(注册中心),负载均衡,熔断,配置中心,网关,消息总线,链路监控等等。做到独立部署,可方便进行水平扩展,独立访问等特点。
    • Spring Cloud主要学习什么
      Netflix Eureka(尤里卡):基于REST服务的分布式中间件,主要用于服务的注册和发现 Feign( 美 [fen]):一个REST客户端,简化WebService客户端的开发
      Ribbon(美 [ˈrɪbən]):负载均衡框架,在微服务集群中为各个客户端的通信提供支持,主要实现中间层应用程序的负载均衡 Hystrix( 美 [hɪst’rɪks] ):容错框架,通过添加延迟阈值及容错的逻辑,帮助我们控制分布式系统间组件的交互Zuul,SpringCloud Gateway:服务网关,为微服务集群提供代理,过滤,路由等功能
      其他 SpringCloud Config:管理集群中的配置文件,统一配置中心 SpringCloud Sleuth:服务跟踪框架,可以跟Zipkin,Apache HTrace和ELK等数据分析,服务跟踪系统进行整合 SpringCloud Stream:用于构建消息驱动的微服务架构 SpringCloud Bus:连接各种消息代理的集群消息总线。
      如下图:
      (注:以上介绍的一些组件属于过时组件,但是它们也是历史遗留下来产物,并不是不能用,而是有更好的代替)
      初步说明各个组件的分工(目前建议使用的组件)
    展开全文
  • 微服务架构

    千次阅读 2016-08-07 20:37:04
    微服务架构 微服务是一项在云中部署应用和服务的新技术。大部分围绕微服务的争论都集中在容器或其他技术是否能很好的实施微服务,而红帽说API应该是重点。 概念 编辑 微服务可以在“自己的程序”中运行...

    微服务架构

    微服务是一项在云中部署应用和服务的新技术。大部分围绕微服务的争论都集中在容器或其他技术是否能很好的实施微服务,而红帽说API应该是重点。

    概念

    编辑
    微服务可以在“自己的程序”中运行,并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构(在现有系统中分布一个API)区分开来。在服务公开中,许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能,那么就必须缩小进程范围。在微服务架构中,只需要在特定的某种服务中增加所需功能,而不影响整体进程。
    微服务不需要像普通服务那样成为一种独立的功能或者独立的资源。定义中称,微服务是需要与业务能力相匹配,这种说法完全正确。不幸的是,仍然意味着,如果能力模型粒度的设计是错误的,那么,我们就必须付出很多代价。如果你阅读了Fowler的整篇文章,你会发现,其中的指导建议是非常实用的。在决定将所有组件组合到一起时,开发人员需要非常确信这些组件都会有所改变,并且规模也会发生变化。服务粒度越粗,就越难以符合规定原则。服务粒度越细,就越能够灵活地降低变化和负载所带来的影响。然而,利弊之间的权衡过程是非常复杂的,我们要在配置和资金模型的基础上考虑到基础设施的成本问题。 [1]  

    现状

    编辑
    微服务作为一项在云中部署应用和服务的新技术已成为当下最新的热门话题。但大部分围绕微服务的争论都集中在容器或其他技术是否能很好的实施微服务,而红帽说API应该是重点。
    企业和服务提供商正在寻找更好的方法将应用程序部署在云环境中,微服务被认为是未来的方向。通过将应用和服务分解成更小的、松散耦合的组件,它们可以更加容易升级和扩展,理论上是这样。 [2]  

    特点

    编辑
    微服务的基本思想在于考虑围绕着业务领域组件来创建应用,这些就应用可独立地进行开发、管理和加速。在分散的组件中使用微服务云架构和平台使部署、管理和服务功能交付变得更加简单。
    微服务是利用组织的服务投资组合,然后基于业务领域功能分解它们,在看到服务投资组合之前,它还是一个业务领域。
    微服务这一概念出现于2012年,是因软件作者Martin Fowler而流行,他承认这并没有精确地定义出这一架构形式,虽然围绕业务能力、自动化部署、终端智能以及语言和数据的分散控制有一些常见的特性。 [3]  

    主流微服务平台

    编辑
    开源工作流平台 “Imixs-Workflow“发布了一款新的微服务架构,作为工作流来管理解决方案。Imixs的微服务( Imixs-Microservice)提供了一个工作流封装成微服务架构。这一服务可以独立于其背后的技术,绑定的任何业务应用中去。这允许业务应用改变业务逻辑的时,不用更改任何代码。这业务目标可以通过工作流模型控制。
    Imixs的微服务是基于Imixs的工作流引擎( Imixs-Workflow Engine)的复杂功能构建的,它可以以多种不同的方法来控制业务数据。Imixs的微服务可以发送电子邮件推送消息、日志业务交换,还可以确保所有类型业务数据的安全。
    Imixs的工作流模型可以给业务处理模型(Imixs-Workflow Modeller)中的每琴单独状态设计一个ACL。这许可了高度复杂的业务应用程序,并在每个流程实例周围驻起了安全层。 [4]  

    微服务架构开发工具

    编辑
    Seneca是构建微服务框架的工具,然后把它们构建到测试和部署的devops工作流中。构建和部署基于服务的应用程序都很好,但却无法维护,这一点很折磨人。还要在服务周围实现一些 持续交付模型的形式,然后使用它来管理并发布更新——这是一个比编写代码理棘手的问题。
    使用微服务构建现代化应用程序是很有意义的,因为它让你既利用了扩展横向扩展架构,也利用纵向扩展架构;还额外得到API的组合,且在整个业务中可重复利用。可能,每一分钟构都在交付新服务,这样你就必须拥有一个敏捷的且响应的应用程序平台,这一平台一直在不断改进中。 [5]  
    展开全文
  • Spring cloud作为当下主流的微服务框架,让我们实现微服务架构简单快捷,Spring cloud中各个组件在微服务架构中扮演的角色如下图所示,黑线表示注释说明,蓝线由A指向B,表示B从A处获取服务。 Spring cloud组成...
  • Spring cloud作为当下主流的微服务框架,让我们实现微服务架构简单快捷,Spring cloud中各个组件在微服务架构中扮演的角色如下图所示,黑线表示注释说明,蓝线由A指向B,表示B从A处获取服务。 Spri...
  • 7个点说清楚spring cloud微服务架构

    千次阅读 2019-11-14 21:29:46
    spring cloud作为当下主流的微服务框架,让我们实现微服务架构简单快捷,spring cloud中各个组件在微服务架构中扮演的角色如下图所示,黑线表示注释说明,蓝线由A指向B,表示B从A处获取服务。 spring cloud组成的...
  • Spring cloud作为当下主流的微服务框架,让我们实现微服务架构简单快捷,Spring cloud中各个组件在微服务架构中扮演的角色如下图所示,黑线表示注释说明,蓝线由A指向B,表示B从A处获取服务。 Spring cloud组成的...
  • 一张图了解Spring Cloud微服务架构

    千次阅读 2019-06-10 11:32:50
    Spring Cloud作为当下主流的微服务框架,可以让我们更简单快捷地实现微服务架构。Spring Cloud并没有重复制造轮子,它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来,通过Spring Boot风格...
  • Spring Cloud 的微服务架构 前言 Spring Cloud 微服务总体架构图 名词理解: Sleuth-链路跟踪: 为服务之间调用提供链路追踪。通过Sleuth可以很清楚的了解到一个服务请求经过了哪些服务,每个服务处理花费了多长...
  • Spring Cloud作为当下主流的微服务框架,可以让我们更简单快捷地实现微服务架构。Spring Cloud并没有重复制造轮子,它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来,通过Spring Boot风格...
  • .Net Core3.1 微服务架构技术栈

    千次阅读 2020-04-12 19:24:32
    微服务架构相对的,叫单体架构。这是我们最熟悉的开发方式,就是一个项目搞定业务全过程,在同一个进程里面完成。随着业务发展,数据量和并发上去了,一般会选择右边的垂直拆分,拆分后的每个系统,依旧是单体架构...
  • 微服务架构技术栈

    2020-05-21 21:40:59
    微服务架构相对的,叫单体架构。这是我们最熟悉的开发方式,就是一个项目搞定业务全过程,在同一个进程里面完成。随着业务发展,数据量和并发上去了,一般会选择右边的垂直拆分,拆分后的每个系统,依旧是单体架构...
  • Spring Cloud作为当下主流的微服务框架,可以让我们更简单快捷地实现微服务架构。Spring Cloud并没有重复制造轮子,它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来,通过Spring Boot风格...
  • 当下互联网行业飞速发展,快速的业务更新和产品迭代也给系统开发过程和模式带来新的挑战。围绕来自团队外部和内部的变化和...想要实现微服务架构,需要明确微服务的设计原理和架构,也需要掌握相应的技术体系和实践...
  • Spring Cloud作为当下主流的微服务框架,可以让我们更简单快捷地实现微服务架构。Spring Cloud并没有重复制造轮子,它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来,通过Spring Boot风格...
  • Spring Cloud作为当下主流的微服务框架,可以让我们更简单快捷地实现微服务架构。Spring Cloud并没有重复制造轮子,它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来,通过Spring Boot风格...
  • 点击上方“程序猿技术大咖”,关注并选择“设为星标”回复“加群”获取入群讨论资格!一、前言为了实现基于微服务开发的产品,或者说为了将单体应用重构为微服务架构时,将面临着众多技术框架的选择。大...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,619
精华内容 647
关键字:

当下主流微服务架构