建设通招标网站,怎么评价网站做的好坏,wordpress上传参数有哪些,网站中查看熊掌号怎么做的博主介绍#xff1a;✌全网粉丝4W#xff0c;全栈开发工程师#xff0c;从事多年软件开发#xff0c;在大厂呆过。持有软件中级、六级等证书。可提供微服务项目搭建与毕业项目实战、定制、远程#xff0c;博主也曾写过优秀论文#xff0c;查重率极低#xff0c;在这方面… 博主介绍✌全网粉丝4W全栈开发工程师从事多年软件开发在大厂呆过。持有软件中级、六级等证书。可提供微服务项目搭建与毕业项目实战、定制、远程博主也曾写过优秀论文查重率极低在这方面有丰富的经验✌ 博主作品《Java项目案例》主要基于SpringBootMyBatis/MyBatis-plusMySQLVue等前后端分离项目可以在左边的分类专栏找到更多项目。《Uniapp项目案例》有几个有uniapp教程企业实战开发。《微服务实战》专栏是本人的实战经验总结《Spring家族及微服务系列》专注Spring、SpringMVC、SpringBoot、SpringCloud系列、Nacos等源码解读、热门面试题、架构设计等。除此之外还有不少文章等你来细细品味更多惊喜等着你哦 开源项目免费哦点击这里克隆或者下载 已经发布Vue3版 文末获取联系精彩专栏推荐订阅 不然下次找不到哟 Java项目案例《100套》 uniapp小程序《100套》 目录
一、为什么选择Nacos
二、DNS-F的技术价值
三、DNS-F的应用场景
四、DNS-F在数据库场景的落地
微服务实战 一、为什么选择Nacos 虎牙关注 Nacos 是从 v0.2 开始的也参与了社区的建设可以说是最早期的企业用户。 在虎牙的微服务场景中原先存在多个注册中心每个注册中心服务于不同的微服务部分导致缺少一个能够整合这些注册中心并将它们逐一打通的大型注册中心来管理整个微服务生态系统。因此考虑使用Nacos作为服务注册中心以下是考虑使用Nacos的原因 1. 相比其他方案Nacos可以与多个开源产品集成例如k8sspring cloud和dubbo, 并使用dns-f作为agent因此不需要额外的配置或本地安装agents或SDK。 2. Tseer Agent, Consul等方案需要本地安装agents或SDK且他们仅仅提供限定的接口因此它们不太适合支持不同的开源产品。 3. K8s使用coreDNS来查询IP地址,但为集群配置单个DNS因此无法管理整个微服务生态系统而Nacos则可以用来管理整个微服务生态系统。 4. Spring Cloud的大部分功能需要深度集成SDK中才能实现这使得它难以支持其他语言。 5. L5是腾讯内部的服务发现方案同样需要本地安装L5 agent向L5 DNS获取到服务数据因此也不能适应不同的开源产品。 综上我们认为使用Nacos作为服务注册中心是一个非常好的选择因为它可以通过dns-f作为agent并且支持多种开源产品的集成同时也为提供了一个管理整个微服务生态系统的中心。 心。 Nacos支持DNS-F功能可以集成多个开源产品如K8S、Spring Cloud和Dubbo以实现服务的注册。在选择服务配置中心方案时希望能够打通配置中心和注册中心以省去在微服务治理方面的投入。因此还比较了几个服务配置中心的开源方案 在当前技术发展的背景下许多开发者都在关注和探索不同的配置中心Configuration Center如Nacos、Spring Cloud Config Server、ZooKeeper和Etcd等。这些工具通过提供一个中心化存储器和API接口使得配置修改、版本管理和配置推送等功能变得更加高效。 虽然这些配置中心都有着其独特的优势但是它们同时也存在一些不同的缺点。 下面将这些配置中心进行优缺点对比 - Nacos Nacos提供一个直接在控制台上进行配置修改的功能并且修改的配置能够自动推送到监听的客户端。同时它还支持多种API接口RESTful APIJava Native接口Spring Cloud接口等并且能够自动记录各个修改的版本信息便于追踪和管理。总的来说Nacos具有易用性高、扩展性强、功能丰富等特点。 - Spring Cloud Config Server Spring Cloud Config Server需要使用Git仓库进行配置修改并且客户端只能在启动的时候加载。虽然它也支持多种API接口和其他语言客户端但是在版本管理方面相对比较弱。总的来说Spring Cloud Config Server适用于Web应用程序特别是基于Spring的应用程序。 - ZooKeeper ZooKeeper是一个支持Java原生接口的配置中心同时提供配置自动推送的功能。但是它没有自动记录版本信息和配置推送历史等功能需要通过调用ZK API进行相应的修改。总的来说ZooKeeper适用于分布式系统的管理和控制。 - Etcd Etcd通过提供RESTful API进行配置修改并且修改的配置能够自动推送到监听的客户端。但是它也没有自动记录版本信息和配置推送历史等功能且也需要通过调用来Etcd API进行相应的修改。总的来说Etcd适用于基于容器的云原生应用程序和大规模分布式系统。 基于以上对比和综合分析建议选择Nacos作为配置中心。因为它不仅易于使用和扩展而且具有较强的版本管理和配置推送追踪能力适合各种类型的应用程序 针对微服务体系现状以及业务场景在诸多可选服务注册和服务发现的方案中综合对比了Spring Cloud Config Server、Zookeeper 和 ETCD最终选择了Nacos。在使用过程中发现Nacos的优势远比调研过程中发现的更多。下面将以DNS-F、Nacos-Sync、CMDB 和负载均衡为例分享虎牙的实践 二、DNS-F的技术价值 Nacos提供的DNS-F功能带来的技术价值有以下四个方面。 首先DNS-F功能填补了内部微服务缺乏全局动态调度能力的空白。相比之下多个微服务体系之间缺乏独立和协同操作能力需要借助Nacos来融合注册中心以使微服务体系之间实现全局动态调度。 其次DNS-F解决了服务端内部面临的挑战包括延时、解析不准和故障牵引慢的问题。在具体应用时一些微服务框架并不支持同机房或者CMDB路由。在一个服务被注册到多个IDC中心后即使在同一机房内也可能调用不同机房的节点导致无端延迟和解析不准。即使在DNS解析优化之后也不可能解决全部 延时和解析不准问题因为DNS只是IP策略的近地解析并不能根据服务的物理状态和物理信息进行路由同时缺乏统一的注册中心当核心服务出现异常问题时难以准确判断如何进行故障牵引从而导致故障牵引慢。连接Nacos的全局注册中心和配置中心可以解决这些问题。目前虎牙还在微服务体系的改造过程中未完全实现统一的注册中心 第三DNS-F功能提供了专线流量牵引能力解决了核心机房流量互通的问题。专线特有的物理建设特性和专线容量的冗余只有50%的情况下某个服务可能出现突发流量大于平时两百倍的情况超出专线的建设能力从而可能导致全网故障。但是通过Nacos的全局注册中心和调度能力可以将流量牵引到其他地方例如迁移到公网或者牵引到一个不存在的地址来平衡流量。某个服务出现问题也不会影响全局服务。 第四DNS-F功能支持服务端的多种调度需求包括同机房路由、同机器路由以及同机架路由。同时基于Nacos的DNS-F功能还实现了外部域名解析的加速和服务故障牵引的秒级生效。 三、DNS-F的应用场景 该图描绘了 Nacos DNS-F 的实际运作。它通过拦截 OS 层的 DNS 请求来处理域名。当 DNS 请求的域名属于内部服务时Nacos DNS-F会从 Nacos Server 获取结果。如果域名并非内部服务Nacos DNS-F 将会将其转发给其他 LocalDNS 完成解析。 四、DNS-F在数据库场景的落地 以数据库高可用的应用场景为例数据库切换效率较低依赖业务方手动修改配置时效不确定通常需要10分钟以上。尽管数据库已经实现了主备功能但当主服务出现问题而需切换IP时仍需要时间与运维和开发协作。 为了解决这个问题我们引入DNS技术。DNS可快速使用备用主机的IP地址进行切换屏蔽故障同时自动实现故障检测和故障切换无需运维和开发协作节省宝贵时间。此外也可使用MySQL-Proxy等其他场景适用的解法但MySQL-Proxy还在建设中使用DNS技术是目前最为合适的解决方案。 最后分享基于DNS-F对LocalDNS的优化。目前还没有建设自己的LocalDNS而是使用公共的DNS大致有以下组成部分。 在应用程序中使用公共 DNS 能够带来某些好处。然而这种组成方式存在一个问题如果服务突然崩溃然后又马上恢复我们将无法重现崩溃原因。这是因为在许多情况下请求超时或解析失败是由公共 DNS 引起的。由于无法保留现场信息导致难以发现问题。 根据我们的监测数据使用公共 DNS时DNS 解析错误率约为1‰而超时比例则更高。这意味着如果服务没有做好容错处理服务会出现异常。值得注意的是许多公共 DNS 解析节点的延迟是不稳定的导致解析延迟相差较大。比如在亚马逊上部分不良节点解析延迟平均超过三四十毫秒。 为了优化使用公共 DNS 所带来的问题我们针对本地DNS基于DNS-F进行了一系列优化。 优化效果如下 ● 平均解析时间从之前超过两百毫秒降低至两毫秒以下 ● 缓存命中率从92%提升至99%以上 ● 解析失败率之前为1‰现在基本上没有了。 这些优化效果还体现在我们的风控服务上。平均延迟与异常比例分别降低了10毫秒和25%有效降低了因延迟或服务超时导致用户上传的图片或文字违规事件。 微服务实战 ✨【微服务】SpringCloud的OpenFeign与Ribbon配置 ✨集Oauth2Jwt实现单点登录 ✨Spring Cloud Alibaba微服务第29章之Rancher ✨Spring Cloud Alibaba微服务第27章之Jenkins ✨Spring Cloud Alibaba微服务第24章之Docker部署 ✨Spring Cloud Alibaba微服务第23章之Oauth2授权码模式 ✨Spring Cloud Alibaba微服务第22章之Oauth2 ✨Spring Cloud Alibaba微服务第21章之分布式事务 ✨Spring Cloud Alibaba微服务第18章之消息服务 ✨Spring Cloud Alibaba微服务第16章之服务容错 ✨Spring Cloud Alibaba微服务第14章之分库分表 ✨Spring Cloud Alibaba微服务第11章之MyBatis-plus ✨Spring Cloud Alibaba微服务第8章之OpenFeign ✨Spring Cloud Alibaba微服务第7章之负载均衡Ribbon ✨SpringCloud Alibaba微服务第6章之Gateway ✨SpringCloud Alibaba微服务第4章之Nacos ✨SpringCloud Alibaba微服务开篇
