微服务解决方案调研发现方案不止一两个

微服务要点

微服务架构的各要点包括服务发现、负载均衡、高可用、集群容错、调度与部署、弹性伸缩、API网关、服务的故障隔离和熔断、配置管理、日志采集、分布式调用跟踪、监控告警。

方案一：kubernetes+springcloud+第三方套件

Spring Cloud 和 kubernetes 是基于不同视角的微服务框架，Spring Cloud是从java语言层面提供一整套微服务框架解决方案。kubernetes则是不拘于特定语言、从服务运行的平台层提供微服务框架需要的功能支持。

从应用的生命周期角度来看，K8S 覆盖了更广的范围，特别像资源管理，应用编排、部署与调度等，Spring Cloud 则对此无能为力。

从功能上看，两者存在一定程度的重叠，比如服务发现、负载均衡、配置管理、集群容错等方面，但两者解决问题的思路完全不同，Spring Cloud 面向的纯粹是开发者，开发者需要从代码级别考虑微服务架构的方方面面，而 kubernetes 面向的是 DevOps 人员，提供的是通用解决方案，它试图将微服务相关的问题都在平台层解决，对开发者屏蔽复杂性。

应用kubernetes和springcloud作为微服务解决方案，由kubernetes提供平台级的微服务框架要点功能支撑，针对java应用可以采用springcloud的组件来提供应用级别的服务故障隔离与熔断功能支持是一种优秀的方案。如果java应用强烈采用springcloud的应用级的微服务框架要点功能支撑，则将其不纳入kubernetes平台级的微服务管控，否则会出现管控混乱。

缺点：

微服务之间的认证授权需在API网关或应用程序内部实现，较难控制。

应用级别的服务故障隔离与熔断功能需在应用程序内部实现。

kubernetes的配置管理对于configmap没有提供配置自动更新的功能。

采用第三方套件时有一定的学习成本。

方案二：kubernetes+serviceMesh+第三方套件

serviceMesh(服务网格):服务网格是一个用于处理服务间通信的基础设施层，它负责为构建复杂的云原生应用传递可靠的网络请求。在实践中，服务网格通常实现为一组和应用程序部署在一起的轻量级的网络代理，但对应用程序来说是透明的。

关于serviceMesh(服务网格)的介绍和开源组件对比见上篇博客《serviceMesh服务网格与开源工具》。

下面以serviceMesh开源组件Istio为例进行方案说明。

使用kubernetes加Istio方案可以从平台层面处理微服务架构要点，而不需要更改任何服务代码。应用开发者只需专注开发应用和服务，极大减少了应用程序的代码。

Istio的额外特性

服务间访问策略管控支持ACL检查，Istio的路由规则可以在路由请求到后端服务时获取更大的控制度，例如为服务上的指定URL的所有请求设置4秒的超时时间

缺点

Istio是一个较新的服务网格开源组件，目前还没有在生产环境部署。

开发人员对Istio相关经验较少，有一定的学习成本。

kubernetes的配置管理对于configmap没有提供配置自动更新的功能。

采用第三方套件时有一定的学习成本。