IT技术博客大学习 共学习 共进步

标签:Microservices

共 9 篇相关文章

IT 累计浏览 2,040

一起来学 Spring 2.X

这是一份针对 Spring Boot 2.x 的全面学习指南,由作者唐亚峰在其个人博客上连载。系列文章从最基础的构建第一个 Spring Boot 工程讲起,为读者铺设了一条清晰的学习路径。 整个系列系统性地覆盖了 Spring Boot 2.x 开发中的核心技术栈。作者不仅详细解释了配置管理、日志框架这些基础内容,还深入到整合 Thymeleaf 模板、使用 JdbcTemplate、Spring Data Jpa 以及 MyBatis 进行数据库访问的实战环节。对于进阶需求,文章进一步探讨了如何集成 Lettuce Redis 做缓存、利用 Spring Cache 二级缓存、接入 RabbitMQ 消息队列(包括延迟队列的实现),以及使用 Swagger 进行接口在线调试。 除了核心功能集成,系列也关注应用运维与工程化实践。例如,通过 Actuator 与 Spring Boot Admin 实现服务监控与管理,配置定时任务,实现文件上传与全局异常处理,以及借助 Liquibase 进行数据库版本管理。在安全与性能方面,讲解了整合 Shiro 安全框架,使用本地锁与分布式锁防止重复提交,并探讨了分布式限流方案的优雅实现。甚至包括 JDK8 日期格式化这种实用细节和 WebSocket 聊天室搭建这样的趣味课题。 这个系列最大的特点是循序渐进且内容扎实,每一讲都聚焦一个明确的主题并提供可运行的示例,非常适合希望从零开始或系统性巩固 Spring Boot 2.x 开发技能的读者作为案头参考。

IT 累计浏览 2,161

组织解构,个体凸显,关系重组

这篇讲的是互联网如何从电子商务开始,逐步解构传统组织、放大个人价值,并最终推动生产关系变革的逻辑与趋势。 作者以一个简单对比切入:大型卖场受到电子商务冲击最大,而楼下小卖部却依然稳固。这背后是信息传递效率的提升直接击穿了旧的生产组织方式。随后,文章聚焦O2O的演进,从大众点评的信息连接,到团购的线上交易闭环,再到以易到用车为代表的共享经济模式,呈现了一个组织不断被解构、个人服务价值不断被凸显的进程。 文中特别辨析了易到用车与Uber在模式上的本质区别:前者在效率与个性化服务间寻求平衡,最大限度激励司机提升服务、建立个人品牌;后者则因系统派单的效率优先逻辑,在一定程度上抑制了个体的差异化价值。 作者最终指出,组织解构与个体价值凸显的趋势将渗透至生活各处。未来,鼓励个体发挥价值的平台将更受欢迎,高频服务会形成头部平台并整合长尾服务,一个全新的基于共享经济的大平台时代即将到来。

IT 累计浏览 3,681

应用层的容错与分层设计

这篇讲的是分布式系统中,如何为应用层远程调用构建健壮容错体系的实践思考。文章从实际项目问题出发,指出系统内部服务间远程调用的不可靠性——无论是网络波动、硬件故障还是服务本身变慢,都可能像多米诺骨牌一样拖垮整个系统。单纯依赖服务端容错还不够,调用端(应用层)必须有独立的防御设计。 作者以微博团队的实践为例,分享了不同场景下的容错策略:访问MySQL时,写操作直接抛异常,读操作则有多级Failover;连接Redis或Memcached则需设置超时、异常标记、定期探测,并通过一致性哈希切换到备份节点;调用HTTP接口则要短超时、谨慎重试,并配合业务降级。 这些分散的实现暴露了问题:各客户端独立编码,原理相通却无法复用,维护成本高,且同步调用消耗大量线程资源。文章进而探讨了统一解决方案的可能性,参考了Twitter的Finagle框架思路——将容错、重试等策略抽象为“Filter”,与服务和Future模型结合,实现异步化的通用网络客户端。一个理想的统一client应该具备分层设计(服务层、网络层)、可扩展协议支持,并内置负载均衡、Failover等高可用能力,最终让开发者更专注于业务逻辑而非繁琐的容错细节。

IT 累计浏览 4,062

中大型移动互联网公司技术架构选择

这篇讲的是中大型移动互联网公司在技术架构演进中的核心选择与思考。作者从多年经验出发,提出架构需快速部署、天然可扩展、高度自动化与量化,并尽可能保持同构化,以降低整体复杂度。 文章以一张手绘架构图为脉络,自上而下逐层剖析。核心方案强调:在接入层通过定制网络套件屏蔽客户端网络细节;业务层力求统一语言(如Java),避免异构系统带来的重复建设与兼容问题;RPC与队列需框架化,配置管理推荐ZooKeeper;日志系统选用scribe或Kafka,并指向HDFS/HBase进行数据分析。监控与跟踪系统则分别推荐了Ganglia、Nagios与Zipkin。 更底层,文章讨论了使用Docker/LXC进行硬件虚拟化,构建统一的PAAS资源控制与运维平台。在开发流程上,强调从自动部署、测试框架、Maven编译、Sonar代码质量到GitLab代码托管的完整工具链支撑,甚至包括用于故障反思的Post-mortem系统。 作者的最终目标很明确:通过这套从用户层到代码生成层的体系化设计,让开发、测试与运维工作尽可能自动化、标准化,从而支撑起业务的快速迭代与稳定运行。

IT 累计浏览 2,340

从概念的角度审视一淘商品搜索的Online系统架构

这篇技术文章从概念角度剖析了一淘商品搜索系统中的信息组织架构,直指当前设计的不足与优化方向。作者指出,随着商品数量增长,类目、产品节点(SPU/SKU)等层级信息在现有系统中存在割裂,特别是产品节点的类目关系和父子层级在Online系统中未被有效利用,导致搜索结果页(SRP)展示和导航逻辑存在缺陷。 文章引入了两个核心概念:AP(访问点/聚合点)与TAG(属性)。AP用于路径导航(如类目、SPU),TAG用于结果筛选(如颜色、尺寸),两者可动态转化。作者认为,当前依赖离线统计的QP决策机制存在局限,而通过构建并利用一棵完整的“AP树”,系统可以进行实时在线统计,从而更智能地决定产品的展示层次、结构化组合(Combo)以及跳转逻辑,大幅降低人工干预成本,提升用户导航体验。 其核心方案是统一CatId、SpuId、SkuId的数值空间,构建更完整的层级树,并增强模块的数据更新能力。这一架构不仅旨在解决当前节点展现别扭、导航路径单一的问题,还为关联推荐、公共信息提取等更丰富的产品功能打开了空间。

IT 累计浏览 1,601

知心怪蜀黍NO.3 社区通讯录的定位与拆分

这篇讲的是社区产品中一个看似小却至关重要的模块——通讯录的定位问题。作者纯银从实际产品经验出发,指出很多社区将通讯录设计为“万能入口”,导致其功能杂糅、定位模糊。 核心的解决方案在于清晰地拆分与回归。作者认为,通讯录最健康、最高效的定位,应该是“私信的通讯录”,服务于用户之间建立直接连接的需求。它不应该承担“找人聊天”的随机社交功能,也绝不能挪用为内容运营或功能跳转的工具栏。文章通过具体案例,分析了通讯录在“找人”与“找内容”两个方向上可能发生的错位,并给出了明确的拆分逻辑与设计建议。 最终,文章回归到产品设计的底层逻辑:一个功能模块的价值,取决于它能否清晰、高效地解决一个核心用户问题。将通讯录从复杂的“超级入口”中解放出来,回归其连接用户的本质,反而能提升整个社区的沟通效率。

IT 累计浏览 3,040

云计算与物联网

这篇讲的是云计算与物联网这两个经常被放在一起讨论,却又扮演着不同角色的技术。文章没有停留在简单的概念并列,而是从一张物联网导论和一张云计算示意图切入,试图厘清它们各自的侧生重点和协作关系。 核心对比在于:物联网(IoT)的世界是由无数感知设备、边缘网关和特定协议构成的,它侧重于数据的生成、采集与初步交互;而云计算则扮演着“中枢大脑”的角色,提供近乎无限的计算与存储资源,擅长对海量数据进行集中处理、分析和长期管理。作者指出,将两者割裂或简单等同都会导致实践的困惑。 文章进一步探讨了二者的融合趋势,例如在需要低延迟、高实时性的工业控制场景,纯粹的云中心模式可能力不从心,从而引出了“边缘计算”或“雾计算”等补充架构。真正的解决方案往往在于构建一个“端-边-云”协同的混合体系。理解这种分工与协作,是设计一个可靠、高效且经济的IoT系统的关键第一步。

IT 累计浏览 3,600

中庸之道的newsfeed的设计

这篇讲的是社交网络核心功能 Newsfeed 背后的一个基础架构权衡。作者从一个有趣的视角切入——万事万物的“中庸之道”,并将它映射到 Web 2.0 时代信息流的设计选择上。 文章剖析了两种经典思路:一种是“推”模式,即为每个消费者实时生成一份信息,优点是读取快,缺点是分发压力大;另一种是“拉”模式,即消费者登录时去主动拉取所有关注者的内容,优点是生产简单,缺点是可能给消费者带来延迟。作者指出,像 Facebook、Twitter 这样的系统,实际上都面对这个根本问题。 文章的核心观点在于,优秀的系统设计往往不是非此即彼的极端选择,而是像中庸之道一样,寻找最大与最小之间的合理结合点。作者引导读者思考如何在存储压力与读取速度、实时性与系统负载之间找到那个“极值点”与平衡区,从而创造出既合理又高效的架构。 这不仅是对一个具体技术问题的探讨,也启发了我们在面对任何复杂系统设计时,都应超越简单的二元对立,去思考更精妙的折中与融合。

IT 累计浏览 2,720

行业应用软件领域的问题是什么?

这篇讲的是行业应用软件领域长期存在的一些深层困境。作者从亲身经历出发,指出许多行业软件陷入“定制化陷阱”:为满足单个客户的特定需求而不断打补丁,最终代码臃肿、难以维护,也无法规模化。文章进一步分析了背后的原因——包括技术架构的先天不足、商业模式的短视,以及开发团队与业务场景的脱节。 文中特别提到,这种问题导致软件生命周期缩短,用户被锁定在昂贵且落后的系统中。作者认为,健康的行业软件应该建立在扎实的通用模块和可扩展的设计之上,通过配置化而非定制化来满足个性化需求。这对于当前数字化转型中的企业选择技术路径,仍具很强的警示意义。