在业务系统中寻找技术含量

从进入互联网公司开始工作起，每个人都在问自己，CRUD 到底有什么技术含量？

别觉得 CRUD 只是业务工程师的问题，无论你在写什么程序，基本上都是在和数据打交道，除了读就是写。只不过读写的时候还会附带一些领域相关的行为。比如：

编译器：读文本，做 parse 网络程序：读连接，decode，encode，写连接 数据库：从磁盘上读，从内存里读，向磁盘里写，向内存里写

工程上，谁也没有权力鄙视谁，你觉得领域的技术含量高，只不过是领域内的工作做的人少罢了。不管门槛多么高的工程领域，只要工程师红利们蜂拥而至，总有一款内卷适合你。

自动化

我们可能会以相同的工作在公司内做了无数遍为由，痛斥公司无情，领导 sb，但是我们可以换一个角度。重复的工作，我们不可以把它自动化吗？

当然可以。比如我们需要关注某个渠道的新闻，每次都要输入网址/点击收藏夹，等待加载。像日常作业一样去完成这些工作。我们可以做一个定时的爬虫，把新闻爬到我们自己的服务器上，通过一个简单的 RSS 服务和订阅就可以把这个流程自动化了。

公司要支持疫情期间的项目，每天上传一些志愿者的白名单，需要把这些白名单导入在线数据库。我们肯定不希望每次都去写恶心的 awk 脚本来做这件事情，只要给运营人员一个上传的接口，并在后台自动 parse，导入就可以了。

线上的系统爆炸了，我们要找出引起爆炸的爆炸源，并且电话通知负责人起床修 bug。这么显式的流程，只要做好系统员工关联以及自动外呼就可以了。

相同的工作，或许每次只需要 5 分钟就可以完成，但只要重复过三次，那你就应该想办法把它自动化，让生活更美好。

有了自动化的思想，你才是一个软件工程师，而不是一个命令执行机器。

配置化

软件系统本质上是真实世界的适配，这种适配在软件的迭代早期是通过代码来体现的。

最粗暴的是 if else，switch，可是我们希望复用啊，甚至还希望能不改代码重启就能实现功能切换。

常见的复杂软件都有外挂的配置，复杂的业务系统也大多有配置。可能是项目启动时需要读取的 config file，也可能是在远程配置系统/db 里存储的配置。

配置化是让软件能够在不改代码的前提下实现功能修改的方式，软件根据配置的变化情况改变自身的行为模式。

像 nginx 这样的软件，我们可以用配置让它做一个 L4 的反向代理，也可以作为一个 L7 的 http 服务器。

业务软件的配置化，体现在对业务变化模式的预判上。

• 如果业务流程变化多，配置内容就是工作流配置。
• 如果计算逻辑变化多，配置内容就是各种表达式配置。
• 如果上游系统变化多，配置内容就是 ACL 的映射配置。

配置内容在系统内部使用时，文本形式的配置已经能够满足大部分需求了。

如果嫌 nginx 那样的配置格式麻烦，用 json 可以表达任意形式的数据结构、逻辑流程、映射方式。这里你可以有些疑惑，我们可以认为：

• 代码和 AST 之间是可以互相转换的
• AST 可以被 Marshal 为 json
• 所以 json 从原理上可以表达一切程序逻辑

如果一套系统的配置需求主要来自于外部，那么基于文本的配置是不合适的。我们时常可以看到一些开源软件的配置机器冗长晦涩(k8s：正是在下)。这些配置由人来编写是机器反人类的。

何况配置本身还存在上下文关联，如果软件文档写的不够详细，正确地配置系统前，我们甚至还得先去读软件的实现代码，使用成本极高。

UI 化

上下文有关联的配置，在文本中非常难配置，而在 UI 中则非常容易。我们可以将合法配置的前提知识都编写到 UI 的关联弹出逻辑中，或者校验逻辑中。这样用户便可以通过简单的交互，迅速知晓软件配置的游戏规则。

如果还是希望用文本来配置，还可以使用所见即所得的方式来缩短配置编辑到生效的反馈时间，来帮助用户迅速发现配置中的错误，及时修正，像 swagger editor^[1] 那样：

将软件配置由文本配置变为界面配置，在某些公司被称为配置“白屏化”。

平台化

只要用 UI 化的思路做系统，迟早会形成一堆散落的接入系统。平台化是对这些系统进行整合的一个机会，以某个具体的主题，把所有相关的流程聚合在一起。

例如 paas 平台，流式计算平台，业务工作流编排平台，文档平台。

在互联网公司，知识只有沉淀成为平台才能成为公共知识，否则只不过是老员工脑子里的糨糊罢了。

中台化

当平台不只服务于当前的业务，有更为泛化的基础能力时，便可以在公司内进行输出。例如一套整合了大数据基础设施和业务接入完整流程的数据平台，不见得只在外卖场景可用，也可以用于网约车，可以用于酒旅。

有些公司把跨业务领域的能力称为商业能力，例如电商的售前，订单流程，售后，都可以沉淀为跨业务的通用功能。

中台建设的最终产出物是一套结合了业务 SDK，多租户隔离能力，自动化扩容能力，相应业务逻辑展现为 UI 能力的多套完整的大平台。对架构师的抽象能力，工程师的技术能力，基础设施的运维能力都是有巨大考验的。

从业务收益上看，这些带界面的中台可以大大降低工程师与 PM，PD，PXX 交流的门槛，非颠覆性的业务，甚至不需要工程师参与就可以由业务人员罗列出所有修改点自己修改完毕了。

被优化

业务技术系统主要支持业务，如果公司的商业模式不再发生大的变化，对于支持系统来说，系统做的好的特点是开发人员们存在感极低，只要领域专家在平台上稍微点点鼠标就可以完成接入申请，找几个新手从平台上抄一两行示例代码就可以完成升级工作。

这时候你就应该被公司优化了。

参考资料

你可能还喜欢

点击下方图片即可阅读

云原生是一种信仰 🤘

关注公众号

后台回复◉k8s◉获取史上最方便快捷的 Kubernetes 高可用部署工具，只需一条命令，连 ssh 都不需要！