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

技术栈选型之微服务公共关注点及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)。

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

配置管理

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

服务发现和LB

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

弹性和容错

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

API管理

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

服务安全

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

日志监控

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

Metrics监控

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

调用链监控

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

调度和发布

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

自愈和自动伸缩

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

---

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

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

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优势比对

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 大部分已经覆盖了。

公众号

参考

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