聊下如何设计知识中台？（附代码）

Posted 2022-11-05 风清扬逍遥子

        关于中台的概念，现在已经烂大街了。大多数都以为随便几个微服务整一整，对外就号称中台。但中台到底是什么？做好中台需要具备哪些能力？今天我们就来聊一聊中台，并且拿我的正在做的知识管理系统，演化成知识中台，是怎样的一个构思，以及往长远的发展，中台为企业带来了什么。

1、中台简介

        可以一句话简单描述，就是为了组件复用，也可以称为功能的复用。而放大了说，企业中台是为了让组织，资源，能力，业务，等等实现统一建设，沉淀，而反向为企业本身创造更大的收益。往小了说，企业在每个业务条线中，为了实现某个业务场景，会对某个重复功能，做重复设计等开发的重复工作量，而这个效果不一定有已经现成实现的效果好，当然也不一定说是目前现有的就做的很不错了，可以达到各个业务条线使用的指标。譬如：一个电商公司，所有的系统都要给用户发消息，如果每个业务条线如支付，订单，采购，IC（商品中台），会员，金融等事业部门都要自行实现消息发送的话，成本会非常的高，那么就专门有了一个系统，或者是专门的一个功能组件，来实现业务发消息这个功能复用。那么当这些组件，都一个一个布施在一套整体的平台，对外或对内输出他的能力减少重复工作，为建设企业赋能的东西，就是中台，这里强调的是“业务中台”  。

2、企业转型中台需要准备什么

        有人说，微服务不就搞定了这个事情了？如果对技术了解不深，一定会把中台和微服务混淆，并且会经常在任何地方都毫不夸张的跟风中台的一些落地，而市面上的大多数公司会因为这些不熟悉真正中台的理论帝的指引，导致了很多公司在转型面临各种问题，甚至如果成本不够，经验不足，公司整体技术水平无法提升一个层次，那么每个业务条线是无法做到这样的事情，甚至已经有很多公司转型失败而垮掉。大部分直接看到的原因是方法的错误，用老的方法解决不了新问题，要用新方法解决旧问题，因为战略、中台、人才的脱节导致了失败，战略是把业务的分散问题集中转化成一个可以通过中台能力去解决的问题；中台是将企业的公共资源整合，并开放出来，解决这些业务的问题；人才是在有了中台，也知道目标问题是什么，然后明确用怎样的组织能力配备什么样的人才来解决问题。

        中台概念一出来，随后阿里出了一篇文章《阿里彻底拆中台》，不得不否认这些技术的引领公司，在全面实现中台化的过程中，即使拥有了几十年的修行，也曾摔的体无完肤，也曾大换血过，都在往数字化转型成功的方向去走，我们作为“跟风着”，要看到这些转型失败的教训，借鉴和汲取经验，起码，这些企业是巨头领先着，无论业务条线和方向是否相同，遇到的失败场景大多数是一致的。阿里中台战略在被提出之前，已经做了7、8年服务化，中台战略提出后，又做了5年的组织、技术、业务层面的变革。对于普通的公司要转型中台，道路要走的稳是不可缺少的，需要配备专门技术人才，需要对业务条线的清晰掌控，需要对未来模块的发展方向有战略定位，非短时间可以达成的效果，即使达成了，也非中台，而是服务中心化；转中台的过程中，如果企业自身没有考虑到组织能力问题，就功能谈功能、就架构谈架构，没有考虑公司面对中台问题应该要角度多元化，没有考虑到协同人才体系建设，会导致中台对一个组织的要求过高，人才没有跟上，也会引起转型失败，这些都需要考虑进来。

3、为什么要做知识中台

        因为每个企业急需建立全新的信息和知识处理平台，以智能化的手段推动数据转换为知识，支撑企业创新业务的快速落地和迭代。这也是企业往数字化转型的必须，要整合这些数据，数字，信息，资源，来快速形成知识数据能力服务市场。

        现如今我们在实现知识管理过程中面临很多的问题，其中不乏重复建设，数据利用率低，数据形态复杂以及应用多态问题，后期将产生数据海量，数据解构等问题要解决；

• 重复建设：

        从技术角度来说，对外提供基础服务的api，接口，前后端组件实际上很难被其他业务模块直接去使用，例如：业务需求多样性。调用方在自己需求不明确的情况下，由于快速交付我们就会输出其需要的接口能力，或是组件能力，一旦其他业务条线发现这个接口不适合他们，而转向需要xxx，那么只要输出的业务条线越多，这种差异化会越来越大，慢慢这个能力就会变得不是灵活，而是难用而重；甚至可能会和不属于自身的业务耦合起来，此时已经偏离了自身核心能力的定位，而身在其中的人员却不会关心这些，说白了，就是没有抽象思维和中台思维。

        从业务角度来说，技术是业务的实现方式，多数场景下，提供方是不会去深入了解需求方的业务需求，如果需求方业务不够清晰导致这个业务多变，现有的业务组件已经太重不可满足，从而导致这个业务组件自身要会重复设计，要么为了快速交付，显然重新新做一个组件，可以理解为之前的重复组件简化版，成本要低的多。

        解决方案：上述问题出现的情况，真实的核心问题，就是人才和组织能力没有做好适配，快速交付一定是当前市场的主流，好的公司快速交付的质量也是不一样的，根源在于如何进行业务的设计，需要交给专门的人员处理，分析，调研，非1-2天可以达成；提供的能力要划分边界，其实就和DDD的思想雷同，用业务边界划分好领域，把核心定位搞清楚，不可一昧满足业务条线而破坏本身抽象化的能力，面对这些复杂的业务场景，区分核心抽象组件和需求变化组件可以解决通用问题。

        如：文件上传，本身就是一个上传的能力，而需求会成为，上传后进行生成文档，提醒消息，与业务模块交互，赋权限等等的A，B，C操作，其实这些都已经偏离了文件上传本身的职责能力；对于这些和业务无关的能力，和我们无关的行为我们可以不关注，但是要更加能清晰的去认识到有多少需求会类似这样业务行为，如果我们把这个需求划清，就应该成为核心本身职责和对外交互职责，通过技术手段抽象好核心职责能力，对于对外交互职责，我只需要在组件中，放出很多行为接口（甚至可以不需要放和和本身职责无关的钩子行为），当核心能力由业务模块使用完成后，统一去实现要去进行下一步交互行为的逻辑；这一部分逻辑，本身和核心职责无关的这一部分我们不做更改和提供，实际上这步就是在确定领域模型的边界。

• 数据利用率低

        知识管理中很多来自业务的数据，从物理上是集中化，但是数据本身呈现碎片化、孤岛化的特点，存在大量冗余和无溯源的数据，这些数据可能因为一些历史数据或者阶段设计问题，用传统的数据处理技术难以对这些数据和信息进行语义化的理解，导致数据的利用率低下。

        拿现有的数据举例子，在知识中台对外输出业务能力的过程中，会有来自很多业务条线数据归集于此，譬如：业务模块中文件上传下载、文档附件的赋权、业务数据形成文档或者附件集中存放等这些数据目前作用服务业务模块，而这些数据本身，却无法在知识本身充分利用起来，甚至会有冗余数据，无法追溯。而这些数据目前只是为业务条线服务，产生了每类数据的碎片化，比如流程中流转的附件信息，日报中上传的附件，流程转文档生成的文档信息，业务模块对文档或者赋权数据等，未来会有更多类型的数据归集进来。乍一看来，都在呈现碎片化，而通过知识中台，可以很好的把这些已经归类好的数据，通过没类数据的特性，抽取出来成为共性，形成一个新的能力，可以是智能推荐能力，智能检索能力，知识聚合等这块还有待思考。

• 数据形态复杂

        未来知识管理业务发展中会有音频，视频，多种文本等各种结构和非结构化的数据都作为信息，存储到知识中台，那这些数据形态多样化，结构多样，不仅需要打通孤岛，使其不仅可以作为模块追溯业务的依据，作为知识本身，还需要对这些数据进行语义化的分析，重新利用服务于用户，再通过构建业务场景反过来服务于业务模块，知识中台需要具备这部分的能力。形成的能力可以有文件检测，语音识别，知识挖掘，知识图谱等。

• 数据海量

        企业在数字化的过程中，产生体量巨大的数据会存入知识管理，且数据规模不断极速增长，传统IT架构已无法应对，就需要有可以支撑的技术中台和数据中台作为底层基础设施，把海量数据支撑起来，进行分析，支持多维检索，维持中台的稳定性；并且在海量数据的基础上，支持将数据归集在业务中台，构建成一个一个的知识应用。

4、知识中台整体架构设计

        上述可以看到的问题，应当建设一个知识中台，对现阶段的每个问题分析，知识中台是否可以很好的解决，以及面对未来的数字化转型，中台整体如何设计，又提供了哪些能力，为企业赋能？

        业务中台首先要为当下生产的组件形成对外开放，可复用能力建立统一平台，制定业务中台组件输出标准，对业务数据聚合分类，为后面的快速构建智能化应用打下坚定基础。 当业务条线需要用到业务组件能力，业务中台会提供相关的业务组件，比如上传下载组件，文档比对组件，内容检测组件，智能搜索组件等，这些是架设在技术中台之上的业务封装，做通用化和场景化的组件。

        技术中台为业务中台提供技术服务，其中包括微服务相关的组件，譬如熔断降级组件保证只是中台多个服务之间高可用，分布式定时任务管理xxl-job对分布式服务统一管理定时任务和调度，对象存储、分布式存储和私有化存储技术对接提供物理数据落地和管理。ELK服务支持全文检索，加速效率和检索精度，自研分词算法和NLP技术结合形成智能化推荐能力等等。当业务模块需要使用技术组件能力，技术中台会提供对应的对接使用说明文档，前后端组件或接口能力，和mock平台，由业务模块去做调用验证，当然平台会具有一定的数据安全校验和身份校验。

        数据中台为整个知识中台提供数据大盘保证，性能监控和预警，对服务的稳定性做好必备保证，同时数据中台还可以为业务中台提供必要的数据能力，如海量数据的知识挖掘，知识图谱的构建等，进而输出到业务中台。

        所以我打算建立的知识中台，其中包括知识业务中台，技术中台和数据中台，实际上数据中台可以和业务中台融合一起，而底层架设的是知识技术中台，帮助上层实现这些组件的输出。对于业务条线需要用到的技术能力，由技术中台提供统一基础支持。

        对此我构建了一个目前的知识管理整体设计框架图：

      

        而这样的架构，熟悉的人很清楚，就是我们当前主流的微服务架构，而微服务不等于中台，上面也有提到过，那么如果要做成中台架构的设计，需要整体发生变化，将目前这些服务，能力抽成中台，由中台统一输出，并且在和业务条线交互，也和传统的服务交互不同，中台讲究更加灵活，职责单一，低耦合高效产出复用能力。

        转型中台后架构演变图：

5、如何快速构建一个知识中台

代码构建中...后面会贴出来

6、企业转型中台会带来哪些好处？

        从企业发展的眼光看中台，传统行业如果往中台转型，会有以下方面的好处：

6.1、避免浪费资源

对于企业来说，各业务部门无需重复造轮子，不论是技术组件还是业务组件，都可以大大降低重复建设的成本，实现数据的价值化，可以做到开箱即用，应对多业务开发，即使项目需求相似，数据大致差不多，可以在原有的组件做封装而减少人力成本，实现敏捷交付。

6.2、快速响应减少业务冲突

对传统的行业来说，期望快速响应用户需求，实现低成本的快速迭代，而后台为了支撑前台业务不断填充新的功能，从而变得日益臃肿，还叠加了很多复杂且交叉的业务逻辑。建设中台后，会减少业务上的冲突，将各组件抽成单一化，统一提供职责分明且单一的能力，对于后续的迭代扩展，都会大大减少业务冲突而增加效率。

6.3、提示企业的组织能力

中台实际上更是一种企业的战略，中台对公司是资产，不是资源，并不会仅仅作用在产品维度，会涉及资源分布，以及协作问题，把各个业务的支撑职能剥离一部分集中到统一的地方进行建设，中台在做业务支撑的同时，更多需要做的是沉淀的事情。这些沉淀，可能是系统，可能是流程，可能是经验，可能是人，这些都不随着一个个项目消失，会变为公司重要的资产。对公司未来做重大的战略决策，中台起到一定的作用。

6.4、提升大效率

为什么说是大效率呢，是因为更多时候，我们看的是单一维度的效率，例如某个项目、某个产品的收益。但实际上中台很多投入是不能这样衡量的，需要从空间和时间两个维度来看。

空间呢，就是说中台很多的项目投入，不直接作用于业务，可能看着像是中台自己搞了一个东西，但是最终业务还因此而收益。

而时间呢，有时候中台做的东西有一些前置储备，短时间可能无法发挥明显效率作用，但是拉长到长期，对企业确实有效的。

总的来说，中台的好处，一定是基于长远的，而短期的收益效果其实并不显著，对转型中台的企业，尤其传统行业在数字化转型期间，转型中台前期却要付出很大的成本。

6.5、多应对平台复杂对接

企业业务数据存储多样化，分散在企业数据湖，业务系统等多个平台。技术栈也比较多样，CDH/HDP，Hadoop平台，Oracle等关系数据库。不同的数据应用平台，如大屏、自定义报表等，需每个团队单独开发应用对接多种不同的数据平台。如果针对每个需求都开发不同的接口和API开发和管理工作量复杂，后期维护成本非常高，而对于中台来说，解决了重复建设问题后，对于不同的平台，中台可以做到中转服务，也可以作为直接服务提供数据和业务对接。

7、企业转型中台面临的问题？

7.1、中台是核心中枢，中台人做事情要有强烈责任心和专业性

中台的架构，将业务的能力实现，由之前的闭环，变为了现在的业务+中台共同完成。再完美的协作机制，也不可能解决所有的问题，而这时候，就必须发挥人的作用，来进行“灰色地带”的补位。业务BP角色就是中台主动补位的体现，他对整个业务的把控要具备足够专业且过硬素质的水平。

同时，中枢灵活、高效、稳定的要求，让我们深感责任重大，而想要做好这几点，就需要中台人的专业性。所以一般上中台核心岗位的要求是较高的，在工作资历和招聘难度上都有体现，非一般的人员可以直接上手，从技术设计上，也需要比较资深的行业专家对中台技术和业务的设计。

7.2、中台人需要很强自驱性和灵活思辨能力

这对企业中台的发展整体素质的要求就非常的高，每个企业做中台的路是不一样，应对问题的复杂度的解决方案，也不一样，如果中台人员不具备这样的思维和强驱动性，那么中台只会大大消耗企业的成本，并且设计的不尽人意。

7.3、中台不能做所有的需求，有限的资源一定要发挥最大的价值

作为中台，时常要面对数以百计的业务需求。这些需求我们都能满足么？当然不是。中台资源一定是有限的，尽管可能中台规模很大，但你相对的业务需求也一定会更多。

所以，中台是做不完所有需求的，肯定需要对需求做取舍，常规的做法就是价值判断+阻断性判断。价值判断很好理解，就是做公司战略导向的、重要业务的重要项目，这样才能实现最大化的ROI。而阻断性判断，就是说当业务已接入中台的情况下，那怕业务不是非常重要，那中台也尽可能需要保证一些对业务有阻断性的能力支持，不让业务停滞。而其他的需求，能业务闭环的，尽量让业务自己闭环。

这样的原则，肯定会让一些业务感到“不平等”，比如为什么这个业务能做，这个不能做，但是这个可能就是一个天然矛盾，尤其是中台本身带宽较窄，不能有较大空间腾挪的时候。而解决这个矛盾，除了要保持良好的沟通之外，更多还需要靠一些对称机制将矛盾转移出去。

7.4、中台是一种组织形式，涉及资源分布，以及协作问题，需要公司CEO、CTO决策并坚持

做中台，除了说业务形态要满足以上要求之外，还需要另外一个关键点，那就是需要公司一把手、二把手做决策。

因为中台架构，本身就是一种组织形式，把各个业务的支撑职能剥离一部分集中到统一的地方进行建设，所以核心还涉及到资源分布分配的问题。那自然，就会延伸出协作的问题，业务与中台的协作，必然没有业务内部协作来得那么得心应手。中台难点，也恰恰更多都是来自于这个问题。

7.5、中台构建中会产生的矛盾点

• 各业务需求实现优先级的矛盾
• 业务与中台职责边界的矛盾
• 中台在业务需求与自身建设资源分配的矛盾
• 短期价值与长期价值的矛盾
• 空间时间原因，衡量价值难度较大的矛盾
• 中台驱动整体有益但局部无收益的矛盾
• 中台资源瓶颈与复杂功能排期长，造成业务黑盒理解的矛盾
• 业务中台协作中owner意识的矛盾

这些矛盾，会给业务与中台双方日常工作带来很多难点，而这些难点其实就是中台发展要解决的最大事情，其实等于，企业前期要构建好一个中台，付出的成本一定是比较大的，所以一般的企业，可能经不起这样完，也需要一定的技术，数据，业务的战略文化的沉淀。评估下来，还得再斟酌斟酌。

评论区欢迎补充和指正！