基本介绍

对于kubernetes是什么，一个比较官方的定义，Kubernetes是一个开源容器编排平台，管理大规模分布式容器化软件应用，简称为k8s.

通俗一些来讲，k8s 的核心理念是以应用为中心，向下屏蔽基础设施的差异，向上通过容器镜像实现应用的标准化，帮助开发人员在仅需关注应用本身，无需考虑部署、容灾、伸缩等运维细节的情况下，开发出大规模、可靠的分布式应用。

优势

如上所述，k8s的核心优势就是降低运维成本，让应用开发人员能够专注于应用本身。具体来讲，包括如下几点：

• 便捷的部署流程和大规模的复制分发能力：应用提供标准化的容器镜像，之后的部署发布流程都可以做到自动化；应用也无需再做更多的事情就可以实现跨平台、跨区域的部署。
• 服务自愈能力：自动摘除不健康的节点并做恢复。
• 敏捷的自动伸缩：根据设定的系统负载，做快速的自动伸缩，实现系统处理能力和成本之间的平衡。

主要概念及实现方式介绍

这篇kubernetes教程的剩余部分会从应用开发人员视角，介绍需要了解的k8s概念，主要包括以下几类：

• Pod, service, deployment等基本概念
• spec+controller这套基本实现原理
• k8s提供给应用的扩展点

spec+controller

这是k8s内部大部分逻辑的实现方式，了解这个逻辑，可以帮助开发人员更好的理解某些特定情况下k8s的行为。

如果翻看k8s的yaml配置，就会发现k8s的大部分组件中都有一个或若干个spec字段，它的含义很好理解，就是对于某个属性的期望值，比如一个服务节点数量的期望值。

controller的作用就是持续监测期望值和实际指标是否一致，不一致时就进行相应的操作进行处理，比如发现节点数不够了，就会启动对应数量的新节点。

这样，无论是上线、扩缩容、还是故障恢复，我们会发现这些逻辑都变得非常清晰，都是触发一下对容器数期望值或实际值的调整，然后让controller去增删节点就可以了。

这套机制是k8s里广泛使用的一个底层设计原则，作用是解开监控和操作逻辑之间的耦合。举个例子，我们在很多情况下都需要触发启动新的节点，包括要做扩容时、部分节点挂了时、要上线时，等等。这些完全没关联的场景如何去触发相同的操作，代码要如何保持整洁呢？k8s的做法就是用一个期望值的概念做中间层，将操作的触发时机和操作本身拆分成独立的逻辑。

了解了这个逻辑，我们可以更容易的理解k8s是怎么工作的。 比如基于HPA做自动扩容，就是根据当前的CPU使用情况，和期望的CPU使用量，决定是增加还是减少节点。

Deployment

Deployment 用于指示 k8s 如何创建和更新应用程序，我们通常理解的一个“服务”、“应用”大体上就对应在deployment这一层上。 像镜像、内存cpu使用限制、节点数、环境变量等各种配置，都是在deployment上。

Pod

pod比较好理解，就是我们通常理解的一个节点。pod是 k8s 中最小可管理单元。

Service

Service是一个需要着重了解的概念，它是一个抽象层，它选择具备某些特征的 Pod（容器组）并为它们定义一个访问方式。 通常的应用场景下，deployment和service是一一对应的，但实际上deployment和service之间并没有必然的联系。

一个请求恰好可以打到某个deployment关联的所有pod上，看起来是一件非常正常的事情。而事实上，这件事情的发生不是由于这些pod通过一个deployment产生，而是因为deployment上配置了一个标签，通过这个deployment生成的pod都获得了这个标签; 同时，另外存在一个service, 设置通过这个标签选择pod, 请求进入的是通过service选择出的一批pod.

探针(probe)和钩子(hook)

k8s提供了一些用于应用扩展的接口，其中就包括probe和hook, 可以帮助应用更好的利用k8s的能力。

k8s提供了 liveness和 readiness 探针，顾名思义，liveness probe的作用是判断应用是否存活，readiness probe的作用是判断应用是否已经启动完毕。

应用可以用http接口等不同形式提供探针，k8s则负责在探测到不同状态时做不同的操作。比如说探测到liveness probe返回状态异常，则可以认为此节点已经丢失，对此节点做删除处理。

hook则支持应用在一些特定阶段插入一些行为，比如preStop hook, 运行应用关闭之前先做一些操作，可以用来做graceful shutdown.

实践思考

通过对本篇kubernetes教程上文列出的概念的了解，相信大家可以从应用开发人员的视角完全理解kubernetes是什么, 也可以大致想象出应用方使用k8s的基本思路： 构建标准镜像，暴露出必要的监控数据，剩下的事情都交给k8s来做。

在准确的数据下，k8s可以帮我们做好系统的自愈、扩缩容等操作，而我们要做的是，结合应用场景，尽量给出更加准确的监控数据。

举一些例子，比如说应用提供的liveness探针，如何能尽量确保准确的展示系统的健康状态，某个接口可以访问，某个端口可以调通，能否等价的说明这个应用是否健康。

比如说k8s以cpu、内存等指标来判断系统负载时，这些机器指标能否真实的展现出应用的真实负载，是否有可能连接池、IO等其他瓶颈会在cpu、内存等瓶颈到来之前就达到。

这些都是需要应用方结合应用的实际情况精心设计的。

此外，k8s的设计理念决定了在k8s环境下，”重启”会是一件非常稀松平常的事，像硬件故障、小概率的死循环、不健康的gc, 等不同类型的问题，都可以在k8s的自主重启下实现自愈； 自动的扩缩容扩充中，也会经常性的有节点启停。 所以说，应用需要让自己的启动流程顺畅一些，避免大量耗时或大量资源消耗。

快速上手步骤

1. 安装 kubectl：从官方下载 kubectl 二进制文件，配置 ~/.kube/config 连接到 K8s 集群，运行 kubectl get nodes 验证连接。
2. 创建第一个 Deployment：编写 Deployment YAML，指定容器镜像、端口（containerPort）、CPU/内存限制，运行 kubectl apply -f deployment.yaml。
3. 暴露 Service：编写 Service YAML，通过 selector 标签关联 Deployment 的 Pod，指定 type: LoadBalancer 或 NodePort，运行 kubectl apply -f service.yaml。
4. 水平伸缩：运行 kubectl autoscale deployment <name> --cpu-percent=80 --min=2 --max=10 创建 HPA，通过压测观察 Pod 自动扩缩容。
5. 配置探针与钩子：在 Deployment 中添加 livenessProbe、readinessProbe 和 lifecycle.preStop 配置，确保应用在 K8s 环境下具备自愈和优雅关闭能力。

职业回顾

2021年里，最大的变化还是来自工作，由于所在的行业一夜之间直接在风口上消失，原本在一家公司长期发展的愿望落空，所以我也被迫重新开始了新的职业规划。一个关键的考量点就是要去大公司还是小公司。我在前边为什么说自己走到了一个重要的岔路口上，其实最关键的一点原因就是感觉无论做哪个选择，在这个年龄其实都不会有什么回头路了。大公司和小公司对一个资深员工的能力要求，差别实际上是非常大的。到了这个阶段，不会再有刚毕业那几年随时大小公司左右横跳的机会。

为了做这个决策，我问了自己几个问题。

在大公司，个人能力会比在小公司成长的更快吗？

在大公司，生活是否会比小公司更舒适？

我在将来是否还需要一份新大公司经历做背书？

在大公司能获得更多的经济收入吗？

经过慎重的考虑，对这几个问题的回答其实都是否。个人成长看个人，我实质上不是一个会受环境影响太大的人。对于work life balance的问题，按理说其实和公司大小没太大的关系，只是凑巧国内的几个大公司这方面都不太行。背书的问题，因为我本来也有大厂的经历，包括综合学历和之前的其他经历，我觉得是不太有可能在这方面吃亏的，另外，根据这一波找工作，以及这两年面试别人的感受，我也会觉得项目本身的含金量，会比在哪个公司更重要一些。至于收入，看大环境、看公司的变化情况、看老板风格、看运气，总之不会和公司大小有太大的关系。

想来想去，感觉去大厂的唯一作用，就是说出去面子上好看一些。所以，也就把这个决定做下了，就是彻底放弃大公司的想法，而是去寻找一些氛围好、前景优良的创业公司机会。说到这儿，有时候我其实非常感激上天的眷顾，仿佛她总会在我一些关键节点上适时的给我抛出一些合适的选项。当然实际上主要是感谢猎头小姐姐提供的信息和整个过程中的帮助，让我来到了一个各方面都非常满意的新公司。在新公司也快4个月了，这段时间包括做事的空间、个人成长、WLB、经济回报，其实都是高于预期的。

生活变化

在新的工作时间下，也有了更多的时间陪女儿。小姑娘最近也处在一个语言的爆发期，基本每天都会说新的话，生活的幸福感也到了一个非常高的阶段。

技术成长

另外，我每年初都会定一些个人成长上的目标。2021年初，我的关键目标其实就是扩大和巩固自己的能力圈，争取掌握一些新的技能，并巩固已有的技能。具体来说包括本职工作相关的技术和管理能力提升，提升商业认知和投资能力，以及建立一些底层的同样技能。

本职工作上，阅读了周志明老师的《凤凰架构》这本书，这本书的关键作用是帮助我建立起了更完善的知识体系，也补全了一些知识上的盲区。学习了极客时间上王争小哥的设计模式专栏，对设计模式有了更深刻的理解，也在公司内做了一次设计模式主题的分享。此外，对于用了很久都没太认真了解过的elasticsearch, 做了一次集中的学习。

对于管理，今年内学习了一些理论知识，也在设法将理论知识运用到实际工作中，感觉还不错。

投资上，今年实际上做了一些非常错误的尝试。今年初开始，我在试图自己去分析公司的基本面，从而找到合适的投资标的，读了很多书，也看了很多大V的经验。我的目前结论是，这个事情的门槛是非常高的，通过自己的学习去达到专业人士的投资效果，是不现实的。基于此次尝试，我的投资收益在今年第一次变成负数。而在未来，我也会放弃个股投资，转向彻底的基金和指数定投。但是我倒不会停止对商业和投资知识的学习，因为我感受到了这些知识对于我思维方式的转变，实际上是会有不错的收获的。

关于底层能力，我今年着重培养的是”清晰力“这么一个能力。这个概念来自于《认知觉醒》这本书，意思是说我们的恐惧很多时候是“模糊”，即没有想明白要面对的究竟是个什么事。而一旦能对事情有清晰的认知，会发现事情并没有那么难。当第一次看到这个概念的时候，我立刻就感觉到我自己一直以来在这方面上问题很大，所以就着手在这方面上进行刻意的练习。效果也很不错，无论是工作还是生活上的事，处理起来都感觉得心应手了很多。

2022 展望

总而言之，这一年对我来说，是一个关键的抉择之年，也在向着人生的目标稳步前行。感谢所有曾经帮助过我的人。希望2022也继续加油。

原文地址: https://lichuanyang.top/posts/2345/

常见问题

Q: 中年工程师的出路在哪？

出路不在公司大小，而在你的能力圈。到了职业中后期，比”去哪个公司”更关键的是：你对什么领域有独到见解、你能解决什么级别的技术问题、你的经验是否形成了可迁移的方法论。作者的选择——放弃大厂光环，去寻找氛围好、前景优良的创业公司——给出了一条可行的路径。但路径不是唯一的，关键是主动思考你要什么，而不是被动等机会砸下来。

Q: 技术人如何应对行业变化？

三个字：能力圈。行业风口可能一夜消失（如作者经历的教培行业），但如果你平时就在持续巩固和扩大自己的能力圈，就拥有了在不同行业间迁移的资本。具体来说：保持技术敏感度（读经典书籍如《凤凰架构》）、培养底层可迁移能力（如”清晰力”）、不要把职业安全感绑定在某一家公司或某一个行业上。

Q: 大公司还是小公司更适合资深工程师？

这取决于你现阶段最需要什么。大公司提供平台背书和资源规模，但个人成长速度和 WLB 未必理想；小公司提供更大的做事空间和更快的决策节奏，但稳定性相对较低。作者对比后的结论是：个人成长靠自己，不靠公司大小；大厂经历已有的话，背书需求不大；收入更多看大环境和个人运气。核心建议是——想清楚自己现阶段的选择标准，再做决策，因为到了这个阶段，不太会有回头路。

设计思路

IP 地址本质上是一个 32 位整数。所谓”IP 段”就是一段连续的整数范围。给定一个 IP，我们要找到它落在哪个 IP 段中——这是一个典型的区间查找问题。

最直接的做法是遍历所有 IP 段，O(n) 复杂度。但全球 IP 段有几十万个，遍历太慢。更好的做法是把 IP 段的起始地址排序后放入数组，用二分查找定位，O(log n) 复杂度，几十万个段只需要约 19 次比较。

数据源

IP 地址库数据可以从 IP2Location Lite 免费获取。数据格式示例：

1
2
3

16781312,JP
16785408,CN
16793600,JP

每行包含两个字段：IP 段的起始地址（转换后的整数）和国家代号。

原始数据其实还包含 IP 段的结束地址，但 IP2Location 的数据段是连续无间隙的——一个段的结束地址恰好是下一个段的起始地址减一。因此我们可以只存储起始地址，结束地址自然而然地由下一个段的起始地址确定。这个优化节省了一半的内存。

数据结构

1
2
3
4
5
6
7
8

public class IpCountryLookup {
    // IP 段的起始地址（有序）
    private final long[] startIps;
    // 对应的国家代号
    private final String[] countryCodes;
    // 总段数
    private final int size;
}

两个并行数组：startIps[i] 和 countryCodes[i] 一一对应。二分查找在 startIps 上进行，找到后从 countryCodes 中取结果。

核心实现：二分查找

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

public String lookup(String ip) {
    long ipLong = ipToLong(ip);
    
    // 二分查找：找最后一个 <= ipLong 的起始地址
    int left = 0, right = size - 1;
    while (left <= right) {
        int mid = left + (right - left) / 2;
        if (startIps[mid] <= ipLong) {
            left = mid + 1;
        } else {
            right = mid - 1;
        }
    }
    
    // right 就是最后一个 <= ipLong 的位置
    if (right >= 0) {
        return countryCodes[right];
    }
    return "Unknown";
}

// IP 字符串转 long
private long ipToLong(String ip) {
    String[] parts = ip.split("\\.");
    return (Long.parseLong(parts[0]) << 24)
         + (Long.parseLong(parts[1]) << 16)
         + (Long.parseLong(parts[2]) << 8)
         + Long.parseLong(parts[3]);
}

性能数据

• 内存占用：约 30 万条 IP 段，两个数组各 ~30 万元素，总计约 4 MB
• 查询延迟：单次查询 < 10 微秒（二分查找约 19 次比较）
• QPS：单机轻松支撑百万级
• 数据更新：IP 库约每月更新一次，定时任务自动拉取并重载

其他数据源对比

如果只需要国家粒度，IP2Location Lite 足够。需要城市精度则推荐 MaxMind GeoLite2。

部署

项目基于 Spring Boot，支持两种运行方式：

1
2
3
4
5

# 直接运行
mvn spring-boot:run

# Docker
docker run -p 8080:8080 lcy362/ip-country

在线体验：http://ip-country.lichuanyang.top/

项目源码：https://github.com/lcy362/ip-country

在通常的开发流程中，会有各种各样的评审(review)环节，比如产品稿评审、设计评审、测试用例评审、code review等。为了做这些评审，难免会引入一些会议。有的人会觉得这些事没什么用，太浪费时间。而实际上，这些事情是非常重要的，如果你产生了评审不重要的印象，原因无非两个，一是认知不到位，而是你所在的环境评审实施的不好。

Review 对团队的价值

关于评审的价值，首先对于团队来说，最大的作用其实就是提升团队的下限。试想一下，如果各个环节都不进行评审，而是直接产品交付一个产品稿，开发就对着开发，任何个人的疏忽都会给整个项目带来无尽的风险。多次的评审环节，实际上就是将一个业务方案，分别用产品稿、代码、测试用例等形式描述，再分别引入更多的人来检查，避免一个人的疏忽造成业务上的风险。

此外，本文的重点，我实际上是想讲讲除了给团队带来的价值外，对于一个个体的人来说，参与评审有什么价值。

Review 对被审查者的价值

首先说一下对于被评审的人，即产品稿、代码等的提交人来说，评审就是一个其他人来帮助你提升的过程，是难得的能获取直接的反馈信息的机会。其实对于很多人来说，相比于学生时代，工作时代学东西的最大难点就是没有人批改「作业」，看了书看了视频之后，没办法确认自己究竟学没学会。而及时的反馈，无论学什么，都是非常重要的。而在参与评审的人中，会包括你的上级，能力更强的同事。他们能够详细的了解你的方案、代码的话，相信是能够给出很多有价值的反馈的。评审，实际上就是给你自己提供一个机会，能够接收到他们的反馈信息。

这里其实隐含了一条对于提交人的要求，就是要能够清晰的表达出自己的方案，这样别人才能低成本的参与到评审中来。比如写代码，要运用合理的设计模式，写出易读的代码。写文档，要有合理的布局、分段，突出方案的重点。向别人讲方案时，要考虑听众的知识背景，确保他们可以听的懂你的方案。

评审对于提交人的另一个重要作用，是分担风险和责任。要知道，无论你公司的制度是什么样的，无论你的职位如何，当你负责的项目没有做好时，最终的结果，一定是有相当一部分是由你自己承担的。承担的形式，可能是直接的绩效损失，可能是别人对你的能力产生了质疑，不管怎样，都是大家不希望面对的。而评审，就是将一部分后果，转移到整个团队上。当然，别想太多，主体的责任一定是还在提交人本人身上。这里，同样体现了提交人清晰表达的重要性。提交人需要将自己方案的关键点，更多的让评审人们接受到。如果评审人成功的接收这些信息，并且在评审时进行充分的讨论并最终达成共识，这一部分决策就可以认为是团队共同做出的了。

Review 对审查者的价值

接下来再来看对于评审人来说，积极的参与对其他人的评审，又有什么作用。首先的价值还是一个学习的机会。所谓三人行，必有我师，从别人的方案里，一定是能够发现一些非常好的点，值得自己学习的。当发现别人的方案和自己的设想不一致时，是一个进行深度思考的机会，可以对自己进行一个连续的追问，看看到底哪种方案比较好，直到得出一个无法质疑的结论。这种深度的思考，对于自己的思考方式会有很好的改善作用。

另外，参与评审也是一个快速提升经验的方法。参与评审，实际上是花费评审的时间，得到一个无限接近于 自己做了这件事 的效果。评审的足够细致的话，你就会对这件事怎么做，有一个非常全面的认识，这件事也就完全可以作为你项目经历的一部分。

总结

本文到这里就要结束了，不知道大家能否通过本文建立起对为什么要做评审、怎么做评审的认知。大家可以通过 公众号( Mobility ), 个人网站 等和我交流。

原文地址: https://lichuanyang.top/posts/57205

四个维度的取舍

职业选择，最重要的无非就是城市和公司选择。城市选择是一件非常主观的事情，比如我，作为一个北方人，既不喜欢南方城市的气候，又想离家近，还需要大城市的机会，北京就几乎成了唯一选择。当然，给大家的建议，功利点的话，建议选择一些快速发展中的强二线城市，比如重庆、合肥，这样随着城市平台的发展，你自己身处其中，身价也会提升。

接下来，我会限定在北京的范围内，结合我自己的经历，说一下公司的选择。

户口：一线城市的入场券

提到北京，一个不得不提的问题就是户口的问题。不过，我强烈不建议你依据一个户口就决定了整个人生怎么走，比如明明不想进体制内，却为了个户口就去了。务必在考虑户口问题之前，优先想好职业发展方向的问题。

很多人会纠结于体制内/体制外、大公司/小公司这些明面上的选择，但这些其实都只是表象而已，同样是体制内，也可能有天差地别的变化。一个正确的做法是想清楚自己真正想要的，然后再去寻找合适的工作机会。对于什么是自己想要的，确实不是每个人都能想的清楚。所以，我把这个问题拆解一下，看看工作的选择究竟意味着什么。大家可以思考以下几个问题：

• 你最希望从工作中获得什么？钱？权力？还是内心的成就感？或是并不想从工作中获得任何东西？
• 你希望工作在你的人生中占据多大的比例
• 对于工作中获取的资源（人脉、信息等），和通过工作提升的能力，那一项你更有信心能带到其他的环境里
• 你喜欢做常规的事务性工作，还是希望持续的去挑战困难问题

对于上边的任何一个问题，任何回答都没有高下之分，比如挑战困难问题并不比做常规工作更优越，这个只是大家根据个人价值观做出的选择而已。

这些选择的任意排列组合，相信都可以找到合适的机会。比如不期待从工作中有所得，不想工作占据太多人生，也愿意做常规的工作，那就可以考虑一些边缘的体制内单位；期望有权力，可以让工作占据很多生活时间，更想通过工作积累资源，就可以考虑核心的、有实权的体制内单位；而如果期望挣钱，更希望通过工作提升个人能力，程序员就是个不错的选择。

想好了上边的问题，就可以选择公司了。很多时候，我们可能无法找到并顺利的进入一个满足所有要求的地方。这也没关系，我们可以利用跳槽，每次解决其中一部分问题，并且持续的搜集信息和提升能力，寻找到合适的机会，并有能力获得这个机会。

大厂：平台的价值与代价

我以自己的经历讲一下我的几个关键选择是怎么考虑的。

刚毕业的时候，我的期望是获得一个北京户口，并且能留在互联网行业内。那个时候我的选择有两个大方向，一是去互联网公司竞争ssp offer, 但是当时的能力确实不足，所以这条路很难走的通；另一条路就是在体制内寻找业务接近互联网场景的机会，最好是面向普通用户的C端产品，因为这样可以有充足的用户量和数据量，让我不至于离业内先进的技术太远。很幸运，我找到了这样的机会，也成功的抓住了。入职之后，也基本如我所料，虽然公司技术水平并不高，企业文化也有很多问题，但是业务场景是非常好的，我也有充足的自己发挥的机会，借助工作，也学到了很多东西。

接下来，我要解决的问题就是大厂经历，所以接下来跳槽的时候就只考虑了几个一线大厂。关于工作本身，倒没什么好说的，这段经历虽然过的很不开心，但是希望达到的目标也达到了，所以也没什么遗憾的。

再下一次跳槽，我期望解决的问题有三个：大幅提高收入，抹平因为在国企呆的时间比较长造成的和同龄人的收入差距；别加班太多；人际关系轻松一些。这三个问题看似矛盾是不是？但是用心去找总是能找到合适的机会的，我也就这样来到了现在的公司。当然不是所有问题都解决的非常好，但是已经足够让我的工作体验非常幸福了。

通过我自己的经历，其实大家也可以看到，我总是似乎在提互相矛盾的要求，总是想鱼与熊掌兼得，而且最后也能幸运的都得到。其实这世界上公司那么多，并不是说有哪两个条件是必然互相矛盾的。大家没有必要过早的就舍弃什么，比如做程序员就一定意味着996，意味着放弃生活吗？显然不是。

上边可以衍生出两个比较细的问题，我也一起说下吧。

一是要不要选择北京户口。我先说一下我通过这个户口获得了什么吧，首先是赶上了15，16年那波房价大涨，让家庭资产在我并没有什么理财观念的时候，也获得了大幅增值。这一点我觉得放在今天，已经不成立了，房住不炒的大前提下，就算北京的房子，也不可能跑的过股市。第二点，就是一些手续办的方便一点，这个我觉得基本可以忽略不计吧，一年估计都办不了一次事，而且越来越多的手续也支持异地办理了。第三点，就是可以放心的让孩子在北京接受教育，不用担忧未来的不确定性。为什么我说是不确定性，因为我觉得接近二十年之后，非京的孩子是否依旧不能在北京高考，是有很大的不确定性的。北京的高考难度会卷成什么样，也是有很大的不确定性的。北京户口，只能说让我个人未来的选择固定了下来，但这个选择未来会是什么效果，其实很难说的准。

所以说，当前来看，北京户口的价值其实非常有限。回到2015年的话，我仍然会毫不犹豫的选择要北京户口。但是如果让我在2021年的今天做这个选择，其实我大概率是不要的。

第二点，是关于大厂经历。这一点，我的看法是必须要有，而且尽早有，但是没必要一辈子都呆在大公司里。大厂经历的价值，其实很多人已经说的很清楚了，所以我也不想再赘述。感兴趣的话可以私下找我沟通。

如何选择

上边的篇幅里，主要说的是方向的选择。选定了方向之后，还有个重要的问题是具体公司的选择。面对一个公司，其实考虑两个问题就可以：

• 我通过这个工作能得到什么
• 我因为这个工作会失去什么，将来有什么办法可以弥补

以我的第一份工作来说，获得的就是户口和互联网的业务场景。同时会失去大公司的学习资源、优良的公司氛围、高薪水等等，这些问题都需要自己想办法去解决。

好了，上文已经讲完了本文的大部分内容。有个点，我一直没有提，就是中年危机的问题，可能会有人问。我为什么不提呢，因为我不觉得这是一个能靠选择解决的问题。有些人会觉得体制内很稳定，即使天天混日子也没人能把你怎么着。但是我不觉得这种依赖外部条件的事情能算稳定，历史上体制内不是没出过问题。走这条路或许你有99.99%的机会一辈子过的安安稳稳，但是如果那万分之一的可能性发生了，你打算怎么办呢。而做程序员就不一样，或许只有50%的机会能平稳的呆在一家公司，但是随着工作提升的能力，让我可以很安心的应对另一半可能性。解决中年危机的唯一方式就是提升自己，不管是提升能力还是积累资源，你总要从工作中有所得，才能持续的保持自己的竞争力。

我是流沙，大家可以通过公众号( Mobility ), 个人网站 等和我交流。

原文地址: https://lichuanyang.top/posts/34931/

常见问题

Q: 一线城市户口还值不值得争取？2021 年的户口价值发生了什么变化？

户口曾经最大的价值是绑定房产增值（作者在 2015-16 年赶上了那波行情）。但在”房住不炒”大背景下，这个红利已基本消失。教育价值方面，近二十年后的政策不确定性很大，非京籍能否在京高考很难预测。所以 2021 年的观点是：北京户口的实际价值已经非常有限，不建议仅凭一个户口就决定职业方向——如果回归 2015 年作者仍会要户口，但如果回到 2021 年，大概率不会要。

Q: 大厂还是小厂？应届生第一份工作选什么最重要？

作者的观点很明确：大厂经历必须要有，且尽早有，但不用一辈子呆在大厂。大厂经历的价值在于平台背书、技术视野和成长加速度，这些已经被反复讨论过。第一份工作最重要的不是户口也不是薪资，而是想清楚四个问题：1) 你最想从工作中获得什么（钱/权力/成就感/什么都不想获得）；2) 工作占人生的比例；3) 资源和人脉 vs 个人能力，哪个更有信心带走；4) 喜欢常规事务性工作还是持续挑战困难问题。

Q: 想鱼与熊掌兼得（高薪 + 不加班 + 氛围好）可能吗？

作者用自己的经历证明：可能，但需要用心去找。这世上公司足够多，并没有哪两个条件是必然互斥的——做程序员不等于必然 996、不等于必然放弃生活。关键是不要过早预设”只能选一个”，先问清楚自己真正想要什么，然后持续搜集信息、提升能力，总能找到满足大部分条件的机会。一次跳槽解决不了所有问题就分多次。

Q: 解决中年危机的根本方式是什么？靠选择体制内能一劳永逸吗？

作者明确表示：不觉得中年危机是能靠选择解决的。体制内的”稳定”本质上是依赖外部条件——历史上体制内不是没出过问题。即使有 99.99% 的概率安稳，但那万分之一一旦发生，你毫无应对能力。真正的解决方式是在每一份工作中持续积累可带走的能力——做程序员可能只有 50% 的概率平稳呆在一家公司，但积累的能力让你能安心应对另一半不确定性。

关于rpc接口的输入和输出，一直有一种观点是将输入和输出都包装成单个request和response类。本文，我们就分析一下这种方式是否是一个合理的设计。

输入参数封装分析

先说输入, 这个我先说结论，当且仅当输入参数过多时，才应该做封装。其他情况下完全没有做封装的理由。

对于将输入参数包装成request类的理由，无非是下边这些

• 修改接口参数时保持兼容性
• 可以定义通用的抽象request类，方便做统一管理

首先，第一条完全就是个伪命题，第一次看到这种论断的时候，我也差一点被绕进去，但是仔细思考一下，就会发现这个完全不成立。

即便使用request体的形式，如果接口提供方增加了必传的字段，调用方仍然需要增加这个参数才能调用，那相比于直接传参数，没有解决任何问题。而这种问题实际上也是无法解决的，因为就不应该让这种情况出现。接口提供方有义务保证后续的修改是向前兼容的。而对于增加的是非必传字段这种情况，即便不包装request类，也可以通过适配器的形式实现新接口并兼容老接口，后续再找机会异步的将老接口下线。

第二条的话，确实存在一定意义。

• 比如在抽象类里加一些统一的请求参数，这一点我认为做在框架里更合适，没有必要暴露在业务代码中
• 再比如添加统一的参数校验，但是单纯为这种效果的话，我觉得用一个过于抽象的类是不合适的，而是应当一类相关的业务用一个抽象类，因为一类业务才会有这种需求。同时，即便不包装成request类，这类需求也没什么难做的，因为它的难度本身就不在输入结构不统一上。

而将输入参数包装成request类的最大问题就是会破坏代码的可读性，会造成语义不明确。本身类似 queryById(long id) 这么一个方法的语义是非常明确的，扫一眼接口定义就可以看清楚输入输出。但是强行封装之后，这个接口究竟要输入什么就不是那么明确了。同时，如果request中有三个参数，是否传入任意组合都能返回结果呢？这也是靠看接口看不明白的。而正常的用参数定义的话，可以使用适配器的形式定义一系列接口，接口调用方也更容易理解。

封装输入参数的唯一条件就是传入参数过多，这时候需要通过其他的方式，比如注释、文档，去约定接口的合法输入值和升级方案。

输出结果封装分析

接下来说输出，将输出结果封装成一个response体，相对于封装输入参数，会合理一些，但也不能乱用。一般将输出结果封装的目的就是包一层返回状态码。

接口隔离原则的视角

这一点实质上就是强迫调用方来了解接口的异常情况。我们知道，基本的设计原则中有一条叫「接口隔离原则」，其具体描述是 Clients should not be forced to depend upon interfaces that they do not use。对于这儿的情况要类似，如果调用方确实不关心请求成功或者失败的原因，那就不应该强迫调用方来了解这个。比如我就是要查个数，只存在查到或者查不到两种情况，并不想关心到底为什么没查到。

所以，在设计接口的时候，需要慎重的考虑接口的异常原因是否是一个应当提供出去的信息，在此基础上，才能说保障response合适或者不合适。

结论与建议

综上所述，盲目的一味去封装所有输入和输出参数，一定是不可取的。对于何时应该做封装，何时不应该，务必要做慎重的考虑。大家有什么想法的话，也可以跟我沟通。

原文地址：https://lichuanyang.top/posts/20888/

常见问题

Q: 什么时候该把 RPC 输入/输出封装成 request/response 类？

输入参数：当且仅当参数过多时才应该封装。如果参数少（如 queryById(long id) 只有一个参数），封装成 request 类反而破坏可读性——你不能一眼看出接口需要什么参数，也无法从接口签名判断传入哪些组合是合法的。输出结果：封装的目的是包一层返回状态码，但需要慎重——如果调用方并不关心失败原因（只关心查到/查不到），就不该强迫调用方处理这层状态码。

Q: RPC 返回值加统一状态码和接口隔离原则冲突吗？

看情况。接口隔离原则（Clients should not be forced to depend upon interfaces that they do not use）的核心是不要让调用方依赖它不需要的东西。如果调用方确实需要知道失败原因（如支付接口需要区分余额不足/风控拦截/网络超时），统一状态码是合理的；但如果调用方只需要”查到/查不到”的结果，强迫它处理状态码就违反了接口隔离原则。关键在于：异常原因是值得对外提供的信息，还是内部实现细节？ 先回答这个问题，再决定 response 的封装方式。

Q: 业界对 RPC 接口设计的普遍实践是什么？

业界没有”绝对正确的标准”，不同场景有不同选择。Google 的 gRPC/labcorn一直采用单 request + 单 response 消息的模式，这与其 ProtoBuf 的 IDL 驱动、跨语言代码生成、强类型校验的定位一致。而更轻量的内部 RPC（如早期的 Dubbo 接口）则倾向于直接传参以保持简洁。好的实践是根据参数数量和调用方需求做判断，而不是一刀切：参数少且语义清晰的接口直接传参；参数多或需要兼容性管理的接口适度封装。

Q: 封装 request 类后如何避免语义不明确的问题？

文中指出，封装后的最大问题是接口签名不再”自解释”——你无法从 query(Request request) 知道需要传什么。解决方案：1) 必须配合文档和注释说明 request 中各字段的必填/选填/互斥关系；2) 定义合法的字段组合，并在 request 类上做校验；3) 对升级方案做明确约定（哪些字段新增是非必填兼容的，哪些是破坏性变更需要新接口版本）；4) 如果参数不多，就不要封装——保持简单是最好的文档。

我为什么不做底层开发

首先，我想说一个很多人的认知，就是认为做底层的开发更容易学到东西，成长更快。我觉得这就是业务开发同学的臆想而已，底层开发没有大家想的那么利于学习，业务开发也没有大家想的那么不利于学习，原因我会在后边展开说。而之所以很多人有这样的认知，很大程度上是因为底层开发的招聘标准通常会高一些，所以这些人本身的学习能力和意愿就是要好一些。

其实底层开发的日常和业务开发也没有太大区别，都是在做需求。只是业务需求的来源是产品经理，底层需求的来源是其他开发，或者底层开发者本人的思考和想法。这里，我要说自己为什么不愿意做底层开发的第一个原因了，就是需求的来源不科学。首先，如果只做底层开发，而脱离了实际业务场景的话，对于技术的认知很可能是有偏差的，这样导致自己想做的一些事很可能是在自嗨，并没有实际应用价值。而如果从其他那些搜集需求呢，也会有类似的问题，业务开发的同学提出的意见可能也就是他自己的非常浅的想法而已，不一定经过了很完善的考虑；再者，业务同学对基础组件究竟该干什么也未必理解准确，他可能分不清楚什么事应该基础组件解决，什么事应该自己解决。

在这，引入了我不愿意做底层开发的第二个原因，就是职责边界不明确。这个和配合的业务方的能力强相关。有时候，自己有些事没做好，业务方也能找到办法解决；而有时，明明和自己没关系，也要被迫处理一些上层的逻辑。

大家也可以看到，上边两个问题都极度依赖同事的能力，所以，如果你一定要做底层开发的话，一定要去技术能力储备强的公司，这个直接关系到你的工作幸福度。公司的选择还影响一件事，就是工作内容，简单的说，就是要造轮子，还是完善开源工具，两类工作可以说是天差地别。造轮子，需要对各种底层知识很熟悉，确实是很能促进进步，这个也是“做底层有利于成长”这种想法的来源。但是这种事仅存在为数不多的几家大公司中。其他大量的完善开源工具的工作，其实和业务开发没有任何区别，只需要了解一下开源工具的边边角角，就可以完成大部分工作，既没有深度，也没有广度。我开篇的时候说底层开发并不能帮助学习，原因也就在这。

所以，要做底层开发，公司的选择至关重要，大，技术能力强，两个条件缺一不可。大家肯定会问，我去这样的公司做不就行了吗。话是这么说没错，但这带来的问题也就来了，这也是我不想做底层开发的第三个原因，职业选择面太窄。国内java底层做的好的也就某里某团两家而已，这两家的企业文化大家也都清楚。所以，不想去这样的公司，是不是就不干了？即使你能接受，巨大的供需量对比，也会带来疯狂的内卷，就像算法岗那样，你是否有足够的把握赢得这场内卷游戏呢？而对于业务开发来说，大厂经历只是一段必要的学习经历和自己简历上的一个亮点，当你对大厂的整个规范流程熟悉了之后，就可以自由的选择想去的公司了。

业务开发的价值

前边讲底层开发说的太多了，下边进入正题，就是业务开发的价值。在我看来，业务开发带给我的能力提升主要在三个方面：业务知识的积累，技术广度的提升和综合能力的提升。

先说业务知识，业务知识其实就是对现实世界的理解。对于我个人来说，工作之余，了解一下其他行业的运转模式，首先就是一个很有意思的事情。其次，不断的去了解不同行业的行业知识，我是完全能感受的到对我认知能力的提升的。这种能力能不能变现？当然是可以的。比如去炒股，工作中的积累让我有了分析一个公司商业模式的能力，对于什么样的是好公司好股票，显然可以比一般人理解的深一些。当然，这儿扯的太远了，大家看看就好，关键是看自己的兴趣，有没有意愿去了解一些技术之外的事情。

接下来是技术广度。业务开发和底层开发的最大区别，其实就是底层开发对深度要求更高，而业务开发对广度要求更高。业务开发需要对各种各样的框架、中间件都有所了解，并且不能了解的太浅，也需要一定的深度，要能够理解它们能解决什么问题，又会带来什么问题，适用于什么场景；面对复杂的业务场景和复杂的系统，要能够全面理解；发生问题时，要有能力快速定位到问题在哪。这些除了需要知识的积累，也需要实际场景下经验的积累。

然后说一下综合能力的提升，相比底层开发，业务开发对人的通用基础能力会有更大的锻炼，比如沟通能力、分析解决问题的能力、权衡取舍的能力。这些能力可以说和技术有关，但关联也没那么大，极端的讲，即使你将来转行了，这些普适性的能力也会很有帮助。我时常在想，学着用一个开源工具，和打王者荣耀，究竟有什么区别。作为新手，参考着现成的例子做一个demo, 就相当于第一次接触这个游戏，随便打打。而随着对这个逐渐熟悉，有的人可能就成了没有感情的调包机器，而有的人就可以逐渐去了解底层的实现。就像游戏里，有的人一直浑浑噩噩，打了几千场连电刀和无尽战刃有什么区别都不知道，而有的人就会去探索伤害的数值机制。所以，我觉得大家别把程序员看成一个多特殊的职业，它和其他职业并没有什么本质的区别。大部分职业事实上都是在用不同的方式解决问题，比如律师是依靠法律，基金经理是依靠对市场和基本面的认知，程序员就是靠代码。我们在不断的工作中，锻炼的是解决问题的能力，而解决的方法并没有人要求你一定要限制在技术之内。

我们在业务开发中，就是要不断积累上边三个方面的能力，这样才能滚起雪球，从而从容的应对中年危机。我写这篇文章，当然也并不是要说业务开发就是好，主要还是想帮大家分析清楚业务开发和底层开发的区别，从而做出一个理性的选择。

如果大家有什么想法，也可以来和我沟通。

原文地址: https://lichuanyang.top/posts/40071/

前置知识

提到设计模式，其实首先需要理解清楚的是面向对象思想。相信大家即使不能非常清晰的描述出来，对面向对象也应该是比较熟悉的。

我们就快速讲一下，面向对象有四大基本特性：封装、抽象、继承、多态；

封装：仅暴露有限的接口，授权外部来访问。将逻辑集中，因此更可控；可读性、可维护性也更好；易用性也更好。

抽象：隐藏方法的具体实现，让调用者只需要关心方法提供了哪些功能，并不需要知道这些功能是如何实现的。

继承：好处就是代码复用。

多态：子类可以替换父类。提高代码的可扩展和可复用性。

什么是设计模式

设计模式是针对软件开发中经常遇到的一些设计问题，根据基本的设计原则，总结出来的一套实用的解决方案或者设计思路。

可以看到，设计模式是非常偏实际应用的，相比设计原则更加具体、可执行。

因此，在了解设计模式之前，就需要了解一些基本的设计原则。这些原则才是指导我们写出好代码的关键。

那么什么是好代码呢？

好代码的标准

这个其实很难描述，我们可以试着归纳一些好代码的特征，比如下面这些：

可维护、可扩展、可读、可测、可复用、简洁。

为了达到这些标准，就需要现有一些基本的设计原则。

基本设计原则

SOLID

单一职责 Single Responsibility Principle

描述很简单，一个类只负责完成一个职责或者功能。但是实际要做好其实还是很难的。

关于怎么样才算职责单一，可以定出一些简单的标准，比如代码行数过多；依赖的其他类过多；私有方法过多；难以给类起名；类中大量方法功能集中等。但是无法定义出一个普适的标准，一定要结合实际情况去考虑。

比如这样一个类

1
2
3
4
5
6
7
8
9
10
11

Student {
    int id;
String name;
String age;
...
String province;
String city;
String county;
String detailAddress;
...
}

在其中至少有四个字段是和地址有关的，那么是否需要把地址相关的职责抽离出来，封装一个新的Address类?

其实，是要视情况而定的，如果地址这些属性只是单纯的展示信息，那么直接放在Student类里，就没有问题；如果在这背后还有一套复杂的物流系统，也就是有很多地址相关的复杂逻辑，那么这一部分就应当单独抽离出来。

在实际的开发中，我们可以先写一个粗粒度的类，满足业务需求。随着业务的发展，如果粗粒度的类越来越庞大，代码越来越多，这个时候，我们就可以将这个粗粒度的类，拆分成几个更细粒度的类。这就是所谓的持续重构。

开闭原则 Open Closed Principle

对扩展开放、对修改关闭。

添加一个新的功能，应该是通过在已有代码基础上扩展代码（新增模块、类、方法、属性等），而非修改已有代码（修改模块、类、方法、属性等）的方式来完成。

开闭原则是相对难理解的一条原则。

“怎样的代码改动才被定义为‘扩展’？怎样的代码改动才被定义为‘修改’？怎么才算满足或违反‘开闭原则’？修改代码就一定意味着违反‘开闭原则’吗？”等问题，都很难回答。

而这条原则又是最有用，因为扩展性是代码质量最重要的衡量标准之一。

实际上，我们也没必要纠结某个代码改动是“修改”还是“扩展”，更没必要太纠结它是否违反“开闭原则”。我们应当回到它的初衷上，只要没有破坏原有代码的运行，就没有违反开闭原则。一个简单的判断标准，当功能没有变化时，对应的单元测试没被破坏，就是一次满足开闭原则的改动。

关于如何做到对扩展开放、修改关，也需要慢慢学习和积累。在 23 种经典设计模式中，大部分设计模式都是为了解决代码的扩展性问题而存在的，主要遵从的设计原则就是开闭原则。

实际写代码时可以假定变化不会发生，当出现变化时，需要抽象以隔离将来的同类变化。

里式替换原则 Liskov Substitution Principle

子类能够在任何地方替换父类，并且保证原来程序的逻辑行为不变及正确性不被破坏。

里式替换原则还有另外一个更加能落地、更有指导意义的描述，那就是“Design By Contract”，中文翻译就是“按照协议来设计”。描述里子类和父类的关系，可以替换成接口和实现的关系。换一种方式描述里式替换原则，就是实现类不能违反接口声明要提供的功能、输入、输出、异常等。

接口隔离原则 Interface Segregation Principle

Clients should not be forced to depend upon interfaces that they do not use。

其核心要素就是一个「接口」的功能要尽量单一，调用方只需要依赖它需要的部分，而不需要去依赖或者调用整个「接口」。

这里的接口可以指代不同的含义，比如一组api接口集合（也就是我们用的一个proxy）。

比如有个项目，会做一些业务流程，生成一些数据，然后又要作为基础服务把数据提供出去，这时，最后就是提供了两个接口, 一个是用来处理内部流程；一个则是作为基础服务堆外提供。这样做的好处就是可以一定程度上避免误调用。

也可以将接口就理解为单独一个接口方法，这时候就是说一个方法的功能要单一。

接口隔离原则跟单一职责原则有点类似，不过稍微还是有点区别。单一职责原则针对的是模块、类、接口的设计。而接口隔离原则相对于单一职责原则，更侧重于接口的设计。接口隔离原则提供了一种判断接口的职责是否单一的标准：通过调用者如何使用接口来间接地判定。如果调用者只使用部分接口或接口的部分功能，那接口的设计就不够职责单一。

依赖反转原则 Dependency Inversion Principle

High-level modules shouldn’t depend on low-level modules. Both modules should depend on abstractions. In addition, abstractions shouldn’t depend on details. Details depend on abstractions.

所谓高层模块和低层模块的划分，简单来说就是，在调用链上，调用者属于高层，被调用者属于低层.

这一原则更多针对框架开发，业务开发里，高层模块依赖底层模块，实际上没有任何问题。

以tomcat为例，tomcat调用web程序来运行，所以tomcat是高层模块。

Tomcat 和应用程序代码之间并没有直接的依赖关系，两者都依赖同一个“抽象”，也就是 Servlet 规范。Servlet 规范不依赖具体的 Tomcat 容器和应用程序的实现细节，而 Tomcat 容器和应用程序依赖 Servlet 规范。

KISS

Keep It Simple and Stupid.

Keep It Short and Simple.

Keep It Simple and Straightforward

KISS原则有不同的表述方式，但是大体意思都差不多，就是要让代码尽量简单。

「简单」实际上是一个很主观的事情，code review是一种很好的间接评价代码是否简单的方式。如果同事review你的代码时，会有很多地方看不懂，这就很可能是代码不够简单。

一些简单的经验：不要重复造轮子；避免过度设计，无论是为了未来不确定的扩展性，还是细微的性能差别。

举个例子，StringUtils中的很多方法，在一个具体的场景中，我们是大概率可以写出一个性能更好的实现的，因为StringUtils中要考虑的很多通用性的问题，在具体的场景中就不需要考虑了。那么，我们是不是要真的这么去做？

DRY 原则（Don’t Repeat Yourself）

这一条本身很简单，不过要注意这里的repeat和单纯代码重复是有区别的。比如两个无关的方法，实现恰好一模一样，这时候就不认为它违反了DRY原则，因为语义上是不重复的。而两个方法，如果方法名到实现都完全不一样，但是是在做一件事，比如isValidIp(), checkIpValid(), 两个方法各自用不同的方法实现了，我们也认为违反了DRY原则。

另外要注意执行重复的问题，比如

1
2
3
4
5
6
7
8
9
10
11
12
13
14

void run1() {
a();
b();
}

void run2() {
a();
c();
}

main () {
run1();
run2();
}

虽然看起来代码封装的很好，但是执行main方法时，a方法执行了两次。如果a是一个开销很大的方法，就会很有问题。

迪米特法则

Each unit should have only limited knowledge about other units: only units “closely” related to the current unit. Or: Each unit should only talk to its friends; Don’t talk to strangers.

“高内聚、松耦合”是一个比较通用的设计思想，可以用来指导不同粒度代码的设计与开发，比如系统、模块、类、函数。

所谓高内聚，就是指相近的功能应该放到同一个类（模块、系统）中，不相近的功能不要放到同一个类（模块、系统）中。

所谓松耦合是说，在代码中，类（模块、系统）与类（模块、系统）之间的依赖关系简单清晰，只依赖必要的东西。

像qwerty中之前对作业相关逻辑的处理，需要了解每种类型作业的实现细节，就是一种违反了迪米特法则的做法。正确的做法是在作业这一侧定义一个通用的模型，模型中将各类作业的不同逻辑封装好，qwerty则只需要了解这个模型。

对于这些设计原则，不需要花费很多精力来扣它们的字眼。更重要的是，理解它们的思想，理解为什么这些原则能帮助我们写出来「可维护、可扩展、可读、可测、可复用、简洁」的代码。

接下来，我们就可以具体说设计模式了。

常用设计模式

经典的设计模式有 23 种。随着编程语言的演进，一些设计模式（比如 Singleton）也随之过时，甚至成了反模式，一些则被内置在编程语言中（比如 Iterator），另外还有一些新的模式诞生（比如 Monostate）

创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式

结构型模式，共七种：适配器模式、装饰者模式、代理模式、门面模式、桥接模式、组合模式、享元模式。

行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。

我们只挑其中一些重要的来讲吧。

简单工厂&工厂方法

比如一个需要根据文件格式来创建不同parser，将配置读取到RuleConfig中的功能，简单工厂模式的实现如下。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

public class RuleConfigSource {
  public RuleConfig load(String ruleConfigFilePath) {
    String ruleConfigFileExtension = getFileExtension(ruleConfigFilePath);
    IRuleConfigParser parser = RuleConfigParserFactory.createParser(ruleConfigFileExtension);
    if (parser == null) {
      throw new InvalidRuleConfigException(
              "Rule config file format is not supported: " + ruleConfigFilePath);
    }

    String configText = "";
    //从ruleConfigFilePath文件中读取配置文本到configText中
    RuleConfig ruleConfig = parser.parse(configText);
    return ruleConfig;
  }

  private String getFileExtension(String filePath) {
    //...解析文件名获取扩展名，比如rule.json，返回json
    return "json";
  }
}

public class RuleConfigParserFactory {
  public static IRuleConfigParser createParser(String configFormat) {
    IRuleConfigParser parser = null;
    if ("json".equalsIgnoreCase(configFormat)) {
      parser = new JsonRuleConfigParser();
    } else if ("xml".equalsIgnoreCase(configFormat)) {
      parser = new XmlRuleConfigParser();
    } else if ("yaml".equalsIgnoreCase(configFormat)) {
      parser = new YamlRuleConfigParser();
    } else if ("properties".equalsIgnoreCase(configFormat)) {
      parser = new PropertiesRuleConfigParser();
    }
    return parser;
  }
}

也就是创建一个工厂类，专门用来「生产」parser。

这里如果就把创建parser的过程，放到load方法里，其实也不是不行。之所以拆出来，就是要把创建这一部分逻辑拆分开。所以，只有当创建逻辑比较复杂的时候才会使用工厂模式。

上边的实现还可以进一步优化，去除大量的if-else。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

public class RuleConfigSource {
  public RuleConfig load(String ruleConfigFilePath) {
    String ruleConfigFileExtension = getFileExtension(ruleConfigFilePath);

    IRuleConfigParserFactory parserFactory = RuleConfigParserFactoryMap.getParserFactory(ruleConfigFileExtension);
    if (parserFactory == null) {
      throw new InvalidRuleConfigException("Rule config file format is not supported: " + ruleConfigFilePath);
    }
    IRuleConfigParser parser = parserFactory.createParser();

    String configText = "";
    //从ruleConfigFilePath文件中读取配置文本到configText中
    RuleConfig ruleConfig = parser.parse(configText);
    return ruleConfig;
  }

  private String getFileExtension(String filePath) {
    //...解析文件名获取扩展名，比如rule.json，返回json
    return "json";
  }
}

//因为工厂类只包含方法，不包含成员变量，完全可以复用，
//不需要每次都创建新的工厂类对象，所以，简单工厂模式的第二种实现思路更加合适。
public class RuleConfigParserFactoryMap { //工厂的工厂
  private static final Map<String, IRuleConfigParserFactory> cachedFactories = new HashMap<>();

  static {
    cachedFactories.put("json", new JsonRuleConfigParserFactory());
    cachedFactories.put("xml", new XmlRuleConfigParserFactory());
    cachedFactories.put("yaml", new YamlRuleConfigParserFactory());
    cachedFactories.put("properties", new PropertiesRuleConfigParserFactory());
  }

  public static IRuleConfigParserFactory getParserFactory(String type) {
    if (type == null || type.isEmpty()) {
      return null;
    }
    IRuleConfigParserFactory parserFactory = cachedFactories.get(type.toLowerCase());
    return parserFactory;
  }
}

这就是工厂方法模式，工厂方法模式实质上是为工厂类再创建一个简单工厂，也就是工厂的工厂，用来创建工厂类对象。

工厂模式的原理和实现都很简单，在实现时其实还有很多可以探究的细节，但在这里就不细说了。我们探讨的关键还是理解什么场景下应该用这种模式，它解决了什么问题。

对于工厂模式来说，应用的场景就是创建类的逻辑比较复杂时，比如需要有一堆if-else, 动态的决定要创建什么对象；或者虽然创建单个对象，但是创建本身的过程很复杂，调用方无需了解如何去创建。

建造者

建造者模式(Builder), 其实应用非常广泛，我们打开任何一个项目，都可以看到很多XXXBuilder.

建造者模式使用的场景是：一个类有多个可配置项，使用方可以自由选择其中若干个进行配置。

如果采用不同构造方法来实现这种效果，面对的就会说无穷无尽的组合。

而如果采用set方法来配置，那么首先当前类就彻底失去了对配置项的控制，调用方可以随时随地调用set方法。另外，如果需要在配置项被配置好之后进行一些合法性的校验，这种方式也无法实现。

这种情况下的解决方案就是建造者模式。

1
2
3
4
5
6

ResourcePoolConfig config = new ResourcePoolConfig.Builder()
 .setName("dbconnectionpool") 
 .setMaxTotal(16) 
 .setMaxIdle(10) 
 .setMinIdle(12)
 .build();

实现也比较简单。

工厂模式是用来创建一组相关但不同的的对象，建造者模式则是对同一个对象进行不同方式的定制。

单例

关于单例是什么，怎么实现单例，作为经典的面试题，就不多说了。只说一下单例的问题，为什么单例主键变成了一种反模式。

单例的问题：

隐藏类之间的依赖关系；

同时，依赖的直接就是单例的实现，违反了基于接口而非实现的设计原则；

可测性不好: 无法被mock(Mockito中)；全局变量有可能导致测试之间互相影响；

不支持有参数的构造函数。

但是，单例模式的优点是有些场景下使用起来更简洁方便，所以也没必要直接就认定不能使用单例。

代理&装饰器

代理模式和被代理类实现同一个接口，负责在业务代码执行前后附加其他逻辑代码（比如性能监控、计数等），然后用委托的形式调用被代理类完成业务功能，从而实现业务代码和框架代码的解耦。

装饰器模式是通过继承被装饰类，来实现功能的增强。比如java中inputStream系列类，就是装饰器模式的应用。

实现层面，代理模式和装饰器模式几乎一样，但是其意图不同。

代理模式中，代理类附加的是跟原始类无关的功能，而在装饰器模式中，装饰器类附加的是跟原始类相关的增强功能。

还是这个观点，对于设计模式，我们没必要扣字眼深究每种设计模式到底是什么，只要知道有这么一种技巧，可以处理类似的这种场景就可以了。

适配器

适配器模式很简单，我们可以直接看例子。

1
2
3
4
5
6
7
8
9
10

public void debug(String msg) { 
logger.log(FQCN, Level.DEBUG, msg, null); 
} 

public void debug(String format, Object arg) { 
if (logger.isDebugEnabled()) { 
FormattingTuple ft = MessageFormatter.format(format, arg); 
logger.log(FQCN, Level.DEBUG, ft.getMessage(), ft.getThrowable()); 
} 
}

应用场景包括：

兼容老版本接口；

应对不同的输入；

封装有缺陷的接口设计；

…

门面

门面模式为子系统提供一组统一的接口，定义一组高层接口让子系统更易用。这里主要是关系到一个接口的粒度应该有多大，从而平衡接口的通用性和易用性。

通常，粒度小的接口通用性肯定会好一些，但这样调用方就需要调用多个方法，必然不太好用。相反，如果接口粒度太大，就会有通用性不足的问题。

门面模式的作用就是解决这个问题。我是做在线教育的，有一个场景是在B端展示各种各样的题目，比如课前的题、课中的题、课后的题，每类中又分很多具体类型，每个类型有不同的数据来源。

这里，就需要权衡接口的通用性和可用性了。而门面模式刚好可以解决我们的问题。首先，我们要定义一个通用的模型，包括题干、参考答案、用户作答等，然后实现一批具体类型的接口。在此之上根据业务场景，封装一些门面层，门面层中只是简单的将子系统的数据组合起来。

策略

定义一族算法类，将每个算法分别封装起来，让它们可以互相替换。

实现方式是定义一个策略接口和一组实现这个接口的策略，运行时可以根据一些条件动态的选择执行哪个策略。

模板方法

模板方法模式在一个方法中定义一个算法骨架，并将某些步骤推迟到子类中实现。模板方法模式可以让子类在不改变算法整体结构的情况下，重新定义算法中的某些步骤。

比如java的AbstractList 的addAll方法就是一个模板方法。

1
2
3
4
5
6
7
8
9
10
11
12
13

public boolean addAll(int index, Collection<? extends E> c) {
    rangeCheckForAdd(index);
    boolean modified = false;
    for (E e : c) {
        add(index++, e);
        modified = true;
    }
    return modified;
}

public void add(int index, E element) {
    throw new UnsupportedOperationException();
}

观察者

在对象之间定义一个一对多的依赖，当一个对象状态改变的时候，所有依赖的对象都会自动收到通知。也就是发布订阅模式。

观察者模式是一个比较抽象的模式，根据不同的应用场景和需求，有完全不同的实现方式，但是思想很容易理解，所以也就不列代码了。像我们使用mq, 也就是在使用观察者模式。

责任链

将请求的发送和接收解耦，让多个接收对象都有机会处理这个请求。将这些接收对象串成一条链，并沿着这条链传递这个请求，直到链上的某个接收对象能够处理它为止。

实际使用中，责任链模式的一种变体应用也很广泛，就是让链上的每个接收对象都处理一遍这个请求。

比如我们有一个拼装数据的逻辑，就是责任链变体的一个应用。

1
2
3
4
5
6
7

private boolean fillUserDataCollection(Map<Integer, UserDataCollection> userExpandMap, Map<Integer, UserDataCollection> originUserExpandMap) {
        return !fillingServices
                .stream()
                .map(filler -> filler.fillUserDataWithFallback(userExpandMap, originUserExpandMap))
                .collect(toSet())
                .contains(false);
    }

UserDataCollection中包含大量字段，每个fillingService负责其中一部分数据的补充。

责任链的核心思路就是拆分，将大类拆成小类。这也是解决代码复杂度的重要手段之一。

经验总结

对于如何写出好的代码，最关键的是要先建立起心理上的认知，知道什么是好代码，也有写好代码的意愿。在此基础上，要对面向对象的思想和各类设计原则有充分的理解，知道为什么好代码要符合这些原则。

实践上，写出好代码的最佳方式就是持续重构。一开始业务发展不明朗的时候，代码无法设计到最好是很正常的。而随着业务的发展，我们会逐渐意识到代码里存在的问题，这时候可以翻翻设计模式中有没有什么现成的解决方案，然后应用到自己的项目中。

最后，说一下，这篇文章中的很多内容实际上来自极客时间的专栏《设计模式之美》。我觉得这个专栏是讲设计模式最好的一个专栏，推荐大家也可以去看看。点击下方图片购买即可。

原文地址: https://lichuanyang.top/posts/58527/

常见问题

Q: 设计模式学了不用会忘怎么办？

这很正常，关键在于学习方法要对。不要试图一次性背下 23 种模式的定义和结构——这种做法必然学了就忘。正确的路线是：先理解 SOLID 等设计原则的思想，然后在实际项目中遇到代码设计问题时，翻翻设计模式中有没有现成的解决方案，有目标地用、持续地重构。用得多了，对应场景和方案的映射就自然内化了，不需要刻意记忆。

Q: 哪种设计模式最常用？

创建型模式中工厂模式和建造者模式用得最多——几乎任何有一定复杂度的项目都能在依赖注入和对象构造中看到它们的身影。结构型模式中代理模式（如 AOP、RPC 框架）、适配器模式（兼容不同接口）和装饰器模式（如 Java IO 流）是最常见的。行为型模式中策略模式、模板方法模式和责任链模式在实际业务开发中出场率最高，因为它们直接对应”根据条件选择算法””定义流程骨架””链式处理请求”这三种高频场景。

Q: 设计模式和设计原则哪个更重要？

设计原则更重要。原则是”为什么”，模式是”怎么做”。SOLID、KISS、DRY、迪米特法则等设计原则指导你判断代码质量的得失，是所有好代码的共同基础。设计模式只是这些原则在某些典型场景下的具体实现方案。理解了原则，即使不记得某个模式的具体实现，也能写出好代码；反过来只记模式不识原理，就容易生搬硬套。

Q: 单例模式为什么变成了反模式？

主要问题在于：单例隐藏了类之间的依赖关系——调用方的代码直接依赖 Singleton.getInstance()，从接口上看不出它用了全局状态；可测试性差——单例无法被 Mock，全局状态可能导致测试之间互相影响；不支持有参数的构造函数——限制了灵活性。但这不意味单例完全不能用，在确实需要一个进程内唯一实例且不涉及复杂测试场景时，单例仍然是最简洁的选择。关键是理解它的代价，而不是迷信”单例一定不好”。

首先，列两个非常没效率的场景。

• 小A开发过程中碰到一个没见过的报错，于是抱着电脑去找团队里的大牛小X, 小X努力的搜集相关的各种必要信息。与此同时，小A就在旁边看着，并且不时的和小X还有旁边的小Y聊着天。
• 小C拿到一个大型需求，匆匆看了一遍，接着就开始开发。开发一半了，发现产品稿上有个点看不明白，又去和产品问。问的过程中产品又想起来别的事，又说了起来。最后聊了半天，小C发现自己之前的工作基本白做了。

虽然有夸张的成分，但是这些事也是确实每时每刻都在发生的。造成这些现象的原因很多，我们今天就好好剖析一下。在剖析效率问题之前，我们需要先看看程序员日常都要做哪些事。其中对工作效率影响比较大的，我把他们主要归为三类：

1. 日常开发
2. 沟通
3. 排查和解决问题

接下来，我们就对这三项逐一分析，如何提升工作效率。

日常开发

日常开发中都有什么情况会造成效率下降呢，我列举几个：

• 像上边小C一样的返工行为
• 日常工作中大量重复劳动，比如写sql，写模板代码
• 本来是一个很小的改动点，改了才发现这也要改，那也要改；更严重的是，根本不知道「那也要改」，结果一改就崩
• 个人注意力不集中，老走神

可以看到，这里边大部分是和代码设计有关的。对于设计，其实就两句话，一是要设计，二是要设计好。

也就是说，首先，你得知道开发之前是得有设计这么个环节的。软件工程是一门科学，它有概要设计、详细设计这些步骤是有道理的。要设计到什么程度再进开发呢？我的观点是越细越好，理论上，除了实际把代码码出来，其他所有事都可以在设计阶段做完。

关于设计的好不好，一个重要的评价标准，就是后续改起来是否容易。如果一个变化的原因会导致多处代码修改，那就是一个不好的设计。如何提升这一点，需要去学习设计模式、架构方面的知识，没有速成之路。

另外，关于注意力的问题，当然大家可以借助番茄钟这样的工具。但是工具永远都只能是辅助，最重要的还是自己去提升主观上的自控力。

沟通

接着说沟通这块，沟通分主动沟通和被动沟通。主动沟通就是你自己这边发起，要去找其他人问问题、讨论；被动沟通则是别人发起，来问你问题或者讨论事。

主动沟通的主要问题就是越聊越远，聊着聊着就不知道聊哪去了。这里我给两个建议，一是发起沟通前一定要想清楚自己想通过这次沟通达到什么目的，不能有个模糊的想法就迷迷糊糊的去了，这种沟通就是最大的时间杀手；二是可以列一个沟通清单，沟通过程中话题扩散其实是个常见的现象，我觉得没必要刻意去杜绝这种事，关键是要保证自己本来想聊的聊出结果来，这就需要一个可以用来check的清单。

被动沟通其实是一种很容易打乱工作节奏的事，但是很多情况下无法避免，比如突然又线上问题要处理，领导有事找你，等等。我们能做的就只有减少不必要的被动沟通次数。比如自己提供的功能，写好文档和注释，其他人就不需要靠问你就能看明白。方法名、返回值等团队内要建立起一些固有约定，大家都遵守，也就不需要问才能了解了。

另外还有一点是做好任务的拆分，做若干个小任务，而不是做一个大任务。这样，当被迫打断工作时，「切换上下文」的成本会低一些。

排查和解决问题

这也是很重要的一个方面。对有些人来说，查Bug改Bug的时间，可能会远高于开发新需求。对于这个，我们的主要目标就是降低排查难度，减少排查时间。可以从下面几个方面做。

1. 设法尽早暴露问题，比如通过写单元测试。同样一个问题，出现在一个小模块里，和出现在一个复杂系统中，排查难度是不言而喻的。

2. 要有足够多的信息，比如日志，比如各类监控数据。就像我们体检一样，只有先看得到那些异常指标，才能再去针对性的详细排查。否则什么指标没有，就只能两眼抓瞎乱查了。

3. 再一个就是排查方式，每个人都需要逐渐积累经验，建立起相对固定的排查问题的套路。比如我，习惯就是遇到问题先把各种能看到的信息都扫一遍，从中发现异常指标，指标看不懂的话就借助搜索引擎或者他人来理解，然后根据指标思考有什么可能原因，再逐步去验证。这里边很重要的一点就是什么样的问题要自己思考，什么样的问题应该借助于他人或者搜索引擎。像上边小A的做法，就是非常不可取的，问别人或者搜索引擎的问题，一定是非常具体的，你随手一个报错发过来，别人首先得花大量时间搜集信息。一个1小时搞得定的问题，强行去问别人，很可能要花掉两个人一下午。

   什么叫具体呢，比如遇到一个ClassNotFoundException, 如果你压根不知道它是什么意思，那去搜一下没有问题。而假如你已经知道它的意思就是找不到类，那再去搜索就没有任何意义，这是要做的是思考这个类为什么找不到，有哪些可能原因。

除了上边这些之外，其实还有一类原因，就是996大环境大家主动选择的摸鱼。对这一点，我还是建议大家快速干完活之后腾出时间提升自己，摸鱼无益。再一点就是用脚投票，多去找没有加班文化的公司、团队，用自己的努力让他们发展的更好。

大家有想法也可以在评论区或者公众号( Mobility )和我交流。

原文地址: https://lichuanyang.top/posts/3423/

看到这个标题，是不是有种要讲信息学的感觉。其实并不是，只是最近观察到一些事情，有些感触所以说一下。最近在网上碰巧看到过两个言论，恰好事实我是比较了解的，所以感慨，二手的信息实在不可信。

实际案例

第一个，是北京西城德胜片区有一个小学叫三帆附小，因为可以直升三帆中学，这个在西城数一数二的初中，所以一直十分火爆。这个学校今年因为教室不够，招生由七个班缩减到了四个班，所以卡了落户四年，即落户不足四年的都要调剂。其实，调剂也不差，因为调剂校里有西城排名前五，而且学位极度充足的西师附小，也有雷锋消息这样的优质直升校。甚至有人买三帆附小学区房就是为了去调剂，因为西师附小的学区房要更贵。

然后，在一个公众号的高赞评论里，看到了「德胜」今年卡落户「两三年」这样的言论，言论作者还顺便以此为依据表达了对买学区房这种行为从智商上的鄙视。

衰减的三个层次

结合事实和最后言论，其实大概猜的出整个传播链条中信息的变化。德胜的三帆附小逐渐变成了德胜，卡落户四年变成了落户两三年的被调剂，又变成了卡两三年。同时，调剂去的是西师附小这种关键信息被丢失。

第二个事，上周望京地区除了新冠的病例，然后各个社区在周末组织全员的核酸检测。其中有个检测点，不知道咋回事，排队的人特别多。不过实际上大部分检测点都挺好排队的，有的点甚至你到了还要等一会，凑够一组5个或者10个人才能测。

然后，这周我恰好听到一个财经类的大V说这个事情，信息变成了「望京地区」几万人寒风中排队做核酸。其实，他说的确实也没错，也没啥恶意，只是提一嘴疫情又有些严重了。不过大家也能感受到，稍微少了那么一些细节，整个感觉就不一样了。你看这个简版的表述，会感觉望京的小伙伴们还挺可怜的，但是实际上，大部分人都轻轻松松、开开心心的就检测完了，至于排大队的那个点，也随时可以去其他点检测。

所以，看这两件事，虽然都是很小的事，我也彻底对二手信息失去信任。有些信息，传播的过程中，遗失或者微调一些关键信息，会导致整个意思大不相同。再者，有些人说话的时候其实只是顺嘴一提，人家没把这个当成一个重要的事，所以也不会去深究信息到底准不准。但是听的人对这个事情重要程度的判断是不一样的，你如果拿这种信息去做决策，可以预见，会有多惨。

那么，

如何对抗衰减

什么算是一手的信息呢，我这里简单列一些：

• 事实。就是实际发生的事，比如今天某地气温X这样的确定性事件，而非某地今天很冷这样的主观判断。
• 专业性的书籍。书毕竟会有校对的过程，也会经过无数读者的考验，所以可信度会高很多
• 公开政策。这个不细说了，因为这个就是标准。
• 可靠来源的数据

总而言之，就是希望大家多去接触一手信息，杜绝二手信息，做重要决策的时候要尤其重视信息的可信度。

原文地址: https://lichuanyang.top/posts/54296/

Redis中主要包括这些对象：字符串、列表、哈希、集合、有序集合、HyperLogLog、GEO等，本文会主要介绍这些对象是如何实现的，对于其命令，可以参考redis官网中对每个命令的说明，这里就不一个一个列了。

在介绍具体的对象之前，先看一下redis中对于对象本身的定义。

1
2
3
4
5
6
7
8
9

typedef struct redisObject {
    unsigned type:4;
    unsigned encoding:4;
    unsigned lru:LRU_BITS; /* LRU time (relative to global lru_clock) or
                            * LFU data (least significant 8 bits frequency
                            * and most significant 16 bits access time). */
    int refcount;
    void *ptr;
} robj;

在一个redisObject中，prt字段就是数据的实际内容，这里的存储会应用之前讲的redis的底层数据结构。可以看到，ptr是作为引用出现在redisObject中，也就是说，redisObject本身和实际数据本身内存可能不在一起。

通过 OBJECT ENCODING KEY 这个命令，可以查看一个key底层实际使用的数据结构。

接下来，我们就具体讲一下各个对象。

字符串

字符串可以说是redis中最基本的一个对象类型了，set 一个普通的key,value,使用的就是字符串对象。字符串对象根据具体情况，会使用int, embstr, raw三种类型的底层编码方式。其中int很好理解，在字符串的值是数字时，就会使用int存储。embstr和raw的底层结构都是简单动态字符串（SDS）,区别在于，embstr中，redisObject和实际存储的SDS在连续的内存空间上。embstr的使用场景是字符串小于等于39字节（如无特别说明，本文中的数值都是使用redis的默认配置），大于39字节时，则使用raw编码。

列表对象

即list, redis中的list是一个双向队列，提供左右两侧的push,pop操作，range操作等。

list的底层实现可以是ziplist或者链表。上一篇文章中，我们介绍了ziplist是一种针对小数据集的，非常高效的数据结构。因此，在使用时，很自然的可以想到，小的list就会用ziplist实现，大的list则用链表实现。对于什么样的列表才算小，redis里使用两个判断标准，一是list中每个元素的最大长度，对应配置list-max-ziplist-value, 二是list中的元素数，对应配置list-max-ziplist-entries。

list的实际应用场景其实就是对双向队列的利用场景，比如微信朋友圈的时间线就可以通过list实现。有时候，也会拿redis的list用作消息队列。

哈希

即我们通常所说的map,与列表对象list, 哈希也会根据数据集的大小选用两个不同的底层结构，分别是ziplist和hashTable(底层是字典)。

这里可以引申出一个小技巧，当我们需要在redis中存储object时，可以使用hash，而非序列化成字符串存储。因为对于一个正常的object来说，是会被通过ziplist存储的。这样，就通过非常小的资源开销实现了对单个字段的get/set.

集合对象

即set, 对应redis中的S系列命令，如SADD,SMEMBERS等，也就是元素不重复的”集合”。同样的，redis的集合也有两种实现方式，分别是intset和hashTable.

redis的集合提供了非常方便的求交集、并集、差集等的方法，可以用在查询共同好友等场景中。

有序集合

对应redis中的Z系列命令，如ZADD,ZRANK等，底层的实现对应ziplist或者skiplist。期数，看完上一篇文章中对于这两个数据结构的介绍，我们是可以很容易的理解redis是如何实现有序集合的。

有序集合也是一种很常用的对象，可以用在排行榜、topK等问题中。

HyperLogLog

redis中的hyperLogLog是一个用于基数统计的结构，即统计不重复元素的个数。它的实现是基于概率算法，通过一定概率的误差，在对空间使用非常小的情况下，实现对大数据量的统计。其具体算法非常精妙，我后边会单开一篇文章介绍。这里就先介绍下它的效果，HyperLogLog可以使用12k的空间统计2的64次方的数据，标准误差在0.81%。

Redis中使用HyperLogLog非常简单，只包含三条命令，PFADD添加元素，PFCOUNT获取当前基数，PFMERGE对多个HyperLogLog进行合并。

GEO

顾名思义，redis中的geo就是一种用来处理位置相关信息的结构。redis中的geo对象提供了添加、查看位置信息，计算两个位置间的距离，查找范围内的元素这些功能。

Geo的底层基于zset实现。其核心处理在于通过GeoHash算法将二维的经纬度编码成一维的hash值，同时还能保住经纬度本身越接近的值，hash值也越接近。GeoHash的细节我们也在后续文章中专门做介绍。经过GeoHash做编码后，就可以利用zset本身的功能来做范围查找等事情了。

现在很多互联网服务的位置服务会选择使用redis来实现，比如附近的人，附近的餐厅。

通过上边的介绍，希望可以帮助大家更好的理解和使用redis。可以看到，redis里针对一些特定情况，进行了非常极致的内存优化，而我们在使用时，就要考虑如何更好的去利用这些优化。

原文地址： https://lichuanyang.top/posts/25564/

基本设计原则

要说设计模式，一定要先提一遍六大基本设计原则。说白了，设计模式就是在这些原则的基础上被提炼出来得一系列最佳实践。

单一职责原则

开放封闭原则

通过扩展解决问题，而不是修改已有的实现。（写代码时可以假定变化不会发生，当出现变化时，需要抽象以隔离将来的同类变化） 修改没有破坏原有的单元测试，即可认为不违反开闭原则

里氏替换原则

子类应当能代替父类

依赖倒置原则

高层模块不能依赖低层模块；应当依赖抽象而非实现

接口隔离原则

接口尽量小

迪米特法则

类间解耦

#设计模式

工厂方法模式

定义一个用于创建对象的接口

抽象工厂模式

创建一组相关或者相互依赖的对象

单例模式

一个类只有一个实例

建造者模式

分别build实例的各个模块

原型模式

复制对象

适配器模式

处理接口不兼容

装饰器模式

动态给一个对象添加一些额外的职责，比生成子类的方式灵活

代理模式

对一些对象提供代理，以限制那些对象去访问其它对象

门面模式(外观模式) (facade)

门面中包含若干个子系统的部分或全部方法，将子系统组合后对外提供。

桥接模式

将抽象部分和实现部分抽离。一个抽象类依赖一个接口，两部分分别可以做扩展

组合模式

把一组相似的对象当作一个单一的对象

享元模式

共享对象，数据库连接池，线程池等即是用享元模式的应用

策略模式

多种不同“策略”动态切换，起到改变对象行为的效果

模板方法模式

父类定义算法的骨架，部分细节由子类实现

观察者模式

对于一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知

迭代子模式

给对象提供一个迭代器（Iterator）

责任链模式

多个对象都有机会处理请求，连成一条链，并沿着这条链传递该请求，直到有一个对象处理他为止。

命令模式

将来自客户端的请求传入一个对象，实现于“行为请求者”与“行为实现者”的解耦

备忘录模式

备忘录对象就是一个用来存储另外一个对象内部状态的快照的对象

状态模式

状态机

访问者模式

将数据结构与数据操作分离

中介者模式

用一个中介者对象封装一系列的对象交互，中介者使各对象不需要显示地相互作用

解释器模式

给定一种语言，定义他的文法的一种表示，并定义一个解释器，该解释器使用该表示来解释语言中句子。典型场景SQL解析等

原文地址: https://lichuanyang.top/posts//21897/

程序员职业的本质

我想从两个方面来说。一是从做的事儿上，在我看来，程序员的工作就是发现问题、分析问题、解决问题三类。事实上，世界上绝大多数工作都可以囊括进这三类事中。二是从能力上来看，我把能力分为两种：对现实世界的认知能力，和将现实世界映射成程序语言的能力。

对于三种类型的事，按发现问题，分析问题，解决问题的顺序，是从宏观到细节的区别，平时做的事，肯定是以解决问题为主，各种琐碎的事，也都是在解决问题。发现问题和分析问题对人的思维深度会有更高的要求，不过对于工作来说，我倒并不觉得这三类事有什么高下之分。如果对确定的问题，总能给出恰当的解决方案，这也是职场上非常硬核的核心竞争力。而对于两类能力，一般还是更关注第二种。但是我觉得对现实世界的认知能力，对于程序员的职业发展是非常重要的。就像抠业务，抠CRUD这事，有门槛吗?我觉得是有的，至少把业务做的很好门槛非常高。有些人总是以非常奇特的方式去实现业务，然后赖产品经理需求描述不清楚，很可能就是缺少对现实的认知。

接下来，就按发现问题、分析问题、解决问题的顺序，分别详细说一下。

发现问题的能力，对程序员来说，其实不是必需的。很多问题，即便你发现不了，或者发现了然后假装它不存在，系统一样可以运行的很好。但是，逐步的累积这种问题，最终必然会导致代码不可维护。下面，我拿一个自己的实际经历来举个例子。之前做过一个旅客飞行记录的项目，国内航班的数据，我们几乎都能拿到。数据存储的时候，主键是用的证件号，为什么呢，因为所有的订票系统，都是用证件号去做key的。但是我们的产品形态并不是这样，而是以用户的维度去显示，一个用户会有多个证件。这样就导致了一个问题：任何一个非常简单的问题，比如要查用户最近一条飞行记录，最近十条飞行记录，都会有一套复杂的处理流程。更不用说随着数据量增加，要分库分表，但同一个用户的证件没法往一张表上落，逻辑复杂度再提升一级。在这个时候，不发现这个问题，其实业务也完全开展的下去，但是很显然，做这块业务就会做的很难受。而意识到这是个问题，再做相应的调整后，才会发现原来这一块的业务如此简单。

那么，怎么才能发现问题呢。这需要我们有对现实世界的认知能力，也需要对设计模式等基础知识有足够的理解。要发现问题，我们首先得有“正常状态”是什么样子的概念，与正常状态不一样的，就是问题。比如前边的例子，一个“正常状态”是查询用户最近的飞行记录，这个需求应该非常简单，还有一个“正常状态”是我们的用户是一个人，而不是一个证件，发现了和政策状态不一致，也就发现了问题。再举一些例子，写单元测试应该是很简单的，当发现单元测试不好写的时候，就需要考虑一下是不是代码的设计出了问题；mysql的一次batch请求，耗时的数量级应该在毫秒级, 而且数据量不应该严重影响耗时，当发现数据量和耗时的关系成了一个非常陡的线性关系，就要考虑一下是不是真的做了次batch(参考 https://lichuanyang.top/posts/63688)。

接下来是分析问题。对于分析问题，我觉得说白了就是把一个表现出来的问题，拆解成一个或若干个“指标”出了问题。这些“指标”，可以是内存、cpu这样实际的指标，也可以是一些基本的概念理解、设计思路。还是上一个例子，我们发现的问题就是一些很简单的需求实现起来很难，最后拆解出来的出问题的“指标”就是存储记录主键的选择。

对于分析问题，要会做合理的可能性推测，然后多利用工具验证或者推翻猜测。之前有一次发现数据存不进数据库，这时候就可以做出若干个合理的推测：数据库本身有问题；和数据库的连接有问题；事务未能正常提交；逻辑错误导致数据未能生成；等等。然后去翻日志，看有没有报错，看Mysql监控，有没有大量未能提交的事务。逐步就定位到问题了。

技术深度 vs 技术广度

最后说解决问题，对大部分程序员来说，这个一直会是做的最多的事。而程序员的解决问题，也就是把现实中的概念在计算机中表示出来。其中最关键的，我理解有两个，一是分解任务，把一个大任务拆分成若干个独立的子任务；二是迅速的理解并使用新工具能力，也就是持续学习的能力。很多人会经常抱怨程序员要学的东西太多了，学不过来了。不过一定要注意哪些东西是值得花费大量时间去学的，哪些东西是简单看看就足够了的。发现有很多人热衷于工具的学习，喜欢写各种版本的Hello World, 这个在我看来就是无效的学习。编程方面的学习，需要兼顾深度和广度，深度，是需要非常透彻的研究一些技术，这个看了一些之后，你会发现各种技术，看起来可能没什么关系，比如数据库和消息队列，但是其中就是会有非常多相似的概念和思想。学过一些之后，就可以建立起自己的知识体系了，然后再去学其他的东西，就会非常快。

因为一个新技术的产生，必然是迫切的要解决一些实际问题。比如为什么会有clickHouse, 因为mysql等的按行存储不适合数据分析，而市面上又没有性能、稳定性都比较好的列存储数据库。再比如jedis直接连redis-server, 在多线程环境下表现不好，所以有了Lettuce。当知道要解决什么问题后，就可以先试着想一下换成你的话，有什么解决方案。然后再去看看人家实际的解决方案。如果方案很接近，那么恭喜你，你对技术的理解已经又上了一个高度。如果不一样，那也恭喜你，又学到了一种新的思想。这些思想，在以后做业务的时候，随时都可以化用。

我的职业观

共勉。

原文地址: https://lichuanyang.top/posts/27398/

常见问题

Q: 程序员是吃青春饭吗？35 岁后做什么？

把程序员看作”吃青春饭”是一种误解。作者认为程序员的本质是发现问题、分析问题、解决问题这三种能力——这些能力是随经验增长的，绝非青春饭。35 岁后的出路取决于你在前十年积累了什么：如果只停留在”被告知需求 → 编码实现”的层面，年龄确实会成为劣势；但如果积累了对现实世界的认知能力和将现实映射为程序的能力，35 岁后恰恰是价值最高的阶段。解决中年危机的唯一方式是在每一份工作中持续获得可以带走的能力。

Q: 技术转管理好不好？什么时候该转？

这个问题文章没有直接回答，但从作者的能力模型框架可以推导：技术和管理只是解决问题的不同手段，核心问题始终是”你最有信心的能力是什么”。如果对现实世界的认知能力（理解业务、沟通协调、资源整合）强于将现实映射为程序的能力，管理方向更适合；反之则继续深耕技术。不必把两者对立起来——很多技术 Leader 本质上是在用技术视角做管理，而纯管理岗位如果没有技术判断力，在技术团队中很难真正发挥作用。关键不是”该不该转”，而是”转之前有没有积累足够的技术深度”。

Q: 技术深度和技术广度哪个更重要？如何平衡？

作者的观点是：深度先行，广度在后。先深入研究几个核心技术，建立起知识体系后，再去看其他技术会发现有大量相似的概念和思想（如数据库和消息队列中都有 WAL、分区、复制等模式）。作者的判断标准很实用：当你学一个新技术时，先想”如果让我来解决这个问题我会怎么设计”，再看实际方案——如果方案接近，说明理解已到新高度；如果不一样，就学到了一种新的思想。至于”写各种 Hello World”式的学习，在作者看来是无效的。

Q: 如何发现代码或系统中的”隐性”问题？

作者给出了一个判断准则：知道”正常状态”应该是什么样子，与正常状态不一致的就是问题。具体信号包括：1) 单元测试很难写 → 代码设计可能有问题；2) MySQL batch 请求耗时就应毫秒级，如果数据量轻微增加耗时陡增 → 可能没真正做批量；3) 一个语义上很简单的需求（如”查用户最近十条飞行记录”），实现却很复杂 → 数据模型或主键设计可能背离业务本质。这些判断力来源于对现实世界的认知（知道什么是”正常”）和对设计模式等基础知识的理解（知道”正常”在代码中应该长什么样）。

为什么需要位运算做大小写转换？

你可能第一反应是：Java 不是有 Character.toUpperCase() 和 Character.toLowerCase() 吗？为什么要自己写？

确实，99% 的场景下你应该用标准库。但了解这个技巧有几个价值：

1. 面试中的常见考点：很多算法面试会考察这种位运算思维
2. 理解计算机底层：知道 ASCII 码的设计精妙之处
3. 嵌入式/底层开发：在没有标准库的环境下，这就是实际操作
4. 代码简洁：ch ^= 32 比 Character.isUpperCase(ch) ? Character.toLowerCase(ch) : ch 优雅得多

ASCII 码的巧妙设计

要理解这个技巧，先看英文字母在 ASCII 表中的编码：

观察规律：大写和小写字母的 ASCII 值恰好相差 32（0x20）。在二进制层面，就是第 6 位（从右数，从 0 开始）的差别：

• 大写字母第 6 位为 0（如 A: 0100 0001）
• 小写字母第 6 位为 1（如 a: 0110 0001）

这就是 ASCII 设计时的精妙之处——大小写转换只需要翻转一个比特！

三种位运算方法

1. 异或（Toggle）：大小写互转

1

ch ^= 32;  // 等价于 ch ^= 0x20

^（异或）运算的规则是”相同得 0，不同得 1”。与 32（第 6 位为 1）异或，就只翻转第 6 位：大写变小小写变大。

2. 强制转大写

1

ch &= ~32;  // 等价于 ch &= 0xDF

~32（取反）使第 6 位为 0，其余位为 1。& 运算后第 6 位清零，不论输入大小写，输出一定是大写。

3. 强制转小写

1

ch |= 32;  // 等价于 ch |= 0x20

| 运算第 6 位置 1，不论输入大小写，输出一定是小写。

边界情况

以上操作只对英文字母有效。对非字母字符无意义，使用前需要先判断：

1
2
3

if (ch >= 'A' && ch <= 'Z' || ch >= 'a' && ch <= 'z') {
    ch ^= 32;
}

实际性能如何？

在现代 JVM 上，Character.toUpperCase() 已被优化为 intrinsic（JVM 级别的原生优化），两者性能几乎没有差距。所以结论是：了解这个技巧，日常开发优先用标准库。位运算大小写转换更适合算法题、嵌入式场景，以及读懂那些用了这个技巧的开源代码。

常见问题

Q: 位运算大小写转换比标准库快吗？日常开发该用哪个？

在现代 JVM 上，Character.toUpperCase() / Character.toLowerCase() 已被 JVM 优化为 intrinsic（JVM 级别的原生指令），与位运算版本性能几乎无差距。日常开发首选标准库——可读性好、语义清晰、有边界检查。位运算版本更适合理解计算机底层原理和应对面试场景。

Q: 什么场景下值得使用位运算做大小写转换？

1. 算法面试：位运算思维是常见考察点；2) 嵌入式/底层开发：没有标准库可用的环境；3) 阅读源码：很多经典开源代码（如 Nginx、Redis 等 C 项目）大量使用这种技巧，需要能读懂；4) 追求代码极简：ch ^= 32 一行搞定大小写互转，在某些场景下更优雅。

Q: 对非字母字符执行位运算大小写转换会有什么影响？

会有无意义的结果。位运算只翻转第 6 位，对非字母字符来说，翻转后产生的字节不一定对应有效字符。比如数字 0（ASCII 48 = 0x30）与 32 异或后变成 16（DLE 控制字符）。因此使用前必须加范围判断：if ((ch >= 'A' && ch <= 'Z') || (ch >= 'a' && ch <= 'z'))。

Q: ASCII 码里大小写字母相差 32 是巧合还是有意设计？

是有意设计。大小写字母的二进制表示恰好只差第 6 位（大写为 0、小写为 1），相差值固定为 32（0x20 = 0b0010_0000）。这个设计让硬件只需翻转一个比特就能完成大小写转换，在早期计算资源有限的时代极大降低了电路成本。类似的精妙设计还有：十进制数字去掉高 4 位就得到其二进制值。

之前在另一篇文章里介绍过使用activemq时，client端的基本语法。

值得注意的是消费者，

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

    public void consume() throws JMSException {
        ActiveMQConnectionFactory cf = new ActiveMQConnectionFactory();
        cf.setBrokerURL("tcp://localhost:61616");
        Connection connection = cf.createConnection();
        connection.start();
        Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
        Queue queue = session.createQueue("TEST");
        MessageConsumer consumer = session.createConsumer(queue);

//        Message message = consumer.receive();
//        TextMessage textMessage = (TextMessage) message;
//        System.out.println(textMessage.getText());

        consumer.setMessageListener(message -> {
            try {
                System.out.println("consumer1: " + ((TextMessage) message).getText());
            } catch (JMSException e) {
                e.printStackTrace();
            }
        });

        Session session2 = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
        Queue queue2 = session2.createQueue("TEST");
        MessageConsumer consumer2 = session2.createConsumer(queue2);
        consumer2.setMessageListener(message -> {
            try {
                System.out.println("consumer2: " + ((TextMessage) message).getText());
            } catch (JMSException e) {
                e.printStackTrace();
            }
        });

        Queue queue3 = session2.createQueue("TEST");
        MessageConsumer consumer3 = session2.createConsumer(queue3);
        consumer3.setMessageListener(message -> {
            try {
                System.out.println("consumer3: " + ((TextMessage) message).getText());
            } catch (JMSException e) {
                e.printStackTrace();
            }
        });

        try {
            TimeUnit.MINUTES.sleep(100);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

    }

多线程消费方式分析

可以看到，实际上有三种方式都可以实现多线程消费同一队列，分别是定义多个connection, session和consumer。这三种方式在应用层面的效果是一样的，都是会生成多个消费者，并行处理队列中的消息。但是在性能上，这三种方式会有较明显的差别。下边详细介绍一下。

首先，定于多个consumer只是一种伪并行，并没有真正并发消费。原因是在JMS协议列，一个session在同一时间点只能被一个线程使用，所以多consumer复用同一session时，只是这些consumer轮流使用这一个session。

而可以考虑开多个connection对应的是物理的tcp连接，一个producer可以新建多个session，这些session就是复用同一个tcp链接。多session和多可以考虑开多个connection都是真正的并发操作，区别只在于是开一个还是多个tcp连接。这个造成的影响很容易理解，多个tcp连接，可以处理更大的网络流量，当然在建立、维护连接时也会带来一定开销。

总结与建议

总的来说，大部分情况下，我们可以定义多session来实现activemq的并行消费。在流量较大时，可以考虑开多个connection。而多个consumer, 目前没有想出有什么场景能用到。

原文链接：https://lichuanyang.top/posts/20459/

问题描述

对于一个计费系统来说，并发问题事实上分为两类，一类是应用并发高，也就是纯粹的用户量大，访问量多，这类问题和一般的高并发问题没有区别，用分布式等手段就可以解决；另外一类问题则是一般分布式手段无法解决的用户高并发问题，也是本文要着重说的。
这类问题源自对某些高频账号，大量的并发访问，会导致瓶颈首先出现在某些数据库记录上，大量操作由于无法竞争到数据库的行锁而导致等待，这些等待中的操作又会占用其他资源，最终导致系统不可用。
针对这类问题，下边介绍一些常用的处理办法。

不设置余额字段

由于对于一个稳定的计费来说，一定是会记录计费流水明细的，所以完全可以不设置余额字段，而采用根据流水明细计算的方式来获取余额。
不过这种方法不是万能的，比如拿广告业务的计费系统来说，频率非常高，而每次的金额很小，这时候想通过计算求和去算余额，显然是不现实的。

合并与拆分

这是两种方式，因为有一些相似之处，都是要降低对单条数据库记录的访问压力，所以也就放到一起说了。
合并，就是对单个账号的数次请求作合并处理，再往数据库写，这样就等于降低了数倍的压力。
拆分，则是把一个主账号拆分成数个子账号，然后把请求分配到各个子账号上，这样单个账号的压力就小了。然后再用其他手段把子账号的数据合并成主账号数据，返回给用户。

减少行锁占用时间

这是个代码层面的优化，前面说了，高频账号之所以会导致系统的性能问题，就是因为要竞争行锁，所以，如果我们能减少每次请求占用行锁的时间，系统性能也就会大幅度提升了。
所以，首先，要尽量加快从获取行锁到事务提交这个阶段的运行速度，将不必要的操作，尤其是一些耗时的操作，放到其他地方执行，比如获取行锁之前或者事务以外。
然后，尽量避免用

1

select ... for update

的方式去获取行锁，二是采用下面这种方式：

1

update xxx set amount=amount-1 where id=x and amount>=1

如果业务层面允许余额扣减成负数的话，就可以不使用where条件中对金额的校验；否则就需要在将要把余额扣成负数时不去更新数据库，并在程序中返回异常。

限流

既然高频账号是单账号的并发达到一定程度后才会导致系统的性能问题，所以我们就可以强制控制这个并发量，使它永远保持在系统可接受的范围内。

缓存

缓存也是一个常用的解决高频账号的方法，在缓存中对余额作操作，然后定时向数据库内同步。

上边介绍了很多方法，当然每一种都会有它的适用条件，也会有其局限性。比如像合并啊，限流啊，实际上都会造成延迟扣费，而在延迟的这个时间段内，可能账户余额已经耗尽，所以如果是严格余额不能为负也不能丢弃记录的业务场景下，其实并不适合用这种方式。
所以说，最重要的还是根据业务场景选择合适的方案。

原文地址: https://lichuanyang.top/posts/56940/

今天用findbugs扫代码时遇到一个很有意思的问题，有关三目运算符的，在这儿记录一下。

就是类似这么一行代码:

1
2

boolean b = true; 
Long a = b ? 0l : Long.valueOf(2); 

Findbugs给出了”Boxed value is unboxed and then immediately reboxed”的提示，意思就是有装箱的对象做了拆箱，然后又马上做了装箱。这个问题其实很常见，一开始也没注意，只是习惯性的把Long.valueOf 改成了Long.parseLong, 确实把这个警告消掉了，不过之后才意识到不对：明明valueOf返回的是Long类型，parseLong返回的是long类型，而需要的正是Long类型，为什么反而用valueOf的时候有问题呢。

其实思考一下大概也能想明白，主要就在三元运算符的另一个分支，因为另一个分支返回的是一个未装箱的0,所以这个三元运算符的返回值就成了long,所以原本的Long类型就要经过一次拆箱才会被返回。要优化这个部分的话，保持两个分支的返回类型一致就可以了。

然后把相关的细节查了一下，了解清楚。

自动装箱/拆箱

从JDK1.5开始，java引入了自动装箱和拆箱，不需要做显式转换，提高了我们的开发效率。比如:

1
2
3
4
5
6
7

Double dWrap1 = 10d; 

double d1 = dWrap1; 

double d2 = d1 + dWrap1; 

DoubledWarp2 = d2 + dWrap1; 

这么一段代码就是可以正常运行的。

另外一个要注意的地方就是，在一个运算，比如前边提到的三元运算符，涉及到类型转换时，编译器会优先选择基本类型，也就是说会优先把已装箱的对象拆箱。

我们一开始的问题只是很细微的性能损耗

1
2

Long B = null; 
Long A = (2>1)?B:0l; 

但是像这样的代码的话就是有bug了， 看似只是把一个null赋给Long类型的A, 但是这过程中会做一次向long的拆箱，所以肯定会报空指针。

所以说，我们在平常的开发中，还是应该尽量避免无意义的装/拆箱和类型转换，不光是出于性能考虑，也是为了避免一些诡异的问题。

原文地址: https://lichuanyang.top/posts/53072/