程序：我从哪里来？

本文做者：AIOps智能运维

干货概览

 

在计算机程序或者服务的层次上，咱们来试着分析前面提到的几个问题。

 

问题

 

1.我是谁？

 

服务叫什么，服务包含了哪些实例，服务规模、部署状况、实例运行情况如何？

 

2.我从哪里来？

 

服务的上游有哪些，不一样的上游流量如何分配？

 

3.我往哪里去？

 

服务的下游有哪些，不一样的下游流量如何分配？

 

面对这样的问题，咱们的答案是什么呢？

 

在百度的运维实践中，咱们只需“BNS”就能够得到想要的答案。

 

BNS（Baidu Naming Service，百度名字服务）是百度云智能运维团队研发的一套分布式的名字服务系统，是百度云Noah智能运维产品中的一个重要基础服务系统。它为每个服务赋予一个独一无二的名字，根据这个名字，咱们就能够获取到这个服务的相关信息 ，这些信息包括：服务在机器上部署信息（机器IP，部署路径，服务配置，端口信息），服务的实例运行情况等其余重要信息。简单来说，它提供了一个服务名到资源信息的一个映射关系。

 

在BNS系统中，服务单元表示一个服务的实例集合，通常以三段式的结构表示，好比：server.noah.all，server表示服务名，noah表示产品线，all表示机房名称，服务单元的名字在系统中是惟一的。

 

使用场景

 

在程序员的平常工做，经常面临如下的场景：

 

场景

 

场景一：我是一名OP工程师，负责几十个系统模块的运维，我经常须要登陆部署服务的机器排查问题，可是只知道服务名，记不住那么多部署信息，怎么办？

 

场景二：我是一名RD工程师，我负责的服务须要扩容，个人服务是不少下游服务的依赖，服务的扩容怎么通知给下游模块？

 

场景三：个人服务部署实例有一个出现故障了，我想对下游服务屏蔽该故障实例，怎么办？ 

 

下面以一个简单的例子来讲明，假设一个模块名是Server，它的上游是Proxy服务，下游是Redis服务，当出现变动或者故障时，如何让上游感知到呢？

 

当新增上线实例、下线摘除实例或者实例发生故障时，BNS系统经过部署在机器上的客户端实时感知到实例的状态变化，同时新增和删除实例的变动状况会当即同步到分布式的缓存系统中，这样用户经过一个BNS名字就能够感知到下游的实例变化。

 

对应上面几个场景，BNS提供了如下的解决方案：

 

场景一：用户想登陆Proxy模块的第一个实例，能够经过ssh 1.proxy.noah.all.serv 方式登陆。

 

咱们基于BNS开发了nsswitch的扩展，而且修改了/etc/nsswtich的配置文件:

 

hosts files dns bns

 

在主机须要解析1.proxy.noah.all.serv 的时候，通常会直接或者间接的调用glibc提供的gethostbyname_r函数，而glibc在实现gethostbyname_r时，会按照nsswitch里配置的顺序files->dns->bns顺序进行处理，这样就实现了经过BNS登陆机器。

 

场景二：Server模块扩容，但愿上游及时感知到下游模块的变动。

 

用户在BNS上进行Server模块的扩容，模块实例变化信息会当即同步到BNS系统中的分布式缓存，在全网任意一台机器上，经过查询就能实时获取到实例变化的详情。

 

场景三：Redis模块3.redis.noah.all实例故障了，但愿对上游屏蔽该实例。

 

经过部署在机器上的客户端感知到实例的状态变化（好比实例状态由0变成-1，即正常变成非正常），并将数据同步到系统中的分布式缓存，上游模块能够经过查询redis.noah.all的实例状态结果，主动过滤非正常的实例，也能够在BNS系统中发起屏蔽故障实例的操做，在查询过程当中会自动过滤该故障实例。

 

在下一节中将具体介绍BNS系统的总体架构。

 

基本架构

 

BNS系统主要包含几个部分：流量接入层，Web Server，存储层，代理客户端。

 

做为一个底层的基础服务，BNS系统天天的访问量近千亿次，这对系统的可用性提出了很高的要求，于是系统须要在各个层面有完善的容灾能力和流量管控能力。

 

1流量接入层

 

系统经过HTTP接口对外提供变动服务，用户经过Web页面或者接口进行服务或实例信息注册。为了保证平台稳定和安全的运行，须要对非法和异常请求进行拒绝，在流量接入层(Proxy)端提供了如下两个功能：

 

流量鉴权：每个服务组、服务单元、实例的注册都须要进行权限验证，用户只有申请了合法的Token才能容许访问，另外系统还提供了白名单等其余的鉴权方式。

 

配额限流：针对产品线、用户、IP提供必定的配额，当请求的数量超过配额，就会拒绝响应的请求，并提示用户Quota超限。

 

2Web Server

 

Web Server提供用户进行各种BNS变动的接口，承担了BNS系统的大部分写入流量，采用分布式多地域的部署方式，能够避免单实例、单机房的故障对可用性形成的影响。

 

3存储层

 

这里主要包含数据库和Cache层两个部分。

 

数据库：采用MySQL存储，采用主从集群部署、读写分离的方式。

 

Cache层：是BNS系统自研的一个缓存模块，缓存了全量的BNS系统数据，采用多地域部署的方式，它主要功能是下降数据库的查询压力。

 

4客户端

 

BNS系统主要包含两个客户端：查询客户端和健康检查客户端，咱们分别用Naming Agent和Check Agent来代指两个。

 

客户端部署在全部的机器上，并提供命令行工具和丰富的SDK以及各种插件，方便用户在各个场景使用。

 

Naming Agent：提供BNS的查询功能，用户能够根据一个名字（服务组、服务单元、实例）就能获得详细的服务信息。Naming Agent与Cache层的数据交互，采用推拉结合的方式，Naming Agent主动拉取数据和Cache模块推送变动数据，同时Naming Agent客户端会将查询过的数据置于本地缓存中，以此下降Cache层的查询压力。

 

Check Agent：提供BNS实例的健康检查功能，用户经过在Web页面对每个实例配置健康检查的方式，机器上的Check Agent会主动探测全部实例的运行情况，并将健康检查的结果上报给Cache层，同时更新数据库内容。

 

总结

 

BNS系统知足服务间交互中常见的的资源定位、IP白名单维护等需求，也能够用于机器列表查询，使用场景包括机器列表查询、服务定位、白名单维护、数据库智能受权等，解决了程序“我是谁？我从哪里来？该往哪里去？”的问题。

 

今天咱们一块儿聊了百度云Noah智能运维产品中的BNS系统，目前系统还在持续迭代和优化中，若您想进一步了解BNS问题，欢迎你们积极留言。

 

原文连接地址：https://developer.baidu.com/topic/show/290061