今天分享的是如何在Go-kit和ServiceMesh中进行服务注册与发现的案例。在上文中我们基于搭建好的 Consul 集群通过 Consul 中提供的 HTTP API 实现了 register 的服务注册与发现功能。我们采用手动构造HTTP请求的方式在服务启动时发送服务实例数据到Consul中完成服务注册在服务关闭时向Consul请求服务注销并通过Consul提供的服务发现接口根据服务名获取可用的服务实例信息列表。在本文我们将使用Go-kit提供的服务注册与发现工具包完成服务注册与发现并介绍ServiceMesh中Istio是如何进行服务注册与发现的。使用Go-kit服务注册与发现工具包自主开发服务注册与发现客户端固然能够加深我们对微服务和服务注册与发现中心交互流程的理解但同样会增加开发人员的理解成本比如要了解服务注册与发现中心对外提供的接口、提交数据的具体细节以及在服务注册与发现中心版本升级迭代或者API发生更新时还需要持续维护客户端代码以避免不可用情况的发生等等。Go-kit作为一套微服务工具集意在帮助开发人员解决微服务开发中遇到的绝大多数问题让他们更专注于业务开发。Go-kit 提供了诸多服务注册与发现组件的客户端实现支持包括 Consul、Etcd、ZooKeeper和 Eureka在内的多种服务注册与发现中心。下面我们以Consul为例实践如何使用Go-kit的sd 包简化微服务服务注册与发现的实现sd包中提供如下注册和注销接口代码如下所示type Registrar interface { Register //服务注册 Deregister//服务注销 }在Go-kit中我们根据选定的服务注册和发现组件实例化 Registrar 接口对应的结构体实现即可使用同样的接口进行服务注册和服务注销。接下来我们实例化sd/consul包下的Registrar用于完成与Consul的交互实例化代码如下:func NewDiscoveryclient(host string, port int, registration *api.AgentServiceRegistration) (*Discoveryclient, error) { config : api.DefaultConfig() config.Address host : strconv.Itoa(port) // 生成 hashicorp client client, err : api.Newclient(config) if err ! nil{ return nil, err } // 使用 hashicorp client 生成 sd consul client sdclient : consul.Newclient(client) return Discoveryclient{ client: sdclient, config: config, registration: registration, register: consul.NewRegistrar(sdclient, registration, log.NewLogfmtLogger(os.Stderr)), }, nil }DiscoveryClient.register 即最终实例化的 Consul 注册器。从实例化的过程可以发现 Consul Registrar的实现依赖于 sd.consul.client 而 sd.consul.client 实现依赖于 hashicorp client即 Consul 的官方实现客户端。深入hashicorp client客户端中的服务注册与发现的实现会发现它也是通过请求ConsulAgent 提供的HTTP API 完成的实现的方式与我们在上一课时中的实践大同小异。api.AgentServiceRegistration 结构体即需要提交到 Consul 中的服务实例信息包含服务名、服务实例ID、服务地址和服务端口等基本信息。然后我们的服务注册和服务注销实现就可以委托给Register执行如下所示func (consulclient *Discoveryclient) Register(ctx context.Context) { consulclient.register.Register() } func (consulclient *Discoveryclient) Deregister(ctx context.Context) { consulclient.register.Deregister() }服务发现的实现也是直接调用sd.consul.client提供的相关方法。通过使用Go-kit提供的Consul 工具包可以在不了解微服务与Consul具体交互逻辑的基础上通过简单调用包中提供的方法即可完成服务注册与发现大大减轻业务人员的开发工作。Service Mesh 中 Istio 服务注册与发现ServiceMesh作为下一代的微服务架构它将服务间的通信从基础设施中抽离出来达到交付更可靠的应用请求、监控和控制流量的目的。Service Mesh一般与应用程序一同部署作为数据平面代理网络以及控制平面代替应用与其他代理交互。ServiceMesh的出现让业务开发人员从基础架构的底层细节中解放出来从而把更多的精力放在业务开发上提高需求迭代的效率。Istio作为ServiceMesh的落地产品之一依托Kubernetes快速发展已经成为最受欢迎的ServiceMesh之一。Istio在逻辑上分为数据平面和控制平面。数据平面由一组高性能的智能代理基于Envoy 改进的istio-proxy组成它们控制和协调了被代理服务的所有网络通信同时也负责收集和上报相关的监控数据。控制平面负责制定应用策略来控制网络流量的路由。Istio由多个组件组成核心组件及其作用为如下Ingressgateway控制外部流量访问Istio 内部的服务。Egressgateway控制Istio 内部访问外部服务的流量。Pilot负责管理服务网格内部的服务和流量策略。它将服务信息和流量控制的高级路由规则在运行时传播给Proxy并将特定平台的服务发现机制抽象为Proxy可使用的标准格式。Citadel提供身份认证和凭证管理。Galley负责验证、提取、处理和分发配置。Proxy作为服务代理调节所有ServiceMesh 单元的入口和出口流量。lstio ArchitectureIstio 架构图这其中 Proxy属于数据平面以 Sidecar 的方式与应用程序一同部署到 Pod 中而 Pilot、Citadel和Galley 属于控制平面。除此之外Istio 中还提供一些额外的插件如 grafana、istio-tracing、kiali和prometheus用于进行可视化的数据查看、流量监控和链路追踪等。Istio默认提供了以下几种安装profile形式它们开启的组件配置如下表所示表示开启空白表示未开启表示未知这其中istiod 组件封装了Pilot、Citadel和 Galley等控制平面组件将它们进行统一打包部署降低多组件维护和管理的困难性。从上表可以看出demo profile是功能最全的配置清单适合于学习和功能演示。previewprofile将可能使用一些开发阶段的测试组件开启的组件不定。官方推荐使用default profile进行安装因为它在核心组件和插件上做到了最优的选择比如组件只开启了Ingressgateway 和 istiod插件只开启了 prometheus。当然我们也可以根据实践的需求选择合适的profile进行安装启动比如下面的安装命令我们使用的是demo profile:istioctl manifest apply --set profiledemo上述命令以demo profile部署Istio该配置下的Istio能够通过可视化界面监控Istio 中应用的方方面面。Istio以 Sidecar 的方式在应用程序运行的Pod 中注入Proxy全面接管应用程序的网络流入流出。我们可以通过标记Kubernetes命名空间的方式让Sidecar 注入器自动将Proxy注入在该命名空间下启动的Pod中开启标记的命令如下kubectl label namespace default istio-injectionenabled上述命令中我们将 default 命名空间标记为istio-injection。如果不想开启命令空间的标记也可以通过 istioctl kube-inject 为 Pod 注入 Proxy Sidecar 容器。接下来我们就为 register 服务所在的 Pod 注入Proxy启动命令如下istioctl kube-inject -f register-service.yaml I kubectl apply -f -register 服务的yaml 配置如下:apiversion: apps/v1 kind: Deployment metadata: name: register labels: name: register spec: selector: matchLabels: name: register replicas: 1 template: metadata: name: register labels: name: register app: register #添加 app 标签 spec: containers : - name: register image: register ports: - containerPort: 12312 imagePullpolicy: IfNotPresent # ...省略环境配置 --- # 添加 Service 资源 apiversion: v1 kind: Service metadata: name: register-service labels: name: register-service spec: selector: name: register ports: - protocol: TCP port: 12312 targetPort: 12312 name: register-service-http这主要的改动有为register 服务添加 Deployment Controller添加了新的标签 app以及为register 添加相应的 Service 资源。如果在部署Istio 时启动了 kiali插件即可在 kiali 平台中查看到register服务的相关信息通过以下命令即可打开kiali控制面板默认账户和密码都为 admin:istioctl dashboard kialikiali 控制台从上图可以看出在kiali控制台中存在多个维度查看Istio 中部署的应用Overview网格概述展示Istio内具有服务的所有命名空间;Graph服务拓扑图Applications应用维度识别设置了app 标签的应用;Workloads负载维度检测 Kubernetes 中的资源包括 Deployment、Job、DaemonSet等无论这些资源有没有加入Istio 中都能检测到;Services服务维度检测 Kubernetes 的 Service;Istio Config配置维度查看Istio 相关配置类信息。register 服务启动后我们在 Applications、Workloads、Services 维度中均可查看到 register 的身影如下 Applications 维度图所示:kiali Applications 维度下的 registerIstio依托Kubernetes 的快速发展和推广对Kubernetes 有着极强的依赖性其服务注册与发现的实现也主要依赖于Kubernetes的 Service管理。我们可以通过以下这张图理解Istio的服务注册与发现lstio ArchitectureIstio服务注册与发现逻辑图通过该逻辑图我们可以看到Istio服务注册与发现主要有以下模块参与。ConfigController负责管理配置数据包括用户配置的流量管理和路由规则。ServiceController负责加载各类ServiceRegistry从ServiceRegistry 中同步需要在网格中管理的服务。主要包含①KubeServiceRegistry从 Kubernetes 同步 Service 和 Endpoint 到Istio②ConsulServiceRegistry从 Consul 中同步服务信息到Istio;③ExternalServiceRegistry监听 ConfigController 中的配置变化获取 ServiceEntry 和WorkloadEntry资源并封装成服务数据提供给ServiceController。DiscoveryServer负责将 ConfigController 中的路由配置信息和 ServiceController 中的服务信息封装成 Proxy 可以理解的标准格式并下发到 Proxy 中。Pilot 组件会从各个 Service Registry比如 Kubernetes 中的 Service 和 Consul 中注册的服务采集可用的服务数据到Istio 中并将这些服务转换为Proxy可理解的标准服务格式下发到Proxy同时下发的还有用户预先配置的路由规则和流量控制策略。在被代理的应用根据服务标识发起 HTTP 通信时Proxy将会从拦截的网络请求中根据服务标识获取对应的服务数据并根据下发的路由规则选择合适的实例转发请求。基于Kubernetes 迅速发展的Istio 在服务注册与发现组件上支持最完善的自然也为Kubernetes这依托于Kubernetes对 Pod、Service 等资源的监控为服务之间的调用提供弹性、负载均衡、重试、熔断和限流等诸多保障。而对第三方服务注册与发现组件的集成和支持比如Consul等Istio官方的实现仅仅是基本可用的级别在性能和易用性方面仍需要不断进行打磨和测试。因此在Istio的落地实践中建议是与Kubernetes强绑定使用以达到功能的最优化发挥。小结服务注册与发现是微服务架构落地实践的基石之一因为有中心化的服务注册与发现中心管理大量动态变化的服务实例使得应用服务可以在无太大压力的条件下进行微服务拆分和横向扩展大大提升了微服务架构的灵活性和伸缩性。在本文我们首先介绍了Go-kit中服务注册与发现工具包并使用其中的Consul工具包改善了register 服务的服务注册与发现的实现。接着我们介绍了 Service Mesh 中的依依者Istio以及其服务注册与发现的实现。Istio 本身并不提供服务发现的能力但是它可以依托Kubernetes 或者第三方的服务注册中心获取服务信息列表并根据设定的路由规则进行有效的动态调用。希望通过本文的学习不仅能加深你对Go微服务中服务注册与发现的认识也能了解到Istio是如何在代理层实现服务注册与发现。