灵雀云微服务和 K8S 集成探索实践

微服务给DevOps的确带来很多挑战，比如持续集成、持续交付，持续部署，监控、认证、授权以及快速配置计算资源等等。

Kubernetes我们认为是一个非常好的方案，它提供了非常详细的功能，比如资源的调度，弹性的伸缩，自动化的部署。今天的演讲我想聊一聊服务发现在微服务中的应用，和灵雀云在做微服务产品的一些经验。

我们现在的代码是业务逻辑参杂着微服务相关操作，随着微服务理念和框架发展，业务逻辑被独立出来，微服务相关操作被整合到框架来完成。

服务发现--Eureka高可用

关于服务发现组件和 Kubernetes 的结合，生产环境我们需要把这些组件实现高可用。以Eureka为例，Eureka集群每一个节点都需要配置集群其他节点IP，形成点对点的集群。把每个IP地址写死在配置文件里，自动化运维极不方便。将集群变成更多节点是一件很不容易的事，更不能随意的把它部署在其他的节点上。

这是一个Eureka集群配置不当的例子，节点A和C无法直接交换数据。Eureka为了强调高可用性而使用最终一致性的模型，这个集群设计，会导致Eureka节点的不一致时间加长，进而service调用报错。为了降低最终一致性带来的问题，通常我们会让service注册到这个集群的所有节点，下面是我们的方案。

Kubernetes 提供一个Service对象，叫Headless Service，了解Kubernetes的人知道每一个Service有一个Cluster IP，但Headless Service没有这个Cluster IP，nslookup可以列表headless service关联的所有pod实例IP。

通过扩展Eureka，添加逻辑去读取这个Headless地址，列表标明它后面所有的实例，然后每一个实例注册到其它实例上面。这样的好处是，配置文件会很简单，只有一个Headless域名。可以实现Eureka集群轻松部署任意实例，而且享受到Kubernetes自动伸缩功能。这样的话就能确保Eureka的最终一致性造成的最低延迟。

第二种方案 Kubernetes StatefulSets，优点是，充分利用Kubernetes的功能完成整个部署，简洁配置。缺点是，需要对Eureka做扩展。如果采用灵雀云平台的话，这个步骤会很简单，添加相关的依赖就可以了。

实际上随着微服务应用的发展，Kubernetes自身已经提供服务发现的功能。这里有另外一个开源方案Kubernetes+spring-cloud-kubernetes，微服务代码可以不用写服务发现的相关逻辑，这个项目的核心观点是，充分用Kubernetes提供的功能去实现自动的服务发现，相当于简化了服务，所有这些可以使用Kubernetes内部的服务发现机制来完成。

这种方案的缺点是，我们的代码是依赖于Kubernetes的，再往后发展，代码如何让服务发现和其他组件不和业务的逻辑掺杂在一起，这就是Service Mesh能够实现的功能。这两张图大概演示了Service Mesh的演变，左边图是两个Service，业务代码和服务发现、熔断器融合在一起，那么有没有可能把它们分开？从同一个进程里分成不同的进程，这就是右边图的想法。

Service Mesh演变

那个想法的实现不是轻而易举的，容器有一个很重要的sidecar pattern，应用这个Pattern可以很好的实现这个想法。把所有跟微服务相关的网络通讯分割，在上面加一个控制面板，通过sidecar进行配置，就变成现在这个样子。这是其中两个Service的实例，扩大化之后就是服务网格，每个小点是一个Service。

Service Mesh是处理服务到服务之间通信的专用基础设施层，透过云原生的复杂拓扑结构，可靠的传递信息。

Linkerd是第一代 service mesh

，然后还经历了Conduit、 Istio。灵雀云下半年将会陆续发布Service Mesh相关的产品，敬请大家期待。