【温故知新】设计模式

设计模式

一、23种设计模式

设计模式

分类 模式名称 一句话定义 核心要点 典型应用场景
创建型(5种) 单例Singleton 保证一个类只有一个实例 私有构造、全局访问点 日志管理器、数据库连接池、配置对象
工厂方法Factory Method 定义创建对象的接口,由子类决定实例化谁 类级别、依赖继承 日志记录器(文件/数据库)、支付渠道选择
抽象工厂Abstract Factory 创建一组相关或相互依赖的对象族 对象组合、拒绝多if-else 跨平台UI组件(Win/Mac按钮和文本框)
建造者Builder 分步构建复杂对象,分离构造与表示 链式调用、Director指挥 SQL查询构造器、StringBuilder、复杂订单
原型Prototype 通过拷贝现有对象来创建新对象 实现Clone接口、浅/深拷贝 游戏怪物克隆、对象初始化成本高的场景
结构型(7种) 适配器Adapter 将一个类的接口转换成客户端期望的接口 包装器、兼容旧代码 电源转接头、第三方SDK接口适配
桥接Bridge 将抽象与实现分离,让它们独立变化 组合优于继承 消息发送(抽象:普通/紧急 vs 实现:邮件/SMS)
装饰器Decorator 动态地给对象添加职责,比继承灵活 层层包裹、透明扩展 Java I/O流 (BufferedInputStream)
代理Proxy 为对象提供一个代理以控制访问 中介、延迟加载 虚拟代理(图片懒加载)、权限代理
外观Facade 为复杂的子系统提供一个统一的简单接口 简化调用、降低耦合 JDBC封装、启动电脑(一键开机)
享元Flyweight 共享细粒度对象,减少内存消耗 池化技术、内部/外部状态 字符串常量池、围棋棋子(颜色共享)
组合Composite 将对象组合成树形结构以表示”部分-整体” 递归结构、一致对待 文件系统(文件夹与文件)、组织架构树
行为型(11种) 策略Strategy 定义一系列算法,封装起来,让它们可互换 消除大量条件判断 电商促销策略(满减/折扣/返现)、排序算法
观察者Observer 定义一对多的依赖,当一个对象改变时通知所有依赖者 发布-订阅机制 事件监听(Button点击事件)、RxJava
命令Command 将请求封装成一个对象,支持撤销和排队 解耦请求者与执行者 菜单按钮操作、宏命令、线程池任务
模板方法Template Method 定义算法骨架,将某些步骤延迟到子类 钩子方法、代码复用 数据库访问流程(连接-执行-关闭)、JUnit
状态State 允许对象在其内部状态改变时改变它的行为 用多态代替if-else 订单状态流转(待支付/已发货/已完成)、电梯状态
责任链Chain of Resp. 将请求沿着处理链传递,直到被处理 解耦发送者和接收者 审批流、Servlet Filter、拦截器
备忘录Memento 在不破坏封装的前提下,捕获并恢复对象状态 快照机制 编辑器撤销(Ctrl+Z)、游戏存档
中介者Mediator 用一个中介对象封装一组对象的交互 减少对象间耦合 聊天室(通过服务器转发)、MVC的Controller
访问者Visitor 将作用于某对象结构的操作分离出来封装 数据结构稳定,操作易变 编译器(AST节点遍历)、报表生成器
迭代器Iterator 提供一种方法顺序访问聚合对象中的元素 统一遍历接口 Java Collection的 iterator()for-each
解释器Interpreter 给定一个语言,定义其文法的一种表示,并解释执行 语法树解析 正则表达式引擎、SQL解析、数学表达式计算

二、MVX设计模式

MVX设计模式

模式 全称与核心组成 数据流与交互逻辑 优点 缺点 典型应用场景
MVC Model-View-ControllerM: 数据/业务• V: 界面展示• C: 接收输入,调度M/V 双向混乱View常直接读Model,Controller同时操控View和Model。很多实现中V和C紧耦合(如iOS)。 • 概念简单,易上手• 开发速度快(小项目) Controller臃肿(Massive VC)• View与Model耦合,难测试• 逻辑分散,维护困难 • 早期Web开发(PHP/JSP)• iOS原生开发(Apple MVC)• 简单Demo或小型工具
MVP Model-View-PresenterM: 数据/业务• V: 被动视图P: 纯逻辑调度 单向清晰View <-> Presenter <-> Model。View只负责画UI,通过接口通知Presenter;Presenter持有View接口,更新UI。 彻底解耦(V与M互不知晓)• Presenter无Android/iOS Context,极易单元测试• 逻辑集中,易于维护 • Presenter易臃肿• 手动更新UI繁琐(需写大量setText等代码)• View接口可能过多 • 传统Android开发• WinForms/ASP.NET Web Forms• 需要高测试覆盖率的项目
MVVM Model-View-ViewModelM: 数据/业务• V: 界面展示• VM: View的抽象模型 双向绑定View <-> (Binder) <-> ViewModel。View与ViewModel通过框架自动同步(Data Binding),无需手动调用。 开发效率极高(消灭样板代码)• 数据驱动,代码简洁• 比MVP更解耦,测试性良好 调试困难(数据流向不直观,难定位Bug)• 内存泄漏风险(绑定未释放)• 复杂逻辑导致ViewModel膨胀 前端主流(Vue/React/Angular)• WPF/UWP• Android Jetpack (LiveData/DataBinding)• 数据密集型应用
MVPVM MVP + MVVMM: 数据• V: 视图• P: 业务逻辑VM: 数据包装 双轨制View <-> Presenter <-> ViewModel <-> Model。P负责逻辑,VM负责适配数据供V绑定。 • 兼具MVP的强测试性和MVVM的高效率• 职责分离更彻底(P只管逻辑,VM只管数据) 架构复杂,学习成本高• 类数量翻倍,代码量较大• 小型项目杀鸡用牛刀 • 大型桌面应用(WPF)• 复杂企业级移动应用• 需要严格分层的大型项目
VIPER View-Interactor-Presenter-Entity-RouterV: UI展示• I: 业务逻辑/用例• P: 格式化数据• E: 实体• R: 路由/导航 单向闭环View -> Presenter -> Interactor -> Entity。严格遵循Clean Architecture,每一层只做一件事。 职责切分到极致• 极高的可测试性和模块化• 代码极其规范,适合团队协作 类爆炸(一个页面5+文件)• 极度繁琐,开发效率低• 学习曲线非常陡峭 • 超大型iOS/Android项目• 金融、银行类App(业务极其复杂)• 长期维护的核心产品

WSL2中apt升级systemd时报错:无法锁定passwd文件

1、环境:
Windows10+WSL2+Ubuntu24
PS:另一台电脑Windows11+WSL2+Ubuntu24,不会报错

2、再现方式及错误信息

# apt-get upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
...
...
Setting up systemd (255.4-1ubuntu8.8) ...
Initializing machine ID from random generator.
Failed to take /etc/passwd lock: Invalid argument
dpkg: error processing package systemd (--configure):
installed systemd package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
systemd
E: Sub-process /usr/bin/dpkg returned an error code (1)

3、错误发生原因
systemd升级的脚本,会调用systemd-sysusers,systemd-sysusers会尝试通过fcntl锁定文件,但WSL中fcntl实现效果与Linux中不同,导致脚本执行失败。
更进一步的解释:
Linux中文件锁是基于文件描述符的,子进程会自动继承该文件锁。
Windows中文件锁是基于进程的,子进程需要自行获取新的文件锁。
WSL中,实现方式,更接近与Windows,重复获取同一个文件的锁自然是失败的。

openat(AT_FDCWD, "/etc/.pwd.lock", O_WRONLY|O_CREAT|O_NOCTTY|O_NOFOLLOW|O_CLOEXEC, 0600) = 3
fcntl(3, F_OFD_SETLKW, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0, l_len=0}) = -1 EINVAL (Invalid argument)

4、如何绕过该错误

# 原文在此:https://github.com/microsoft/WSL/issues/10397

# 切换到/bin
# 将systemd-sysusers修改为systemd-sysusers.org
# 将systemd-sysusers做成一个echo的符号链接(用于欺骗升级脚本,让其以为得到了正确的结果)
# 切换回之前的目录
cd /bin && mv -f systemd-sysusers{,.org} && ln -s echo systemd-sysusers && cd -

# 修复包依赖
apt --fix-broken install

# 继续升级
apt-get upgrade

医疗大模型数据防护

医疗大模型训练数据,除了脱敏之外,至少还要做下面的工作
1、完整的医疗数据,即便做了基础的去标识化工作,也很容易反向推断定位到某个个体,所以要进一步加强:泛化(32岁改为30~40岁)、模糊、并引入噪声
2、医生不是神,并非所有的诊断都是对的、并非所有治疗方案都是最佳的,不合适的数据剔除很难
3、医疗数据的归属权有争议(极端一些,比如一个人在一家医疗机构做了全基因测序,测序结果是这家医疗机构的吗),需要获取患者授权,最好能给予收益分成
4、医学伦理、社会道德、大众接受程度这些问题,要考虑在前面
5、医疗数据在部分国家地区是不允许高度集中的,分散在各机构服务器中(医院、体检机构、公卫机构),所以要数据不动模型动,采用类似联邦学习的技术

医疗健康场景下Constitutional AI规则

1、生命优先,患者安全第一,推荐风险较低的方案,提醒及时就医
2、保持大模型的专业及严谨性,不得针对训练边界之外的病种给出建议,更不可随意发挥
3、医学建议要透明可解释,要能溯源到教材、规范、病例和高可信的论文等材料
4、大模型仅为辅助工具,关键节点包括处方、医嘱、手术等,最终决策权还给医生
5、尊重患者的尊严与自由
6、保护隐私,遵守相关法律
7、保障患者知情权,说明大模型的局限性及潜在风险
8、符合道德及医学伦理,公平无歧视
9、如果面向患者,那输出要更有温度,不要过于冷漠

导致惨重代价的运维事故2025

2025年11月:Cloudflare大规模故障
事件经过:11月18日,Cloudflare CDN、安全服务等多款产品宕机,团队误判为DDoS攻击,回滚旧文件后,于19日凌晨01:06全部恢复。
事故原因:数据库权限调整后生成错误配置文件,引发核心代理系统异常。
造成损失:全球大量依赖Cloudflare服务的网站及业务受影响,平台承诺加速系统韧性升级。

2025年11月:亚马逊云服务重大事故
事件经过:美国太平洋时间凌晨2:01,AWS因运营问题导致近70项自有服务受影响,亚马逊、迪士尼+、Canva等平台及多款云游戏瘫痪。
事故原因:未公开披露具体技术原因,确认与美国东部1号区域相关。
造成损失:全球多家知名平台服务中断,影响用户使用及企业业务营收。

2025年10月:亚马逊AWS北弗吉尼亚区域崩溃
事件经过:AWS US-EAST-1区域中断长达15小时,波及全球。
事故原因:核心依赖服务失效,DynamoDB DNS解析异常引发连锁故障。
造成损失:数千个服务瘫痪,潜在经济损失高达百亿美元。

2025年10月 微软Azure配置错误,导致全球中断
事件经过:Azure Front Door错误配置变更,Azure全网瘫痪,引发Office 365、Teams等核心服务全球性中断,持续数小时。
事故原因:网络配置变更失误,触发底层逻辑缺陷致级联故障。
造成损失:全球用户无法使用核心服务,企业远程办公中断,微软赔付客户,声誉受损。

2025年9月:韩国政府数据中心火灾
事件经过:数据中心锂离子电池迁移维护时爆炸起火,858TB核心数据丢失,160多项公共服务受影响,一周仅恢复18%系统。
事故原因:运维操作引发的基础设施事故。
造成损失:政府服务瘫痪,修复成本高,公信力受损。

2025年8月:上海医保系统故障
事件经过:8月11日,上海医保系统因电信云平台机房供电故障无法正常结算,应急备份系统接管后,本地门急诊结算恢复,大病、住院及异地结算受影响。
事故原因:电信运营管理的云平台机房供电系统故障。
造成损失:患者就医结算受阻,异地参保人需自费后报销,影响民生服务。

2025年6月:谷歌云全球性服务中断
事件经过:6月12日,谷歌云遭遇全球性服务中断,持续约13小时。期间,谷歌工作空间(Google Workspace)、安全运营产品等外部API请求大量失败。
事故原因:服务控制组件高负载处理失效。“服务控制”组件是谷歌云策略检查系统的核心,负责读取配额和政策信息。该组件未能有效应对高负载情况,导致API请求处理堵塞,进而引发了全局性的服务中断。
造成损失:大量企业客户业务受阻,谷歌为此向客户致歉并推出了服务控制改进计划,重建客户信任。

2025年3月:华金期货交易系统长达7.5小时宕机
事件经过:3月10日,华金期货的交易系统突发异常,客户无法通过文华财经等主流交易端登录账户。故障持续了整整7小时26分钟,直到半日过去才被修复。
事故原因:软件故障与应急处置不当。虽然具体技术原因因“证据灭失”未能完全查清,但监管调查发现其在应急处置中未妥善保护现场,且暴露出灾备系统性能不足、过度依赖外部供应商等问题。
造成损失:达到“一般网络安全事件”标准;期货市场瞬息万变,长时间的交易中断导致客户面临巨大的穿仓风险和亏损,公司也因此收到监管罚单。

2025年1月:埃隆·马斯克旗下X公司数据中心火灾
事件经过:X公司租用的俄勒冈州希尔斯伯勒数据中心发生火灾。
事故原因:储能设备管理问题,电池房间存在运维漏洞。
造成损失:影响X平台部分服务稳定性。

当“锚”切断数字动脉:红海光缆中断事件复盘

当“锚”切断数字动脉:红海光缆中断事件复盘

一、事件始末:一艘货轮的失控,三条光缆的毁灭

2024年2月18日,伯利兹籍万吨散货轮”鲁比玛号”(MV Rubymar)满载4.1万吨化肥,在红海曼德海峡航道通行时,遭遇武装导弹袭击。船体严重受损,船员第一时间紧急弃船撤离,船舶彻底失去动力与人为操控能力。

按常规认知,遇袭失能船舶会快速沉没。但”鲁比玛号”并没有立刻倾覆,而是出现了极具特殊性的次生风险———它在洋流作用下持续漂移,船体全程拖拽着巨型船锚,在红海海域缓慢漂流超过70公里。坚硬锋利的锚爪如同一柄失控的犁刀,持续剐蹭、切割海底地层。

2024年2月24日,导弹袭击发生整整六天后,船锚斩断了红海海底三条核心跨境互联网通信光缆(相互之间距离很近):
Seacom/Tata TGN-Eurasia
Asia Africa Europe-1(AAE-1)
Europe India Gateway(EIG)

2024年3月2日,这艘失事货轮才最终完全沉没,彻底结束漂移破坏过程。

二、红海走廊:全球互联网的”单点瓶颈”

红海海底光缆是欧亚、非欧跨境数据传输的核心骨干链路,承担着全球互联网的核心流量承载任务,其战略传输地位无可替代。具体来看:

指标 数据
欧亚跨境网络数据经红海传输比例 约80%
红海光缆承载全球互联网流量比例 约17%
红海光缆支撑日均跨境金融交易量 超6万亿美元

在高可用的分布式系统架构设计中,总流量汇聚于一条物理走廊(狭窄的海峡、活跃冲突、复杂的地缘政治环境),这本身就构成了一个高风险单点故障区域(Single Point of Failure)

虽然红海海底铺设了多条不同的光缆(EIG、AAE-1、SEA-ME-WE 5等),但它们几乎都经由同一条狭窄水道。这意味着,一次大范围的物理事件(无论是地震、船锚拖拽还是蓄意破坏),都有可能同时影响多条线路,导致物理层面的”集中导致的冗余失效”。”鲁比玛号”事件恰好验证了这个假设:一条失控的货轮,一次漂流,就切断了三条光缆。

从运维的视角来看,本次事件是这样的:一个高可用集群,全部副本都在同一个机房。机房对外有三根线路,但三根线路沿着同一个管道铺设。一台挖掘机一铲子把管道挖断了,对整个机房网络造成了难以预期的、不可逆的灾难性破坏。

三、故障传播:从物理层到业务层的级联崩塌

三条核心光缆同步断裂,直接触发了区域性骨干网络的带宽断崖式衰减与链路稳定性骤降。红海主干链路可用数据传输量直接缩减四分之一,也就是欧亚大陆的网络带宽减少了四分之一,欧亚大陆的网络”集体降速”。

从维度角度分析,本次故障的影响具备影响范围广、持续时间长、级联效应明显三大特征:

1、全域性——覆盖范围极广
东非、西亚、欧洲、东亚跨境通信全面受影响。政企专线、跨境云计算、国际结算系统、跨境办公网络均出现运行异常。具体表现为:
欧亚之间网络延迟显著上升,部分路由延迟大幅上升;
东非、中东部分区域互联网连接近乎中断;
跨国企业实时通信、视频会议、金融数据传输出现严重抖动与丢包;
云服务提供商跨区域同步和灾备系统面临更高的数据一致性风险。

2、持续性——故障层级极高
这是骨干核心链路的物理性损毁,而非边缘节点故障,无法通过局部设备重启、带宽扩容、节点切换等常规运维手段修复。光缆修复历时5个月,全网降级运行状态持续近半年。

3、连锁性——单点故障引发全网失衡*
根据BGP(边界网关协议)的路由收敛机制,受影响的流量会尝试切换到可用路径。故障发生后,运维团队通过非洲西海岸的Equiano、Peace、WACS等备用光缆进行流量迂回调度,缓解主干链路带宽压力。

但备用链路传输距离更长、带宽容量有限,无法完全抵消主干光缆断裂带来的性能损耗。这就好比一条八车道高速公路突然断了六条车道,所有车辆被强制并入两车道乡间公路。剩余备用链路长期高负荷运行,进一步加剧了网络抖动与服务不稳定,运维团队需持续监控全网流量、动态调整路由策略、处置突发拥堵,运维值守压力达到极值。

从维度角度来看,这是一次典型的“降级服务”事件:系统没有完全宕机,但核心性能指标严重劣化,用户体验大面积受损,且故障恢复的时间窗口完全不可控。

四、修复难题:最令人绝望的不是修复要多久时间,而是”什么时候能开始修”

海底光缆修复的技术流程本身是成熟的:派出专业维修船(cable ship),用ROV(水下机器人)定位断裂点,捞起光缆,进行熔接、测试,然后重新铺设回海床。在正常条件下,一次标准的海底光缆修复作业需要2–4周。

但”鲁比玛号”造成的这次故障,修复耗时长达5个月——从2024年2月故障发生,直至2024年7月才完成全部修复、链路调试与全网恢复。

不是因为技术难度,而是因为拿不到施工许可

断裂点位于红海海域,该海域地缘冲突持续、海域局势高度紧张,无任何安全施工条件。各大国际通信运营商、运维团队无法直接进驻海域开展勘查、打捞、熔接、修复作业,所有施工行为必须提前与红海当地实际控制方谈判沟通,申请专属施工许可。漫长的地缘博弈、流程洽谈、权限审批,成为阻碍故障修复的核心卡点。

此外,全球可用的深海光缆维修船仅约60艘,排期本就紧张。同期红海地区已有多条光缆受损,维修资源被多任务挤占,进一步加剧了修复延迟。

这给系统运维领域带来了一个极为深刻的教训:故障恢复时间(MTTR,Mean Time To Repair)的瓶颈,不仅在技术层面,更多时候卡在在组织和环境层面。你可以拥有全世界最先进的熔接设备和最优秀的工程师团队,但如果一枚导弹让整片海域变成了”施工禁区”,你的SLA(服务等级协议)就是一张废纸。

在全网降级运行的5个月中,运维团队处于长期高度戒备状态,需要持续执行流量监控、路由动态优化、突发拥堵处置等工作。这不是一次”修复完成即可恢复常态”的标准事件,而是一场漫长而消耗极大的运维持久战。

五、行业启示:重构极端场景下的网络稳定保障体系

2024年7月,三条光缆陆续恢复服务。互联网继续运转,仿佛什么都没有发生过。但它不应该被当作一个”偶发事件”而被轻易遗忘。我们应该好好的做一次复盘,复盘报告(Post-Mortem)如下:

1、故障根因(Root Cause)
船舶遭受武装袭击后失控漂移,船锚物理性破坏海底光缆。直接原因是地缘军事冲突,间接原因是缺乏对失控船舶的有效拦截或预警机制。这是一起典型的非技术性运维灾难——故障诱因不在设备、软件或人为操作失误,而在于外部不可控的地缘事件引发的基础设施次生损毁。

2、暴露的系统性弱点

弱点 说明
物理路径冗余不足 多条光缆经由同一走廊,易被同一次事件批量破坏,形成”集中导致的冗余失效”
地缘风险未纳入架构评估 光缆铺设和路由规划长期忽视冲突区风险,运维风险模型缺乏非技术变量
维修能力全球稀缺 专业维修船约60艘,大型故障修复排队周期长
跨组织协同机制缺失 光缆运维团队与军事/外交系统之间无标准化协作流程,冲突海域处置无先例可循
备用链路性能差距大 迂回链路带宽有限、延迟高,无法有效承接主干溢出流量

3、行业启示:重构极端场景下的网络稳定保障体系

“货轮漂移断缆”是一次罕见的非技术性运维灾难,彻底暴露了传统跨境网络运维体系的结构性短板:过往运维风险防控多聚焦于技术故障、自然天灾、施工风险,完全忽略了地缘冲突引发的次生基础设施损毁风险,全网冗余架构、应急预案、故障处置机制存在明显盲区。从系统运维与网络稳定维度复盘,本次事件带来三大核心启示:

第一,风险评估模型必须升级
跨境骨干网络稳定性风险已全面多元化。地缘政治、海域冲突等非技术因素,已成为威胁全球数字基础设施安全的核心变量。传统以设备故障率、链路可用性为核心的风险评估体系,必须纳入地缘安全、冲突烈度、海域管控状态等非技术维度,构建更全面的风险预判能力。

第二,全球光缆冗余架构亟待重构
核心通道过度集中、备用链路绕行成本高、性能损耗大,单点损毁即可引发全网降级。未来应推动跨洋光缆路径的真正物理分散化布局,增加跨极地、跨大洋的替代路由建设,同时提升卫星通信(如低轨卫星星座)在应急场景下的带宽兜底能力。

第三,跨境基础设施运维需要治理创新
冲突海域的故障处置无标准化流程、无安全保障机制,技术修复能力完全受制于地缘局势。国际社会需要建立跨境数字基础设施的保护性国际框架,将海底光缆纳入关键基础设施保护范畴,为冲突区域的应急修复提供制度性保障。

希望未来,光缆线路不需要军舰巡航,数据中心附近不需要导弹防护,期待和平。

记一次存储Inode数量引发的生产故障

前一段时间,突然收到了系统报警,某上传服务异常。

经过排查,上传服务正常,但存储无法正常写入,一直写入失败,表现为:
1、一块新盘,32T,已使用2T,可用30T,控制台和命令行操作结果一直
2、服务写入时,一直报“no space left on device”
3、没有收到任何存储报警

立刻找了云服务厂商的老师,解决了问题:
1、除了限制写入文件总量的大小、并发写入的速度,同时还限制了inode数量
2、上传服务,写入了大量小文件,耗尽了inode数量
3、上传服务,再次写入后,inode申请失败,导致写入失败
4、存储组的老师,紧急扩展了inode数量,解决了问题

经排查,云服务商反馈:
1、为了控制成本,我们之前买了一块较小的硬盘,然后进行了扩容
2、而存储的底层协议为FlexGroup
3、而FlexGroup的普通卷,在扩容的时候,只要超过了1T,默认的Inode数量就一直为21251126,不再提升
4、而我们的上传服务,一个小文件只有几百k,很快就把Inode数量耗尽了
5、对于Inode数量限制,云服务商没有提供任何监控

虽然FlexGroup的超大卷默认会提升Inode数量,但我们一开始购买的服务确是普通卷,然后进行扩容,扩容后仍是普通卷,就触发了Inode数量不会自动增加这个问题。

后续,我们做了两个约定:
1、尽量采购超大卷
2、如果要采购普通卷,同时提单,增加Inode数量
3、云服务商同步进行产品更新,后续产品迭代时,从根源上解决这个问题

PS:
最近发现,他们居然做了一个inode扩容的功能,默认是最小值,可以手工扩展,也能设置为自动扩展。
不知道是谁定的需求,默认选项不应该是自动扩展吗?

快速成长的必备软技能25:别造轮子

快速成长的必备软技能25————轻易不要造轮子

我们有些兄弟,对技术和解决问题有极大的热情,但又会有个小问题,有事就容易上头,总想自己去造轮子。

我之前经历过一个项目,做移动互联网挂号的,甲方是一个超级大三家。
为了应对流量冲击,设计的时候势必要引入消息队列,去削峰填谷。
当时整个团队都很有极客精神,技术水平也不错,感觉MQ中间件比较笨重,就花了半天,借用Redis揉了一个。
结果上线不久,消息一扩散,大家都来抢号源,没几天系统就崩了。
于是在这个基础上,越走越远,调优,抗住,崩了,再调优。

甲方的人也坐不住了,用户叫骂声一片,毕竟看着有号但挂不上,过一会儿系统恢复又没了,能不急么。
痛定思痛,用了MQ,好了。。。

复盘时,大家还是七个不服八个不愤,认为自己可以继续调优。
这时候,项目负责人问了一句,这个MQ中间件,别人优化了N年。你们凭啥觉得自己一两周的赶工,能干过别人N年的努力呢?

其实,在业界,如果现有技术如果能满足要求,成本最低的方法,往往是使用现有技术。
当现有技术无法满足要求时,大家会想办法去调优。
如果调优也无法满足时,才会去造轮子。而且造轮子,并不是一般的人和团队能承担的起的。

那些头一热就要造轮子的人,一般都是在开着汽车换轮胎的紧急时候,才会去想造轮子的。
几乎没有时间测试、调优、写文档,只追求能用就行。
但请注意,生娃不养娃,罪过甚于不生娃。
这个轮子造了,为了让轮子活下去,你要不断去完善功能,完善代码,甚至不断的回应社区。
这样,100个轮子,才可能有1个活下来。

否则,就是给后来维护的人,挖了一个巨大的焦油坑,不断造成无尽的浪费。

对了,还有类似的行为,大家可能都遇到过:
这个服务/功能,咱们用XXX语言再写一遍吧
最近XXX技术很火,咱们把YYY换了吧
这个项目,我们可是没有用XXX框架,而是自己从头实现的哦

遇到这种情况,先别上头,先考虑一下三个问题:
1、必要性:确实不造轮子不能解决问题吗
2、投产:公司、团队、个人能得到什么
3、轮子能活下去吗?你和团队能有多少热情,能投入多少资源

快速成长的必备软技能24:化繁为简

快速成长的必备软技能24:化繁为简

在职业生涯中,你会发现两种人
一种能快速的从复杂问题中,找到问题的关键,把事情主要矛盾分析清楚
一种能快速的把问题搞的复杂无比,让事情变得困难,让小事变成大事
而且两种人,在不同的企业文化下,好像都能活得不错

作为技术出身的人员,一般比较直接,不太擅长应对第二种人,更不擅长“没有困难制造困难”
所以多数的,都会逐步演化成第一种人

化繁为简,看起来很难,需要经过大量的训练,但抓住一些点,就会变简单:
1、搞清楚真正要解决的问题是什么
2、为了解决这个问题,至少至少要完成哪几件事情,要投入什么资源
3、搞清楚相关方的利益都是什么
4、做出合理且恰当的安排

经过这些训练后,相信你也可以做到,在千头万绪中,快速抓住主要矛盾,集中精力解决问题。

快速成长的必备软技能23:风险控制

快速成长的必备软技能23:风险控制

不知大家有没有听说过一句话“吃亏要趁早”为啥呢?
因为随着一个人的成长、发展及岗位提升,同样的错误造成的负面影响会指数级增长,甚至增大到不可承受的地步
尤其是一些低级错误,对于专业人士来说,是不被允许发生的
甚至会导致职业生涯的毁灭

所以我们要做好风险管控:
首先,是职业风险
举个例子,有些朋友不仅风险意识淡薄,而且毫无法律意识,别人拿个资料过来,不看资料内容,甚至不看资料标题,会直接盲签。
这样做风险很高的,签这些资料,不仅仅是授权,还要承担对应的责任。
如果不看就签,就算把你自己卖了,你都不知道。

然后,是健康风险
相信大家几乎每年,都能从新闻中听到,某大厂程序员,工作中猝死。
我工作了这几年,已经有3位同班同学去世了,都是酒后骑摩托出事故去世的,两位是家里的独子,一位是家里的长子。
这些人悲剧的离开,有时候只是一个家庭悲剧的开始。

再有,是行业风险
三十年河东,三十年河西。行业的起起落落是再正常不过的失去了。
大家要定期做好自我评估,避免在一个下行的行业中,花费太多的时间。
否则事倍功半,何苦来着。

君子不立于危墙之下,管控好风险,及时做好风险规避。