View on GitHub

业务逻辑拆分模式

https://autonomy.design

Part.2 只对自己写的代码负责

这个 Part 我们主要讨论如何拆分进程的事情。标题是“只对自己写的代码负责”,这里包含了两个关键词:

要达到“只对自己写的代码负责”是非常高的追求,需要很强的基础设施的支撑。我们经常会抱怨单元测试不好做,线上bug无法复现之类的问题。

微服务

微服务的起源是 devops 运动。鼓励 dev 拥有自己的线上服务,dev 自己来做 ops 的工作从而减少沟通成本。 毫无疑问,微服务的合理性并不是从 Autonomy 或者 Consistency 出发,而是以 Feedback 为主要的出发点。

当一个 7*24 的互联网高并发应用稳定性成问题的时候,最合理的做法是什么?据 Google SRE 统计,线上70%的故障都是由某种变更而触发的。 控制变更的速度,尽量延长灰度发布的时间是最重要的事情。 如果变更的粒度只有进程,而进程又只有一个,势必上线的队列会过长。 此时拆分微服务就是延长灰度发布时间最有效的手段。 同时让每个 dev 直接负责线上服务的稳定性告警,可以极大加快故障的定位和处置速度。

那么是不是拆分进程一时爽,一直拆分一直爽呢? 很多过度使用微服务的分布式系统无一例外地遇到了严重的 Feedback 问题。 难道应该是强调一个业务就应该由一个团队端到端负责,重新打起 Monolith 的大旗吗? 这其实就等价于说,怎么分技术的进程,应该取决于业务部门的组织架构。 但是业务部门的组织架构也是三天两头调整的。就是技术部门想要跟着调,业务部门每调整一次,集群就完全重部署一次SRE也不会同意的。

那么怎么拆分进程才是合理的呢?为什么这么拆就是合理的呢?

拆分进程的目标

在讨论应该如何去拆之前,我们先来看一下进程拆分不好导致的症状,以及度量 Feedback 维度做得如何的指标

发布变更,告警定位该如何做?

只对自己写的代码负责要体现在发布变更,告警定位这两个环节里。

拆进程不是唯一选择,应该 Autonomy 优先

回到微服务应该怎么拆分,多少个进程是合理的。 相比 ProcessBoundary,我认为控制好 FunctionBoundaryPluginBoundary 更有利于 Feedback。 相比 MultiProcess,我认为一开始就设计好 MultiTenancyMultiVariant 更有利于 Feedback。 进程之所以好用是因为开源社区提供了很完善的基础设施。所以我们习惯了迁就于已有的技术设施,来切分进程以利用上这些现成的设施。 从而因为进程的切分来影响我们对Git仓库和团队的切分。

如果能够做好 FunctionBoundaryPluginBoundaryMultiTenancy 以及 MultiVariant,怎么分进程根本就不是一个问题。 所有的代码都跑在一个进程内,一样可以把 Feedback 做得很好。 那微服务的拆分,其实就等价于Git仓库的拆分,也就是 Autonomy 章节中讨论的问题,怎么拆团队拆Git仓库的问题。 其主旨原则就一条:拆分之后,接口的定义要稳定,不要天天修改,导致频繁的跨团队强协作。我们也对怎么量化这个原则给出了指标计算的方法。

所以 Autonomy 优先,Feedback 的问题,交给基础架构部门通过改进基础设施来解决。