我也不想做中台，但是刀架脖子上了

从技术角度上来说，中台是一种技术架构方法；从组织角度上来说，中台也是一种组织架构方法。

我只能看清中台在这两个角度上的投影。这两个投影都与架构相关，唯独与“万能”无关。

今天我就从技术架构的角度帮大家捋一捋中台到底是什么鬼。

OK，Let's Go！

在当年单机时代，所有的软件架构都是单体架构。当时流行的架构区分为 C/S 架构和 B/S 架构。

C/S 指的是客户端（那时叫客户机）和服务端（那时叫服务器），是桌面程序。B/S 指的是浏览器和服务器。

当时是不叫单体架构的，因为还没区分出其他架构。当时最典型的架构框架叫做 MVC，即 medel（代表数据）、view（代表展示）、controller（代表业务逻辑处理）。

架构敏感的同学会立刻生出一堆问题：

• 怎么支持超多超复杂的业务啊？
  

• 扩展性怎么做？
  

• 怎么解决复用的问题？

• 耦合太紧，一旦出问题就全部完蛋，怎么办？

是的，但是不用担心，当时的需求并没有那么复杂，基本上从业务逻辑到数据访问到返回结果一路写下来也就搞定了。

所以单体架构的优点非常明显：

• 开发简单
  

• 测试简单
  

• 部署简单

Tips：架构演进的过程中，“拆”和“合”就是架构的核心中的核心。

这就是“垂直分层架构”，也就是大名鼎鼎的“面向服务架构”--SOA。

我们把每一个业务的每一层单独拆成一个小模块，各自改各自的东西，不需要再去公共组件中去修改了。

在进行进一步解耦之后，每个模块的复杂度降低了，模块之间的耦合度也降低了。由于有多个 DAO，SQL 执行的效率也提升了。

这时候就会有人问了，这得拆多少个微服务？这对管理简直是一个灾难！各管一滩事，谁去统一管控？

所以微服务架构还有一个事情是必须做的，就是增加管理组件。

是的，您发现了，解决一个问题必然会带来其他问题。微服务做到了进一步解耦，解决了很多分层架构的很多问题，但是遇到了以下挑战：

• 每个微服务可能会用不同语言的不同版本。

• 有太多的基础框架和工具需要学习。

• 所有的 client、server 都需要维护 n 个版本。

• 上下游需要同步升级，否则你懂的。

解决办法呢？能不能进一步解耦？有人说了，都解耦到这种程度了，再解，那得变成啥德行啊？

这个架构的好处就显而易见了，所有的通信都让代理实现，服务就只做自己的业务逻辑处理就好了。所有的跨语言问题、各个微服务版本的问题、上下游的问题全部解决了。

懒婆娘的裹脚布，终于一层层的解开到最后，终于该说中台架构了。以服务网格架构为分界线，前面的架构优化思路只有一个，就是“拆”。

到服务网格，就没法再拆下去了，那么还有更好的模式吗？既然提到了中台，那么这自然就是解决之道。

Supercell 的故事就不用再重复了。这里必须八卦一下阿里和腾讯，阿里向 Supercell 学习了中台方法论，并把它进化成超级武器；腾讯把 Supercell 收购了，却只是用来继续做游戏。从组织的角度上来说，阿里完胜。

是的，信息系统的核心就是抽象，我们在业务线之上，再抽象一层就完了。所以中台架构的核心思想不再是“拆”了，而是“合”。

各自的微服务中必然就有共同的服务，我们可以把这些共同的服务合并、标准化、统一化，封装后对外提供服务。

在业务逻辑部分做这种抽象整合重组，就是业务中台；在数据部分做这种抽象整合重组，就是数据中台；在算法部分做这种抽象整合重组，就是算法中台；在技术底层做这种抽象整合重组，就是技术中台。

而想要实现上述任何一种中台，必须要先做组织的抽象整合重组，这就是组织中台。

这也说明了，任何一个中台并不是孤立的，没有组织中台，妄想单独做其中一个中台，把中台当做银弹，那么必死无疑。

作者：彭文华

编辑：陶家龙

出处：转载自公众号大数据架构师（ID：bigdata_arch）