阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 「吃草的罗汉」欢迎转载，保留摘要，谢谢！

• 技术中台的作用是什么？
• 在什么情况下，才有必要做技术中台？
  • 前提1：技术组织结构垂直化
  • 前提2：业务线又多又复杂
• 有了技术中台，是不是就能上天？

---

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
4. 新的源码解析文章实时收到通知。每周更新一篇左右。
5. 认真的源码交流微信群。

---

在技术圈，每年总有那么一拨人，喜欢把 “某某岗位要不要写代码” 这样的话题拿出来讨论一番。

比如，前年的话题是CTO要不要写代码，去年的话题是架构师要不要写代码，今年的话题是技术总监要不要写代码……按这逻辑，明年的话题是不是要讨论工程师要不要代码？

说实话，我并不喜欢讨论这类话题，因为每家公司的客观环境与人文价值观都不相同，聊这些，除了引发争吵，不会从中得到更多。

相比之下，我更愿意参与一些技术话题的讨论，因为大家面对的场景相似，采用的技术也相似，这样能更容易产生共鸣，更容易擦出 “爱” 的火花。

就在刚过去的半年里，「中台」成了技术圈内讨论的热门词汇，就连一些名不见经传的小公司，也都纷纷喊出了「要向中台转型！」的口号，甚至有人说「不做中台，那就等着死吧！」

如果我没有记错，「中台」思想源自于2015年，马云参观一个著名的游戏公司Supercell之后提出了，简言之就是“小前台、大中台”，随即阿里就成立中台事业群，并取得了很好的成效。随后，美团点评也开始走中台策略，腾讯在去年的组织架构调整中，也提出建设具有 “腾讯特色的技术中台”。

技术中台的作用是什么？

要搞明白这点，你需要先搞清楚「技术前台」、「技术中台」与 「技术后台」 之间的关系，以及他们各自扮演的角色与作用。

先来说说我们的「技术前台」。

「技术前台」，说白了就是为业务部门开发功能的技术团队，如果是ToC的业务，交付物必须贴近终端用户，如果是ToB的业务，交付物需要满足商家的需求。脑海中必须时刻牢记 “小步快跑，快速试错” 的理念，业务说啥，就是啥，业务要怎么做，你就怎么做。

另外，研发资源的投入基本和业务对等，业务需求多，人数增加，业务需求少，人数相应减少，而且团队组织也基本按功能线来划分。

运用的技术栈也相对单一，以Java语言为例，通常 “1个NG + 1个War/N个Jar + 1个数据库” 就搞定了，而其余的技术服务都将由「技术中台」提供。

「技术前台」的核心价值体现在对业务逻辑的理解与实现上，是技术向业务传递价值的阶梯。

我觉得在这点上，与线下销售团队的前台营销有一些类似。

再来说说我们的「技术中台」。

「技术中台」，说白了就是强调资源整合、能力沉淀的平台体系，当「技术前台」实现业务功能时，为他们提供底层的技术、数据等资源和能力的支持。

这怎么理解？

从这张图中可以看到，「技术中台」有点像编程时的适配层，起到承上启下的作用，将整个公司的技术能力与业务能力分离，并以产品化方式向前台提供技术赋能，形成强力支撑。

在什么情况下，才有必要做技术中台？

俗话说 “知己知彼，百战不殆”，在我看来，面对技术问题时，“知己” 比 “知彼” 更为重要。

在实施「技术中台」之前，我们是否要静下心来对自己进行 “灵魂拷问”？比如说，当前的时机是否已经成熟？或者怎么才叫成熟？

在我看来，要想做「技术中台」，客观环境需先满足两个前提：技术组织结构垂直化、业务线又多又复杂。

否则，「技术中台」的结果只会是两种：一场闹剧 或者 一笔赔钱的买卖。

前提1：技术组织结构垂直化

曾经有朋友说过，每家公司的组织结构演进都是一部心酸血泪史。我很费解，问为什么？

他说，因为这中间掺杂着太多的主观判断与情感纠葛。

比如，某员工认为公司管理混乱，组织架构来回调整，今天拆这个团队，明天合那个团队，纯属病急乱投医，高管都是些横行霸道，滥用资源的傻逼货，借机搞人，这公司，没救了。但高管们大呼冤枉，觉得组织架构调整的目的是为了提高产出和人效，如果你干得不爽可以离开，这种事情，本来就不可能让每个人都满意，既得利益者肯定大加赞赏，而失去利益者肯定狂喷不止，不用理会。

的确，这种 “自我革命式” 的调整，基本不可能一步到位，需要一个过程慢慢演化，而在这个过程里，自然会遭遇很多的阻力或质疑。

瞧瞧这结构，经典的职能分工模式，有什么问题吗？我不但说不出问题，甚至能找出一万个理由说明这种模式的好处。开发按业务线分开，测试与运维形成上下层关系，谁也不想管对方，两边的老大也是评级的，相安无事。

那什么情况下才会觉得这种模式有问题呢？

客观的说，职能分工模式更适合瀑布式开发模式。先谈需求，再谈工期，随后按部就班地往下做，但当用户的需求开始变的多种多样，业务方时不时的就要上一个新功能，做一个新系统的时候，你会发现开发出来的系统很难变更，至少很难快速变更。

于是，你把开发按系统功能进行重组，每个团队都围绕 “交付速度” 开展工作，但这样又遇到了两个新的问题：

• 多种多样的中间件，每个团队独立选型中间件，没有统一的维护，没有统一的知识积累，无法统一保障SLA。
• 开发与测试、运维之间目标不一致（比如测试A君，开发要求你只做功能测试，快上线，但测试老大却要求你做非功能测试，保障质量，避免背锅……到底听谁的？），陷入永无休止的扯皮与争吵。

面对这两个新的问题，我们做出了调整：

• 成立平台架构组，负责中间件、自动化测试/运维、数据库等技术工具或服务的开发、维护。
• 把质量管理部中的测试团队，与系统运维部中的应用运维团队，按照系统功能拆分至各开发团队，由原开发经理负责，形成各自独立的Feature Team。

到这个时候，虽然整个组织结构还未完全实现垂直化分工，但已基本能够达到 “快速试错，小步快跑” 的目标。

另外，这更像平台化的另一种雏形，就是逐渐把一些公共、底层的技术能力抽象出来，与业务逻辑分离，并形成各种接入式基础服务，同时可以为多个业务线提供服务。

也就是说，打造「技术中台」的前提是平台化，而平台化的先决条件是「组织结构垂直化，技术工具公共化」。

如果没有这样的前提，就失去了打造「技术中台」的立身之基。

前提2：业务线又多又复杂

曾经有朋友问我，技术的核心价值是什么？我的答案是 “改变世界”。

他说，别扯淡，好好说话。

他说，对业务驱动型的公司来说，技术的核心价值是 “降低成本，提升效率”，而单从架构设计的角度来看，想达成这项目标的两个手段是「通用性」与「复用性」。

现在想想，这句话可以完美的衔接到「技术中台」上去。

回顾几年前，我们的业务逻辑也曾非常单一，要么用你的银行卡买卖基金，要么用你的电子钱包买卖基金，方便，快捷。

渐渐地，随着业务创新业务增多，需要前后台系统定制开发，逻辑兼容难度增加。

在这样的局势下，为满足企业规模扩大和多样化经营对组织机构的要求，公司开始转向事业部制，按产品、地区或市场(顾客) 划分经营单位。

为了应对业务方的这次调整，我们开始将业务开发中的一些共享服务分离出来，成立了业务中台组（由于本文以技术中台为主，业务中台的内容将不进行展开说明），将可以复用的服务和代码，交由这几个组开发出服务来，给业务组使用，这样数据模型会统一，业务开发的时候，首先先看看有哪些现成的服务可以使用，不用全部从零开发，也会提高开发效率。

与「业务中台」相呼应，「技术中台」就像一个工具大仓库，里面放满了各式各样的技术工具，无论是哪个团队，哪个人，快速找到自己的工具，拿来就用就行了。

而维护工具的这群人，不用贴近业务开发，每天的任务就是研究如何使用这些工具，如何调优，遇到问题如何Debug，形成知识积累。有了这么一群专职的人，就可以根据自身的情况，选择有限几个技术栈集中研究，限定业务组只使用这些工具，可保证选型的一致性。

如果你只有一条业务线，那就别搞「技术中台」了，把人凑在一堆，又省钱，又省力。

有了技术中台，是不是就能上天？

理论上讲，当业务线变多且越来越复杂，前台与后台之间的“技术债”会随之变多，重复造轮子与沟通成本太高的现象会增多，通过技术中台可以一定程度上来解决这个问题。

这种理论看似完美，但在实际执行上却困难重重。

设想下，如果「技术中台」做得太多，资源投入就会很大，无法形成正向的利益传导，如果「技术中台」做得太少，又无法深入理解业务，导致适配方案落地性变差，渐渐失去价值。

这句话怎么理解？

十年前，我在某金融软件公司工作，随着客户数的增多，成本与效率/质量的矛盾日益凸显。

设想下，从一波人维护一套代码，渐渐变成一波人维护几套代码，这样一来，Bug增多，效率下降，抱怨也随之变多，再加上甲方挖人，最后人员离职，团队土崩瓦解，Game Over……

在这种情况下，一般公司会采取三种应对措施：

1. **一对一服务 - 项目制：**多个团队，多套代码，多套标准，服务多家客户，但这样一来成本又难以承受，时间一长，肯定资不抵债。
2. **一对多服务 - 标准化：**一个团队，一套代码，一套标准，服务多家客户，但客户不买账，客户说我的需求都是个性化的，你别来某某标准来引导我，叫你咋做，你就咋做，不愿意？那您走，我找别人家做。
3. **一对多服务 - 产品化：**一个团队，一套代码，多套标准，服务多家客户，通过技术与配置化的手段，利用SOA思想，打造自己的产品化平台，但对技术投入要求较高，尤其是核心人才的依赖较大，中小型企业一般都很难留住这些人，只要他们一走，公司基本完蛋。

回想下，当年那些叱诧风云的软件公司，又有几家活下来了？以金融业为例，恒生算是在第二条路上走的比较成功的，而我们当年却死在了第三条路上。

在我看来，我们的「技术中台」就是一家 “乙方服务公司”，而我们的「技术前台」更像是一家 “甲方电商公司”。

不可否认，有了这家 “乙方服务公司” 之后，在面对大型项目及快速多变的业务时，技术的投入与主动权更强了，但由于理念、职责、节奏与使命不同，外加 “屁股决定脑袋” 的立场，前台与中台之间很容易引发矛盾。

从职责角度来说，前台是 “快速应对业务变化”，中台是 “稳定高效提供服务”。

一个追求效率，一个追求质量，这矛盾是天然存在的。

怎么理解？我来举个小例子说明下。

前台部门的A团队和B团队，由于业务需要同时向「技术中台」提出要接入缓存服务的需求，「技术中台」的中间件产品线中有一套基于Proxy的自研分布式缓存系统，已在其他业务线运行多年，但由于A团队与B团队的技术债都各不相同，必须通过增加适配器才能完成接入，而此时人手又不够，按重要程度排序，只能先接A团队，但B团队也有需求，又等不及，怎么办呢？就先给他来个Redis接着玩玩吧，等A团队接好了再来接你的。

一个月后，等A团队接完了，找到B团队，这时痛点已不存在，团队的激情自然不高，毕竟没有收益，就不了了之了。

几个月后，安全团队提出要对Redis集群进行改密，由于A团队接入的是「技术中台」的缓存中间件产品，采用代理模式，并通过控制台操作，既方便，又快捷，找个晚上，5分钟内，全部搞定。

但B团队用的是直连Redis的模式，密码嵌入在SDK中，不仅在改密过程中需要前台与中台联动，而且还需要在改密后重启应用服务，这样一来，只有配合应用发布的周期才能干这件事。

最终，原本五分钟可以搞定的事，整整搞了三周才搞定，「技术中台」的运维同学更是陪熬了多次通宵，还因为人为疏忽引发了一次事故。

就在这件事过去的一年时间里，由于B团队系统的业务规模逐渐增大，Redis数量也逐渐增多，「技术中台」的运维成本与风险也随之上涨。

这期间，中台曾多次与前台交涉，希望能够通过适配的方式将A团队接入缓存中间件，但始终未能达成。

在「技术中台」看来，“你们只顾自己，不管别人，功劳你们拿，黑锅我们背？”

在「技术前台」看来，“你TM懂个屁！我们都快被业务逼疯了，你们不就多费点人工吗？多加点班会死吗？总扯一些理念干嘛？对你没收益的事，你干嘛？”

因为这样的分工模式，导致这种矛盾在工作中很多，而且似乎并没有更好的方法彻底解决。

有人说，要解决很简单，要么强压，要么加大投入，下下狠心就得了。

先来说说强压，似乎能够在短时间内达到目的，但纯属 “杀敌一千自损八百” 的招数，难道要业务研发团队停下手上的活，倾巢而出一起搞技术改造吗？更何况，前台承受的压力，是中后台团队无法想象的。

退一步说，抛开 “互相理解” 这个话题，强压的套路等同于 “攻城为上，攻心为下”，对今后的管理与团队氛围都会带来诸多的麻烦。

再来说说加大投入，看看我上面提到的 “死在路上的软件公司们”，还想加大中后台的投入吗？

如果你不是大厂，还是算了吧。

那句话怎么说来着？最悲惨的结局是，你的技术中后台越发强大，但你的业务规模却在逐渐萎缩。

可悲，可叹。

在互联网时代，技术圈似乎从来不缺少热议话题，但有质量，有深度，且能解决实际问题的却少之又少。

现在人人都在讨论「中台」，今天「产品中台」，明天「数据中台」，这个说能提高效率，那个说能排除万难，聊得不亦乐乎。

对于企业来说，话题热不热并不重点，方案牛不牛逼也不重要，关键是能帮助用户找到效率、质量与成本的平衡点，或许才算是一个合格的「技术中台」。