稳定抽象原则（Stable Abstractions Principle）是非常重要的抽象设计原则。小到一个类的方法，一个组件或者微服务的接口，大到整个系统的架构，都应该尽量遵循该原则。
抽象是基于归纳法，所以越稳定的东西，越适合提前做好抽象复用。因为你已经了解问题的全貌，而且问题域后续变化的可能小，所以抽象出来的东西就比较稳定，也容易被复用。
而越不稳定的东西，越不适合做提前抽象。这就需要我们想清楚，尽量延迟决策，或者压根放弃共同的抽象。对于差异很大，又不稳定的问题域。你会发现用少量的代码重复（Repeat Yourself），来代替代码复用，可能比那个拧巴的共同抽象，有更高的效率和实用价值。
什么东西稳定？
问题域越明确，越容易形成稳定的抽象。从这个角度而言，越偏向纯技术的领域越稳定，比如，对于文件的操作，无外乎就是打开、关闭，读写，基于这个前提，Linux提供了如下C语言的操作接口：
int open(const char *pathname, int flags);
int close(int fildes);
ssize_t read(int fd, void *buf, size_t count);
ssize_t write(int fd, const void *buf, size_t count);这套玩意几十年如一日，稳定，持久，有用。
再比如，服务治理中间件，解决的就是微服务互相通信的问题，包括服务注册、发现、负载均衡、熔断等。所以不管是Spring Cloud还是Dubbo，也可以很稳定的被抽象，被复用。消息中间件也是一样，就是要解决消息的生产、传递、消费问题，也很稳定。
其它的技术领域也是一样，比如云计算，整个IT基础实施也是相对稳定的问题域，就是要提供可隔离的网络、高可靠的存储、可弹性的计算。所以也能在更大层面被抽象，被复用。
底层技术的难度在于技术深度。就问题域而言，它要解决的问题是相对稳定的、清晰的。这就给合理的抽象，持续的打磨迭代带来了机会。
什么东西不稳定？
上层业务应用看起来没有什么“技术含量”，但其难度在于合理的业务抽象和设计权衡。越上层的业务越不稳定，稳定抽象的难度越大。这也是为什么当年阿里的业务中台失败的原因。因为他尝试在一个极其不稳定的电商业务领域，构建一套相对稳定，可复用的中台抽象。
试想一下，饿了么、飞猪、淘宝的履约、配送又有多少共性呢，没有共性，如何抽象，如何复用能力呢。你硬是要把这些不同的业务形态，揉在中台里面。其结果就是他们不得不在看似共同的抽象：placeOrder，fullfill，deliver下面，搞出很多奇怪的扩展点（Extension Point），而这些扩展点又严重依赖中台的提前定义，业务的多变性，导致没有人可以做好提前的抽象。这是问题域不稳定的一个典型特征。
基于不稳定抽象的代价
这种基于不稳定问题域的抽象复用，会带来极大的耦合成本，主要体现在三个方面：
人员协作耦合：如果需要中台提供新的扩展点，也就是新的抽象，你就要协调一堆的人，还要排期，这叫协作耦合。
代码耦合：因为业务逻辑是直接以代码的方式嵌入在中台系统，导致多个团队要在一起搞代码，其测试、联调、集成、发布成本都很高。另外，因为新框架的认知成本造成的认知复杂度，也使得coding的难度加大。
部署耦合：因为是中台统一部署，从而导致不同的业务之间可能会相互影响。比如某个业务突发事件，可能导致其它业务的稳定性都受到影响。
这种业务之间的严重耦合，比起烟囱式的业务应用，不但没有做到效率提升，反而因效率低下拖了业务的后腿。这也是为什么，阿里最后不得不以“拆中台”收场。
抽象设计价值评估
抽象很重要，但不合理的抽象会得不偿失，那么要如何评估抽象的价值呢？这里没有明确定量指标，但有一个定性的指导。还记得我在《当我说维度的时候，我到底在说什么》中提到的象限法吗，这个在我们做决策的时候，非常有用。根据前文的介绍，我们可以把影响抽象价值放在两个维度上，一个是稳定程度，一个是复用程度。
对于高价值区，这个没有任何异议，我们要不遗余力的去构建公共的技术底座，复用公共的技术能力，从而提升整体的研发效率。这里请Don't Repeat Yourself！
这里要特别留意的是极度危险区。比如上文提到的不同电商业务的履约服务，但实际上问题域的共性很小，稳定性很差就属于极度危险区。这里虽然也可以抽象，但抽象层次往往过高，不会有多大的复用价值，再加上深度耦合带来的问题。烟囱式的解耦将是更加合适的选择！
危险区是那些复用程度很高，但稳定性不足的领域。比如商品领域，还是以电商业务为例。虽然饿了么、淘宝、飞猪的业务差异很大，但是商品的类目管理、属性管理，商品上架，浏览，搜索，推荐还是有很大的共性所在。这里肯定是有复用的空间的，但是也要注意程度的把控。可以考虑把中台做薄，复用可以复用的部分，比如商品数据的存储，类目管理可以由平台统一做。对于商品审核、上架这些差异性比较大的部分，交给业务自己去处理。还是解耦比较好，一股脑的做厚中台，又会陷入耦合的噩梦。更具体的措施我在《业务中台的困境，及可能的解》中已经说的比较清楚。
天下没有免费的午餐
Don't Repeat Yourself在大部分时候是正确的，但是复用的代价就是会引入耦合。正如Neal Ford在《Fundamentals of Software Architecture》一书中所说：“When an architect designs a system that favors reuse, they also favor coupling”
特别是在人员众多的大型系统中，耦合的代价往往要比duplication的代价大的多，天下没有免费的午餐，因此，如果共性不够大，问题域变化多，抽象不稳定。我宁愿用少量的duplication解耦，也不愿意陷入耦合的噩梦。
扫一扫
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
