场景说明

目标是需要拆分出内部服务 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 的效率工具,里面还有我最常用的剪贴板历史、快速网页搜索、谷歌二次口令扩展等功能,接下来我会逐一介绍。

阅读全文 »

谈谈领域驱动设计的落地

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

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

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

阅读全文 »