我们先来关注下微服务的各种技术栈的优缺点。
1、Spring Cloud
为开发人员提供了用于构建MSA的工具,例如:配置中心、服务发现、断路器、路由等。它是基于Java的Netflix OSS库构建的。
关于如何使用Spring Cloud构建一个微服务架构,推荐您阅读:Microservice Architectures With Spring Cloud and Docker,相关项目架构图如下:
1.1、优点
- Spring技术栈,快速上手,开箱即用:Spring平台提供了统一编程模型,以及Spring Boot快速创建应用程序的功能,为开发人员提供了出色的微服务开发套件,仅仅需要很少的配置,就可以创建应用;
- 组件库丰富;
- 不同Spring Cloud组件可以很好的集成工作,一切基于注释驱动,易于开发,感觉就像是Java开发者的天堂。
1.2、缺点
- 仅限于Java。我们前面提到MSA架构的魅力在于能够在需要时修改技术栈,库甚至语言的。Spring Cloud则无法做到这一点。Netflix的Prana项目中使用了边车模式,通过HTTP调用可以在系统中集成非JVM的应用。通过HTTP与Prana进行跨进程通信,使得用其他语言编写的应用程序或Memcached、Spark和Hadoop等服务能够利用Netflix OSS库提供的特性,而不必为目标语言或平台重新编写库;
- Java程序员承担了太多的责任,服务发现、负载均衡、配置中心均需要单独部署,而且我们要保证高可用,除了实现服务功能,我们还必须构建和管理一个微服务平台;
- 不能覆盖MSA整个生命周期:微服务平台部分必备功能缺失,自动化部署、调度、资源管理、进程隔离、自我修复等仍然是一个问题。我们仍然需要引入Kubernetes或者Cloud Foundry来解决此类问题。
2、Dubbo
其实dubbo只是一个rpc框架,其架构如下(来源于官方网站[1]):
调用关系说明
- 服务容器负责启动,加载,运行服务提供者。
- 服务提供者在启动时,向注册中心
注册
自己提供的服务。- 服务消费者在启动时,向注册中心
订阅
自己所需的服务。- 注册中心返回服务提供者地址列表给消费者,如果有变更,注册中心将基于
长连接
推送变更数据给消费者。- 服务消费者,从提供者地址列表中,基于
软负载均衡算法
,选一台提供者进行调用,如果调用失败,再选另一台调用。- 服务消费者和提供者,在内存中累计调用次数和调用时间,定时每分钟发送一次统计数据到
监控中心
。
其提供了Metrics监控,服务发现和负载均衡,rpc调用,其实不能算是一个MSA体系,不过后来阿里整合了Spring Cloud,推出了Spring Cloud Alibaba
,作为微服务开发的一站式解决方案。其中包含了Dubbo Spring Cloud
。
由于 Dubbo Spring Cloud
构建在原生的 Spring Cloud 之上,其服务治理方面的能力可认为是 Spring Cloud Plus,不仅完全覆盖 Spring Cloud 原生特性,而且提供更为稳定和成熟的实现:
- 服务限流降级:默认支持 WebServlet、WebFlux, OpenFeign、RestTemplate、Spring Cloud Gateway, Zuul, Dubbo 和 RocketMQ 限流降级功能的接入,可以在运行时通过控制台实时修改限流降级规则,还支持查看限流降级 Metrics 监控。
- 服务注册与发现:适配 Spring Cloud 服务注册与发现标准,默认集成了 Ribbon 的支持。
- 分布式配置管理:支持分布式系统中的外部化配置,配置更改时自动刷新。
- 消息驱动能力:基于 Spring Cloud Stream 为微服务应用构建消息驱动能力。
- 分布式事务:使用 @GlobalTransactional 注解, 高效并且对业务零侵入地解决分布式事务问题。。
- 阿里云对象存储:阿里云提供的海量、安全、低成本、高可靠的云存储服务。支持在任何应用、任何时间、任何地点存储和访问任意类型的数据。
- 分布式任务调度:提供秒级、精准、高可靠、高可用的定时(基于 Cron 表达式)任务调度服务。同时提供分布式的任务执行模型,如网格任务。网格任务支持海量子任务均匀分配到所有 Worker(schedulerx-client)上执行。
- 阿里云短信服务:覆盖全球的短信服务,友好、高效、智能的互联化通讯能力,帮助企业迅速搭建客户触达通道。
3、Kubernetes
Kubernetes是一个开源系统,用于应用程序自动化容器部署、扩展和管理。它支持多语言,并提供了用于配置,运行,扩展和管理分布式系统的原语。
优点
- 多语言和通用容器管理平台,能够运行云原生和传统容器化应用程序;
- 易于构建跨团队的平台:提供的服务(例如配置管理,服务发现,负载平衡,指标收集,日志聚合)可以通过多种语言来使用;
- 解决了更多MSA的问题:除了提供运行时服务外,Kubernetes还允许您置备环境、设置资源约束、RBAC、管理应用程序生命周期、启用自动缩放和自我修复等;
- 社区活跃,技术发展迅猛;
缺点
- 具有通用化服务和原语的平台,没有针对特定语言或平台进行优化,上手比较困难;
- 不是以开发人员未中心的平台,致力于打造具有DevOps意识的IT人员使用,手动安装高可用的Kubernetes集群需要繁琐的操作和配置;
- 是一个较新的平台,仍然在发展,每个版本都会新增很多特性,新功能比较难跟上;但是其提供更多API是可扩展的,并且向后兼容;
下面列一个表格总结下
技术栈 | 优点 | 缺点 |
---|---|---|
Dubbo | 阿里背书; 成熟稳定; RPC高性能; 流量治理; |
耦合性高; 只支持Java; 国外社区小 |
Spring Cloud | Spring技术栈,快速上手,开箱即用; 组件库丰富; 不同Spring Cloud组件可以很好的集成工作,一切基于注释驱动 |
仅限于Java Java程序员承担了太多的责任 不能覆盖MSA整个生命周期 |
Kubernetes | 多语言和通用性; 易于构建跨团队的平台 覆盖MSA整个生命周期; 社区活跃; |
服务和原语通用化,技术门槛高; 配置繁琐,偏DevOps和运维; 平台快速发展,变化快; |
4、MSA技术选型
Dubbo只是一个RPC框架,提供的功能不能覆盖整个MSA生命周期。
Spring Cloud是开发人员友好的平台,可快速上手。
而Kubernetes是DevOps友好的,具有陡峭的学习曲线,但提供了更多的微服务问题解决方案。
Spring Cloud在JVM内部非常强大,而Kubernetes在管理这些JVM方面非常强大。
能力 | Dubbo | Spring Cloud | Kubernetes | 其他技术 |
---|---|---|---|---|
分布式调用链追踪 | / | Spring Cloud Sleuth | Zipkin,Skywalking | |
Metrics监控 | Dubbo Admin/Monitor | Actuator/MicroMeter | metrics-server | Prometheus,Grafana |
集中式的日志管理 | ELK | ELK | EFK | |
任务管理 | Spring Batch | CronJob | ElasticJob/XXL-JOB | |
服务发现和负载均衡 | zk/Nacos + client | Eureka + Ribbon | Service | |
API网关 | / | zuul | Ingress | |
配置管理 | Diamond/Nacos | Spring Cloud Config | ConfigMaps/Secrets | |
应用打包 | Jar/War | Jar/War | Docker Image/Helm | |
自动伸缩和自愈 | / | / | Pod/Cluster Autoscaler,Scheduler | |
发布和调度 | / | / | Deployment strategy,A/B,Canary,Scheduler strategy | |
进程隔离 | / | / | Docker,Pods | |
环境管理 | / | / | Namespaces,Authorization | |
资源配额 | / | / | CPU and memory limits,Namespace resource quotas | |
IaaS | GCE,Azure,CenturyLink,VMWare,Openstack |
根据以上对比,我们想要搭建一个完整的微服务体系架构,有很多技术可以选择的。那么究竟应该如何选择呢
下面是推荐技术选型方案:
- 如果是新团队做技术选型,建议直接上Kubernetes,当然,你可以采用Spring Boot。为了提高内部服务调用的效率,可以整合dubbo,但是建议采用Kubernetes内置的服务发现和负载均衡,也就是引入的外部技术要最小化;
- 中小企业可能没有人力成本去自建Kubernetes平台,可以采用
公有云
; - 尽量不要混搭,会增加维护成本;
- 针对历史采用了Dubbo的项目,尽量迁移到
Dubbo Spring Cloud
完善其他组件。使用Dubbo Spring Cloud[2],配合Kubernetes实现DevOps系统。内部调用通过Dubbo RPC进行,提高效率。
技术方案选型归纳如下: