【另类架构】之驾车感悟(下)

简介: 【另类架构】之驾车感悟(下)

路面积水问题

当日是个雨后的早晨,四处都有积水。

这是发生在“变道转向”之后再次让我陷入思考的第二件事。


image.jpeg


示意图如上,我要说的积水问题必须是在高架上下闸道口的坡面上的。为什么我不说更常见的平坦路面的积水区呢?因为作为一个有素质的老司机,经过平坦路面的积水区时路边若是有行人,必然速度放缓慢慢前行,以防积水泼溅到路人。而在高架坡面上因为视野中看不到高架底下的行车或者行人,有些时候下意识的就冲过去,高架下方“争渡争渡惊起一滩鸥鹭”。


这里还是友情提醒一下,驾车但凡涉水不管什么情况都要放缓,这对别人对自己都没坏处。


那么这个故事到底对架构有借鉴意义呢?请大家思考:

  • 路面为什么会有积水?
  • 积水情况是否有监控?
  • 我只是高架路面设计师,如何想得到高架下的行车或行人?


路面为什么会有积水

原因无非两个,路面不平整或者没有倾斜度,排水系统不给力。对于路面施工的质量问题,没什么好说的,施工和验收环节都没做到位。而依赖的排水系统不给力,对于高架施工队来说这个锅好像是可以甩给排水系统团队的。


无需多言,这里我要类比的软件架构类别是“服务治理”。很明显高架路面系统依赖了排水系统,那我们就来说道说道限流、路由、熔断、降级这四块。


限流比较容易理解,我的排水管道就这么粗,你拿盆往里灌肯定喷出来,所以超出排水管道处理能力的水就不收了。那多的这些水怎么处理呢?不知道大家有没有听过“海绵城市”,通过一些特殊材料或特殊管道设计,将这些水先蓄在某些地方,以后随时可以拿来浇浇公园的花草啥的也算有效利用,架构里这就是常见的“削峰”,一般通过MQ队列来实现。当然还有更简单粗暴的就是水从哪里来回哪里去,我路边整几排烧红的铁棒,水一沾上就变为蒸汽蒸发掉了(好像发现了什么了不得的发明), 架构里对应的就是“快速失败”,既然系统已经处理不了你了,就直接给你个失败应答完事。


路由就是把水引流到不同的排水口(多个排水口可以理解成排水系统的分布式多节点),污水和雨水是不同的排水通道,这个可以叫灰度或A/BTest;大雨会启动更多的排水口进行排水,或者易积水路段使用大的排水口,这个叫“弹性扩容”或者“权重路由”。


熔断就像家里的保险丝,当排水系统达到自己能力的上限,水再也进去不去的时候(响应超时持续报错),排水口可以考虑自动关闭。等排水系统缓过劲来之后,可以打开排水口继续接受排水,这里需要不时的去探测排水系统是否恢复,决定何时再开启排水口。此处的熔断就是为了保护排水系统本身,不要因为大量的水灌入导致排水管道的破裂脱节之类的恶劣情况发生。


降级之前要先分级,在排水压力很大的情况下,可以让关键核心路段的积水先排掉别让交通完全瘫痪,其他边缘路段就自我牺牲一下先关闭主动排水口,也就是说在排水能力有限的情况下,把优先权让给关键核心,这种是资源抢占式的降级;假设平日的排水是在管道流动的过程中加入了过滤杂质的功能,以防大形体的垃圾进入排水系统堵塞住出水口,那在暴雨天气排水压力很大的情况下,是否可以考虑关停过滤功能,或者把过滤的标准放宽,这样排水的过程必然顺畅很多,这种是裁剪枝节、降低失败率、提高关键流程吞吐量的降级。


积水情况是否有监控


这个问题其实有一定的迷惑性,积水这种表象级别的监控绝对不是我们的目的,而是应该看更深一层,如何监控到路面的凹陷凸起。类比到软件系统,如果没有监控,我们对它们将一无所知。可悲的是,有相当比例的工程师对于系统上线后的感知,仍旧是通过是否有异常日志或者业务故障通知,才意识到自己系统的问题。实际上软件产品的交付物其中一个很重要的特性就是“可监控”,对于一个无法从内到外看个透彻的黑匣子,是相当恐怖的一件事情。


那么到底应该监控什么呢?除了对自身业务或技术指标的监控,对于依赖方的监控同样重要。不能只盯着自己高架路面的平整度,还要监控你依赖的排水系统处理能力,如果处理速度越来越慢,那就要考虑告警并介入了。


细节为王,眼界放宽


开篇我说过现在的架构师不好混,实际上作为一个经验老到的架构师,他的能力就深藏在一些细节和眼界上,而这些都不是吃快餐养成的“准”架构师们短时间内可以望其项背的。就像上面的问题“我只是高架路面设计师,如何想得到高架下的行车或行人?” 话说没吃过猪肉也见过猪跑,我就不信你没有在雨天有积水的马路上走过,或者亲身经历或者看到别人被积水坑害过。


回到软件架构上,有些细节可能让你空想你是想不出来的,但是你从初级工程师成长起来肯定踩到过某些坑,而这些坑都应该在你的架构设计里避免。一个标准的系统应用特性,很多人可以张嘴就来:可扩展性、高可靠、高可用、低延迟、BLABLABLA,又有多少人真正的对“可运维”“可监控”“可排障”“可持续交付”等在概要设计初期就有考虑呢?


课间不休息了,我再啰嗦两句

到这里,发现自己就半小时的车程感悟了这么多,也真的挺难为自己的。


总结性陈述:其实主要就扯了临界时间窗口服务治理两个架构设计经常遇到的点,结合提前打转向灯 防止路面积水两个场景做了发散性的对比,其他一些只言片语的架构思想仅为个人心得,如有异议随时欢迎来怼。


就此搁笔,有缘再见。


相关文章
|
存储 算法 架构师
【另类架构】之驾车感悟(上)
【另类架构】之驾车感悟(上)
179 0
【另类架构】之驾车感悟(上)
|
19天前
|
弹性计算 API 持续交付
后端服务架构的微服务化转型
本文旨在探讨后端服务从单体架构向微服务架构转型的过程,分析微服务架构的优势和面临的挑战。文章首先介绍单体架构的局限性,然后详细阐述微服务架构的核心概念及其在现代软件开发中的应用。通过对比两种架构,指出微服务化转型的必要性和实施策略。最后,讨论了微服务架构实施过程中可能遇到的问题及解决方案。
|
28天前
|
Cloud Native Devops 云计算
云计算的未来:云原生架构与微服务的革命####
【10月更文挑战第21天】 随着企业数字化转型的加速,云原生技术正迅速成为IT行业的新宠。本文深入探讨了云原生架构的核心理念、关键技术如容器化和微服务的优势,以及如何通过这些技术实现高效、灵活且可扩展的现代应用开发。我们将揭示云原生如何重塑软件开发流程,提升业务敏捷性,并探索其对企业IT架构的深远影响。 ####
42 3
|
1月前
|
Cloud Native 安全 数据安全/隐私保护
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####
|
19天前
|
Java 开发者 微服务
从单体到微服务:如何借助 Spring Cloud 实现架构转型
**Spring Cloud** 是一套基于 Spring 框架的**微服务架构解决方案**,它提供了一系列的工具和组件,帮助开发者快速构建分布式系统,尤其是微服务架构。
136 68
从单体到微服务:如何借助 Spring Cloud 实现架构转型
|
21天前
|
设计模式 负载均衡 监控
探索微服务架构下的API网关设计
在微服务的大潮中,API网关如同一座桥梁,连接着服务的提供者与消费者。本文将深入探讨API网关的核心功能、设计原则及实现策略,旨在为读者揭示如何构建一个高效、可靠的API网关。通过分析API网关在微服务架构中的作用和挑战,我们将了解到,一个优秀的API网关不仅要处理服务路由、负载均衡、认证授权等基础问题,还需考虑如何提升系统的可扩展性、安全性和可维护性。文章最后将提供实用的代码示例,帮助读者更好地理解和应用API网关的设计概念。
48 8
|
1月前
|
Dubbo Java 应用服务中间件
服务架构的演进:从单体到微服务的探索之旅
随着企业业务的不断拓展和复杂度的提升,对软件系统架构的要求也日益严苛。传统的架构模式在应对现代业务场景时逐渐暴露出诸多局限性,于是服务架构开启了持续演变之路。从单体架构的简易便捷,到分布式架构的模块化解耦,再到微服务架构的精细化管理,企业对技术的选择变得至关重要,尤其是 Spring Cloud 和 Dubbo 等微服务技术的对比和应用,直接影响着项目的成败。 本篇文章会从服务架构的演进开始分析,探索从单体项目到微服务项目的演变过程。然后也会对目前常见的微服务技术进行对比,找到目前市面上所常用的技术给大家进行讲解。
53 1
服务架构的演进:从单体到微服务的探索之旅
|
25天前
|
消息中间件 运维 Kubernetes
后端架构演进:从单体到微服务####
本文将探讨后端架构的演变过程,重点分析从传统的单体架构向现代微服务架构的转变。通过实际案例和理论解析,揭示这一转变背后的技术驱动力、挑战及最佳实践。文章还将讨论在采用微服务架构时需考虑的关键因素,包括服务划分、通信机制、数据管理以及部署策略,旨在为读者提供一个全面的架构转型视角。 ####
35 1
|
28天前
|
弹性计算 运维 开发者
后端架构优化:微服务与容器化的协同进化
在现代软件开发中,后端架构的优化是提高系统性能和可维护性的关键。本文探讨了微服务架构与容器化技术如何相辅相成,共同推动后端系统的高效运行。通过分析两者的优势和挑战,我们提出了一系列最佳实践策略,旨在帮助开发者构建更加灵活、可扩展的后端服务。
|
28天前
|
消息中间件 运维 Cloud Native
云原生架构下的微服务优化策略####
本文深入探讨了云原生环境下微服务架构的优化路径,针对服务拆分、通信效率、资源管理及自动化运维等核心环节提出了具体的优化策略。通过案例分析与最佳实践分享,旨在为开发者提供一套系统性的解决方案,以应对日益复杂的业务需求和快速变化的技术挑战,助力企业在云端实现更高效、更稳定的服务部署与运营。 ####