中台是个什么鬼d(ŐдŐ๑)

最近看了阿里中台一书，恰好在公司也是做的中台开发，就和大家聊一聊中台。

前后端，前后台

先说几个词，前端，后段，前台，后台。

前后端

前后端比较好理解，前端就是客户端，后段就是服务器端。狭义上理解，如果是java开发的web程序，那么java代码写的，需要在服务器的jvm里面运行的代码都是属于后段，而html/css/javascript都是属于前端。如果是前后分离的写法这个很容易区分，后段工程师写后段接口，前端工程师写页面，并通过jquery或者vue等调用后端接口。但很多老项目的开发方式还是采用的前后端不分离的写法，比如jsp开发，工程师同时需要开发后段程序和前端展示。所以你问我jsp是属于后段还是前端，我觉得都有。

前后台

再来说说前后台。后台管理系统，erp系统等等都是属于后台，而电商网站就属于前台。一个比较好区分的方法就是看这个系统是面向外部客户的还是面向公司内部数据管理的。从这个方面来说，后台和前台可能都包括了前后端开发。

架构演变

然后我们聊聊项目架构的演变史。

烟囱式架构

起初的项目架构是烟囱式的架构，整个项目是一个war包。这种项目架构优势也是很明显的，就是开发简单，逻辑很清晰，一个项目可能很快就来发出来了。部署也很方便，直接丢到tomcat里面就能运行。

但是烟囱式架构也带来了很多问题，新项目来了很多基础的功能都需要重新开发，比如登录，比如文件上传下载，而且并发大了以后靠提升服务器质量增加内存这种方式显然不靠谱。

集群模式

于是出现了集群模式。集群模式更多还是部署层面，还不属于架构层面。最常见的我们通过nginx来实现负载均衡搭建项目集群。还是一个war包，但是我们将war包部署在多台机器上，nginx通过配置负载均衡对外暴露一个统一的入口。用户访问nginx暴露的入口，nginx将用户的请求在分摊到war包部署的不同机器上。通过这种方式我们将原本的高并发分摊到了多台机器。但是这个模式还是有问题，首先还没有解决复用的问题，其次我们发现项目中的服务的并发量并非都是一样的。比如订单服务的并发很大，但是用户服务的并发很小。而因为订单服务和用户服务是绑定在一个war包里的，所以为了满足并发需求我们部署多台机器来适应订单服务的并发，但是用户服务是不需要的。所以这里就有一个资源浪费的问题。

SOA架构

为了解决上述两个问题，我们引入了soa架构，面向服务架构。面向服务架构的第一部分就是把一些可以复用的，通用的，基础部分从单独的war包中抽离出来形成另外的一个个项目，单独部署。开发新项目直接调用这个公共的服务。第二部分是再拆分，将项目中不同业务的部分再拆分到不同的项目中来达到按需部署的目的。这套架构已经很好的解决了上述问题了，常见的思路是有一个企业服务总线，所有的服务都去服务总线注册，然后别的项目可以通过服务总线来调用注册过的服务。单独的服务可以根据并发量配置成集群。调用方不用关心被调用方怎么部署的，反正服务总线来帮你调用。

上述方式的缺点也是可以看到的，那就是总线承担了所有的压力，服务越多，总线的压力就越大。当然大多数公司可能并没有那么多的服务，所以大多数公司通过服务总线是可以解决问题的。

微服务架构

针对上述问题一个可以想到的解决思路就是我不通过总线去调用服务，而是越过总线直接去调用服务本身，这个的解决方案就成了现在很火的微服务了。目前常用的两套开源微服务架构方案是spring cload和dubbo。他们最大的区别就是请求方式的区别，spring cload是基于http协议的请求方式，采用tcp短连接。而dubbo是采用rpc调用，采用tcp长连接，基于自己的一套消息序列化方案。总的来说，dubbo肯定性能更好，因为复用了tcp连接。但是我更推荐spring cload，因为请求方式更规范，而且随着机器性能网络带宽等等的发展，dubbo的这个优势会越来越小。而阿里自己也弃用了dubbo，用了另外一套解决方案hsf。

微服务的核心是服务的注册与发展。类似于服务总线，微服务也有一个组件叫做注册中心。服务启动以后会自动到注册中心注册自身的相关信息。但是服务调用方不通过注册中心去调用服务，而是从注册中心获取到服务的地址列表，然后自己去调用服务。

中台

最后我们来聊聊中台，阿里的中台主要是各个共享服务中心，包括用户中心，订单中心等等。中台通常位于前后台之间，采用微服务的架构开发。所以中台不是技术名词，而是一个战略名词。

中台解决前后台步调不一致问题

中台出现和受追捧的原因如下。随着互联网的发展越来越快，前台项目需要不断变化来适应市场的发展，如果变得慢了，很可能就会被市场淘汰和被竞争对手超越。然而传统前后台的方式两者之间是有冲突的，后台最需要的就是稳定，因为后台是服务内部的，他的功能完全是满足需求的。仅仅因为前台业务要变化，而让后台去跟着做出改变，在后台看来完全是没有动力去做的，一个怕系统改了以后不稳定，二是就算改好了自己也落不到什么好处。从这个点来看，中台承接了后台与前台。软件开发有句话说得好，一切问题都可以通过增加一个中间层来解决。中台就是一个中间层，解决了前台后台两者步伐不一致的问题。

中台支持前台快速开发，促进企业创新发展

随着中台建设的不断完善，他支持前端快速变化的能力越来越好。公司能够在大中台的基础上快速开发新的前台应用，快速开发，快速上线，快速试错，这是一个良性的尝试，也是支持创新最好的方式。因为快，所以即使失败了也不会损失太大，着手下一个就是了。如果没有这样的中台机制，那么公司创新的成本就太高了，一个想法从提出到出产品花了两年，有几家公司能承受失败的风险。

中台有利于数据统一，方便大数据分析

当然，中台还有其他的好处，比如大数据分析。传统公司各种系统相互隔离。可能当初建系统也没有考虑那么远，建了很多系统，而且每一套系统都是单独部署维护的。现在想要打通这些孤岛，把各个系统之间的数据整合起来进行大数据分析是很难做到的一件事情。如果采用中台架构，通过中台做数据整合，对外提供统一的数据出入口，这样大数据分析就方便的多了。