“在云原生环境下通常一个企业业务流程由多个微服务共同组成，比如商城、会员、订货、零售、基础服务、OMS、API查询等等。如果每一个微服务需要占用8G内存，10个微服务就是80G，占用的计算资源就太大了。”用友网络YonBIP开发总监肖静提到了一个很少见诸于媒体的技术名词——“元数据驱动”。
依照肖静的说法，只有元数据驱动，才能让这些微服务动态共享地调用计算资源，在面向多域多例的企业应用时形成紧耦合，提升计算效率；不仅如此，只有基于大量最佳实践封装了的元数据驱动模型，才能让低代码或无代码真正高效发挥作用。
这几句话或许在IT男肖静看来，是最通俗易懂的解释了，然而对于笔者这样一个编程门外汉来说，仍然太过生涩。笔者忽然想起来最近在陪上小学的儿子学编程，他学的其实就是无代码、搭积木式的编程方法，或许能够帮助我们更直观地理解什么是元数据驱动。
元数据驱动
让无代码编程成为现实
小时候，谁都玩过搭积木。其实无代码编程就和搭积木差不多，只不过组成积木的是“当”xx被xx”，或者“如果xx否则xx”，“重复执行”，“保持等待直到xx”等隐含着代码的逻辑指令，孩子们需要的仅仅是“编”。
实际上，“编程”这个词是由编和程两个字组成的，和“编书”、“编故事”没啥区别，因为“编”就代表着一种逻辑。
荷兰计算机科学家、图灵奖获得者EdsgerWybeDijkstra说过一句话：“我们使用的工具影响着我们的思维方式和思维习惯，从而也将深刻地影响我们的思维能力”。
很显然，用英语写出来的编程语言作为一个工具不仅对于中国人太难了，即便对于英语是母语的人来说，也并非易事。因为只有图形化、积木化的无代码开发工具，才能让每一个普通人真正把全部精力用于思考业务的流程逻辑，才能在企业数字化转型和IT进入社会化创新时代的今天，最大化发挥创新力。
换句话说，如今的企业数字化转型不仅是要把企业内部各系统间的数据打通，而且还要引入各种企业外的数据，包括供应链上下游和社会化的数据，来进行实时的运营分析，来支持企业的管理和辅助决策。对于数字时代企业信息系统的构建来说，实际上就是从传统ERP拓展到BIP社会化商业创新平台的过程。
然而，数据采集范围扩大了，数据来源增多了，对于IT系统技术架构来说，社会级应用意味着需要依靠新的云原生架构，在其基础上部署和运行多方基于云原生和容器化的微服务，才能够为企业带来真正的数据和业务闭环。
这时候，IT技术架构就回到了文章开篇所讨论到的问题：如何降低多方开发的多个微服务共同组成的业务应用的计算资源负载？如何让微服务间的松耦合变成动态紧耦合，来提升计算效率？答案是，构成同一个企业业务应用的微服务需要在同一套规则下编写，也就是说，构成各个微服务的“积木”，需要统一，而这些“积木”，就是“元数据模型”。
肖静举了个直观的例子，就像雷神山、医院，它不再用传统的水泥、沙子、钢筋盖楼，而是框架式的，还支持灵活配置，因此施工速度大大提高了。
元数据驱动
是构建微服务的能力
“其实MDD元数据驱动本身属于APaaS，是应用平台或者业务中台能力。云原生属于GPaaS，是技术中台的能力。元数据驱动对应的是开发框架，即模型驱动开发和元数据动态建模。”肖静解释说，“用友做了大量最佳实践模型的封装，从对应的领域层、业务层一直到视图模型层和UI层，形成了用友iuap5.0业务中台里面快速支撑业务应用构建的能力。”
实际上，iuap平台最早脱胎于用友NC自身的开发平台UAP——UnifiedApplicationPlatform，即统一应用平台。年发布的iuap3.0，虽然在服务客户方面与UAP有一脉相承的地方，但实际上已经是一个完全重写代码的基于互联网架构的平台。
而最新的iuap5.0，更是完全基于云原生架构重写的新一代PaaS，包括了技术平台、数据中台、智能中台及业务中台，为企业提供了中台化构建能力、多云环境下的混合云开放集成互联互通能力、技术普惠化下的低代码开发和数智能力、自助应用快速构建能力，支撑企业服务产业生态伙伴共享共创，实现数字企业的智能服务。
“我们从年开始做用友云的终端云服务套件YonSuite，当时定位我们先把对应的财务、供应链和制造三个领域的产品，包括数字化建模、财务的收付、总账、固定资产、存额核算、进销存，以及生产订单、物料清单等十几个模块用对应的元数据驱动引擎进行对应的应用构建。”肖静回忆说。
应该说，元数据驱动并不是一个新概念，因为元数据模型实际上就是积木式的封装模块，但以前的元数据的驱动引擎是放在虚机环境下的，主要是单域单例，满足不了今天社会化应用需要对应多个数据库实例的需求。
“在对应的云原生、微服务下，我们把每一个领域下的应用拆成一个服务，那它就是一个域；每一个域我们为了保证服务的独立性，就要单独的实例。”肖静解释说，“要让服务之间不受对应的各种资源互相之间进行冲突，保证独立性、隔离性，就必须全新开发支撑多域多例的元数据驱动引擎。”
据悉，无论是Salesforce还是其它友商的元数据驱动，大部分还没有对应到微服务架构下的多域多例模式；即便少数对应了多域多例，也只停留在领域层，极少部分到了业务逻辑层，但覆盖到UI和视图模型层的应该只有用友一家。
“我们不仅封装了大量的前端模型，而且对驱动引擎做了彻底的云原生微服务的改造。”肖静表示，“用友今天的元数据驱动引擎，是我们将企业应用服务进行了一系列的微服务解耦，对每个服务进行数据库实例独享，并且进行了大量的验证，填平了无数的坑，是真正的自研自创。”
元数据驱动
是BIP赋能生态的底层逻辑
我们知道，传统的ERP对于企业来说主要是业务支撑和管控，把企业内部的人财物打通，以流程为中心进行驱动，在适应变化的灵活性上有一定的局限性；而今天的商业环境需要企业快速应变，需要企业通过在线的运营服务和客户保持黏性，需要利用在线产生的数据，通过算法和模型，优化和快速迭代服务。
换句话说，数智化时代，企业必然以数据驱动为核心，进行商业化创新。这中间，企业需要一个商业创新平台，协同企业内部、企业外部，以及社会化商业线索，进行便捷、快速和高效地开发和部署应用。
在这样一个大环境下，用友YonBIP应运而生。因而YonBIP不只是一个工具化的商业操作系统，更是全生命周期的多元综合服务体。实际上，YonBIP是用友及生态整体业务的统一平台，而iuap5.0则是YonBIP的技术支撑底座。
很显然，iuap5.0需要承载的上层应用极其复杂，同时iuap5.0又需要让生态伙伴能够很方便地上手进行面向各个业务场景的个性化开发和各个领域的定制开发，因为YonBIP需要通过平台服务和运营，赋能生态伙伴，与生态ISV合作创新，服务于更多的行业客户。
这，就是YonBuilder低代码开发平台以及元数据驱动引擎和模型的意义所在。
有了这样的业务需求，肖静和他的同事们没有退路。肖静举了一个例子：“早期做云服务，PC写PC的，移动写移动的，没有视图模型层。而现在的架构是组件化开发，在对应的运行态、部署态要做到服务的可分可合，对应的业务逻辑、计算模型必须视为同一份，因此我们在元数据驱动开发框架里面，每一层的视图模型、业务逻辑、领域模型都要完全一致才能做到多端应用在模型层的统一，而且还要保障独立服务的资源扩容的高可用。”
这一番话说起来简单，但实现起来，会遇到各式各样的问题。“比如OLTP、OLAP对应分析查询，我们就选择了很多条路；比如微服务架构拆分完之后的事务一致性问题，实际上有非常多的攻坚点，我们需要一个一个去攻坚。”肖静解释说，“当我们真正把大量对应的能力，高度封装集成形成这套开发框架之后，用友iuap5.0业务中台就具备了快速支撑业务应用构建的能力，业务的开发配置就变得极其简单——像YonSuite1.0采用这套框架建模，从立项到发版只花了半年多的时间，而以前没有三年时间是做不出来的。”
肖静对用友的技术架构如数家珍，这也难怪，因为今年已经是他在用友的第18个年头。作为一个有着近20年码农经历的典型技术男，肖静的日常穿着普通得不能再普通：一件黑色套头衫、一条牛仔裤。然而让人没想到的是，这件印着BIP和OD（over
联系电话：