金融全产品交易模式下，技术中台应该是怎样的？

相信很多人都听过这样一句话：脱离了整个业务场景谈架构或者谈技术，其实就是耍流氓。技术中台最近这段时间非常火热，在各样的大会、文章里面都出现过相关的话题。

很多人脑海中就会认为：只要公司做大了，我的业务就要去做中台，如果不做中台好像我就活不下去，这种话题外界流传的也非常多。

在我看来，中台其实并没有什么标准，因为每家公司都会基于自身的业务场景来进行实践，比如我这边分享的是金融全产品交易模式，有的人可能基于公司的电商场景，有的可能是游戏平台的场景，或者是其他什么场景。

我从来不认为中台是一个什么标准，因为每家公司都有自己的一些特性，这中间掺杂到人、组织结构、流程，SOP 等等各样的事务，所有掺和起来的整体更像是一个公司经营的战略。

所以，我认为中台不是一种技术实现，而是一种技术战略。包括微服务，之前的 SOA 也都一样， 它根本就不是一种技术。

如果你说它是一种技术，那么它用的是什么？它该用什么语言还是用什么语言。服务又要怎么拆呢？所以它其实是一种业务模型，跟你的技术没有多大关系。

我个人更赞同这句话：中台它不是一种实现，它其实是一种战略或者布局。

在这个布局中间，会包含 4 个元素，除了技术、业务，还包括数据和组织结构。中台的实现都是基于自己的业务去做的，有些公司自己只有一条单一的业务线，没有复用，也就没有必要去做中台。

所以为什么我们要去做中台？不管是业务状态的，还是技术状态的，简单来说就是一句话：我们需要复用！

因为当我们的业务线开始变多，并逐渐形成了事业部，这时我们就需要有这样的一些技术手段，包括调整组织结构等等，用比较低的成本去支撑多条业务线的实现，这样才是一个划算的买卖。

什么情况下，技术中台才会有价值

1. 业务系统的演进过程

在谈技术中台之前，先简单为大家介绍一下我们业务系统的演进过程，方便大家了解背景。

我们的发展历程跟很多公司差不多，基本上都是从单体架构单产品开始，然后发展到单体架构需要去支撑多产品，再到重新定义。

我们公司以前是做线下金融交易业务，从 12 年余额宝出来之后，开始做线上。最开始实现的就是一个简单的买卖交易，随着产品线的增多和渠道商的增多，在 2014-2016 年我们有重复建设的过程，在 2017-2018 年我们形成了事业部，这时就需要对我的服务和架构以及业务条线进行重构结构的调整，这是很正常。

如上图所示的 1.0 发展阶段，因为我们是基于基金来做理财的，有公募基金、私募基金。对于前端我们有 APP、网站、外部渠道的合作柜台等。交易的实现很简单，就是做交易的服务模式和交易体系，包括我们的支付，以及后台的运营都很简单，连接数据库就可以解决。

到了 2.0 时代，就需要一个单体架构去支撑多产品。我们的软件架构还是一样，但是随着交易量的上升，可能要用到一些基础组件，比如上图左下角显示的 Redis、memcache 等，这些也都是大家常用的。

同时我们也开始有了自己的账户体系，从支付中间分离出我们的账户中心，包括我们也用到了很多 MQ。

从后面的基础组建中间，可以发现一个很有意思的问题，我相信很多公司都遇到这样问题。

你用的任何一个技术或者选型通常都是根据你团队的老大，比如你公司的 CTO，或者一些技术债而决定的。

为什么要用这些技术？是因为之前有人用了，换你接手，短时间内财力、物力、人力都解决不了，所以你只能沿用先前的技术。或者是你的老板觉得某个东西好用，叫你也用。

所以大家能够发现我们进化到 2.0，各种技术选型和技术手段可谓五花八门，这是因为业务部门给到的压力，只能快速的去应对。

这时就会产生以下 4 个问题：前台负责部分业务拼装、缺少分层，系统相互调用、基础组件五花八门、多套运营后台。

举个例子，假如你的前端团队现在在做一个东西很忙，你的后台团队正在做一个东西，但并不那么忙。这时公司需要上一个很急的项目，该怎么办？

从架构分层来说，应该是由前台来做的。但是前台现在很忙，让项目排队等候？对于很多的中小型企业，这是不可能的。

既然后台团队正空着，可以先在上面开始做，这样子看上去好像所有的人都很饱和。

但时间一长，也会带来一个问题，就是在你快速发展的过程中，会产生很多的技术债。

到最后你会发现，明明应该在后台逻辑层去实现的东西，你却在前台实现了。前台应该实现的东西，这些逻辑判断却在后台实现。

这就导致了前台负责部分业务拼装的现象，尤其是在业务发展速度很快的前提下。缺少分层系统互相调用，也是由这个原因导致的。

什么基础组建五花八门，多套运营后台重复建设的问题不用多说，像这种阶段相信大家都经历过。

进入 3.0 阶段，上图显示的是我们的多业务线，在中间部位有机构、零售、高端、储蓄罐、产品中心、账户中心、批量、后台，支付后台、报表后台、交易后台…

很明显的看到，其实我们已经开始把不同的产品放到不同的事业线里面去了。

2. 技术中台的前提

技术中台其实是一个技术战略，这个战略中间它包含了业务、数据、技术以及组织结构，甚至还有文化。

要做技术中台，我个人认为首先要具备两个大前提：

（1）技术组织结构一定要垂直化

如前面所介绍的我们公司的组织结构，这个系统的发育过程经历了 1.0、2.0、3.0 等阶段，到 3.0 时代之后，我们才开始有意识说我们要去做一个所谓的技术中台。

在 1.0 和 2.0 的时代，我们是按照职能来划分的，如下图所示，相信很多公司基本上都是按这样来划分的。

图中用红框标出来的就是我们的研发团队，研发团队中间只包含研发，他们只做开发。后面还有两个团队，质量管理部，其实就是测试团队和 QA 团队，包括我们的系统运维团队。

这个组织结构是按职能来划分的，测试和测试在一起，研发和研发在一起。那么，对于这种结构，大家是否觉得有问题？

为了解决这个问题，我们需要从自身业务特性出发。作为一家强业务驱动型的公司，一般看你的技术团队、成本中心、产品中心这三样东西。

有人可能好奇什么是强业务驱动？可以这样理解，就是你卖出去赚钱的产品，是因为你业务的产品。比如我们怎么赚钱？就是卖我们的金融产品，给客户带来收益，客户分给我们钱，我们是靠这个活着的。

用最低的成本达到最高的产能效率来帮助你的业务获得更多的收益和流量，这个就是你成本中心的价值。质量更不用说，那为什么我把效率提升上来了？

对于一个正在快速发展的公司，哪一个最重要？一定是效率！我可以不惜成本，质量也没关系，只要在交易的主链路中间不出现任何问题，就可以在牺牲质量的前提下上线。

为什么这样说？因为假如我有的东西缺失了，但只要服务化切得好，某一个东西坏了，可以让它下线，做服务降级也没有问题，但是你的效率一定要快，因为要抢时间。

而在我们 1.0、2.0 时代，当时的按职能划分的组织结构是很有问题的，达不到提高效率的结果。

为什么这样说呢？因为我们当时存在一个痛点：因屁股决定脑袋而引发的多种多样的中间件！每个团队独立选型中间件，没有统一的维护，没有统一的知识积累，无法得到统一的保障。

在快速交付的过程中，肯定也会遇到各种障碍，开发、测试、运维团队的目标不一致。比如测试 A 君，开发要求你只做功能测试，快上线，但测试老大却要求你做非功能测试，保障质量，避免背锅……到底听谁的？从而陷入无休止的争论。

基于 1.0、2.0 阶段的这种野蛮生长过程之后，我们为了解决每个团队的目标从而提高交付速度，决定把技术服务下沉，快速试错，小步快跑。

最后把整个测试团队以及运维团队做了拆分，成了现在这个结构，也即是说把每个测试、研发、运维分到了这些以功能为目标团队里。

（2）业务线又多又复杂

再次以我们自身为例，如下图所示，底部的 7 个红色字块，代表了我们公司做的全品类产品。

将这些产品全整在一起，不仅对自身的资质、牌照提出了很高的要求，还伴生有技术性和业务性的许多问题，最可怕的是还有合规上的问题。

比如证监会跟保监会的东西就不能放在一起，但是对于客户来说，下 100 万的单子，各买 50 万的保险和股票型基金是一件很正常的事情，但是合规上就是不可以。

这就是我所讲的在系统建设过程中出现的又多又复杂，还有一些合规上的问题。因为产品繁多，系统就显得乱七八糟。

而业务创新比较多，需要前后台系统定制开发，逻辑兼容难度增加。再加上业务逻辑分散，缺少统一适配层，所以每次测试工作都需要 ALL IN。

如下图所示，基于前面这些内容，我们现在的整个技术前中后台就是按这么划分的。

前台主要是做功能，也是现在整个研发团队中间人数最多的，大概占到总体的 60~70%。

中台主要解决的就是中间件自动化运维以及集中自动化。

技术后台是什么？其实就是整个的基础架构，网络安全、存储虚拟化，包括我们的服务器，云厂商这方面的一些问题。

技术中台的作用，有点像编程时的适配层。适配层从上启下，将整个公司的技术能力与业务能力分离。

中间我们把整个团队，包括整体的 KPI、战略全部分离了，做到技术能力和业务能力分离，并以产品化的方式向前台提供技术赋能，形成强力的支撑。

至于把测试运维打散到产品线还能否高效跑起来，就看你技术中台资源整合的能力了。

技术中台实践过程中的问题与挑战

在技术中台的演进过程中，我们还面临着三个挑战：

1. “屁股决定脑袋”

前面提到我们技术前台的团队占到全体人员的百分之六七十。显而易见，假设我的前台团队有 100 个人的话，可能技术中台只有 20 个到 30 个人。

在这样的前提下，一个团队要来应付前端这么多人，势必会遇到下面这些问题。

由于理念、职责和节奏以及使命不同，再外加屁股决定脑袋的立场，前台和中台的矛盾是很多的。

从职责的角度，前台他要的是快速应变，中台要的是稳定高效提供服务。一个追求效率，一个追求质量，矛盾是天然存在的。

2. “该死的技术债”

那么前台追求效率，中台追求质量，两边的目标不一致，所以你前台的需求中台要怎样去实现呢？

我们来看一个场景示例，下图展示的是我们公司的技术中台的一个产品，这个产品是 A 团队和 B 团队同时需要接入分布式缓存。

A 团队、B 团队指的就是前台的团队，前台 A 团队由于业务需要，同时向技术中台提出了要求接入缓存的需求（技术中台的中间件产品线中有一个基于代理的资源）。

因为 A 团队和 B 团队的技术债不一样，两个团队系统也不一样，所以必须要求增加适配器才能完成接入。

什么叫适配器？简单来说可能是一个基于代理的 SDK，或是基于某一个协议的。

如果之前另一个团队没有用代理，而是直联 Redis，该怎么办呢？就只能通过中间适配器的方式来帮它桥接到现在这套系统里面去。

为什么要这样做？因为对于中台团队，这样做的技术成本会很低。因为我只要维护一套系统，通过两个适配器，两个 SDK 的封装包，就能解决。

3. 众口难调

在我们技术中台做技术选型的时候，基本上都是出于老板的丰富经验。你的老板用了 A 你就去用 A，你老板用了 B 技术你也只能用 B 技术。当然还有一些技术债的问题，这就导致了谁说了都算，谁说了也都不算这样的尴尬境地。

混合交易场景下，技术中台的未来在哪？

前面所说的多产品交易，基于多金融体系下的这种混合场景交易，我们的技术中台未来该怎么走？

现在由于我们公司需要从线上转型到线下，包括我们自身的一些调整以及行业的变化，我们的技术团队人员在收缩，对于技术的投入越来越小。

前期已经把整个技术架子搭到这么大，但是现在却没有那么多的人和成本去投入，所以这是一个很悲惨的过程。

当你的产品比人还多，比如你技术中台所提供的产品有 30 个，现有团队就只有 20 多个，你想想看你的服务会做得好吗？

所以这个就是我们接下去所要解决的一个很大的问题，前台没办法变动，毕竟业务总得要做。当你的人员规模萎缩，但是业务还在，该怎么办？只能把这个事情往外走。

比如我们从线上转线下，APP 和网站等都还在，外包又会限制你的效率和行业敏感度。而自建研发团队，也会受到规模和技术投入上的限制。

你在缺人、缺经验、缺钱，再加上一些客观条件的限制，不少中小型企业可能只能摸着石头过河，既没有时间试错，也没有试错的本钱。但需求仍然还在！

公司还是会继续给你提需求，所以只能要一点做一点、坏一点修一点，处于疲于奔命的状态。基于这样的情况，最后我们准备上腾讯云。

因为我们的业务转型，对线上的依赖在下降，所以我们现在可以选择把我们一些标准的服务上到腾讯云，完成我们技术中台的标准、工具以及团队的逐步上云。

后台也是一样，我们可以把我们的服务器，包括我们的网络全部都上到腾讯云，来解决我们目前所需要的一些问题。

我觉得对于建设中台，并不意味着中大奖，它其实是靠每家公司逐渐演化才能产生收益的。

因为你做任何东西都需要投入，一定要记收益，不是做着玩的。技术中台要基于自己的特性，它就像健身一样，3 个月有效果，10 个月有结果，可惜的是大多数企业基本上都是一拍脑袋就上了。

我们的技术中台是基于之前我们的特性，中间有数据、有业务、有团队、有流程、有文化，才形成了我们现在所谓的技术中台。它确实解决了帮我们度过 2015-2016 年快速发展过程中所需要的东西。

我们现在之所以能够去上云，而且我们也能够制定成这个过程，就是因为我们现在把整个技术变成了前中后台，才能够非常清晰的划分出前台和中后台的区别。

我们才能把中、后台逐渐的往腾讯云上迁移，我们也清楚了哪些东西需要去上云，哪些东西是不要上云的。

Q&A

Q：公司也要做中台产品，这是企业的未来道路吗？

A：你不管你做什么中台，首先你需要有一定的规模，而且你要多业务线，然后你的组织结构要相对偏垂直，也就是大家分工要明确，并且你有很多复用的需求，你才有必要去做中台。

Q：创业公司如何低成本搭建中台，如何说服领导大建中台，解决技术和业务效率低的问题？

A：个人建议，如果你现在的团队还在 100 人以下，也没有那么多业务线的话，我建议你不要走这条路，继续走原先的路。除了上面谈到的组织结构的问题，即便是换成中台垂直的模式，也有很多新的问题出现。如果你的复用用到不多，个人建议你还是说服领导不要去做中台了。

本文转载自头哥侃码公众号。

原文链接：https://mp.weixin.qq.com/s/QR-Ym4-_N9BONxEySoediQ