链接：https://www.zhihu.com/question/50806354/answer/139653085

spring cloud +docker 当然没有问题，只是当我们搭建集群实现高可用的时候，觉得k8s对于我们的情况更适用（我们多半的应用都是非Jvm程序），但是可能最后还是会二者皆用。

我的意思并不是说k8s 与spring cloud冲突。我们使用这两个技术的初衷都是为了实现应用的微服务化。然而对于微服务而言，有六个基本必须实现的1.进程通讯2.服务注册与发现3.负债均衡4.配置中心5.熔断器6.网关路由

其实两者都用是一个不错的解决方案。k8s和spring cloud 的出发点不同，一个是基于容器管理的概念，一个是基于程序的注册与发现（我个人认为Netflix 的核心在于注册中心）。二者都可以达到我们的目的。就拿实现一个高可用的注册中心Eureka 来说，单纯从Netflix的设计思想来说，eureka 是一个AP 系统，要保证数据的同步，可以采用注册中心（Eureka server ）相互注册的方案，实现一个集群，但是集群每加入一个节点，要更新所有的client的配置。常规的思想，我们可以通过负载均衡的轮询算法实现，然而这个思路正是k8s 的出发点。可能Spring Cloud +K8s二者皆用是一个最好的方案，但是二者择其一一样可以达到目的。

By the way 一点小问题， Spring Cloud 中进程通讯是使用rest，性能和RPC 不是一个数量级上的，当应用被以一个很小的粒度拆分，可能有的服务与服务之间会存在链式的调用问题，性能上的差距将会更加明显。
……………………………………

研究SpringCloud有阵子了，搭建了一个springcloud微服务平台，昨天和公司的大牛们做了一下相关的技术分享，有了一些新的心得与体会，可能会推翻先前的所有工作吧。好处网上很多，我就不说了。实际过程中必然会遇到一些问题，Chris Richardson 微服务系列算是一个比较完善的理论前期支撑，里面也有谈到微服务会遇到的问题，我认为最大的问题还是运维部署问题吧！

总所周知，Spring cloud 的核心是Netflix微服务框架，非常成熟，但是在netflix oss开发初期，那个时候还没有docker，我们现在所有的服务都是通过虚拟容器承载的。

Netflix OSS的许多内容都是在一个已经过去的年代写出来的，那时所有东西都只能运行在AWS云上而没有其它选择。关于那个年代的许多宝贵遗产和前提假设都已经被封装到了Netflix的库里面，对于现在你运行的环境（比如Linux容器）已经不适用了。在Linux容器、Docker、容器管理系统等等出现之后，我们越来越看到把我们的微服务运行在Linux容器（公有云、私有云，或者都要，等等）里的巨大价值。另外，因为这些容器都是直接把这些服务打包起来、对外不透明的，所以我们倾向于不要过多关心在容器里面运行的到底是什么技术（是Java？还是Node.js？或者Go？）。Netflix
OSS主要是为Java开发者服务的，它是许多的库、框架和配置的集合，你需要把它们包含在你的Java程序或服务代码里面。

就服务发现而言，netflix是使用eureka，用Netflix OSS（SpringCloud Netflix也是一样的道理）时通常你要建立一台服务发现服务器，让所有可以被各种客户端发现的服务注册在这里。比如你用Netflix Ribbon来与各种其它服务交互，就需要能找出来它们都运行在哪里。各种服务可能下线，可能按它们自己的运行需要退出，也有可能我们要向集群中加入更多服务来做横向扩展。这种集中式的服务发现注册机制通常可以帮助我们跟踪集群中有哪些服务是可用的。

问题之一是，做为一个开发人员你需要做这些事情：

决定我到底是想要一个AP系统（Consul、Eureka等）还是CP系统（ZooKeeper、etcd等等）。

想明白在上了规模时如何运行、管理和监控这些系统（这可不是一个小小的演示系统）。

而且，你要找到对应你使用的编程语言的客户端库，才能与服务发现机制通信。回到我们刚才讨论的问题，微服务可能是用许多不同种语言实现的，所以可能一个成熟的Java客户端库好找，但相应的Go或Node.js库就没有了，那你只好自己写一个。可对每一种语言和每一个程序员，他们都可能对怎么实现这样的客户端库有自己的想法，这样你就会忙于维护各种不同的客户端库，做的事情功能都是一样的可是实现逻辑却各自不同。也有可能每种语言都会使用它自己的服务发现服务器而且也有它自己现成的客户端库呢？所以你就要为每一种语言都管理和维护不同的服务发现服务器吗？（Netflix oss Prana和SpringCloud Netflix sidecar 可以支持跨语言，但还是存在一些局限性）

当然，以上提出的问题是很小的一个点，更大的还是先前说的运维部署问题，当拆分出了成百上千个服务，会出现很多琐碎的问题，如Eureka高可用集群对clientService的配置问题。

令人欣喜的是，Kubernetes 貌似可以解决现在所遇到的问题，可能可以取代netflix的整套技术（只是可能，我也是今天开始调研的，有了新的进展再来谈谈Kubernetes 吧）