质疑中台“共享服务中心”—兼谈“代码或功能复用\重用的危害

摘要与说明：因篇幅稍长，以下观点，您若认可或完全不能接受，可以略过此文。如果您感兴趣，请耐心阅读，欢迎不同意见。

要点1.“复用软件更像是器官移植而不是拼装乐高积木”， 也就是说，表面上看起来两个人的器官功能一样，但实际上有细微的差异，这就会导致移植后的排异反应，必须靠不停吃药来维持。

要点2.代码复用或功能复用很好，但不能滥用。复用微服务层级的功能所带来的好处是虚幻的。

 

在二十多年前，当我在大学刚开始学习编程的时候，老师、课本、语言的发明者都教导我要“重用”或者“复用”代码或者程序，这样我们的程序就会像拼积木那样迅速造出更多高级的东西。在我们的编程生涯中，我们以不同的形式来复用或重用代码。在面向过程语言中，我们提炼“公共函数（function）库”，在面向对象语言出现后，我们开始提炼 “公共对象库”。现在，微服务概念出现之后，我们又开始提炼“共享的服务中心”，这样一路下来，大家都觉得顺理成章。我相信，很多人都和我一样有过这样的经历和想法，并且曾经深信不移。可以说“复用\重用”的思想已经深深地根植于每个程序员的意识之中。

当前，国内流行的“中台架构”特别倡导建设“共享服务中心”，复用“共享服务中心”内沉淀的服务，这是传统SOA的架构思想，这种想法来自于单体应用的时代我们对代码复用的惯性思维。但在微服务时代，继续在微服务服务级别沿用这种“代码或这功能复用”的思维会特别地有害，主要的问题就是会产生“上帝式服务”，如果这个“上帝服务”不稳定，那么整个系统就会不稳定，这就要求上帝式服务必须特别稳定，而在企业的业务系统中，稳定的业务服务提炼的难度和代价特别高，甚至只是理论上存在而现实很难实现。

但是，由于传统思维如此强势并占主导地位。如果有人说“复用\重用“的思想有问题，那么很多人肯定会感觉吃惊，或者觉得这是“无稽之谈”而不以为意，甚至还可能认为这是故意制造惊世骇俗的言论或想成为网红而制造热点。但是正如《演进式架构》一书所说的那样：“复用代码显然很好，然而任何美好事物都不能被滥用”，该书中还引用了John.D.Cook博士的话：“复用软件更像是器官移植而不是拼装乐高积木”。可见，“复用代码”并非总是好的，甚至可能危害巨大，想像一下“内脏移植”的排异反应能理解John.D.Cook博士的警告了。也就是说，表面上看起来两个人的器官功能一样，但实际上有致命性的细微差异，这就会导致移植后的排异反应，必须靠不停吃药来维持。我们对业务和领域的理解未必能够足够透彻，所以“功能复用”的滥用就会导致排异反应。

乐高积木则不然，乐高积木组件的功能单一，相同功能组件之间不存在致命性的细微差异。所以我们如果追求代码的复用性那么这块代码的功能就必须足够存粹和单一，代码的复用性越高，它所能实现的功能就越单一，推论到极致就是我们复用最多功能包括+ - * \ = ，因为你可以将它们看成操作函数，虽然复用性高了，但是可用性确实降低了，因为一条“加法语句”几乎完成不了什么软件功能。对于领域软件开发者而言，代码复用性越高，就越会失去领域的功能与特性。可以说，能够被广泛复用的代码都是软件业的“标准件”，比如Log4j。就像机械行业的“标准螺钉，螺母”等。虽然标准件被广发使用，但是它的用途就是那么单一，因而无论软件业还是机械行业，相对行业所有组件而言，标准件的种类还是不多，都是远远少于专业组件，就是因为高可用的复杂零件甚难通用。因而，《演进式架构》一书告诉我们的“代码复用性越高，其可用性越低”。所以，对复用性的追求应有个合适的限度。

当然，和使用乐高积木一样，我们复用标准件问题不大，因为它们的功能单一，所以稳定，就像Log4j库，java的String、Collection库等，它们其实发展了很多年，甚至在其他古老语言中已经积累了足够的经验和教训。如果我们没有足够的经验，尽量不要试图一次性提炼出共享的服务让所有人复用，这不仅成本和代价巨大，而且后遗症严重。因为，我们复用了别人的代码，就意味着在我们的功能（身体）里耦合了别人的功能（器官）。

回想一下，我们所复用的那些通用的功能，基本上都是来自开源的跨业务领域的通用功能代码库。我们真的复用身边同事所写的共享的业务功能了吗？我的答案是很少很少，这是不是难以置信？与我们的直觉不符？因为我们感觉自己使用了很多其他同事的类，大家在协同工作，虽然共享范围不是那么广，但总是在复用别人的类库。好吧，仔细品味一下，我们大多数的情况下都是在利用别的同事类库中的数据模型或数据来完成自己所负责的数据处理功能。所以，函数式编程强调把数据与代码分离。感兴趣的话，可以看看《FUNCTIONAL AND REACTIVE DOMAIN MODELING》(中文版《函数响应式领域建模》)，关于“数据与代码”分离这一点，以后有机会讨论“面向对象编程中“对象抽象”的概念再进一步阐述。

总之，代码复用或者功能服务用会带来耦合，复用越多耦合越多，传统SOA架构理念所提倡的服务复用思想不再适用于数字化时代的系统架构。共享服务中心或者共享能力中心都是传统SOA架构理念的产物，在数字化时代采用微服务架构配合流式计算更适合大型企业。