NBA直播,足球直播,篮球直播,欧洲杯直播,lol直播,英雄联盟直播,dota2直播,dnf直播,cf直播,绝地求生直播,王者荣耀直播,游戏直播,赛事直播,YY直播,美女直播,视频直播,足球直播

　　虎牙关注 Nacos 是从 v0.2 开始的（最新版本：Pre-GA v0.8），我们也参与了社区的建设，可以说是比较早期的企业用户。

　　首先，在虎牙的微服务场景中，起初有多个注册中心，每一个注册中心服务于某一部分微服务，缺少一个能融合多个注册中心，并把他们逐一打通，然后实现一个能管理整个微服务体系的大的注册中心。

　　以下内容摘自我们考虑引入 Nacos 时，在服务注册中心方案上的选型对比：

　　其次，在服务配置中心方案的选型过程中，我们希望配置中心和注册中心能够打通，这样可以省去我们在微服务治理方面的一些投入。因此，我们也同步比较了一些服务配置中心的开源方案：

　　例如 Spring Cloud Config Server、Zookeeper 和 ETCD，总体评估下来，基于我们微服务体系现状以及业务场景，我们决定使用 Nacos 作为我们服务化改造中服务注册和服务发现的方案。使用过程中，我们发现，随着社区版本的不断更新和虎牙的深入实践，Nacos 的优势远比我们调研过程中发现的更多，接下来，我将围绕 DNS-F、Nacos-Sync、 CMDB 和负载均衡 4 方面来分享虎牙的实践。

　　Nacos 提供的 DNS-F 功能的第一个技术价值在于，弥补了我们内部微服务没有一个全局动态调度能力的空白。刚才提到，虎牙有多个微服务体系，但并没有一个微服务具备全局动态调度的能力，因为它们各自都是独立的。目前，我们通过 Nacos 已经融合了四个微服务体系的注册中心，最终目标是把所有的微服务都融合在一起，实现全局动态调动的能力。

　　第二，DNS-F 解决了服务端端到端面临的挑战，即延时大、解析不准、故障牵引慢的问题。

　　当内部有多个微服务体系的时候，每一个体系的成熟度是不同的。例如，有一些微服务框架对同机房或 CMDB 路由是不支持的，当一个服务注册到了多个 IDC 中心，去调用它的服务的时候，即便是同机房，也可能调用到一个不是同机房的节点。这样就会无端的造成服务的延时和解析不准。

　　即使我们基于 DNS 做一些解析的优化，但仍然无法完全解决服务的延时和解析不准。这是因为 DNS 都是 IP 策略的就近解析，无法根据服务的物理状态、物理信息进行路由。此外，当一个核心服务出现问题，如果缺少一个融合了多个调用方和被调用方的信息的统一的注册中心，就很难去准确判断如何去牵引，从而导致故障牵引慢。有了 Nacos 后，就可以接入一个统一的注册中心以及配置中心，去解决这些问题。（目前，虎牙还在微服务体系的改造过程中，未完全实现统一的注册中心）

　　第三，提供专线流量牵引能力。虎牙的核心机房的流量互通，是使用专线来实现的。专线的特性就是物理建设的，而且我们的专线建设可能不像 BAT 那么大，例如我们专线%，假设某个直播异常火爆，突发流量高于平常的两百倍，超过了专线的建设能力，这时候一个服务就有可能会导致全网故障。但是，通过全局的注册中心和调动能力，我们就可以把流量牵引到其他地方，例如迁移到公网，甚至牵引到一个不存在的地址，来平衡一下。即便某个服务出现问题，也不会影响我们的全局服务。

　　第四，支持服务端的多种调度需求，包括同机房路由、同机器路由，以及同机架路由，Nacos 都可以去做适配。此外，基于 Nacos 的 DNS-F 功能，我们还实现了加速外部域名解析和服务故障牵引秒级生效。

　　这张图是 Nacos DNS-F 的一个具体实现，实际上是拦截了 OS 层的 DNS 请求。如果经过 DNS 的域名是内部服务，它就会从 Nacos Server 获取结果，如果不是，就会转发到其它的 LocalDNS 进行解析。

　　以数据库高可用的应用场景为例，我们的数据库切换效率比较低，依赖业务方修改配置，时效不确定，通常需要 10 分钟以上（备注：我们的数据库实际上已经实现了主备的功能，但当一个主服务出现问题的时候，总是要去切换 IP。）切换 IP 的过程中，依赖运维和开发的协作，这是一个比较长的过程。

　　引入 DNS 后，当主出现问题的时候，就可以很快的用另外一个主的 IP 来进行替换，屏蔽故障，而且节点的故障检测和故障切换都可以自动完成，并不依赖运维和开发的协作，节省了时间。当然，这个场景的解法有很多，比如说使用 MySQL - Proxy 也可以去解这个问题，但我们的 MySQL - Proxy 还在建设中，想尽快的把这个问题解决，所以采用了 DNS 的方式。

　　下面我们再着重分享下基于 DNS-F 对 LocalDNS 的优化。虎牙还没有去建设自己的 LocalDNS，大部分使用的是一些公共的 DNS，大致有以下这些组成。

　　这种组成方式会存在一个问题。假设服务突然一下崩溃后，之后服务又马上正常了，这种情况我们无法重现去找到崩溃原因。因为很多场景下，是一个公共 DNS 的请求超时导致的，甚至一个解析失败导致的，在那一刻，因为无法保留现场的，所以就发现不了问题。

　　以我们的监测数据来看，DNS 解析错误的比例达到 1‰左右，超时比例将更高。意思是在使用公共 DNS 的情况下，服务有 1‰的几率是会超时或失败，如果服务没有做好容错，就会出现异常。同时，一些公共 DNS 解析的延时都是不定的，比如在亚马逊上一些比较不好的节点，它的延时会比较高，平均超过三四十毫秒。

　　然后我们基于 DNS-F 对 LocalDNS 做了一些优化。优化结果如下：

　　优化的效果也体现在我们的风控服务上，平均延迟下降 10ms，服务超时比例下降 25%，降低了因延迟或服务超时导致的用户上传的图片或文字违规但未被审核到的风险。

　　Tars 主要是支持 C++，但对 Java、PHP 等开发语言的支持力度比较差，这就使得我们非 C++的业务方去调用它就会很别扭。引入 Nacos 以后，我们通过 Nacos 支持的 DNS 协议来实现服务发现过程中对全语言的支持。

　　当然，Nacos 不只是一个注册中心，它具备了融合多个数据中心的能力，支持多数据源的同步，例如，我们目前已经支持了 Taf（虎牙内部的一个重要微服务体系）、Nacos 自身、ZooKeeper、以及 K8S 上一些服务注册的同步。

　　同时，基于 Nacos 集群的双向同步功能(Nacos-Sync)，我们实现了国内的两个可用区，以及国外的多个可用区之间的数据值同步，最终实现了一处注册、多地可读。

　　Nacos-Sync 是事件机制，即同步任务通过事件触发，可以灵活地开启和关闭你要同步的任务，然后根据服务变化事件触发监听，保证实时性，最后通过定时的全量突发同步事件，保证服务数据的最终一致。同时，Nacos-Sync 也支持服务心跳维持，即多个数据中心的心跳，可以使用 Nacos-Sync 代理要来实现远端同步。此外，也支持心跳与同步任务绑定，便于灵活控制。

　　由于 Taf 上有数万个注册服务，同步的量特别大，所以我们在 Nacos-Sync 做了一些改造，通过任务分片来实现数万服务同步的可用性保障。改造步骤是先以服务为粒度定义任务，然后在多个分片上分散任务负载，最后以单分片多副本来保证任务可用性。

　　在服务进行多机房或者多地域部署时，跨地域的服务访问往往延迟较高，一个城市内的机房间的典型网络延迟在 1ms 左右，而跨城市的网络延迟，例如上海到北京大概为 30ms。此时自然而然的一个想法就是能不能让服务消费者和服务提供者进行同地域访问。

　　Nacos 定义了一个 SPI 接口，里面包含了与第三方 CMDB 约定的一些方法。用户依照约定实现了相应的 SPI 接口后，将实现打成 Jar 包放置到 Nacos 安装目录下，重启 Nacos 即可让 Nacos 与 CMDB 的数据打通。

　　在实际的落地过程中，我们是在 DNS-F 接入 Taf，在 DNS-F 上实现 Taf 的中控接口，无缝对接 Taf 的 sdk。DNS-F 提供缓存负载均衡和实例信息，Nacos 则提供负载均衡信息的查询接口。

　　虎牙的域名（）会接入华南、华中、华北多个 IDC 机房，每个机房都会建设一个 Nginx 去做负载均衡，经过负载均衡的流量会通过专线返回到我们的后端服务器上。在这个过程中，如果我们去修改一个在中间的配置，需要下发到多个机房的上百个负责负载均衡的机器上，如果出现配置下发不及时，或下发配置失败，极大可能会出现故障，同时，负责均衡服务的机器对弹性能力的要求较高，在业务高峰如果不能快速扩容，容易出现全网故障。

　　传统的配置下发方式是通过服务端下发文件更新配置，更新配置生效时间长，由于需要预先知道负责均衡集群的机器信息，扩缩容需要等元信息同步以后才能接入流量，扩容流量的接入时间较长。

　　引入 Nacos 后，我们采用了配置中心监听方式，通过客户端主动监听配置更新，配置便可秒级生效，新扩容服务主动拉取全量配置，流量接入时长缩短 3 分钟+。

　　一是在 DNS-F 上，我们增加了对外部域名的预缓存的支持，Agent 的监控数据对接到公司的内部监控，日志输出也对接到内部的日志服务，然后和公司的 CMDB 对接，并实现了 DNS-F Cluster 集群。我们之所以去构建一个 DNS-FCluster 集群，是为了避免内存、硬盘或版本问题导致的 DNS 服务无效，有了 DNS-F Cluster 集群，当本地 Agent 出现问题的时候，就可以通过集群去代理和解析 DNS 请求。

　　二是在 Nacos-Sync 上，我们对接了 TAF 注册服务和 K8S 注册服务，以及解决了多数据中心环形同步的问题。

　　三是在 Nacos CMDB 上，我们对 Nacos CMDB 进行了扩展，对接了虎牙自己的 CMDB，并对接了内部的负载均衡策略。

　　本文作者：张波，Nacos Committer，虎牙基础保障部中间件团队负责人，阿里云 MVP。

　　首先看一下，微服务架构的演进历程中我们更关注的是什么？Serverless。这个过程中，每一次的进化，大体上可以认为都是通过拆分和抽象，伴随牺牲一定的性能，来达到最终提升人效的目的。

　　云端架构需要处理和应对可能出现的故障，保证架构和服务的可用性；还需要充分利用好云端的弹性，要能根据负载进行灵活的伸缩。

　　我们今天要聊的混合云部署，就是既在企业内部的私有云部署服务，又使用企业外部公有云部署服务的模式。和多机房一样，混合云部署同样要考虑几个关键的问题。

　　本文从核心、RPC、消息、无线网关、控制面、安全、运维、测试等模块对 Service Mesh 双十一大规模落地实践进行详细解析。

　　借着专栏即将结束的机会，我整理了一下大家的留言，总结了一些比较典型的问题，并从中挑选了5个在这篇文章中给与回答。

　　本文主要分析 WeiboMesh 在运行阶段请求路由的实现，对比现有的通用 Service Mesh （比如 Istio ）在这方面的不同。

　　18 年下半年，UCloud 对首尔数据中心机房进行了整体的热迁移。本文详细介绍了这个下项目中最后难度的工作之一：公共组件与核心管理模块迁移的方案设计和实践历程。

　　为数以亿计的用户提供优质的视频服务的爱奇艺技术产品团队，为了适应业务的快速迭代和创新，并支撑海量的用户请求，很多团队都对各自的业务系统自发地进行了微服务架构的改造。

　　UCloud 最新发布了名为“Sixshot”的可用区特性，用UCloud VP陈晓建的话说，“可用区就好比云计算的太祖长拳，看似平平淡淡，但要打得好着实不易。”本文是解密「云计算的太祖长拳」系列的第一篇，将全面解析UCloud可用区特性技术内幕，阐述基础网络的改造和外网新特性技术实现。

　　Qunar 运维自主研发一套故障自愈系统，解决了机房网络的上行和下行两个链路的问题。

　　2019年初，严选的服务数量已经近千，系统越来越庞大。为了能更好地支撑上业务的蓬勃发展，严选团队和网易轻舟团队开启了云原生平台的共建项目，以此拉开了严选应用云原生演进的帷幕。本文主要从严选的视角介绍一下相关的实践过程。

　　这篇文章并不是全盘否定 ZooKeeper，而只是根据阿里近 10 年来在大规模服务化上的生产实践，对服务发现和注册中心设计及使用上的经验教训进行一个总结。

　　百度网盘的实践落地并不只局限于 Service Mesh，首先是构建了从点延伸到线的 Service Mesh 进行服务通信管控，然后是在 UFC 这个 Service Mesh 的基础之上，站在全局视角对服务进行治理，保障服务的稳定性。

　　从PC时代主要从服务端提升访问质量，到智能调度流量，演进到移动智能时代，将接入控制能力延伸到终端。百度基础技术通过提供完整解决方案，实现了访问全链路优化。

　　本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...