皮皮网

1.flannel原理之subnet
2.HashiCorp IPO 解析
3.问题排查不再愁，源码Nacos 上线推送轨迹功能
4.实战：Nacos配置中心的分析Pull原理，附源码
5.七、源码Docker常用安装
6.RocketMQ—NameServer总结及核心源码剖析

flannel原理之subnet

       flannel包含subnet和backend两个关键模块，分析其中subnet模块负责子网的源码管理，包括子网的分析woodie指标源码申请与监控。在初始化时，源码subnet模块会尝试从etcd中获取一个未被使用的分析子网。当检测到其他子网的源码加入或移除，会向backend模块发送消息，分析后者据此调整相应的源码路由。

       本文旨在详细解析subnet模块的分析工作原理与代码结构。所有讨论基于flannel v0..0版本的源码源代码，我个人更倾向于使用老版本，分析主要原因是源码代码相对简洁，核心功能变化不大。

       subnet管理主要通过Manager接口实现，任何实现此接口的管理组件都可视为subnet manager。目前，subnet管理主要包括基于etcd和基于k8s的实现，如有需要，如使用consul，可自定义接口实现。

       与subnet相关的代码位于flannel/subnet目录下，包含etcdv2和kube两个目录。etcdv2是接口实现的核心部分。

       Manager接口定义了关键方法，包括获取网络配置、子网租赁以及监控子网状态。

       在etcdv2实现中，subnet manager使用两个关键文件：registry.go和local_manager.go。registry.go负责etcd请求的封装，为local_manager提供交互细节。local_manager实现接口方法，如从etcd获取网络配置、子网租赁以及监控子网状态。

       子网租赁过程复杂但巧妙。flannel采用策略从subnetMin到subnetMax之间随机选择个子网，最终选中一个，将其写入etcd的prefix/subnets/prefix/subnets/ip，用点分十进制替换为连字符表示。与DHCP不同，flannel没有DHCP服务器，而是各个flanneld节点协同完成子网申请，处理冲突和重试。

       子网状态监控由backend模块执行，通过监听etcd的事件，后者的操作逻辑在后续文章中会进行深入探讨。

       registry.go内部封装了与etcd交互的逻辑，对外提供接口供localManager使用。从registry角度看，etcd有两部分目录：$prefix/config存储网络配置，$prefix/subnets存储子网信息。registry中的*Subnet相关函数对这两个目录进行增删改查以及事件监听。

       撰写源码分析文章的体验揭示了从代码到实现思路的清晰表达。flannel的golang代码风格倾向于接口先行，先定义接口再具体实现，体现自顶向下的设计、自底向上的实现思维，这种风格显著提高了代码的可扩展性，便于添加新模块而无需修改现有backend模块。刷网的源码

HashiCorp IPO 解析

       近日，HashiCorp，一家行业领先的开源基础设施软件服务商，宣布申请 IPO。Morgan Stanley主导发行，预计募资金额超过1亿美元，股票代码为"HCP"。由Mitchell Hashimoto和Armon Dadgar共同创立的HashiCorp，旨在为云世界重塑基础设施管理。尽管Hashimoto在年卸任CEO，由Dave McJannet接任，Dadgar目前担任CTO，公司坚信“基础设施能激发创新”，提供一系列开源技术产品，以解决云应用面临的挑战。产品覆盖基础设施配置、安全、网络和应用部署，旨在助力大规模实时提供、保护、连接和运行基础设施。HashiCorp产品专为使IT运营商和从业人员实现云基础设施自动化设计。随着越来越多软件开发和向云端转移，HashiCorp提供业界领先的解决方案，加速企业的转型。主要产品包括Terraform、Vault、Consul和Nomad。产品为自我管理型，支持公有、私有和混合云部署。此外，HashiCorp还提供云平台HCP，用于集中管理。

       HashiCorp在开源产品下载量上表现亮眼，财年下载次数超过1亿次。同时，公司基于开源产品销售的专有软件，主要针对大型企业客户，表现积极。尽管未披露ARR数据，但截至上一季度，隐含ARR为2.亿美元，同比增长%；上季度平均收入留存率为%。目前，HashiCorp拥有名客户，其中ARR超过万美元的客户名，超过万美元的客户名。公司成立于年，年正式商业化运营。截至最近一次融资，HashiCorp共筹集3.亿美元，E轮融资由Franklin Templeton领投，投后估值.7亿美元。总部位于加州旧金山，员工以远程办公为主，总部员工仅占%。

       HashiCorp提供广泛的产品和部署模型，专注于基础设施自动化、生态系统支持及自助服务理念。开源麻将源码 github产品为自我管理型，支持公有、私有和混合云部署。尽管HCP占上季度总收入的5%，但增长最快。所有产品基于开放源代码开发，拥有活跃社区支持。尽管保持代码控制，任何人都可提出代码贡献，经审查后整合到代码库。产品可单独使用，也可作为堆栈协同工作，如Vault和Consul结合，构建零信任安全基础。鉴于企业转向多云和混合云，HashiCorp发现云服务商之间的空白，提供云基础设施自动化的单一控制平台，商业产品包括Terraform、Vault、Consul和Nomad。

       HashiCorp产品包括Waypoint、Boundary、Vagrant和Packer等，解决云运营模式挑战。从社区孵化到大规模商业产品发布，公司采用独特发展路径。以下是产品截图和原则图形。

       HashiCorp的盈利策略基于在开源产品上销售专有功能，主要通过订阅模式实现盈利。产品可部署于私有云、公有云或内部环境。HCP为云产品，增长最快。定价系统分层，随着使用量增加调整。对于自我管理产品，每个产品作为基本模块出售，HCP提供按小时或年付费选项，目标是逐步转变为基于使用量的定价模式。GTM战略结合开源模式的自助服务性和针对大型企业的直接销售。通过挖掘已有开源用户和自助云产品账户，销售团队直接进行销售。合作伙伴渠道也是重要组成部分，截至上个季度，HashiCorp有多家ISV和家ISV合作伙伴。扩张策略确保了高收入留存率，过去四个季度平均为%。主要商业产品Terraform和Vault驱动收入，占最近一段时间收入的%以上。

       市场机遇方面，HashiCorp受益于软件增长趋势，支撑管理新软件基础设施的需求。产品部署于公有云、私有云、多云和混合云，市场潜力巨大。IDC数据显示，预计年全球公有云服务市场规模将达到亿美元。HashiCorp通过预测基础设施、安全、风吹雨云商城源码网络和应用市场规模，估计未来市场规模。根据 Group数据，年这些市场合计规模为亿美元，预计年将达到亿美元。市场规模既包括云过渡重组的传统市场，也包括现代应用部署和基础设施管理的新市场。公有云和私有云市场分别预计在年至年间增长至亿美元和亿美元，复合年增长率达%。

       HashiCorp面临激烈的市场竞争，涉及单一云解决方案提供商、传统供应商以及新兴技术服务商。公司与AWS、Azure、GCP等公有云服务商竞争，与Red Hat、CyberArk、VMware、IBM等供应商竞争，同时也与Pulumi、Teleport等开源项目和产品竞争。开源软件构成公司主要竞争对手，许多公司选择自建基础设施，而非支付HashiCorp商业产品的费用。然而，管理复杂性要求专业知识，限制了这一策略的应用。

       HashiCorp股权结构包括GGV、IVP、Bessemer、Redpoint、True Ventures、Mayfield、TCV和Franklin Templeton等机构投资者。Dave McJannet并非联合创始人，于年成为CEO，拥有4%的发行前股份。股权基于流通在外的普通股和优先股。最近一轮融资在年3月，由Franklin Templeton领投，融资1.亿美元，投后估值.7亿美元，每股.亿美元。年5月，公司以每股.美元的价格出售约1.亿美元的股票，估值略低于E轮融资。以下是各大股东的股权分布：

       以下是关于HashiCorp产品的多个截图和代表原则的图形。

       HashiCorp的财务和其他指标显示，隐含ARR约3亿美元，同比增长%。HCP的隐含ARR接近万美元，同比增长%。毛利率非常高，比Confluent上一季度的%高出个百分点。非GAAP营业利润率为-%，表明公司仍处于亏损阶段。以下是业务和指标深入分析的图表。

       以下是关于HashiCorp客户和收入的多个图表，包括客户总数、ARR超过万美元的实物商城购买源码客户、ARR小于万美元的客户、新客户净增长、各季度、各细分的客户总数等。

       以下是关于客户增长的图表，包括客户数量变化、ARR超过万美元的客户增长、ARR小于万美元的客户增长、客户细分的隐含ARR和ACV趋势、按客户类别划分的隐含ARR等。

       以下是关于销售效率和投资回报周期的图表，包括净新增客户情况、隐含CAC指标、新增隐含ACV、美国本土与国际收入占比情况、现金流、季度损益表、季度指标、估值等。

       以下是关于HashiCorp估值的图表，包括按NTM收入计算的值、隐含ARR倍数范围、HashiCorp隐含企业价值等。

       HashiCorp正顺应数字化转型、云应用和多云基础设施的趋势，提供关键的云软件解决方案。公司产品广泛覆盖基础设施管理，拥有开源社区支持和全球市场覆盖，尤其在财富强企业中受欢迎。然而，公司面临的主要挑战包括市场竞争、增长速度放缓以及实现盈利的挑战。随着HCP等产品的快速发展，HashiCorp将寻求加速增长并持续推动创新，预计将迎来规模庞大的首次公开募股，吸引投资者关注。

问题排查不再愁，Nacos 上线推送轨迹功能

       在微服务体系下，注册与配置的管理成为日常运维的关键环节。然而，在面对调用或配置的频繁变更，特别是每日百万级的变更与亿级的推送时，问题排查成为了用户的一大困扰。传统的开源方案，如 Zookeeper、Eureka、Consul、Apollo 等，虽提供了基础的注册与配置服务，但在问题排查的可追溯性方面显得力不从心。它们仅提供了零星的日志记录，而无法直观判断推送过程是否成功，用户往往需要深入分析源码或通过登录注册与配置中心的节点，查看原始日志来寻找问题线索，这无疑增加了排查的难度。

       为解决这一行业痛点，Nacos 在行业内首度推出“推送轨迹”功能，以提升注册与配置中心的可观测性。推送轨迹功能，将服务或配置从服务器端到客户端的推送过程中的关键信息进行可视化展示，使用户能清晰了解每个推送事件的时间、送达客户端的IP地址、服务名称、所属分组、实例IP数量以及产生推送的Nacos节点名称。通过此功能，用户可以快速追踪并定位注册中心与配置中心在服务推送或配置变更过程中的异常，显著提高问题排查的效率。

       具体而言，Nacos的推送轨迹功能在注册中心层面，提供了服务推送记录的详细信息，包括推送时间、客户端IP、服务名称、服务分组、实例数量和节点名称等关键信息，同时支持根据服务和IP进行多维度查询。而在配置中心层面，用户能够查看配置变更的记录，包括变更事件和推送记录，以及与特定IP相关的推送轨迹。用户不仅可以查询到配置变更事件的MD5值、变更内容和推送时间，还能通过IP查询所有相关的推送轨迹，进一步了解配置变更和发布过程中各环节的详细情况。

       在实践应用中，通过选择查询维度，用户可以进一步细化查询范围，例如根据IP查询接收的所有推送信息。此外，Nacos还规划了后续的自诊系统，包括事件统计、健康审计等功能，旨在为用户提供更全面的业务功能状态数据，进一步降低注册与配置中心的问题排查难度，提升整体可用性。

实战：Nacos配置中心的Pull原理，附源码

       在单体服务时代，配置信息的管理相对简单，通常只需维护一套配置文件即可。然而，随着微服务架构的引入，每个系统都需要独立的配置，并且这些配置往往需要动态调整以实现动态降级、切流量、扩缩容等功能。这使得配置管理变得复杂。

       在传统的单体应用中，配置通常存储在代码或配置文件中。比如在Spring Boot中，可通过`@Value`注解加载来自yaml配置文件的配置。但这种方式存在缺点：修改配置需重启应用，对于大规模应用或频繁变更的配置，操作繁琐且容易出错。哪吒就曾思考，更新配置为何如此复杂？答案是，配置管理应该更高效和自动化。

       配置中心（Configuration Center）应运而生，它集中管理应用的配置信息，提供更灵活和便捷的配置管理机制。程序启动时自动从配置中心拉取所需配置，配置更新后，服务无需重启，实现动态更新。

       以Nacos为例，它采用Pull模式获取服务端数据。客户端以长轮询的方式定时发起请求，检查服务端配置是否变化。Nacos还支持注册中心功能，服务注册到Nacos，通过定时任务或心跳机制保持状态，确保调用服务时获取到的是健康在线的服务。服务端主动注销机制则用于管理服务的生命周期。

       配置中心提供了统一管理和动态更新配置的功能，显著降低了分布式系统中配置管理的成本，提升了系统的稳定性和可用性。配置注册、反注册、查看和变更订阅等功能使得配置管理更加高效。

       在选择微服务注册中心时，需考虑技术栈、团队熟悉度和业务需求。主流选项包括Eureka、Consul、Zookeeper和Nacos。最终选择应基于实际需求，综合考量这些因素，以找到最合适的微服务注册中心解决方案。

七、Docker常用安装

       安装Docker的总体步骤包括安装并配置常用软件如Tomcat、Nginx、MySQL、Redis、RabbitMQ、.NetCore项目、ELK、Consul、RocketMQ、Nacos及Sentry。具体操作如下：

       在安装Tomcat时，若计划将项目部署至根目录，需在tomcat文件夹创建ROOT文件夹，并将项目文件拷贝至其中。

       安装并配置Nginx以实现负载均衡，通过编辑nginx.conf文件，添加对应web应用的IP地址和端口号，并配置proxy_pass以指向upstream的名称。

       安装MySQL，通过特定命令映射端口、指定服务名称、挂载配置文件和日志目录，并初始化root用户密码。运行命令后，登录MySQL并展示数据库。

       安装Redis5.1，使用redis-cli连接Redis，并通过客户端工具配置redis。

       安装并部署.RocketMQ项目，使用Dockerfile创建并运行镜像，注意正确使用端口映射和命名。

       部署.NetCore项目，通过Dockerfile构建并运行镜像，确保数据库连接字符串使用宿主机IP。

       安装并配置ELK系统，使用Elasticsearch、Logstash和Kibana三个组件进行日志收集、处理和可视化。确保所有组件版本一致，并根据配置文件进行相应设置。

       安装Consul，通过拉取镜像并启动，访问其管理页面进行管理。

       安装RocketMQ，使用Docker-Compose环境搭建，配置docker-compose.yml文件以运行broker服务，并使用本机IP作为brokerIP。

       安装Nacos，通过访问其管理界面进行管理，使用默认登录账号和密码。

       安装Sentry，使用git下载源码进行安装，若忘记DSN，可通过项目设置找到。

RocketMQ—NameServer总结及核心源码剖析

       一、NameServer介绍

       NameServer 是为 RocketMQ 设计的轻量级名称服务，具备简单、集群横向扩展、无状态特性和节点间不通信的特点。RocketMQ集群架构主要包含四个部分：Broker、Producer、Consumer 和 NameServer，这些组件之间相互通信。

       二、为什么要使用NameServer？

       当前有多种服务发现组件，如etcd、consul、zookeeper、nacos等。然而，RocketMQ选择自研NameServer而非使用开源组件，原因在于特定需求和性能优化。

       三、NameServer内部解密

       NameServer主要功能在于管理路由数据，由Broker提供，并在内部进行处理。路由数据被Producer和Consumer使用。NameServer核心逻辑基于RouteInfoManager类，用于维护路由信息管理，提供注册/查询等核心功能。NameServer使用HashMap和ReentrantReadWriteLock读写锁来管理路由数据。

       四、结论

       作为RocketMQ的“大脑”，NameServer保存集群MQ路由信息，包括主题、Broker信息及监控Broker运行状态，为客户端提供路由能力。NameServer的核心代码围绕多个HashMap操作，包括Broker注册、客户端查询等。

zookeepervsetcdvsconsul哪个好?

       比较 Zookeeper、etcd 及 Consul，它们都是强大的一致性元信息存储解决方案。在服务应用中，它们的功能大多可以互相替代，例如主节点选举等功能。

       Zookeeper在开发和版本更新方面表现相对落后，社区活跃度也远不及etcd。从易用性角度看，etcd的RESTful API更符合应用需求，操作更为便捷。

       考虑周边产品生态时，开发者的语言偏好和应用环境也至关重要。如果团队熟悉Java并且有较多的Java应用，Zookeeper可能是更合适的选择。对于侧重于Go语言的团队，etcd则因其源码可读性成为更好的选项。

       综上所述，选择Zookeeper、etcd还是Consul，应综合考虑应用需求、技术栈以及团队熟悉度。在应用服务的广泛场景中，它们的互换性较强，具体选择应基于团队的实际情况和长期规划。

springcloud？

       å¾®æœåŠ¡æ¡†æž¶ä¹‹SpringCloud简介

       åœ¨äº†è§£SpringCloud之前先了解一下微服务架构需要考量的核心关键点，如下图：

       å¯¹äºŽä»¥ä¸Šç­‰æ ¸å¿ƒå…³é”®ç‚¹çš„处理，不需要我们重复造车轮，SpringCloud已经帮我们集成了，它使用SpringBoot风格将一些比较成熟的微服务框架组合起来，屏蔽掉了复杂的配置和实现原理，为快速构建微服务架构的应用提供了一套基础设施工具和开发支持。

       SpringCloud所提供的核心功能包含：

       SpringCloud架构图

       SpringCloud子项目

       SpringCloud旗下的子项目大致可以分为两类：

       å¦‚下：

       1.SpringCloud与SpringBoot

       SpringBoot可以说是微服务架构的核心技术之一。通过在SpringBoot应用中添加SpringMVC依赖，就可以快速实现基于REST架构的服务接口，并且可以提供对HTTP标准动作的支持。而且SpringBoot默认提供JackJson序列化支持，可以让服务接口输入、输出支持JSON等。因此，当使用SpringCloud进行微服务架构开发时，使用SpringBoot是一条必经之路。

       2.SpringCloud与服务治理(Eureka)

       æœåŠ¡æ²»ç†æ˜¯SpringCloud的核心，在实现上其提供了两个选择，即Consul和Netflix的Eureka。

       Eureka提供了服务注册中心、服务发现客户端，以及注册服务的UI界面应用。

       åœ¨Eureka的实现中，节点之间相互平等，有部分注册中心“挂掉”也不会对整个应用造成影响，即使集群只剩一个节点存活，也可以正常地治理服务。即使所有服务注册节点都宕机，Eureka客户端中所缓存的服务实例列表信息，也可让服务消费者能够正常工作，从而保障微服务之间互相调用的健壮性和应用的弹性。

       3.SpringCloud与客户端负载均衡(Ribbon)

       Ribbon默认与Eureak进行无缝整合，当客户端启动的时候，从Eureka服务器中获取一份服务注册列表并维护在本地，当服务消费者需要调用服务时，Ribbon就会根据负载均衡策略选择一个合适的服务提供者实例并进行访问。

       SpringCloud通过集成Netflix的Feign项目，为开发者提供了声明式服务调用，从而简化了微服务之间的调用处理方式。并且默认Feign项目集成了Ribbon，使得声明式调用也支持客户端负载均衡功能。

       4.SpringCloud与微服务容错、降级(Hystrix)

       ä¸ºäº†ç»™å¾®æœåŠ¡æž¶æž„提供更大的弹性，在SpringCloud中，通过集成Netflix下子项目Hystrix，通过所提供的@HystrixCommand注解可以轻松为我们所开发的微服务提供容错、回退、降级等功能。此外，Hystrix也默认集成到Feign子项目中。

       Hystrix是根据“断路器”模式而创建。当Hystrix监控到某服务单元发生故障之后，就会进入服务熔断处理，并向调用方返回一个符合预期的服务降级处理（fallback），而不是长时间的等待或者抛出调用异常，从而保障服务调用方的线程不会被长时间、不必要地占用，避免故障在应用中的蔓延造成的雪崩效应。

       è€ŒHystrix的仪表盘项目（Dashboard）可以监控各个服务调用所消耗的时间、请求数、成功率等，通过这种近乎实时的监控和告警，可以及时发现系统中潜在问题并进行处理。

       5.SpringCloud与服务网关(Zuul)

       SpringCloud通过集成Netflix中的Zuul实现API服务网关功能，提供对请求的路由和过滤两个功能

       è·¯ç”±åŠŸèƒ½è´Ÿè´£å°†å¤–部请求转发到具体的微服务实例上，是实现外部访问统一入口的基础。

       è¿‡æ»¤å™¨åŠŸèƒ½åˆ™è´Ÿè´£å¯¹è¯·æ±‚的处理过程进行干预，是实现请求校验、服务聚合等功能的基础。

       é€šè¿‡Zuul，可以将细粒度的服务组合起来提供一个粗粒度的服务，所有请求都导入一个统一的入口，对外整个服务只需要暴露一个API接口，屏蔽了服务端的实现细节。通过Zuul的反向代理功能，可以实现路由寻址，将请求转发到后端的粗粒度服务上，并做一些通用的逻辑处理。此外，Zuul默认会与Eureka服务器进行整合，自动从Eureka服务器中获取所有注册的服务并进行路由映射，实现API服务网关自动配置。

       6.SpringCloud与消息中间件(Stream)

       SpringCloud为简化基于消息的开发，提供了Stream子项目，通过建立消息应用抽象层，构建了消息收发、分组消费和消息分片等功能处理，将业务应用中的消息收发与具体消息中间件进行解耦，使微服务应用开发中可以非常方便地与Kafka和RabbitMQ等消息中间件进行集成。

       SpringCloudBus基于Stream进行扩展，可以作为微服务之间的事件、消息总线，用于服务集群中状态变化的传播。

       æ¯”如SpringCloudConfig借助Bus，可以实现配置的动态刷新处理。

       7.SpringCloud与分布式配置中心(Config)

       é’ˆå¯¹å¾®æœåŠ¡æž¶æž„下的配置文件管理需求，SpringCloud提供了一个Config子项目。SpringCloudConfig具有中心化、版本控制、支持动态更新和语言独立等特性。

       åœ¨Config子项目中将微服务应用分为两种角色：配置服务器（ConfigServer）和配置客户端（ConfigClient）。使用配置服务器集中地管理所有配置属性文件，配置服务中心可以将配置属性文件存储到Git、SVN等具有版本管理仓库中，也可以存放在文件系统中。默认采用Git的方式进行存储，因此可以很容易地对配置文件进行修改，并实现版本控制。

       8.SpringCloud与微服务链路追踪(Sleuth)

       SpringCloud中的Sleuth子项目为开发者提供了微服务之间调用的链路追踪。

       Sleuth核心思想就是通过一个全局的ID将分布在各微服务服务节点上的请求处理串联起来，还原了调用关系，并借助数据埋点，实现对微服务调用链路上的性能数据的采集。

       å› æ­¤ï¼Œé€šè¿‡Sleuth可以很清楚地了解到一个用户请求经过了哪些服务、每个服务处理花费了多长时间，从而可以对用户的请求进行分析。此外，通过将采集的数据发送给Zipkin进行存储、统计和分析，从而可以实现可视化的分析和展示，帮助开发者对微服务实施优化处理。

       9.SpringCloud与微服务安全(Security)

       SpringCloudSecurity为我们提供了一个认证和鉴权的安全框架，实现了资源授权、令牌管理等功能，同时结合Zuul可以将认证信息在微服务调用过程中直接传递，简化了我们进行安全管控的开发。

       SpringCloudSecurity默认支持OAuth2.0认证协议，因此单点登录也可以非常容易实现，并且OAuth2.0所生成的令牌可以使用JWT的方式，进一步简化了微服务中的安全管理。

       .SpringCloud的其他子项目

       è‡ªå®šä¹‰springcloud-gateway熔断处理

       ä¸€ã€åœºæ™¯

       ä½¿ç”¨springcloudgateway后，有了熔断，问题也就随之而来，服务间调用有了hystrix可以及时的排除坏接口、坏服务的问题，对系统很有帮助。但是！不是所有的接口都是极短时间内完成的，不是所有的接口都可以设置一样的超时时间的！

       é‚£ä¹ˆæˆ‘们面临一个问题，那就是百分之的接口都可以在1s内完美完成，但是就是那几个特殊接口，需要十几秒，几十秒的等待时间，而默认熔断的时间又只有一个。

       äºŒã€åˆ†æž

       åœ¨å‰é¢springcloudgateway源码解析之请求篇中我们知道请求会经过一些列的过滤器（GatewayFilter）,而springcloudgateway的降级熔断处理就是由一个特殊的过滤器来处理的，通过源码分析我们关注到HystrixGatewayFilterFactory这个类，这个类的作用就是生产GatewayFilter用的，我们看下它的实现

       å¯ä»¥çœ‹åˆ°çº¢æ¡†å¤„最后构建了一个匿名的GatewayFilter对象返回，这个对象在接口请求过程中会被加载到过滤器链条中，仔细看到这里是创建了一个RouteHystrixCommand这个命令对象，最终调用command.toObservable()方法处理请求，如果超时熔断调用resumeWithFallback方法

       é€šè¿‡æºç åˆ†æžgateway在路由时可以指定HystrixCommandKey，并且对HystrixCommandKey设置超时时间

       ä¸‰ã€æ–¹æ¡ˆ

       çŸ¥é“网关熔断的原理就好办了,自定义熔断的过滤器配置到接口请求过程中，由过滤器来读取接口熔断配置并构建HystrixObservableCommand处理请求。

       è‡ªå®šä¹‰ä¸€ä¸ªç±»XXXGatewayFilterFactory继承AbstractGatewayFilterFactory，将api和对应的timeout配置化，来实现细化到具体接口的熔断配置，具体实现如下：

       packageorg.unicorn.framework.gateway.filter;

       importcn.hutool.core.collection.CollectionUtil;

       importcom.netflix.hystrix.HystrixCommandGroupKey;

       importcom.netflix.hystrix.HystrixCommandKey;

       importcom.netflix.hystrix.HystrixCommandProperties;

       importcom.netflix.hystrix.HystrixObservableCommand;

       importcom.netflix.hystrix.exception.HystrixRuntimeException;

       importorg.springframework.beans.factory.ObjectProvider;

       importorg.springframework.cloud.gateway.filter.GatewayFilter;

       importorg.springframework.cloud.gateway.filter.GatewayFilterChain;

       importorg.springframework.cloud.gateway.filter.factory.AbstractGatewayFilterFactory;

       importorg.springframework.cloud.gateway.support.ServerWebExchangeUtils;

       importorg.springframework.cloud.gateway.support.TimeoutException;

       importorg.springframework.core.annotation.AnnotatedElementUtils;

       importorg.springframework.mand;

       if(CollectionUtil.isNotEmpty(apiTimeoutList)){

       //request匹配属于那种模式

ApiHystrixTimeoutapiHystrixTimeout=getApiHystrixTimeout(apiTimeoutList,path);

command=newUnicornRouteHystrixCommand(config.getFallbackUri(),exchange,chain,initSetter(apiHystrixTimeout.getApiPattern(),apiHystrixTimeout.getTimeout()));

       }else{

       command=newUnicornRouteHystrixCommand(config.getFallbackUri(),exchange,chain,initSetter(serviceId(exchange),null));

       }

       returncommand;

}

       /

***@paramapiTimeoutList

*@parampath

*@return

*/

privateApiHystrixTimeoutgetApiHystrixTimeout(ListapiTimeoutList,Stringpath){

       for(ApiHystrixTimeoutapiTimeoutPattern:apiTimeoutList){

       if(this.antPathMatcher.match(apiTimeoutPattern.getApiPattern(),path)){

       returnapiTimeoutPattern;

}

       }

       ApiHystrixTimeoutapiHystrixTimeout=newApiHystrixTimeout();

       apiHystrixTimeout.setApiPattern("default");

       apiHystrixTimeout.timeout=null;

       returnapiHystrixTimeout;

}

       @Override

publicGatewayFilterapply(Configconfig){

       return(exchange,chain)-{

       UnicornRouteHystrixCommandcommand=initUnicornRouteHystrixCommand(exchange,chain,config);

returnMono.create(s-{

       Subscriptionsub=command.toObservable().subscribe(s::success,s::error,s::success);

       s.onCancel(sub::unsubscribe);

}).onErrorResume((Function)throwable-{

       if(throwableinstanceofHystrixRuntimeException){

       HystrixRuntimeExceptione=(HystrixRuntimeException)throwable;

HystrixRuntimeException.FailureTypefailureType=e.getFailureType();

switch(failureType){

       caseTIMEOUT:

       returnMono.error(newTimeoutException());

       caseCOMMAND_EXCEPTION:{

       Throwablecause=e.getCause();

if(causeinstanceofResponseStatusException||AnnotatedElementUtils

       .findMergedAnnotation(cause.getClass(),ResponseStatus.class)!=null){

       returnMono.error(cause);

}

       }

       default:

       break;

}

       }

consulmanager部署和使用

       书接上回 渐行渐远：prometheus的安装以及监控指标的配置

       这次主要介绍如何使用consulmanager 去监控各个监控项

       一 consulmanager安装

       github.com/starsliao/Te... #consulmanager项目地址

       consulmanager 是一个开源的项目，现在已经更名为tensuns，有兴趣的可以自行研究

       要想安装consulmanager，必须先安装下面三个 docker ，docker-compase， consul

       1.1 安装consul

       1.1.1 安装consul-基于centos7

       1.1.2 生成uuid

       1.1.3 配置文件设置

       1.1.4 启动consul

       访问方式 ip:

       1.2 安装docker和docker-compase

       1.2.1 安装docker

       1.2.2 安装docker-compase

       二 安装 ConsulManager

       2.1 下载源码

       下载地址 github.com/starsliao/Co...

       目录结构如下：

       2.2 docker-compose.yml 内容

       2.3 启动并访问

       三 配置consulmanager

       3.1 云主机管理

       3.1.1 同步云主机

       云主机管理就是可以自动同步云服务器到consulmanager这个上面

       前提是需要你在云账号里面创建access key 和secret key,这个账号还需要有访问主机的权限

       新增云资源

       创建完成之后，你可以手动同步，也可以自动同步，然后去云主机列表查看，是否同步过来了

       3.1.2 批量云主机监控

       前提是每天主机需要安装好node-exporter

       选定好指定的组，选择好系统，点击生成配置，然后把这个配置，粘贴到prometheus的配置文件中

       进行重启prometheus

       然后进去到prometheus-target里进行查看

       当然如果你的node-exporter的端口不是,怎么办，打开cousul的web页面，可以自定义设置

       3.1.3 导入对应的模版

       导入ID：

       详细URL： grafana.com/grafana/das...

       3.1.4 设置告警规则

       3.2 blackbox站点监控设置

       3.2.1. 配置Blackbox_Exporter

       在Web页面点击

       Blackbox 站点监控/Blackbox 配置，点击

       复制配置，如下所示：

       复制配置到 blackbox.yml，清空已有的配置，把复制的内容粘贴进去，重启blackbox_exporter

       3.2.2 配置Prometheus

       在Web页面点击 Blackbox 站点监控/Prometheus 配置，点击复制配置。编辑Prometheus的

       prometheus.yml，把复制的内容追加到最后，reload或重启Prometheus

       3.2.3. 配置Prometheus告警规则

       在Web页面点击

       Blackbox 站点监控/告警规则，点击复制配置。

       编辑Prometheus的配置文件，添加 rules.yml，然后把复制的内容粘贴到rules.yml里面，reload或重启Prometheus。

       然后去prometheus查看告警规则是否生成

       3.2.4. 查看Prometheus

       在Prometheus的Web页面中，点击Status-Targets，能看到新增的Job即表示数据同步到Prometheus。

       3.2.5 新增tcp或者/grafana/das...

       最终在grafana访问的效果如下：

       四 总结

       到这里基本的监控项和报警规则都已经设定好了，接下来会介绍告警的方式和具体实现

RocketMQ4.9.1源码分析-Namesrv服务注册&路由发现

       路由中心在消息队列系统中的作用在于管理和提供路由信息，以简化消息的路由过程。在传统的模型中，生产者直接连接消息队列服务器，但随着集群扩展，需要更灵活的路由管理机制。路由中心引入，负责监控和管理集群中的实例，实现动态路由发现和实例状态感知。其核心功能包括实例注册、路由信息更新与实例状态监控。

       路由中心通过心跳机制感知实例数量的变化，确保路由信息的实时更新。常见的路由中心系统包括zookeeper、consul和etcd，它们支持分布式系统中的服务发现和配置管理。

       在RocketMQ中，Namesrv扮演着路由中心的角色，提供关键功能包括服务注册、路由信息管理和实例状态监控。Namesrv的核心在于保存和维护路由元信息，如topic、队列、broker地址等，并支持查询和更新操作。

       在RocketMQ源码中，服务注册功能通过`processRequest()`方法实现，根据请求类型执行相应的逻辑。对于注册broker的请求，通过`registerBrokerWithFilterServer()`或`registerBroker()`方法处理，具体实现细节在源码中体现。注册流程涉及多个步骤，确保broker信息的正确记录和更新。

       路由信息的删除主要涉及两种情况：broker正常停止或异常。当broker正常停止时，它会向Namesrv发送注销消息，Namesrv接收到此消息后，从相关数据结构中移除该broker的信息。当broker异常时，Namesrv通过心跳机制检测实例状态，并在超时后主动删除相关路由信息，以保持路由信息的准确性和实时性。

       RocketMQ的设计中，Namesrv采用定时任务监控实例状态，通过发送心跳包或记录最后心跳时间，来检测异常实例并及时更新路由信息。这一机制确保了系统在实例动态变化时，能够高效地管理路由，提供稳定和可靠的消息传输服务。

       通过上述描述和分析，可以清晰地了解到路由中心在消息队列系统中的重要作用，以及Namesrv在RocketMQ中如何实现关键功能以支持动态路由管理和实例状态监控。