技术栈选型之微服务公共关注点及Dubbo、Spring Cloud和K8s横向比对

前言

目前 Dubbo、Spring Cloud、K8s是开发微服务的三个主流开源框架和平台,那么Dubbo、Spring Cloud、K8s到底该如何选型?他们分别有什么样的适用场景?有什么异同?

如果缺乏足够的经验,对微服务架构原理以及整个行业服务化演进的历史缺乏了解。那么对这三个产品该如何选择,的确会感到困惑,服务框架和平台的选择是搭建微服务架构的一个基础。好比构建一个大厦的一个基建材料,它的重要性是不言而喻的。

特别值得一提的是Dubbo、Spring Cloud、K8s分别是阿里巴巴、Netflix还有谷歌三家互联网公司,他们在应对大规模微服务开发带来的挑战时,各自独立演进出来的解决方案。换句话说,Dubbo、Spring Cloud、K8s,都是对同一个问题,也就是分布式微服务开发框架的一个解。

都是对同一个问题的解,只不过三家的解法侧重点和抽象级别不太一样

因为都是对同一个问题的解,所以这些产品当中有部分功能是重叠的,而且可能还是排他的。

也就说,如果你选中了其中一家的产品,就不要随便混搭再选择其他家的产品。因为这三家都是自成一体的,虽然技术上可以做到把他们当中的两个甚至三个硬揉在一起。但是架构上会缺乏一致性,这时候你要同时维护多套体系,维护成本会变高。

所以对于互联网开发人员,尤其是架构师,应该对这三个产品有比较深入的理解。这样才能正确的做出选型决策,不至于在一开始打基础的时候就犯下方向性错误。

所以我们下面就来详细的剖析一下这三个产品如何选型,我们的 staffjoy 项目为什么选Spring Boot加上K8s。

微服务公共关注点

我们知道微服务最终的目标是实现业务价值,交付业务价值,但是为了让开发人员能够专注于业务交付,微服务需要底层基础设施的支撑,这些基础设施也称为微服务的公共关注点(common concerns)

我们解决微服务的技术问题,很多的时候就是在解决这些公共关注点的问题,我们具体来分析一下这些公共关注点。

6.微服务公共关注点

配置管理

第一个是配置管理,对微服务应用的可变参数进行配置;这些参数可以是启动期一次性配置的,比方说数据库连接字符串;也可以是运行期动态配置的,比方说调整缓存的过期时间、业务促销限购数量等等,这些是可以动态配置的。

服务发现和LB

第二个是服务发现和负载均衡(LB)。服务分布在不同的节点上,服务之间要相互调用,首先要定位找到对方,这个就是服务发现。他是微服务架构的基本问题。另外,服务一般以多实例方式部署,调用方需要以某种负载均衡的策略去访问目标服务实例,这就是LB负载均衡

弹性和容错

第三个关注点是弹性和容错分布式微服务通过网络互联,网络有可能会不稳定,服务实例有可能产生延迟、出错、甚至宕机。微服务系统必须具备弹性和容错能力,才能保障服务质量和用户体验

API管理

第四个关注点是API管理,这里主要指微服务系统对外暴露API。一般通过API网关进行管理,网关是微服务的大门,需要支持反向路由、安全鉴权、日志监控和限流容错等基本功能高级的网关还要支持AB测试、蓝绿和灰度测试等高级功能,这是API管理的范畴。

服务安全

第五个关注点是服务安全用户访问微服务首先需要认证。对某些敏感的服务进行操作还要进行鉴权,服务之间调用也需要一定的权限管控。

日志监控

第六个关注点是日志监控服务访问日志需要进行集中的采集、存储和分析,方便后续进一步的分析微服务的性能,甚至是用户的行为。

Metrics监控

第七个关注点是Metrics监控对微服务的调用需要进行Metrics埋点监控,Metrics监控既可以对服务的性能,包括调用量、延迟、错误数等等进行监控。也可以对重要的业务指标,如登录数、下单数进行监控。

调用链监控

第八个关注点是调用链监控。分布式微服务之间的依赖关系错综复杂,通过调用链监控,能够实时掌握微服务之间的依赖关系,服务之间调用的性能。出现问题的时候能够通过分析调用链,及时的进行排障。

调度和发布

第九个关注点是调度和发布。微服务最终是要发布到生产环境当中去的,目前推荐的微服务交付手段主要是容器云环境。容器云需要支持自动的容器资源调度和发布,高级的需要支持滚动发布,还有蓝绿发布这些高级的发布机制。

自愈和自动伸缩

第10个关注点是自愈和自动伸缩。云环境当中的节点有可能会宕机或者飘移,网络可能随机不稳定,恢复平台需要有自动侦测问题和自动恢复的能力,这个就是自愈,。也就是self-healing的能力。另外,用户流量可能会突发骤增,微服务平台理想的需要根据用户的流量的变化自动的伸缩,英文叫auto scaling,这样做可以节省硬件资源,同时又不影响用户体验。


如果把微服务的上述这些关注点,把它们抽象封装和沉淀下,最终产生的软件产品就是微服务开发框架或者说平台,那么Dubbo、Spring Cloud、K8s就是阿里巴巴、Netflix、谷歌这三家公司各自演进沉淀并且开源贡献给社区的解决方案。

7.Dubbo、Spring Cloud和K8s

在解决分布式微服务开发框架或者说平台的时候,他们三家给出的解法和侧重点不太一样,接下来做一个全面的横向比对,来分析一下这三家的产品有哪些不同点。

Dubbo、Spring Cloud和K8s横向比对

8.Dubbo、Spring Cloud和K8s横向比对

一、服务发现和负载均衡

服务发现和负载均衡是微服务的基本问题,三家都给出了解决方案:

  • Dubbo的服务发现主要是基于ZooKeeper来实现的,配合客户端做发现和负载均衡。阿里又推出了一个叫Nacos产品,它是一个更通用的服务发现产品,它的功能更像是Java版的Consul,长期可能会替换ZooKeeper成为Dubbo的首选服务发现机制。
  • Spring Cloud 他的服务发现主要引用了Netflix的Eureka配合Ribbon实现客户端发现和软负载
  • K8s他是直接在平台层来解决服务发现问题的。他直接在平台中引入了一个Service的抽象概念,屏蔽了底层服务发现和负载均衡的细节。让应用开发和服务框架都不需要关心底层服务发现的细节,这是K8s的做法。

二、API网关

  • 在这一层阿里没有开源相应的产品,实际上阿里内部是有网关的,不过他的设计和业务有耦合,所以不好开源。
  • Spring Cloud引入了Netflix的 Zuul 网关。Zuul是经过Netflix大流量考验的一个成熟产品。
  • 在K8s的体系当中,和网关对应的概念叫Ingress,他实际上定义了一些规范,具体可以采用各种实现,比方说有 nginx、envoy或者是traffic等等都可以做Ingress。

三、配置管理

  • 阿里推出的 Nacos 产品,他除了服务发现以外,也是具备配置管理的能力。
  • Spring Cloud它是有Spring Cloud Config的产品,实现比较简单,后端基于git进行配置管理的。
  • K8s它在平台层内置支持ConfigMaps,还有Secrets配置机制,他可以对接各种存储机制。

四、容错限流

  • 阿里开源了Sentinel的容错限流解决方案。这个是阿里自主创新,经过双十一考验的生产级的限流平台,可以对应用各个层级进行细粒度的流量控制。
  • Spring Cloud直接支持Netflix开源的Hystrix容错限流组件,Hystrix在Netflix平台稳定性方面发挥了巨大作用,它目前已经成为业界限流熔断的一个标配。
  • K8s它内置支持健康检查HealthCheck、启动就绪探针Probe这些容错机制,如果需要细粒度的流量控制,那么就需要引入 ServiceMesh 的机制进行配合。

五、日志监控

  • 在日志监控这块三家都没有单独的开源产品。
  • 不过社区已经有ELK,也就是Elasticsearch、logstash、Kibana这样的成熟的标配解决方案,三者都可以直接集成。
  • K8s它是推荐使用Fluentd进行日志监控,所以它是推荐集成EFK。

六、Metrics监控

  • Dubbo它内置集成的Admin、Monitor的工具进行服务调用性能的指标监控。
  • Spring Cloud支持 Actuator、MicroMeter这些机制,可以采集和暴露metrics指标,可以很方便的和Prometheus监控系统进行对接。
  • K8s支持Heapster采集K8s平台内部资源的性能指标,也可以很方便的对接Prometheus。如果需要进一步监控应用层性能指标,那么就需要引入ServiceMesh进行配合。

七、调用链监控

  • 阿里内部有一个调用链监控平台,原理和Dapper、ZipKin类似,不过没有开源。
  • Spring Cloud提供Spring Cloud Sleuth 可以和Zipkin调用链进行对接。
  • K8s推荐采用Uber开源的Jaeger进行调用链监控,也可以使用Zipkin进行调用链监控。

八、应用打包

  • Dubbo这块没有专门的标准,一般的Jar/War它都是支持的。
  • Spring Cloud它是支持嵌入式容器,加上 Uber Jar方式打包,他可以方便应用的发布和运行。
  • K8s它是直接支持容器镜像部署,它不关心容器内部的具体的应用形式。另外,K8s支持Helm这样的应用级的打包标准,可以实现应用商店这样的功能。

九、服务框架

  • Dubbo RPC:Duboo本质上的是一种二进制的RPC框架。它的消息协议比较紧凑,性能比较好,Dubbo也是可以扩展支持REST,可以参考当当的DubboX,它是对Dubbo的一个扩展。
  • Spring(Boot)REST:本质上的是一种HTTP REST的框架,它比较松散,比较简单,开发测试都是友好的。
  • 框架无关:K8s它是一个平台,它是具体的应用框架无关的,它只认容器,不同的语言栈,比方说Java、Go或者是Pythone、Ruby等等。这些框架都可以住在K8s里。具体的语言栈无关的是K8s,区别于其它两个框架的一个最大的亮点。

十、发布和调度

  • Dubbo 和 Spring Cloud 都没有单独的考虑,都是交给运维去解决。
  • K8s 它本身重点解决的问题就是服务发布和调度,所以它内置是支持Schedule 调度发布的能力的。

十一、自动伸缩和自愈

  • Dubbo 和 Spring Cloud 都没有单独的考虑,都是交给运维去解决。
  • K8s具备自动故障检测和自愈的能力。如果需要使用它的自动伸缩的话,需要引入额外的组件,完全实现自动伸缩的话,还是有一定的技术门槛的。

十二、进程隔离

  • Dubbo 和 Spring Cloud 都没有单独的考虑。
  • K8s它是通过容器进行进程隔离,同时,它引入了Pod,可以进一步对服务进行隔离。

十三、环境管理

  • Dubbo 和 Spring Cloud 都没有单独的考虑。
  • K8s支持 Namespace 进行逻辑隔离,可以实现多环境的,各个环境可以单独配置认证授权机制。

十四、资源配额

  • Dubbo 和 Spring Cloud 都没有单独的考虑。
  • K8s支持对cpu、memory进行使用量的限制,也支持namespace级别的配额管理。

十五、流量治理

  • 这里的流量治理主要是指高级的流量调度能力,或者说AB测试、蓝绿测试。
  • Dubbo 它是通过 ZooKeeper加上Client配合,它是支持一定的流量调度能力的。这块也是Dubbo区别Spring Cloud的一个亮点。
  • Spling Cloud在这块没有专门的解决方案。
  • K8s要支持流量治理需要引入Service Mesh进行配合。

Dubbo、Spring Cloud和K8s优势比对

9.Dubbo、Spring Cloud和K8s优势比对

Dubbo亮点:

  • Dubbo经过阿里大规模流量的冲击洗礼,它最大的亮点就是成熟稳定
  • 二进制RPC性能比较好,同时它开箱即用,在流量治理方面做的非常细致,有特色。
  • 它是一款具有中国特色的世界级的服务框架。

Dubbo不足:

  • 一个是历史比较久远,采用的技术栈有点老旧;另外,由于多年代码的堆积,整个框架变得有点臃肿。
  • 第二个是耦合性比较高,这个框架它是你要么全用,要么不用。不是那种可以组件化,灵活装配的框架;
  • 第三个不足是它仅限于JVM 语言栈。
  • 第四个不足Dubbo的流行主要是在国内,国外的社区是比较小的。

Spring Cloud 亮点

  • Spring Cloud 是 Spring 和 Netflix 开源的一个融合,同时吸纳了两者的优势。
  • Spring 框架有超过十年的历史,它也是开源界的一个传奇,Spring框架社区异常活跃。框架本身成熟灵活,开发者体验好,是它最大的亮点。背后又有Pivotal公司的专业支持,不断的完善和推陈出新。
  • Netflix OSS,是Netflix开源现代微服务架构大胆创新的产物。同时也经历了Netflix大流量冲击,Netfilx框架的一大亮点的是抽象和组件化做的比较好。它可以像搭积木一样,灵活组装微服务基础架构,而且可以替换。

Spling Cloud不足

  • 首先也是仅限于JVM语言栈,其它语言栈支持非常有限。
  • 另外,Spring Boot因为封装比较多,运行起来比较吃资源,尤其是跑在容器里的时候,占用的资源是比较多的。

K8s 优势

  • K8s 是从平台层解决微服务基础设施问题,它的抽象层级比较高。
  • 它一次性解决了服务自动化发布的难题,而且它做到了具体服务框架无关,可以容纳各种语言栈的框架。
  • 可以这样认为,就是说Dubbo、Spring Cloud ,仅仅解决了微服务基础设施的部分问题。
  • 那么,K8s 它是一个完整的微服务基础设施解决方案,K8s背后有谷歌支持,社区非常活跃,被认为是未来的数据中心操作系统,云原生应用的一个标配。

K8s 不足

  • 首先是它是一个更偏向于 DevOps 和运维的一个平台,它比较重,比较复杂,技术门槛相对比较高。
  • 一般的中小公司,技术能力不够的话可能hold不住,这是它的不足。

Dubbo 和 Spring Cloud 比喻

  • 我们首先把 Dubbo 和 Spring Cloud 来做一个比喻。
  • 如果把他们比作PC机,Dubbo更像是一个品牌机,一次性买好就可以用,一般不会替换内部的组件。
  • 那么 Sprinig Cloud ,它更像是一个组装机自己组装,而且可以灵活的替换。

Dubbo 和 Spring Cloud 是框架和组件,K8s它是一个平台。

架构风格比对:

  • 阿里他讲究实用,解决实际问题,追求高性能,设计上倾向于Only In One,就是全部打包在一起。
  • Netflix 讲究抽象组件化,系统可以灵活装配和扩展。
  • 谷歌 讲究体系化和平台化,抽象层次最高,它是对整个数据中心进行抽象打包。
  • 它更偏向于云架构的思想。就是要把应用容纳到基础设施当中去,而不是倒过来让基础设施去迎合应用,这是云架构的思想。

建议:

  • 就是到底该怎么样来选型呢?其实这三个产品都有大规模成功落地的案例,就是说没有绝对的好坏。
  • 理解微服务关注点,根据企业上下文综合考虑。
    • 作为架构师来说,最重要的是理解这些框架背后的 SOA 和微服务的公共关注点,理解这些产品如何解决这些关注点,它们各自的优势和不足。
    • 然后根据企业实际的上下文,包括发展阶段、业务、技术、团队综合的进行考量。
  • 尽量不要混搭,保持体系一致性
    • 值得提一下的是,不太建议上述框架的混合使用,比方说 Dubbo 和Spring Cloud 的混用。本来这两家是自成体系的,功能上有冗余重叠,混用的话就要维护两个体系,不太一致。
    • 那么Dubbo加K8s或者 Spring Cloud加K8s是可以考虑的。
  • 建议 K8s + Spring Boot 。
    • 一是看重社区生态
    • 另一个是对微服务公共关注点考虑的全面性
    • 综合起来,比较建议:K8s+Spring Boot 。K8s 平台微服务公共关注点考虑非常全面,Spring Boot 开发效率比较高;
    • 这两个都是目前社区的主流,K8s 针对微服务公共关注点,可以认为是最完备的一个解决方案,服务框架只需要 Spring Boot ,因为 Spring Cloud 支持的这些功能,K8s 大部分已经覆盖了。
    • 考虑到 K8s 的技术门槛和运维成本比较高,对于一般的中小公司不太建议自建 K8s 集群,建议直接采用公有云的K8s,把 K8s 运维的活外包给公有云。
  • 基于综上考虑,所以 staffjoy 实战项目的技术栈采用的就是 Spring Boot + K8s。

总结

微服务最终的目标是实现业务价值,交付业务价值,但是为了让开发人员能够专注于业务交付,微服务需要底层基础设施的支撑,这些基础设施也称为微服务的公共关注点(common concerns)

  1. 配置管理
  2. 服务发现和LB
  3. 弹性和容错
  4. API管理
  5. 服务安全
  6. 日志监控
  7. Metrics监控
  8. 调用链监控
  9. 调度和发布
  10. 自愈和自动伸缩

我们解决微服务的技术问题,很多的时候就是在解决这些公共关注点的问题。

如果把微服务的上述这些关注点,把它们抽象封装和沉淀下,最终产生的软件产品就是微服务开发框架或者说平台,那么Dubbo、Spring Cloud、K8s就是阿里巴巴、Netflix、谷歌这三家公司各自演进沉淀并且开源贡献给社区的解决方案。


Dubbo、Spring Cloud、K8s 分别是阿里巴巴、Netflix还有谷歌三家互联网公司,他们在应对大规模微服务开发带来的挑战时,各自独立演进出来的解决方案。都是对同一个问题,也就是分布式微服务开发框架的一个解。

都是对同一个问题的解,只不过三家的解法侧重点和抽象级别不太一样。

  • Dubbo 和 Spring Cloud 是框架和组件,K8s它是一个平台
  • 阿里他讲究实用,解决实际问题,追求高性能,设计上倾向于Only In One,就是全部打包在一起。
  • Netflix 讲究抽象组件化,系统可以灵活装配和扩展。
  • 谷歌 讲究体系化和平台化,抽象层次最高,它是对整个数据中心进行抽象打包。它更偏向于云架构的思想:就是要把应用容纳到基础设施当中去,而不是倒过来让基础设施去迎合应用,这是云架构的思想。

K8s、Dubbo、Spring Cloud 比对:

  • Dubbo经过阿里大规模流量的冲击洗礼,它最大的亮点就是成熟稳定
  • Spring Cloud 是 Spring 和 Netflix 开源的一个融合,同时吸纳了两者的优势。
    • Spring 框架有超过十年的历史,它也是开源界的一个传奇,Spring框架社区异常活跃。框架本身成熟灵活,开发者体验好,是它最大的亮点。
    • Netflix OSS,是Netflix开源现代微服务架构大胆创新的产物。同时也经历了Netflix大流量冲击,Netfilx框架的一大亮点的是抽象和组件化做的比较好。它可以像搭积木一样,灵活组装微服务基础架构,而且可以替换。
  • K8s 是从平台层解决微服务基础设施问题,它的抽象层级比较高。它一次性解决了服务自动化发布的难题,而且它做到了具体服务框架无关,可以容纳各种语言栈的框架。
  • 可以这样认为,就是说Dubbo、Spring Cloud ,仅仅解决了微服务基础设施的部分问题
  • K8s 它是一个完整的微服务基础设施解决方案,K8s背后有谷歌支持,社区非常活跃,被认为是未来的数据中心操作系统,云原生应用的一个标配。

建议 K8s + Spring Boot :

  • 一是看重社区生态
  • 另一个是对微服务公共关注点考虑的全面性
  • 综合起来,比较建议:K8s+Spring Boot 。K8s 平台微服务公共关注点考虑非常全面,Spring Boot 开发效率比较高;
  • 这两个都是目前社区的主流,K8s 针对微服务公共关注点,可以认为是最完备的一个解决方案,服务框架只需要 Spring Boot ,因为 Spring Cloud 支持的这些功能,K8s 大部分已经覆盖了。

公众号

知行chen

参考

《Spring Boot 与 Kubernetes 云原生微服务实践 ~ 全面掌握云原生应用的架构设计与实现》 杨波

Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐