我也不想做中台，但是刀架脖子上了
中台到底是什么鬼?很多人写类似的文章，想告诉大家什么是“中台”。反正我看一篇扔一篇，原因是没有一篇能够说清楚。
创新互联2013年至今，先为古冶等服务建站，古冶等地企业，进行企业商务咨询服务。为古冶企业网站制作PC+手机+微官网三网同步一站式服务解决您的所有建站问题。
图片来自 Pexels
这也不怪谁，原因很简单，一个“概念”，其实是所有人的想象的合集，跟“鬼”的逻辑是一样的。
从技术角度上来说，中台是一种技术架构方法;从组织角度上来说，中台也是一种组织架构方法。
我只能看清中台在这两个角度上的投影。这两个投影都与架构相关，唯独与“万能”无关。
今天我就从技术架构的角度帮大家捋一捋中台到底是什么鬼。
信息系统架构
软件开发技术的发展与硬件不一样。冯诺依曼早在 1945 年就提出了“冯·诺依曼体系结构”，硬件系统在几十年间，基本没有任何变化。
但是软件开发的架构，却在不断的进化。从最早的单体架构到最新的云原生架构，都是为了应对不断复杂的需求和爆发式增长的数据。
OK，Let's Go!
单体架构
在当年单机时代，所有的软件架构都是单体架构。当时流行的架构区分为 C/S 架构和 B/S 架构。
C/S 指的是客户端(那时叫客户机)和服务端(那时叫服务器)，是桌面程序。B/S 指的是浏览器和服务器。
当时是不叫单体架构的，因为还没区分出其他架构。当时最典型的架构框架叫做 MVC，即 medel(代表数据)、view(代表展示)、controller(代表业务逻辑处理)。
如下图所示：
架构敏感的同学会立刻生出一堆问题：
- 怎么支持超多超复杂的业务啊?
- 扩展性怎么做?
- 怎么解决复用的问题?
- 耦合太紧，一旦出问题就全部完蛋，怎么办?
是的，但是不用担心，当时的需求并没有那么复杂，基本上从业务逻辑到数据访问到返回结果一路写下来也就搞定了。
所以单体架构的优点非常明显：
- 开发简单
- 测试简单
- 部署简单
分层架构
当业务逻辑复杂到一定程度，单体架构就没法支撑了，上述问题也就逐一暴露出来。
当时的程序员们就想了各种办法，核心就是“拆”。那么，有几种拆的方式呢?
Tips：架构演进的过程中，“拆”和“合”就是架构的核心中的核心。
是的，有两种拆分方法，横向和纵向。横向把业务逻辑拆分为网关层、业务逻辑层和数据访问层，这就是“水平分层架构”。
所谓的“前后端分离”，也属于水平分层的进一步拆分。
纵向按照业务进行拆分，每个模块提供一个单独的服务，可以拆成用户服务、商品服务和订单服务。
这就是“垂直分层架构”，也就是大名鼎鼎的“面向服务架构”--SOA。
拆完之后，该抽象抽象，该解耦解耦，各自对外提供相应服务，单体结构遇到的复杂业务、复用、一错全崩等问题都迎刃而解了。
微服务架构
但是，当需求提的越来越多，业务变得越来越复杂的时候，我们发现，无论是水平拆分还是垂直拆分，都无法再提升我们的开发效率，一些公共耦合会导致系统的复杂度提升，程序包慢慢变成祖传屎山。
这时候又要祭出架构的法宝“拆”字诀。
我们把每一个业务的每一层单独拆成一个小模块，各自改各自的东西，不需要再去公共组件中去修改了。
在进行进一步解耦之后，每个模块的复杂度降低了，模块之间的耦合度也降低了。由于有多个 DAO，SQL 执行的效率也提升了。
同时，为了应对高吞吐量和海量请求，微服务还对静态资源和代理进行进一步拆解，引入了 MQ 将同步请求解耦为异步请求，加入 RPC 框架，进行远程服务调用等等。
这时候就会有人问了，这得拆多少个微服务?这对管理简直是一个灾难!各管一滩事，谁去统一管控?
所以微服务架构还有一个事情是必须做的，就是增加管理组件。
这些组件的核心作用就是对各种微服务进行统一管控，不仅能管理微服务的全生命周期，还能在某个微服务被流量撑爆的时候进行各种丢车保帅的操作，在长长的链路中，可以不断向下跟踪，发现问题的根源。
服务网格架构
是的，您发现了，解决一个问题必然会带来其他问题。微服务做到了进一步解耦，解决了很多分层架构的很多问题，但是遇到了以下挑战：
- 每个微服务可能会用不同语言的不同版本。
- 有太多的基础框架和工具需要学习。
- 所有的 client、server 都需要维护 n 个版本。
- 上下游需要同步升级，否则你懂的。
解决办法呢?能不能进一步解耦?有人说了，都解耦到这种程度了，再解，那得变成啥德行啊?
还真可以。
这个时候，我们的整个微服务体系，就变成了这个网格的样子，所以叫服务网格架构。
这个架构的好处就显而易见了，所有的通信都让代理实现，服务就只做自己的业务逻辑处理就好了。所有的跨语言问题、各个微服务版本的问题、上下游的问题全部解决了。
中台架构
懒婆娘的裹脚布，终于一层层的解开到最后，终于该说中台架构了。以服务网格架构为分界线，前面的架构优化思路只有一个，就是“拆”。
到服务网格，就没法再拆下去了，那么还有更好的模式吗?既然提到了中台，那么这自然就是解决之道。
Supercell 的故事就不用再重复了。这里必须八卦一下阿里和腾讯，阿里向 Supercell 学习了中台方法论，并把它进化成超级武器;腾讯把 Supercell 收购了，却只是用来继续做游戏。从组织的角度上来说，阿里完胜。
每个微服务都是个性化的，在单一业务线中，这就是最优的架构。但是业务线一多，或者上下游系统太多，每条业务线都在重复造轮子，存在大量资源浪费的情况;不同业务线之间的数据也是孤立的，无法打通。那该怎么办呢?
是的，信息系统的核心就是抽象，我们在业务线之上，再抽象一层就完了。所以中台架构的核心思想不再是“拆”了，而是“合”。
各自的微服务中必然就有共同的服务，我们可以把这些共同的服务合并、标准化、统一化，封装后对外提供服务。
所以就会出现各种中心，这些中心的组合，就是中台：
在业务逻辑部分做这种抽象整合重组，就是业务中台;在数据部分做这种抽象整合重组，就是数据中台;在算法部分做这种抽象整合重组，就是算法中台;在技术底层做这种抽象整合重组，就是技术中台。
而想要实现上述任何一种中台，必须要先做组织的抽象整合重组，这就是组织中台。
这也说明了，任何一个中台并不是孤立的，没有组织中台，妄想单独做其中一个中台，把中台当做银弹，那么必死无疑。
作者：彭文华
编辑：陶家龙
出处：转载自公众号大数据架构师(ID：bigdata_arch)
分享标题：我也不想做中台，但是刀架脖子上了
网页路径：http://www.gawzjz.com/qtweb2/news44/10794.html
网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等
声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联