高晓庄 札记

从单体架构迁移到微服务，我是怎么设计的 架构演进从来不是”重写”，而是一场有节奏、可回滚、能持续交付的工程。本文复盘我在一个传统单体系统上做微服务化改造的完整设计思路。 为什么不直接重写接手时，系统是一个运行多年的单体应用，业务逻辑高度耦合，编译一次要十几分钟，任何小改动都要整体发版。团队第一反应是”推倒重写”。 但重写意味着：在很长一段时间内没有新功能产出，且新旧系统切换期的数据一致性几乎无法保证。最终我们选择了绞杀者模式（Strangler Fig Pattern）——在保留老系统运转的前提下，逐步把能力”绞杀”出来。 拆分原则：先按业务域，再按变更频率拆分粒度是最容易踩坑的地方。拆太细，分布式事务和运维成本爆炸；拆太粗，等于没拆。 我们的经验是两轮拆分： 第一轮按业务域：把系统切成若干个自治的领域边界（用户、订单、设备、GIS 等），每个域对应一个团队、一个独立的交付单元。 第二轮按变更频率：把”频繁变更”和”稳定不变”的模块再次分离，让高频模块能独立发布，不用拖着稳定模块一起回归。 判断边界是否合理的标准很简单：这个服务能不能独立演进、独立部署、独立扩容？ 如果三个...

面试里经常出现这样的对话： “讲讲工厂模式。”“工厂模式有简单工厂、工厂方法、抽象工厂……” 然后就开始背定义。但背完往往自己也是糊的，因为这三个名字实在太像了。 其实它们的演进逻辑非常清晰，理清了就永远忘不掉。 起点：到处 new 的坏味道假设你在做一个支付系统，支持微信和支付宝两种支付方式。最初你可能会这么写： 12345if ("wechat".equals(type)) { return new WeChatPay();} else if ("alipay".equals(type)) { return new AliPay();} 问题来了：如果以后要加”银联支付”、”苹果支付”，这段 if-else 就得一直改，而且这样的判断散落在代码各处，改一处漏一处。 创建对象的逻辑，不应该和业务逻辑混在一起。这就是工厂模式要解决的问题。 第一站：简单工厂把创建逻辑抽到一个”工厂”里： 123456789public class PayFactory { public...

单例模式大概是每个学 Java 的人第一个接触的设计模式，也是面试里被问烂、但很多人其实没真懂的一个。 它的目标很简单：保证一个类在整个系统中只有一个实例，并提供一个全局访问点。 为什么需要单例？典型场景：配置管理、线程池、数据库连接池、日志器、Spring 容器里的 Bean（默认就是单例）。这些对象如果重复创建，要么浪费资源，要么状态不一致。 难的不是”理解目标”，是在并发下正确、安全地实现它。 写法一：饿汉式123456789public class Singleton { private static final Singleton INSTANCE = new Singleton(); private Singleton() {} public static Singleton getInstance() { return INSTANCE; }} 类加载的时候就创建实例，所以叫”饿汉”——不管用不用，先造出来。 优点：简单，线程安全（由 JVM 类加载机制保证） 缺点...

刚学设计模式的人，最容易犯一个错：把它当成”要背下来的 23 个名词”，然后拿着锤子到处找钉子。 这完全跑偏了。 设计模式的价值，从来不在”记住”，而在理解它为什么出现。 设计模式到底解决什么问题写代码久了你会发现，很多问题会反复出现： 怎么保证一个类只有一个实例？ 怎么在运行时切换不同的算法？ 怎么让两个模块解耦、互不直接依赖？ 怎么在不改老代码的前提下扩展新功能？ 这些问题被无数工程师踩过、想过、总结过，最后沉淀成了一套”常见问题的常见解法”——这就是设计模式。 它本质上是一套经验的复用。你不需要自己重新发明轮子，前人已经替你想好了。 把设计模式当”通用语言”我真正体会到设计模式的价值，是在团队协作里。 假设你在代码评审时看到这样一段话： “这里建议用策略模式把这块 if-else 拆掉。” 如果你们团队都懂策略模式，这句话一句话就说清楚了，不用解释一大堆背景。 但如果没人懂，你就得说：”你看这里，我们有三种计费方式，现在是 if-else 判断，以后可能还会加第四种、第五种，而且每个分支的逻辑还很长……” 设计模式是工程师之间沟通问题的通用词汇表。它让”复杂的设计意...

写在最前面：关于这个博客的一些憧憬代码写久了，会慢慢发现它其实只是人生一条很窄的线。线之外是哲学、是经济学、是与人相处、是面对自己。 我很早就想有一个自己能”长”出来的地方。可以是把踩过的坑写下来留给未来的自己，可以是把看世界的角度摊开和陌生人共享，更可以是把那些天马行空的、未成形的、有点脆弱的念头老实留下来，看它们最终会变成什么形状。 这个博客，就是这块地。 这个博客想留住三样东西第一，把踩过的坑和想清楚的瞬间留下来。 今天以为搞明白的事，三个月后回看可能又是另一回事。把当时的判断原样存好，将来能看见自己走过的弧线，结果本身反而不那么重要。 第二，让视野从单纯的技术拓出去。 代码只是一种视角，世界还有很多视角值得用同等的耐心去理解。哲学不是用来装点门面的，是用来校正思维方式的；经济学不是用来算账的，是用来理解利益与选择背后逻辑的。我希望这个地方慢慢长出这些东西，和技术文章并列存在、互为参照。 第三，逼自己成为”想清楚再说话”的人。 公开地写有一个反向作用——它会让你在落笔之前多想一拍，在发布之前多校一稿。长此以往，思考的肌肉会比手速长得更结实。 对自己的几点奢望 五年后回来看，...