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

开发 架构 开发工具 中台
中台到底是什么鬼?很多人写类似的文章,想告诉大家什么是“中台”。反正我看一篇扔一篇,原因是没有一篇能够说清楚。

 中台到底是什么鬼?很多人写类似的文章,想告诉大家什么是“中台”。反正我看一篇扔一篇,原因是没有一篇能够说清楚。

[[338746]]

 

图片来自 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)

责任编辑:武晓燕 来源: 大数据架构师
相关推荐

2023-02-14 11:18:28

人工智能Chrome

2017-10-23 15:17:42

技术业务职位

2023-10-19 16:03:34

人工智能元宇宙

2024-04-01 07:50:02

独立开发编程独立产品

2014-10-22 13:37:44

开发者程序员

2020-07-23 10:51:29

NginxWebApache

2021-07-29 07:51:43

工具 HappensBefore

2021-08-11 11:25:22

happens - bJava代码

2020-10-20 06:48:24

架构师CPU服务器

2021-01-27 15:38:27

微服务架构IT

2010-03-30 10:02:09

陈晓薇

2020-11-30 08:07:31

中台CTO项目

2020-08-03 07:55:37

程序员软件技术

2019-11-04 13:09:43

数据平台架构

2020-03-02 19:51:40

戴尔

2023-12-21 09:14:27

AI科技

2013-05-20 16:30:37

移动应用App推广

2020-06-01 14:02:25

Vue.js框架模板

2017-09-12 12:13:57

梦想 咸鱼
点赞
收藏

51CTO技术栈公众号