知一杂谈

场景说明

目标是需要拆分出内部服务 Y 为独立的系统，且暂时不改变系统 A 的被依赖关系，拆分前的情况如下图。

这里假定两个接口层处理模块只会调用只会调用内部服务 Y，并且其中存在着业务逻辑，也许你会疑惑接口层为什么会有业务逻辑，事实上你大多数情况下会遇到。更具体的说，接口层的业务接口 1 中包含业务逻辑，于是会产生对内部服务 Y 的两个及以上接口的调用。

处理思路

那么你会遇到以下几种情况需要处理。

前言

分布式系统主要的目的之一就是解决大量用户的高并发问题。自己做过几个业务系统，也和别人聊过他们所做过的业务系统，其实大家都使用了相同的数据库，有的系统会使用 Redis 缓存，会使用 MQ 做系统解耦，有的也会使用搜索引擎。这些系统的构件相同的地方都是在处理数据，只不过职责不同罢了。归纳有以下几类：

• 数据库提供结构化的持久保证。
• 缓存为了提高并发和响应速度。
• MQ 带着事件消息将后续任务解耦。
• 搜索引擎提供快速的全文检索能力。

以上这几个构件就可以组成相对完备的实时数据系统，可以应对常见的业务需求。

数据框架

关于一个业务系统的通用数据框架可以用下面的图来表述。

前言

这篇文章是汇总历史发布过的，所有关于我的博客编写发布系统文章。文章以时间线倒序的方式罗列整理。

2022-04-07 博客主题必备功能

1. 支持数学公式
2. 支持 mermaid 流程图
3. 支持标准的 Markdown

测试页面

2022-02-13 统一博客编写环境

日常会在 macOS 和 Ubuntu 之间切换，博客是基于 Hexo 生成的，不同系统的 Node 版本会有较大差异、环境稳定性比较差，为了方便平时写博客，想到了用 Docker 统一博客生成环境，于是自己写了 Dockerfile，在结合 VS Code 编写，可以做到系统无差。

日常开发只需要在 VS Code 中边写边预览，图片是通过 PasteImage 插件快捷键插入。预览和发布只需要以下两个命令即可。

预览本地博客：alias run-blog='docker exec -it container_id python utils/goto.py blog'

发布博客文章：alias push-blog='docker exec -it container_id python utils/goto.py push'

Docker 项目：https://github.com/noogel/noogel.github.io.docker

基础语法示例

1
2
3
4
5
6

# H1
## H2
### H3
#### H4
##### H5
###### H6

引用

• 无序列表
• 无序列表
• 无序列表

1. 有序列表
2. 有序列表
3. 有序列表

斜体

粗体

行内代码

1
2

多行代码
多行代码

分割线：

数学公式

1

$$d=\sqrt{\sum_{k=1}^n(x\_{1k}-x\_{2k})^2}$$

效果：

$$d=\sqrt{\sum_{k=1}^n(x_{1k}-x_{2k})^2}$$

流程图

sequenceDiagram
    老板C ->> 员工C : 开始实行996
    
    par 并行
        员工C ->> 员工C : 刷微博
    and
        员工C ->> 员工C : 工作
    and
        员工C ->> 员工C : 刷朋友圈
    end
    
    员工C -->> 老板C : 9点下班

ROI 是指投资回报率，对应系统架构设计上来说需要从业务发展和收益角度综合评估 ROI 来进行取舍。需要确保架构符合业务的发展，在设计开发时需要重点关注一下几个地方：

1. 系统迭代需求的提出。
   • 为了满足业务需求
   • 为了解决系统问题
     • 需要收集系统问题，找出核心问题。
2. 提出设计方案。
   • 明确核心价值，解决了什么样的关键问题、系统难点、业务需求。
   • 实现成本
     • 复杂度，实现设计方案的复杂度是否可以接受。
       • 技术复杂度，系统的并发性、可用性、一致性要求。
       • 业务复杂度，对于业务需求的支持程度。
     • 人力成本，是否满足各方对人力消耗和时间节点上的要求。
   • 设计的局限性
     • 可量化指标，项目的结果是否可以被量化，被观测到。
     • 可测试性，测试的覆盖度能到多少，QA 的测试成本有多少。
     • 可扩展性，下一次迭代可以降低多少成本。
3. 评估产出收益，项目的价值。
   • 人力节省
   • 机器节省
   • 收入提升
   • 流量提升

按照上述清单可以在进行架构设计时进行思维训练，同时不要局限于清单，做到动态调整。

基于多次复盘的经验汇总，仅以当前工作环境做汇总，供参考。

1. 系统问题定位和解决
   • 需要抓住足够多的证据链，不能臆测代码和运行机制。常用手段有 curl，日志，sentry。
   • 能在本地复现不要跑到联调，降低定位成本。
   • 排查超过两小时并且无清晰路径下需要扩大问题知晓范围，找人协助。
   • 排查过程需要有详尽的记录，记录要字符串，减少截图数据。
2. RFC 设计
   • 跨系统交互需要补充系统交互图，明确系统边界。
   • 需要数据备份和回滚方案，做好预案。
   • 设计文档需要同步小组群。
   • 评审会需要拉上 leader 知晓。
   • 系统设计需要考虑兼容性和可观测性。
   • 需求项目要建立人员 backup 机制。
3. 系统开发
   • 迁移是迁移，不要做重构，保证功能原样，同时也会降低测试成本。
   • 警惕复制代码的行为，必须知晓你提交代码的逻辑和背后含义。
   • 对于复杂逻辑和接口需要有详尽的注释，或者粘贴 wiki 链接说明设计。
   • 新系统设计需要维护起测试用例，保证单测覆盖度，降低测试成本。
4. 联调和沟通效率
   • 重大项目和长耗时，需要考虑拉站会或者小黑屋。
   • 能群聊的不要私聊，扩大内容的知晓范围。
   • 并行工作需要分时间块，避免碎片化时间并行。
   • 遇到人力合作问题，需要及时升级到 leader 支持。

技术面试看什么

1. 流畅的表达能力和清晰的逻辑分析能力。
2. 比较扎实的基础知识和技术学习热情。
3. 问题发现和推动解决问题的能力。
4. 丰富的项目经验积累和架构规划能力。

优秀候选人的一些品质

1. 对于所了解的技术知识理解的很透彻，从语言描述上能够表达准确、有逻辑、有调理。
   • 表达中不会有『这个』『那个』『嗯』『啊』的语气词和停顿。
   • 对于项目问题的解答，主动阐述项目背景，问题现状，做了什么，产生什么样的收益。
   • 优先说出答案的关键 123，再展开举例说明，是一种清晰有效的表达方式。
2. 从技术底层知识上，对于一些相对关键的技术知识能够灵活掌握，能从技术前世今生很顺畅的表达出来。
3. 实践能力上，候选人对于理论的了解不仅停留在书面上，而是动手实现一个技术理论。

技术面试怎么做

从工作经验来分，以三年为界，分为两类面试思路：

1. 越是经验丰富的候选人，可以提出一个比较模糊的问题，尽量让候选人来主导拆解这个过程。同时也要避免跑题浪费时间。
2. 对于经验很少的候选人，则可以从基础性知识和具体的问题上展开，如果难度过高需要积极的给出提示和引导。

前言

今天要说的是 macOS 下的一款效率软件 —— Alfred，想必大家就算没用过也耳闻过，老实说用好它带来的效率提升绝对不止 10 倍。博主已经安利给很多同事使用，他们普遍觉得上手有些困难，主要是配置复杂，今天的文章会一步步地介绍这款神器的高效之处。

有的人可能会说系统自带的 Spotlight 就很好用，确实是这样。在之前我会用 Spotlight 搜应用、文件、进行计算等，而 Alfred 的功能更强大，是一款可以更加 All in 的效率工具，里面还有我最常用的剪贴板历史、快速网页搜索、谷歌二次口令扩展等功能，接下来我会逐一介绍。

2021年已经过去，准备对去年看过的书进行一个复盘，回忆下从中得到了什么成长。

谈谈领域驱动设计的落地

前文提到了事件风暴产出的领域模型是概念模型，到实际落地还有些距离，而落地的结果也是各不相同，我觉得说落地，要先回顾一下领域驱动设计的两个作用。

1. 通过战略设计拆分子域，指导微服务拆分。
2. 通过事件风暴建立领域概念模型，指导代码设计。

也就是说领域驱动设计产出的结果是指导性的，并不是一个直接可落地的结果。落地的方案则是要通过架构设计和框架选择上来进行。架构是为了控制软件复杂性而做，就好像『一千个读者心中有一千个哈姆雷特』，不同人做架构不尽相同。下面说说我的落地方式。