一口气说透中台--给你架构师的视角 _中台

中台到底是什么鬼？
很多人写类似的文章，想告诉大家什么是“中台” 。反正我看一篇扔一篇，原因是没有一篇能够说清楚。这也不怪谁，原因很简单，一个“概念”，其实是所有人的想象的合集，跟“鬼”的逻辑是一样的。
从技术角度上来说，中台是一种技术架构方法；从组织角度上来说，中台也是一种组织架构方法。我只能看清中台在这两个角度上的投影。这两个投影都与架构相关，唯独与“万能”无关。今天我就从技术架构的角度帮大家捋一捋中台到底是什么鬼。
【一口气说透中台--给你架构师的视角】信息系统架构
软件开发技术的发展与硬件不一样。冯诺依曼早在1945年就提出了“冯·诺依曼体系结构”，硬件系统在几十年间，基本没有任何变化。

文章插图

但是软件开发的架构，却在不断的进化。从最早的单体架构到最新的云原生架构，都是为了应对不断复杂的需求和爆发式增长的数据。

文章插图

单体架构
在当年单机时代，所有的软件架构都是单体架构。当时流行的架构区分为C/S架构和B/S架构。C/S指的是客户端（那时叫客户机）和服务端（那时叫服务器），是桌面程序。B/S指的是浏览器和服务器。
当时是不叫单体架构的，因为还没区分出其他架构。当时最典型的架构框架叫做MVC，即medel（代表数据）、view（代表展示）、controller（代表业务逻辑处理），如下图所示：

文章插图

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

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

扩展性怎么做？

怎么解决复用的问题？

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

是的，但是不用担心，当时的需求并没有那么复杂，基本上从业务逻辑到数据访问到返回结果一路写下来也就搞定了。
所以单体架构的优点非常明显：

开发简单

测试简单

部署简单

分层架构
当业务逻辑复杂到一定程度，单体架构就没法支撑了，上述问题也就逐一暴露出来。当时的程序员们就想了各种办法，核心就是“拆” 。那么，有几种拆的方式呢？
tips：架构演进的过程中，“拆”和“合”就是架构的核心中的核心。

文章插图

是的，有两种拆分方法，横向和纵向。横向把业务逻辑拆分为网关层、业务逻辑层和数据访问层，这就是“水平分层架构” 。所谓的“前后端分离”，也属于水平分层的进一步拆分。

文章插图

纵向按照业务进行拆分，每个模块提供一个单独的服务，可以拆成用户服务、商品服务和订单服务。这就是“垂直分层架构”，也就是大名鼎鼎的“面向服务架构”--SOA 。

文章插图

拆完之后，该抽象抽象，该解耦解耦，各自对外提供相应服务，单体结构遇到的复杂业务、复用、一错全崩等问题都迎刃而解了。
微服务架构
但是，当需求提的越来越多，业务变得越来越复杂的时候，我们发现，无论是水平拆分还是垂直拆分，都无法再提升我们的开发效率，一些公共耦合会导致系统的复杂度提升，程序包慢慢变成祖传屎山。这时候又要祭出架构的法宝“拆”字诀。

文章插图

我们把每一个业务的每一层单独拆成一个小模块，各自改各自的东西，不需要再去公共组件中去修改了。在进行进一步解耦之后，每个模块的复杂度降低了，模块之间的耦合度也降低了。由于有多个DAO，sql执行的效率也提升了。
同时，为了应对高吞吐量和海量请求，微服务还对静态资源和代理进行进一步拆解，引入了MQ将同步请求解耦为异步请求，加入RPC框架，进行远程服务调用等等。