我也不想当中台，可脖子上插刀的中台又是什么鬼？很多人都写过类似的文章，试图告诉大家什么是“中台”。反正我看了一篇就扔了一篇，因为没有一篇文章能解释清楚。图片来自Pexels。没有人应该受到责备。原因很简单。一个“概念”其实就是大家想象的集合，“鬼”的逻辑也是一样的。从技术角度看，中台是一种技术架构的方法；从组织的角度来说，中泰也是一种组织架构的方法。我只能从这两个角度看到中间平台的投影。这两种投影都与建筑有关，与“通用”无关。今天就从技术架构的角度，帮大家搞清楚中台是个什么鬼。信息系统架构软件开发技术的发展方式与硬件不同。冯诺依曼早在1945年就提出了“冯诺依曼体系结构”，几十年来硬件体系基本保持不变。但是软件开发的架构是在不断发展的。从最早的单体架构到最新的云原生架构，都是为了应对日益复杂的需求和数据的爆发式增长。好了，走吧！单体架构在单机时代，所有的软件架构都是单体的。当时流行的架构分为C/S架构和B/S架构。C/S是指客户端（当时叫client）和server（当时叫server），都是桌面程序。B/S是指浏览器和服务器。当时还不叫单体架构，因为还没有区分其他架构。当时最典型的架构框架叫做MVC，即medel（代表数据）、view（代表显示）、controller（代表业务逻辑处理）。如下图所示：对架构敏感的同学马上就会有一堆疑问：如何支撑超多超复杂的业务？可扩展性怎么做？如何解决复用问题？该怎么办？是的，但不用担心，当时的要求并没有那么复杂。基本上，从业务逻辑到数据访问再到返回结果都可以写下来。所以单体架构的优势非常明显：开发简单，测试简单，分层架构部署简单。当业务逻辑复杂到一定程度时，单体架构无法支撑，以上问题就会一一暴露出来。当时的程序员想了各种办法，核心就是“拆”。那么，有多少种拆解方式呢？Tips：在架构演进过程中，“拆”与“合”是架构的核心。是的，有两种分割方式，水平分割和垂直分割。将业务逻辑横向拆分为网关层、业务逻辑层和数据访问层，这就是“横向分层架构”。所谓“前后端分离”，也属于横向层级的进一步拆分。按业务垂直拆分，每个模块提供单独的服务，可以拆分为用户服务、商品服务和订单服务。这就是“垂直分层架构”，也就是著名的“面向服务的架构”——SOA。拆解之后，进行抽象，解耦解耦，各自对外提供相应的服务，单一结构遇到的业务复杂、复用、一错崩塌等问题都解决了。微服务架构但是，当需求越来越多，业务越来越复杂的时候，我们发现不管是水平拆分还是垂直拆分，都不能提高我们的开发效率，一些公共的耦合会导致系统的复杂度增加增加了，程序包也渐渐变成了祖传的狗屎山。这时候就必须要用到结构法宝“拆”了。我们把每个业务的每一层都独立成一个小模块，修改自己的东西，而不去公共组件去修改。进一步解耦后，降低了各个模块的复杂度，模块之间的耦合度也降低了。由于有多个DAO，SQL的执行效率也提高了。同时，为了应对高吞吐和海量请求，微服务进一步拆解静态资源和代理，引入MQ将同步请求解耦为异步请求，添加RPC框架，进行远程服务调用等。此时，有人会问，要拆多少微服务？这对管理来说是一场灾难！乱七八糟，谁管谁管？所以在微服务架构中还有一个必须做的事情，就是增加Management组件。这些组件的核心功能是统一管理和控制各种微服务。它们不仅可以管理微服务的整个生命周期，还可以在某个微服务被流量压垮时，进行各种操作来救车。在长链接中，可以继续向下追溯，找到问题的根源。服务网格架构是的，你看，解决一个问题必然会产生其他问题。微服务实现了进一步的解耦，解决了很多分层架构中的很多问题，但也遇到了以下挑战：每个微服务在不同的语言中可能使用不同的版本。需要学习的基础框架和工具太多了。所有客户端和服务器都需要维护n个版本。上下游需要同步升级，不然你就明白了。解决办法是什么？能否进一步脱钩？有人说已经脱钩到这种程度了。如果再脱钩，又会变成什么样的德行呢？真的有可能。这个时候我们整个微服务系统就变成了这个网格状，所以叫服务网格架构。这种架构的好处是显而易见的。所有通信都由代理实现，服务只需要做自己的业务逻辑处理即可。所有跨语言问题，各种微服务版本问题，上下游问题都解决了。中台结构懒娘的裹脚布终于一层层解开到底，终于要说到中台结构了。以服务网格架构为分界线，之前的架构优化思路只有一个，就是“拆”。说到服务网格，已经拆不开了，那么有没有更好的模式呢？既然提到了中台，自然就是这个解决方案了。Supercell的故事无需赘述。这里就不得不八卦一下阿里和腾讯了。阿里向Supercell学习中台方法论，进化为超级武器；腾讯收购了Supercell，但只是用来继续做游戏。从组织上看，阿里赢了。每个微服务都是个性化的，这是单一业务线中的最佳架构。但是，如果业务线过多，或者上下游系统过多，各个业务线都是在重新发明轮子，存在大量的资源浪费；不同业务线之间的数据也是孤立的，无法打通。那我们该怎么办呢？是的，信息系统的核心是抽象。我们在业务线之上，然后我们完成了一个抽象层。因此，中台建筑的核心思想不再是“拆”，而是“合”。各自的微服务中必须有共同的服务。我们可以将这些公共服务进行组合、标准化、统一，打包后对外提供服务。所以就会有各种中心，这些中心的组合就是中台：业务逻辑部分的抽象整合重组就是业务中台；数据部分抽象整合重组为数据中台；在算法部分做这种抽象整合和重组的是算法中台；在技??术底层做这种抽象的整合重组，就是技术中台。但是，要实现以上任何一个中台，都必须先对组织进行抽象整合重组，这就是组织中台。这也说明任何中间阶段都不是孤立的。如果没有有组织的中台，你想单独成为其中一员，把中台当银弹，那你就死定了。作者：彭文华编辑：陶家龙来源：转载自公众号大数据架构师（ID：bigdata_arch）
