邢海涛：大家好，我来自灵雀云，今天给大家分享一下我们在微服务产品开发的一些实践。微服务给DevOps带来很多的挑战，这里就不细讲了，持续的集成、持续的交付，还有持续的部署，前面的嘉宾已经讲的非常详细了。
Kubernetes我们认为是一个非常好的方案，它提供了非常详细的功能，比如资源的调度，弹性的伸缩，自动化的部署，今天的演讲我想聊一聊这个服务发现在微服务中的应用，和我们在做这个产品的一些经验。
比如说我们现在的代码是要加上一些业务无关微服务相关逻辑，随着微服务框架发展，业务无关代码逐渐的就分离出来，而由框架来完成。
这个部分，我们聊聊服务发现组件和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后面所有的实例。通过扩展Eureka，我们添加逻辑去读取这个Headless地址，列表它后面所有的实例，然后让每一个实例注册到其它所有的实例上面。这样的好处是，在我们的配置文件很简单，只有一个Headless域名。我们就可以做到让Eureka集群轻松部署随意多的实例，而且享受到Kubernetes自动伸缩功能。这样的话就能确保Eureka的最终一致性造成的最低延迟。
优点是充分利用KUBERNETES的功能完成整个的部署。缺点是需要对Eureka做扩展。但是如果采用我们平台的话，这个步骤会很简单，只不过是添加相关的依赖就可以了。。
实际上随着这个微服务应用的发展，其实Kubernetes自身已经提供有服务发现的功能。这里有另外一个开源方案，我们的微服务代码里面可以不用写服务发现相关逻辑的，Spring Cloud Kubernetes，这个项目的核心观点是充分用Kubernetes提供的功能去实现自动的服务发现，相当于也简化了我们的服务，所有这些都会使用Kubernetes内部的服务发现的机制来完成。
缺点是，我们的代码是依赖于Kubernetes的。再往后发展，我们的代码如何让服务发现和其他的一些组件，不和我们业务的逻辑掺杂在一起，那就是Service Mesh。这两张图大概演示了Service Mesh的演变，左边图是两个Service，业务代码和服务发现，熔断器都是融合在一起的，那么能不能有可能把它们分开？从同一个进程里面分开成不同的进程，那就是右边图的想法。
刚才那个想法很难去实现，在容器领域有一个很重要的sidecar pattern，应用这个Pattern可以把刚才的想法很好的实现。这个图，把所有跟微服务相关的网络通讯分割，我们在上面加一个控制面板，这个sidecar进行配置，就变成现在这个样子。这个是其中两个Service的实例，再扩大化之后，这个就是服务的网格，每一个小点就是一个Service。Service Mesh的定义，它是处理服务到服务通信的专用基础设施层，它是透过云原生的复杂的拓扑结构，负责可靠的传递信息，它主要通过上面介绍的这种方式实现。
这个图稍微旧了一点，
Linkerd是第一代的service mesh。Conduit已经变身Linkerd2、最后是Istio。我们公司下半年会陆续发布Service Mesh产品，敬请期待。
简单介绍一下我们公司，灵雀云是国内容域PaaS领域，估值高、总融资额大的IT服务企业，现在金融、运营商、制造等行业用有诸多五百强企业的客户。这是两位创始人，均来自微软Azure团队。
这是灵雀云的发展里程，2017年9月份完成了腾讯领投的过亿B轮融资，2018年5月份完成了以英特尔投资的过亿B+轮的融资，6月份我们拿到中国容器领域金额第一大单，中标中石油项目。
灵雀云平台基于容器技术以DevOps理念，面向微服务的新一代PaaS平台，灵雀平台全面集成Kubernetes，同时深度支持Spring
Cloud和未来的Service Mesh等微服务平台。这是我们主要的客户，谢谢大家。
热门专题
