PaaS中如何实现服务注册和服务发现？

ASIS：
目前主流开源的服务发现框架包括spring cloud相关、dubbo等。
K8S平台运行在其之下，若整合需要定制开发。PCF源生支持Spring Cloud体系。
对于服务发现本身而言k8s使用了服务器端的HA和服务发现而非spring等通过客户端实现的服务发现，这是两种模型。

TOBE：
istio等service mesh是一个方向

正如楼上的回答，PaaS上的服务注册和服务发现分为两个层次:

应用层 - 通过微服务框架,如springcloud。springcloud中的eureka组件可以向各个微服务提供注册和服务发现的功能。
系统层 - K8S/OpenShift本身自带服务发现机制，其通过DNS域名解析来实现。

目前在微服务领域，Service Mesh(服务网格)正在成为微服务架构的新趋势。Istio作为Service Mesh的落地工具，则是使用K8S/OpenShift系统层面实现的服务注册与发现功能。

在我们企业内部，将微服务与PaaS云深度结合。我们将基于SpringBoot的微服务以容器的方式部署在PaaS云上。但是Kubernetes本身提供的服务注册和服务发现机制，并不能够满足我们企业内部微服务架构的需求，为此我们自研了一套与企业内部接入层深度耦合的服务注册和服务发现架构。
对于集群内部的互相调用的组件，我们采用的是基于Kubernetes Service或者Kube-DNS的方案。Pod在创建后，我们会通过图形化管理控制台同时创建相应的Service，将服务发布到集群内部。
对于集群外部组件调用集群内部组件的情况，我们没有使用Kubernetes自带的解决方案，而是自研了一套服务组册、服务发现的解决方案。一方面原因是我们企业内部已经存在功能完善的基于HAProxy和Nginx接入层，所有的外界请求需要先通过接入层接入到PaaS云平台。另一方面，出于安全性考虑，在我们企业内部，各个服务器之间的通讯也是基于防火墙白名单控制的，所以我们不可能让所有的外界请求直接接入到Kubernetes的节点上。基于上面两个原因，我们自研了一套基于etcd和confd的服务注册服务发现机制。
首先，由于我们企业内部的技术栈相对单一，我们设计了5种基础镜像供开发者选择，开发者构建的Docker镜像必须基于这五种镜像之一。这五种镜像分别是：
1、 纯Linux操作系统镜像
2、 Linux操作系统+JDK镜像
3、 Linux操作系统+JDK+Tomcat镜像
4、 Linux操作系统+nginx镜像
5、 Linux操作系统+IHS镜像
由于我们PaaS云平台上运行的容器都是基于这五种基础镜像的，那么我们就在这5种镜像里面加入了postStart脚本和preStop脚本。容器在启动时，会调用postStart脚本，postStart脚本将容器自己的宿主机IP地址、映射到宿主机的端口以及容器所属应用和模版等信息注册到ETCD里。
同时接入层的nginx和HAProxy服务器上，我们运行了confd进程，confd会监测ETCD的变化，根据预先设定好的模版，生成nginx和HAProxy的配置文件并重新加载使之生效。这样就完成了服务注册和服务发现的过程。
在容器停止的时候，会调用preStop脚本，这个脚本会将容器在ETCD上的记录删除，这样就完成了服务的解注册。当然，我们也预想到，容器可能不会以正常的形式停止，在这种情况下，容器虽然停止了，但是preStop脚本不会被调用。为了解决这个问题，我们以DeamonSet的形式，在集群每个节点上均部署了一个HouseKeeping容器，这个HouseKeeping容器主要的职责就是监测ETCD里面的脏数据，并将其删除。