前期回顾:
微服务架构下的核心话题 (一):微服务架构下各种项目的顺势崛起
微服务架构下的核心话题 (二):微服务架构的设计原则和核心话题html
为了实现基于微服务开发的产品,或者说为了将单体应用重构为微服务架构时,将面临着众多技术框架的选择。大公司每每会有专门的部门或团队来负责自主研发本身的框架,以知足产品的须要,可是对于通常的中小型企业,选择合适的开源框架就显得更接地气了。本章将简单介绍微服务中,在技术选型时须要注意哪些原则,一些经常使用的开源技术框架,但愿可以为你们在进行技术选型、调研时提供一些思路方向。前端
笔者面试过不少程序员,一说起微服务,就会具体说道Spring Boot、Spring Cloud,而后就是“背诵”各类具体的用法和配置文件。并非说这样不对,但咱们更但愿知道的是这些技术框架的原理,为何选择它,它与其余相似框架又有何不一样呢。nginx
至于一个技术框架该怎么用,它适用于什么场景,笔者建议能够直接阅读官方或对应的github上的文档,有须要时还能够阅读下关注点的源码,这样对正确的理解它,是颇有必要的,毕竟官方发布的东西是相对权威的,其余地方的资料或许存在片面性,对你们的使用、理解存在必定的误导。(这只是笔者对你们在技术选型时,查阅资料的一些建议)git
在软件开发领域,几乎天天都有新的技术框架诞生、更新,一些新的概念更是层出不穷,技术选型时,不免让人无从抉择。 对于技术选型,我我的有如下几点建议:程序员
在微服务架构中,各种组件/技术不少不少,但并不意味着全部的都应该引入你的项目,假若单纯为了覆盖全技术栈或组件而所有引入,这将是一种很不明智的选择。后续将会成为你项目的累赘,让你苦不堪言。github
只要你记住这六个字:“有需求,再引入”,就OK了。伴随着项目体系架构的完善、功能的健全,当有某方面的需求时,在逐步考虑是否引入某些技术组件。web
“一个新项目里最好不要使用超过30%的新技术”,我以为这句话是有必定道理的。对于你彻底不知道、不了解的技术,你是没法预估、掌控在使用过程当中会出现的任何风险,一旦出现问题,短期内解决不了,你将会变得很难堪。面试
在这里不是说拒绝使用、接触新技术,新技术是值得你们去追捧、了解、学习,一些新技术在很大程度上能给咱们带来史无前例的利处,解决其余技术框架解决不了的问题。这里所说的“新技术”,是指没有通过充分的考察、技术验证、存在种种疑惑的技术,而是一味的拿来主义,这样的风险可想而知。spring
确保选择的技术,是业界使用最多的、被你们承认的技术,即便出现了问题,也能应对自如。至少在团队内部小范围是很是承认的。docker
GitHub上star的数量是一个重要指标,同时参考近年来代码、文档、issues等更新频率,各大技术博客是否有相关技术分享记载,这些都是可以说明该技术是否活跃、受欢迎程度、使用人群多少等。
拥有强大社区支持的技术,在选型后,假若使用出现疑问、问题、bug等,可以有地方可提、可修复、可深究探讨,毕竟如今的技术社区都是足够开放的。
慎选我的开源的技术框架、组件等,里面到底有多少坑,没几我的能说清楚的,何况说不定哪天就不复存在了呢。
任何技术的出发点都是为最终业务而服务的,不一样业务、不一样项目规模,对技术的要求指标都是不一样的。处于初创期的业务,选型的基准是相对灵活,毕竟业务相对简单,支撑业务不是很大,只要够用、开发效率足够高就好。处于复杂业务而重构的项目,选型就需谨慎,每每伴随着一些复杂需求诞生、规模大小的不肯定性,不得不考虑选型技术可能伴随着一些小修小补或者螺旋式上升的重构,则需选型便于适配、切换、替换,耦合度低的技术。
正由于技术选型和业务相关,咱们可以观察到一些很明显的现象:新技术每每被早期创业团队或大公司的新兴业务使用;中大型公司的核心业务则更倾向于用一些稳定了几年的技术;一个公司若是长期使用一种技术,就会倾向于一直使用下去,甚至连版本都不更新的使用下去。
学会从业务端思考。首先咱们须要充分地理解业务,理解用户需求,理解当下须要解决的首要问题,以及可能的风险有哪些,再将目标进行分解,进行具体的技术选型、模型设计、架构设计。
对于未经验证的新技术、新理念的引入必定要慎重,必定要在全方位的验证事后,再大规模的使用,最终肯定选型。新技术、新理念的出现,天然有它的诱惑,慎重并不表明保守,技术老是在不断前进,拥抱变化自己没有问题,可是引入不成熟的技术看似能带来短时间的收益,可是它的风险或者是后期的成本可能远远大于收益。
验证后,才有说服力,用着更放心。
每种技术架构都有其优缺点,存在即合理,不一样的业务场景使用不一样的应用架构,技术框架,不必定说最新的架构、技术就是最适合你的。
微服务架构中常说起到的主要技术框架选型以下表所示,本文后面将基于此展开说明对比。
类型 | 框架 |
---|---|
服务治理 | Dubbo、Spring Cloud |
API网关 | Zuul、traefik、OpenResty、Kong |
服务注册与发现 | Zookeeper、Eureka、Consul、etcd |
配置中心 | Spring Cloud Config、Apollo、Nacos |
链路追踪、监控 | Zipkin、CAT |
Dubbo是一款高性能、轻量级的开源JAVA RPC框架,以及SOA服务治理方案。简单的说,Dubbo就是个服务框架,说白了就是个远程服务调用的分布式框架。它提供了三大核心能力:面向接口的远程方法调用、智能容错和负载均衡、以及服务自动注册和发现,很容易和Spring框架无缝集成。
Dubbo逻辑架构以下图所示:
Dubbo特色:
在现有的微服务架构下,Dubbo只能说是一个服务治理框架,或者说是一个RPC框架,是以接口为粒度,一个接口类就就是一个服务。若是直接用Dubbo来实现微服务架构,还缺乏如下几个功能:
Spring Cloud是目前最主流的微服务架构落地首选方案之一,是基于Spring Boot实现的开源框架,是一个全家桶,是微服务的总体技术栈。
Spring Boot是Spring 的一套快速配置脚手架,使用默认大于配置的理念,用于快速开发单个微服务。
它为服务注册发现、动态路由、负载均衡、配置管理、消息总线、熔断器、分布式链路追踪、大数据操做等提供了简单的实现,让咱们能够更简洁的使用它。
正如咱们前面说过的,微服务是能够独立部署、水平扩展、独立访问的服务单元,而Spring Cloud就是这些微服务的“大管家”,采用了微服务这种架构以后,项目的数量会很是多,调用链路复杂,从而管理成了很大的问题,而Spring Cloud框架偏偏提供了各类组件用于管理和治理微服务。理所应当的,就成了你们首选框架了。
Spring Cloud的总体架构以下图所示,提供一站式的微服务架构解决方案。
使用Spring Cloud来构建微服务架构能够省去你整合各家技术的成本,Spring Cloud为咱们构建微服务架构提供了一站式的解决方案,就比如当初Spring诞生是为解决EJB企业应用开发的众多问题而提供的一站式轻量级企业应用开发解决方案同样,随着使用Spring Cloud的产品数量增长,Spring Cloud在微服务架构中已一统江湖。
下面是Spring Cloud的完整技术栈,看完你就知道它为啥会在微服务架构中一统江湖了。
Dubbo | Spring Cloud | |
---|---|---|
功能/专一点 | 专一于RPC和服务治理 | 微服务架构生态、技术栈 |
通讯协议 | RPC(远程方法调用)协议 | REST/HTTP(已有组件支持gRPC协议) |
服务注册与发现 | Zookeeper(CP) | Eureka(AP) |
负载均衡 | 软负载均衡(Random/RoundRobin) | Ribbon |
容错机制 | 有 | 有 |
熔断机制 | 无 | Hystrix |
配置中心 | 依赖外部组件,如:Nacos | Spring Cloud Config |
网关 | 无 | zuul,Gateway |
服务监控 | Dubbo + Monitor | Hystrix + Turbine、Spring Boot Admin(SBA) |
链路监控 | 无 | Sleuth + Zipkin |
多语言支持 | 只支持Java | REST支持多语言 |
社区活跃 | 高(依靠阿里) | 高(依靠Spring) |
消息总线 | 无 | Spring Cloud Bus |
数据流 | 无 | Spring Cloud Stream |
批量任务 | 无 | Spring Cloud Task |
…… | …… | …… |
经过上表对比,很容易发现Spring Cloud拥有不少的项目模块,包含了微服务系统的方方面面。Dubbo是一个很是优秀的服务治理和服务调用框架,但缺乏不少功能模块,例如网关、链路追踪等。在项目模块上,Spring Cloud占据着更大的优点。对比并非否认谁,推崇谁,只是说明在不一样场景下,有利优劣,需客观来看。
若是仅关注于服务治理的这个层面,Dubbo其实还优于Spring Cloud不少:
若是对效率有极高的要求建议使用Dubbo,相对比RPC的效率会比Restful高不少,若是选择微服务架构去重构整个技术体系,那么 Spring Cloud是当仁不让之选,它能够说是目前最好的微服务框架没有之一,而且能够断言,未来Dubbo能够很好的整合到Spring Cloud中。
API网关做为微服务中全部服务的惟一入口,省得业界各种成熟的技术框架组件,在进行技术选型时,须要特别考虑是否拥有如下特性:
Zuul做为Spring Cloud中的核心组件之一,充当API网关的重要角色,全部请求均可以经过Zuul达到后端的应用程序、服务。Zuul提供了动态路由、监控、弹性负载和安全等特性,其核心是一系列的Filter,其做用相似于Servlet框架中的Filter,或者AOP。
Zuul底层利用各类Filter实现了以下功能:
基于上述这些功能特性,使得Zuul做为API网关的不二之选。
Zuul的逻辑架构以下图所示:
Zuul的过滤器之间是不直接通讯的,而是经过一个RequestContext的类来进行数据传统,RequestContext继承ConcurrentHashMap,使用ThreadLocal变量来记录每一个Request须要传递的数据。
Zuul的过滤器是由Groovy来实现的,这些过滤器文件被存放在Zuul Server的特定目录下,Zuul会按期轮询这些目录,修改过的过滤器会动态加载到Zuul Server中,以便过滤请求使用。
Zuul的大部分功能都是经过过滤器来实现的,其中定义了4种标准的过滤器类型(pre、route、post、error),以知足应用于请求的不一样阶段。
(若是想更清晰深刻的了解Zuul,能够参考上图的Zuul逻辑架构图,并结合Zuul源码深刻研究下。)
在了解traefik以前,不妨先看看它的总体架构图,以下所示:
从上图不难看出,traefik充当了HTTP反向代理的角色,使得发布的服务变得轻松有趣。在微服务中,实质上是一个为了让部署微服务变得更加便捷而诞生的HTTP反向代理、负载均衡工具。,它支持多种后台 (Docker, Swarm, Kubernetes, Marathon, Mesos, Consul, Etcd, Zookeeper, BoltDB, Rest API, file…) 来自动化、动态的应用它的配置文件设置。
除了众多功能以外,traefik的不同凡响之处还在于它会自动发现适合您服务的配置。无需维护和同步单独的配置文件,一切都会自动,实时地进行(无需从新启动,不会中断链接)。使用traefik后,你能够将更多的精力、时间花费在开发和部署上面,而不是在配置和维护其工做状态上。
特性:
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等都进行一致的高性能响应。
Kong是一个在Nginx中运行的Lua应用程序,而且能够经过lua-nginx模块实现,Kong不是用这个模块编译Nginx,而是与OpenResty一块儿发布,OpenResty已经包含了lua-nginx-module,OpenResty不是 Nginx的分支,而是一组扩展功能的模块。
是一个Api Gateway,经过插件的形式提供负载均衡,日志记录,身份验证,速率限制,转换等功能。能够很轻松扩展功能,模块化,能够运行在任何基础设施上。
它的核心是实现数据库抽象,路由和插件管理,插件能够存在于单独的代码库中,而且能够在几行代码中注入到请求生命周期的任何位置。很方便地为路由和服务提供各类插件,网关所须要的基本特性,Kong都如数支持:
上面这些特性中,反复说起了Kong背后的OpenResty,实际上,使用 Kong以后,Nginx能够彻底摒弃,由于Kong的功能是Nginx的父集。
Zuul | traefik | OpenResty | Kong | |
---|---|---|---|---|
功能/用途 | Spring Cloud中的核心组件之一,充当API网关的角色 | 支持动态配置的HTTP反向代理和负载均衡器 | 基于Nginx与Lua的高性能Web平台,服务代理/网关 | 企业级API管理 |
学习成本 | 简单 | 简单 | 适中 | 适中 |
社区 | 开源、活跃 | 开源 | 开源 | 开源/企业版 |
扩展性 | 可扩展,本身实现Filter | 可扩展,本身实现 | 可扩展,插件 | 可扩展, 插件 |
服务发现 | 动态 | 动态 | 动态 | 动态 |
通讯协议 | Restful | http,https,grpc,websocket | http,https,websocket | http,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)配置管理流程
配置的权限管控、灰度发布、版本管理、格式检验和安全配置等一系列的配置管理相关的特性也是配置中心不可获取的一部分。(这也算是配置中心的高级特性做用)
Spring Cloud Config做为Spring Cloud中的一个组件,其功能开放,可开发性强,常是各种配置中心自我研发的基石。
从Spring Cloud Config的源码(spring-cloud-config-server)中,能够看出目前支持本地存储、Git仓库存储、SVN仓库存储、数据库存储方式,其余存储方式可参考源码自行实现便可。
以Git存储方式为例说明,Spring Cloud Config包含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有数据的一致性问题,能够经过如下的方式来支持高可用:
Apollo(阿波罗)是携程框架部门研发的分布式配置中心,可以集中化管理应用不一样环境、不一样集群的配置,配置修改后可以实时推送到应用端,而且具有规范的权限、流程治理等特性,适用于微服务配置管理场景。
Apollo分为MySQL,Config Service,Admin Service,Portal四个模块:
本地测试Config Service,Admin Service,Portal三个模块能够合并一块儿部署,MySQL单独安装并建立须要的表结构。在生产环境使用Apollo,Portal能够两个节点单独部署,稳定性要求没那么高的话,Config Service和Admin Service能够部署在一块儿,数据库支持主备容灾。
Nacos是一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。这正是Nacos官方给出的定义:
an easy-to-use dynamic service discovery, configuration and service management platform for building cloud native applications.
核心功能:
Nacos部署须要Nacos Service和MySQL:
单机模式下,Nacos可使用嵌入式数据库部署一个节点,就能启动。若是对MySQL比较熟悉,想要了解总体数据流向,能够安装MySQL提供给Nacos数据持久化服务。生产环境使用Nacos,Nacos服务须要至少部署三个节点,再加上MySQL主备。
总体来看,Nacos的部署结构比较简单,运维成本较低。Apollo部署组件较多,运维成本比Nacos高。Spring Cloud Config易于定制化二次开发,生产高可用的成本最高。
Spring Cloud Config | Apollo | Nacos | |
---|---|---|---|
开源时间 | 2014.9 | 2016.5 | 2018.6 |
实时生效(推送) | 基于Spring Cloud Bus完成 | 基于HTTP轮询(1s内) | 基于HTTP轮询(1s内) |
版本管理 | 支持(Git、SVN) | 支持 | 支持 |
配置回滚 | 支持(Git、SVN) | 支持 | 支持 |
灰度发布 | 支持 | 支持 | 待支持 |
权限管理 | 支持 | 支持 | 待支持 |
集群 | 支持 | 支持 | 支持 |
多环境 | 支持 | 支持 | 支持 |
监听查询 | 支持 | 支持 | 支持 |
多语言 | 只支持Java | Java、Go、C++、Python、PHP | Java、Python、Nodejs |
单机部署 | Config-Server + Git + Spring Cloud Bus(实时更新推送) | Apollo-quickstart + MySQL | Nacos单节点 |
分布式部署 | Config-Server(2) + Git + MQ (部署复杂) | Config(2) + Admin(2) + Portal(2) + MySQL (部署复杂) | Nacos(3) + MySQL(部署简单) |
配置格式校验 | 不支持 | 支持 | 支持 |
通讯协议 | HTTP、AMQP | HTTP | HTTP |
数据一致性 | 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/
欢迎微信扫码下面二维码,关注微信公众号【程序猿技术大咖】,进行更多交流学习!