中台建设务虚笔记：从一个故事开始

韩记酱肉

中台建设务虚笔记：从一个故事开始 田卫 转转技术 转转技术 转转研发中心及业界小伙伴们的技术学习交流平台，定期分享一线的实战经验及业界前沿的技术话题。 各种干货实践，欢迎交流分享，如有问题可随时联系 waterystone ~ 149篇内容 2024年09月05日 11:35 北京 一、从一个故事开始古希腊的哲学家柏拉图（Plato）曾经对人做过一个定义，他认为：人是两足，无毛的动物。而同时期的弟欧根尼（Diogenes）听后， 直接拿了一只扒光毛的鸡，扔在了柏拉图的面前，这就是你说的人？做开发这么久，学习过很多概念，也看过不少的书，但今天回过头来看自己实际工作中所负责的系统， 除了具体的编码技巧，术的层面外，在系统的设计上，真的是一言难尽，似乎一直都达不到满意的状态，经常幻想着要是能够从零开始构建就好了。理论和实践是有不同，但究竟在那个点上造成的？二、抽象与具象的挑战GOF设计模式相关的书籍，我想做技术的同学，多多少少都看过，甚至不止一遍。面试时候，一问单例模式，我们恨不得能答出花来。包括经常让人感到云里雾里的DDD，相关的聚合根，领域服务，界限上下文...概念一问也都清楚，但为什么在我们的实际工作中，看到的工程代码，需求评审后的技术方案，常常感到是那种一学就会，一用就废的无力感。抽象与具象的变化我想这里最大的问题就是，抽象和具象之间的变化问题。以上面的故事为例，当从具象（人：张三，李四）到抽象（两足，无毛）的时候，我们是看着具体的事物，提取共性特征去做归纳，相对容易一些。因为这时候，我们不知道“我们不知道”，以为看到的是全部，是本质，归纳了所有。软件开发相关的书籍中，列举的代码，也经常是那种以类似“动物-抽象，鸡鸭狗-实例”这种来示例的，确实对于理念的理解，容易一些，但脱离日常工作有些远，以至于在紧张的交付排期中根本反应不上来，没法充分和实际建立联系，不断实践。换成“发货，C2C发货，POP发货，自营发货，后验发货，以旧换新发货...”就不知道咋搞了，只在此山中，云深不知处。而从抽象到具象的时候，硬套也很容易跑偏，要的是人，实际给的是鸡，确实都是“双足，无毛”。在转转内部常说一线有神明，我想很大程度上也是来规避跑偏的问题。三、工作中的情况我所在的部门，在转转属于中台，准确地说是业务中台。涵盖了电商典型的业务场景：订单，商品，营销，支付等。作为业务中台，抛开技术这个工种上要特殊关注的系统稳定性等职责外，团队存在的最大价值其实就是：通过复用，来提升效率，让相关支撑的边际成本越来越低。就像我的Leader S常说的：你做的这个东西，至少得让两个及以上的场景来用吧，否则有啥用呢？既然复用这么重要，而从具象到抽象又比较容易，岂不是业务中台很好搞啊？嗯...怎么说呢，上帝的归上帝，凯撒的归凯撒，并非那么容易。我们做开发的，最理想的是编码的时候，能够提前考虑到未来需求场景的变化，做好扩展，抽象，解耦等提前量，这样下一次需求来时，微微一笑，弹指间就搞定了。但实际中，这样的时刻有，但有限，更多的时候不是这样的。例如，以扩展性为例，扩展的本质是什么？是占位符。你只有提前想到了，才可能在代码里预留下位置。但谁又能预测未来呢？尤其是复杂多变的业务逻辑，不像某个技术组件，例如RPC，MQ等，再怎么变化，常用的都是哪几个功能，受业务变化带来的影响微乎其微，更多是深度问题。这里多说一下，转转是一个二手交易平台，和JD、TB、PDD这种新品电商最大的不同就在于商品，二手商品每一个都是孤品，非工厂同一个模子生产出来的标准新品。你的手机和我的手机是两个不同的商品sku，尽管新买的时候是一模一样的，但作为二手商品的时候，由于你我日常对手机的使用情况迥异，我们需要让用户看到其不同地方（官方质检），叠加上这些二手商品不能够像新品一样，批量采购入库或工厂直发，需要先一个一个的从用户手里回收上来，同时不同品类下天然的商品特性差异（例如，吉他与手机），其背后支撑的系统复杂性就更高了。从收到验到卖的链路很长，变化多，抽象复用难度非常大，当然也很有意思。继续。通过抽象来复用，进而提升效率，这个思路是没错的，难点在于，日常中台开发中我们更多的只能依靠归纳各业务已经发生的动作来做抽象。毕竟软件系统的设计通常基于归纳法，而非演绎法。你很难在不了解具体业务的情况下进行演绎推测。即使有一些行业经验，也只能是尽量保证方案设计的灵活和正确性。从业务中台视角看，这就会引出一个关键问题，即我们该什么时候对什么场景来做抽象，进而沉淀复用。时机早了，就可能起不到复用，反而造成中台系统代码堆叠愈来愈臃肿。场景变化多了，又会退化成某个业务的定制逻辑，被牵引着，疲于应对，成为资源瓶颈。时机晚了，配合迁移改造的业务方就会变多，成本又一时太高，后续也不一定有那么多新场景继续用。难道追求成本与效率的方向错了么？四、虽然没有银弹计算机科学家弗雷德·布鲁克斯（Fred Brooks）在1986年就提出了著名的没有银弹（No Silver Bullet），旨在提醒人们在面对复杂问题时，不应期待简单的解决方案，而应采取多维度、系统化的方法来解决问题。面对上文业务中台遇到的问题，今天依旧适用，没有啥神话中的能一击致命地消灭邪恶生物的银弹，要不然巨头也不会挣扎这么久后，宣布放弃中台。但，虽然没有银弹，我们却有有价值的目标，通过抽象来复用，进而来提升效率，这个思路是没错的。中台基础服务需求一线有神明，回到我自己的实际工作中，去tapd需求列表上看那一个个上线了的需求，什么需求比预期要快的交付，只是几行代码或简单配置了下。什么需求30人日还没搞定，远超预期，还一堆生产问题。什么方向一两个人就能支撑住。什么方向一直在加人还是被业务投诉排不上...中台订单侧需求答案似乎浮现了出来，以我所在的团队为例（不好提别人嘛），其有一个方向叫基础服务方向，涉及商品，用户，经纬区划，点赞/收藏/足迹，标签，地址，类目属性等场景的研发支撑，服务整个转转集团各个方向的需求。但你猜，这个方向日常投入的研发资源是多少？答案2个人，最近一年甚至是1.5人，至少我在中台的这几年是这样的。而另一个订单方向，最近1年是5个人，之前多的时候11个人。你这不是胡扯么？脱离需求量谈资源就是耍流氓。但问题是，为啥都是中台领域，一个需求多，一个需求少；一个交付周期长，一个常常只需要配合联调；一个大部分是产品需求，一个更多的是技术需求。肯定不是人的问题，因为研发之间是互备流通的，难道是运气？总不会是一个PM会拒绝需求，另一个不会拒绝吧？哈哈。五、厚一些 or 薄一些上面的问题，我觉得是厚与薄的问题。那厚的是什么，薄的是什么。其实就是“业务中台”中的“业务”。和业务契合的多，交织的多，就厚；反之就薄。但问题是，你是“业务中台”啊，要是没有业务的话，岂不是就退化成了“技术类中台”，像技术中间件部门（对应转转的架构部），PaaS，IaaS平台等，各业务中肯定是有重复建设的效率空间的，而且极有可能很可观。我们这里先不用纠结厚与薄的问题，厚也好，薄也罢，只是一系列选择的结果（记住这个点）。也不用纠结“中台”这个词，虽然它这几年坐过过山车，争议很大，平常我自己也少主动使用。但还是那句话，它存在的初衷是没错的，即通过抽象各上游各业务中共性的部分，来让现在及未来新旧业务的迭代，少做一些事情，进而提升研发效率。那好，到这里最关键的就来了，什么样的业务场景有共性？进而，什么样的共性易抽象？再进而，什么样的共性抽象变更少？5.1 薄作为中台研发，自然是要第一优先去做哪些需求变化少，且业务共性多的场景去抽象，沉淀复用。这类场景是什么样的呢，从上面提到的例子中，可以窥见，就是转转基础服务方向日常所支撑的事情。从具体需求看，它有个特点是“业务逻辑不多，更靠近技术”。这不难理解，因为越靠近技术，业务带来的变化影响相对越小，自然也越容易抽象。想想看，典型的技术中间件，或者各种开源项目，为啥能在各行各业技术中应用，而不需要定制成什么 RocketMQ4PDD、RocketMQ4JD、RocketMQ4MeiTuan。在转转，基础服务方向所涉及的商品，用户，经纬区划，点赞/收藏/足迹，标签，地址，类目属性等领域，日常主要提供“靠近技术”的通用能力：即通过对各上游业务所负责运营类目的二手商品，进行数据抽象建模，进而通过RPC提供通用接口，对商品数据进行存储访问，基本校验等。就类似一个大的DAO(Data Access Layer)层，收口共享数据的同时（这很关键），不去过多关注上游业务商品怎么拼接展示，价格展示小数点几位，商品上下架规则怎么判断，新用户怎么定义等，都交给更了解业务的业务侧... 中台开发日常更专注在系统的性能，一致性，稳定性，数据模型的可扩展性，接口的易用性，持续的抽象等方面的工作（参见上面的基础服务方向的需求list配图），做的很薄。5.2 厚之前提到过一个点，就是“薄厚都是一系列选择的结果”。要是有选择，没人愿意一开始就选择厚，毕竟薄才是ROI最高的选择。从实践看，可以断定厚几乎都是从薄变化过来的，为什么？上面我们选择薄，是因为它共性多且变化少。而从中台复用效率的追求出发，还有一个组合就是通用强但变化也多，即日常虽有业务变更的挑战，但好在各业务都在使用，通用性非常的很好，例如电商行业的订单，支付，营销等方向。在最初薄的基础上，所属系统的每一代的研发同学，每一周都会去做新的需求迭代， 而面对一个个具体需求的时候，我们会发现"真的，这个需求当下放在中台做，比业务侧更快，毕竟之前有个依赖逻辑也在中台放着"。是的，我们只能通过当前的快去判断是否合适，很难要求每一个一线开发同学，每一次都有长远的综合收益考虑，而时间维度也是终极难点，所谓熵增。最后当维艰的时候，已经难以调头了。既成事实，不必悲观。一蓑烟雨任平生。厚并不意味着效率低，毕竟它还有个维度是通用性好，依然优于每个业务都构建自己的订单模型，驱动状态流转，对接外部支付渠道，对接OMS仓储，控制红包发放及财务预算，彼此间还要打通数据，以便端上来做统一的展示（总不能有多个“我买到”的吧）。同时，技术外看，这些领域在电商行业内具有高度的专业性，其学习曲线也相对陡峭，涉及和财法税打交道，一个交易模式选择自营还是POP是有非常多的考虑的，至少平台的利润不能低于自营扣税吧。所以对于这种情况，我们决策上就要谨慎一些，判断的关键点在于业务场景是否在可接受的预期内变化（嗯，废话，但你是否会关注你公司的战略变化，它会影响业务&组织变化，进而影响系统架构），否则就没有收益了，这也是为什么，转转这些厚的方向，过去面对大的业务变动，例如交易模式调整，业务融合，就会非常吃力的原因。当然，这也是最难的地方。通常这些厚的方向对外变成对应领域的共享服务(Shared Services)，来打包提供整体的领域产品解决方案，区别于很薄的“DAO层”， 组织上投入也会相对多一些，除了技术资源外，也配备有相应的产品专家。同时数据上也集中收口，方便客户端上的统一展示体验，及商业大数据运营上的分析，这些都是好处。但没有免费的午餐，好处不能让你都占了，厚的缺点也真不少。例如，中台经常被诟病的沟通协作问题，最近公司有个业务部门入职不少新人，每天都会有人过来找我旁边的同学了解一些业务逻辑，一天下来，不少时间都是在解答咨询问题，成本不低。还有加剧系统的稳定性问题，明明上线的需求是A业务的，但B业务却躺枪，跟着遭殃，且变更上线频率也增高。再就是，厚了以后，和业务的边界不好把握，相关参差太多，完全依赖个人经验对未来业务发展的预判。最后剩下的两种组合情况（如上四象限图），即复用差变化多和复用差变化少，则要识别并且拒绝掉，因为没有实质意义，脱离中台效率的初衷，最终要么是成为瓶颈，拖累业务，要么是自身维护成本越来越高，都很难受。六、不要迷路最后和一下稀泥。过去关于中台的问题，这些年行业里面讨论的比较多，也都有自己所服务公司下的论据。有的说要厚一些，有的说要薄一些，有的说干脆就别叫中台了，不就是个共享服务(Shared Services)么。我觉得确实没有什么对与错，这些都只是结果，不是目的。作为技术同学，我们最终在这样一个行业里面，还是期望能展现技术的价值，而其最终看的就是围绕效率，这也是Internet的价值所在。而对于身边大部分技术工作来说，技术对于所在公司的价值也不外乎以下三点：高效支撑业务。一个是高效，一个是支撑。前一个是关键。保障业务的连续性，也就是保障生产系统持续稳定，即凭啥公司这点人可24h不断的服务全国各地的n多用户。帮助公司构筑行业壁垒，例如专利类等。我们日常只需要围绕这些价值点去做，去解决实际行业问题就行，最终无论长成什么样子，我想都是合适的。就像做架构一样，不用纠结于各种架构范式(Architectural Paradigm)，只要能解决当前实际业务问题，并且顺带考虑一些未来时间维度的变化设计（这点很重要，是差距），最后系统演变成什么样子就是什么样子，像洋葱就是洋葱架构，像凤凰也可以叫凤凰架构，白猫黑猫嘛，哈哈。七、结语行文至此，也要结束了。不觉中来中台三年多， 结合上次内部的实践分享及本次务虚的部分，也算是对过去的一个阶段总结。期间遇到过一些问题，也解决过一些问题，未来还会有新的问题。抬头，杏叶微黄，一切正当时。作者介绍田卫，转转中台研发工程师部分配图及参考资料：https://www.infoq.cn/profile/3CB3B1724F2E52/publishhttps://mp.weixin.qq.com/s/MJd9vVzPH_5YftavWOkPXwhttps://kimi.moonshot.cn/kimiplus-square想了解更多转转公司的业务实践，欢迎点击关注下方公众号：