Day01

简介: Day01:微服务并非绝对优于单体,需结合业务场景。简单应用单体更优,复杂系统适合微服务。常用中间件如Nacos、OpenFeign、Gateway等。Nacos支持心跳机制与主动检测,临时实例异常剔除,非临时则保留。对比Eureka,Nacos在服务发现、健康检测、集群模式上更具优势。负载均衡常用轮询算法。

Day01

每日必会
微服务的好处?一定比单体好吗?

面试官这个不一定,技术还是为业务服务的,简单的业务单体肯定更好,他没有分布式事务、服务雪崩等一系列服务治理的问题,并且部署、维护成本低。微服务更适合一些表模型复杂、业务链路长的场景,这样虽然会带来一些服务治理问题,但是也降低了服务之间的耦合,有利于后续的服务拓展。

微服务你用到了哪些中间件

我的项目用到了Nacos,当做注册和配置中心;远程服务调用OpenFeign;网关GateWay

SPRINGCLOUDGATEWAYZUUL

SPRINGCLOUDALIBABA

SPRINGCLOUDCONFIG,NACOS

EUREKACONSU

SPRINGCLOUD

服务监控和保护

DUBBO-ADNIN,功

SPRINGCLOUDGIATEWAY

SPRINGCLOUACONFIG

ZK,REDIS,NACOS

配置中心

SENTINEL

DUBBO

服务网关

IGNHTTP协I

HSTRIX

服务远程调用

功能弱

DUBBO,FEIGRN

DUBBO协议

注册中心

EUEKA

NACOS

ZUL

无

无


Nacos注册中心的心跳机制

Nacos支持服务端主动检测提供者状态:临时实例采用心跳模式,非临时实例采用主动检测模式临时实例心跳不正常会被剔除,非临时实例则不会被剔除

NACOS注册中心细节分

服务消费者

册服务信息

ACOS主动询问

L0CALAOST:8O81

服务列表缓存

USER-SEVICE:

采用心跳监测

注册中心

服务PU11

服务提供者

定时拉取

ACOS

远程调用

非临时实例

临时实例

00


●这里也有可能问到Eureka和Nacos的区别,我贴个图有点印象(比较少,了解即可)

EUREKA-CLIENT

心跳续约,每30秒1次

UREKA的作用

USERSERVICE

1OCA1HOST:8082

UREKA-SEVER

服务消费者

USERSERVICE

1OCA1HOST:8080

USER-SERVICE的信息

服务提供者

2)拉取服务

LOCA1HOST:8081

1OCA1HOST:8081

1OCA1HOST:8082

)远程调用

1OCALHOST:8083

注册中心

1)注册服务信息

OCA1HOST:8081

1OCA1HOST:8083

SER一SERVICE

ORDER-SERVICE:

....,3)负载均衡

USER-SERVICE:

USER-SERVICE

ERVICE

8083

8082

ORDER-

8081

8080


Nacos与eureka的共同点
一都支持服务注册和服务拉取
二都支持服务提供者心跳方式做健康检测
Nacos与Eureka的区别
一Nacos支持服务端主动检测提供者状态:临时实例采用心跳模式,非临时实例采用主动检测模式
二临时实例心跳不正常会被剔除,非临时实例则不会被剔除
三Nacos支持服务列表变更的消息推送模式,服务列表更新更及时
四Nacos集群默认采用AP方式,当集群中存在非临时实例时,采用CP模式;Eureka采用AP方式

常见的负载均衡算法

有轮询、加权轮询、权重、响应时间、随机、区域可用等吧,我们项目中一般都是轮询,它的意思就是当有多台机器的时候,就一个一个轮着来。

理论专项
●Java基础
○JMM模型
○HashMap
○线程池核心参数
○synchronized

相关文章
|
前端开发 架构师 搜索推荐
COLA 4.0:直击应用架构本质的最佳实践
COLA 4.0:直击应用架构本质的最佳实践
4392 1
COLA 4.0:直击应用架构本质的最佳实践
|
开发框架 前端开发 Linux
开源项目推荐:C++ Web/Http Server/Rest开发框架(请重点关注Oat++和搜狗workflow)
开源项目推荐:C++ Web/Http Server/Rest开发框架(请重点关注Oat++和搜狗workflow)
5378 0
|
7月前
|
安全 API 决策智能
AutoGen 架构演进全梳理:从 v0.4 到 Microsoft Agent Framework
Microsoft AutoGen(2023–2025)是开创性多智能体开源框架,以“群聊式协作”替代单Prompt链,支持智能体对话、工具调用、代码执行与人工介入。v0.4达技术巅峰,后并入Microsoft Agent Framework(MAF)。其核心范式——LLM专家团队协同——已成行业标准。
2165 3
AutoGen 架构演进全梳理:从 v0.4 到 Microsoft Agent Framework
|
7月前
|
人工智能 API 网络安全
零技术阿里云/本地部署 OpenClaw 全模态落地:MiniMax语音绘图+千问/Coding Plan模型配置实战
在AI协同逐步成为主流工作模式的当下,OpenClaw(曾用名Clawdbot、Moltbot)凭借轻量化部署、多模态交互、多模型统一调度能力,成为个人与团队高效使用AI能力的首选框架。其核心价值在于打通语音对话、图像生成、文本处理、工具调用等全链路能力,同时支持云端与本地混合部署,满足不同场景的隐私与算力需求。本文基于2026年最新实践,完整覆盖阿里云服务器部署、本地macOS/Linux/Windows11三端部署、阿里云千问大模型与免费Coding Plan模型配置、MiniMax全模态能力集成,以及各类常见问题的系统性解决方案,所有指令均可直接复制使用,无需额外调试即可完成从环境搭建到
1348 0
|
7月前
|
人工智能 安全 API
告别多App切换!OpenClaw阿里云/本地部署+多渠道集成,把AI装进微信/WhatsApp
工作中需要反复切换ChatGPT网页查资料,手机端想调用AI却没有便捷入口,想要自动化流程却被复杂配置劝退——这些痛点,开源项目OpenClaw都能完美解决。它并非简单的聊天机器人,而是能将AI能力融入微信、WhatsApp等日常消息应用的智能代理工具,支持本地私有化部署与云端稳定运行,既能执行命令、读写文件、调用外部API,还具备长期记忆功能,真正成为融入日常的AI助手。
1408 11
|
8月前
|
机器学习/深度学习 算法 物联网
高效微调方法对比:选择最适合你的微调策略
本文对比LoRA、QLoRA、Adapter、Prefix/Prompt Tuning等主流高效微调方法,从参数效率、显存占用、推理延迟、实现难度和任务适配性五维度分析,助开发者根据硬件条件与场景需求选择最优方案。
|
5月前
|
缓存 监控 NoSQL
【Redis】Redis缓存三大核心问题:缓存穿透 / 击穿 / 雪崩(原因 + 解决方案)
本文系统解析Redis缓存三大高危问题:**穿透**(查不存在数据)、**击穿**(热点Key过期瞬间并发压库)、**雪崩**(大量Key集中失效或集群宕机)。深入剖析根因,提供分层防护方案——布隆过滤器+参数校验防穿透、永不过期+本地缓存防击穿、过期打散+高可用架构防雪崩,并强调全链路兜底与生产避坑要点。
1093 2
|
人工智能 自然语言处理 前端开发
智能体三强争霸:Coze、Dify、FastGPT谁是企业AI化的最优解?
2025年AI智能体技术爆发,企业面临如何高效实现AI化的挑战。Coze、Dify、FastGPT作为三大热门平台,各具特色:Dify主打开源与全球化,Coze专注对话式AI,FastGPT深耕企业知识库。本文从技术架构、功能、部署、生态等维度深入对比,帮助企业找到最适配的AI引擎,推动智能化转型。
|
存储 缓存 人工智能
《从木偶江湖到活色长安:NPC行为失控的架构级解决方案》
本文聚焦武侠开放世界游戏《江湖余烬》内测时,长安城高NPC密度、高交互场景下的NPC行为崩坏问题—25%的NPC出现动作重复、卡墙、剧情“失忆”等异常,仅在极限场景触发且常规修复无效。文章梳理了“主状态机+子行为树”的NPC技术架构,通过三层排查锁定核心矛盾:主线程卡顿致状态切换时序错乱,内存碎片引发数据串扰,事件总线拥堵形成恶性循环。经“状态协同重构+内存总线优化+监控容灾搭建”的三层解决方案,最终将NPC崩坏率降至0.3%,玩家投诉大幅下降,同步总结出开放世界NPC系统设计的五大核心教训,揭示架构协同稳定性对游戏沉浸感的关键意义。
682 1
|
监控 Cloud Native 调度
《云原生架构从崩溃失控到稳定自愈的实践方案》
本文以某大型电商供应链系统“618”大促期间的“服务雪崩”故障为切入点,剖析了云原生架构在极端流量下的稳定性短板。故障根源在于库存调度服务接口设计缺陷导致数据库连接池耗尽,且服务间缺乏熔断隔离机制,引发全链路瘫痪。技术团队通过重构核心接口、引入“熔断-隔离-降级”防护体系、搭建三位一体监控闭环、设计全流程流量管控方案,并开展常态化故障注入演练,实现架构从“事后救火”到“事前防御”的转变。改造后系统故障恢复时间大幅缩短,核心业务零中断,同时沉淀出云原生架构抗风险建设的实战方法论。
435 5

热门文章

最新文章