系统中的接口规约一直以来我都认为是早在信息化系统建设的时候，就已经在全面的考虑的东西，因为很早以前，我们做系统开发的时候，都会调研各个业务方的现有系统，以及未来预期规划的系统，然后会依据现有系统和规划系统来设计数据接口规范，以保障系统数据在各个系统之间的传递。 当时在各种的信息化设计方案的时候，都会写到信息化系统的建立，为公司打破“数据孤岛”，实现数据共享、数据实时使用提供了有力支持 但是最近我和好几个信息化、数字化建设方、或是业务甲方进行沟通的时候，发现现实中的实际情况是很多系统依然是处于一个独立系统的状态，系统中的数据并不能对外共享，也没有接口可以调用，甚至多人都在问我有关数据接口的相关系统或是相关建设方案，我听后对此是否诧异，因此这里我特别分享一篇来分享关于信息化、数字化系统的接口规约的内容。
在数字化建设过程中，我们经常能听到很多人都在提数字化建设蓝图，这种蓝图的作用主要有几点：
其实可能大部分人对这种规划图看一眼就略过，因为大家都知道，规划是规划，建设是建设，可能建设完后，和这个规划上面的内容基本上80%的都不一样。但是其实这里就已经在对各个数字化系统的接口进行了规范，这里其实就应该甲方客户在系统接口规约的第一次确认。
在早年的信息化系统建设过程中，我们在系统设计中的接口规划是通过最早客户交流过程中，需求文件的业务描述来实现的。说到这里要是项目经验丰富的，或是一直关注我的朋友应该就能发现问题了，数字化的接口规划是在蓝图中的，但是在信息化建设过程中，接口规划一般在需求文件中描述，而需求文件是晚于蓝图规划的。这里其实就是我要特别来说的一个情况，其实就目前系统建设来说，数字化系统的建设无论从系统数量、系统复杂度、系统构建程度来说，都是要远高于信息化系统建设的，这也就是为什么数字化建设基本都会使用新技术去构建的原因，其实主要就是系统复杂度的问题。（这里的观点各位读者可以不认可，但是也不用喷我，因为我也不会认可你的观点）
这里再举个例子来说明，早年我在生物医药公司做开发的时候，开发的系统被称之为SCM（Supply Chain of Management）系统。但是现在来看，那个系统包含了ERP、MES、WMS、TMS、BI、QMS、以及少部分LIMS系统功能。这一个系统实现了从Quote 一直到 Shipping，最后直到 Charge Fee 的全部流程，如果交由现在的数字化方式来进行构建，必然会拆分成至少五到六个系统进行规划，拆分后，系统接口的必然成为必须规划的一个内容。但是在当在一个信息化系统构建的时候，我们的接口规划基本是在需求设计的时候进行，将接口作为需求的一部分进行描述，放在需求设计中，例如：SCM系统实现的接口就包括和SAP、CRM等系统的接口实现。
由上面这个过程可以看出，在信息化建设中，数据接口的设计被作为一种不是必须的客户需求业务进行处理，而在数字化建设过程中，数据接口是一种天然存在的属性，因为要设计、规划数字化的体系，必然要带有接口，也正是由于这种原因，当信息化建设过程中，由于建设人员水平不够、规划能力欠缺，同时对于公司后期信息化发展前景的不明确，就很容易设计出“数据孤岛”式的信息化系统。同时也因为客户甲方的对于未来信息系统规划也缺少预见性，或是并不清楚数据接口的重要性，因此更看重当下的功能使用， 从而不会对系统的数据接口有更多的建设要求。
依据上面所说，信息化系统中，早年接口的实现是将接口作为客户需求去处理，因此这种需求一般很少有架构和设计人员会将其设计为开放式、共享式、可管理式的。因为这个需要额外带来几倍于传统接口开发模式的工作量。并且甲方客户在可扩展性和未来规划不会有新的要求，所以建设方更不可能主动去为自己加更多的工作量，而且后期开发接口也是早年很多信息化系统做二次开发或是进一步创收的重要途径，更不可能主动去断了自己的财路；（在我第一份工作的时候，给烟草系统做信息化系统，那时候运维最主要的利润来源就是做数据分享，注意：这里还是还不是数据接口，是用数据分享的模式，就是我把数据导出给你，或是我告诉你怎么导出数据，并不开发功能，就这种数据分享的模式，报价的时候基本上以一条SQL十万的价格报价，而当时我一个月工资才两千多一点，这在当时的市场中是一种很普遍的现象），因此整体的信息化系统的接口建设工作就变成了几个方面博弈：我知道你不知道、我不知道，你也不知道、我知道你知道，但是你要表现的不知道。当然这种情况并不能长久的存在，后来客户渐渐的在需求调研阶段都会提出和现有系统做对接的需求，这也就是我前面说的信息化系统的建设中，接口的规划一般会放到需求调研阶段，作为开发需求去处理。 那时候比较常用的接口模式基本为WebService模式，其实WebService模式也都已经是客户明确提出接口需求后，研发部门做出的接口开发实现方式，这种方式使用XML作为描述方式，可以定义方法、动作、参数、数据等多种内容，在曾经的接口开发中极为流行。在更早的时候，接口的开发和实现基本都是采用文件的方式是最常见的。将系统中的数据定时生成数据文件，其他系统读取数据文件，然后依据数据文件进行解析，将数据接入到自己系统。数据文件共享的方式，在部分银行的核心系统，或是部分券商的交易系统中依然存在，因为这类系统通常是已经建设完成有二三十年，早期这类方式算是研发的标准方案。WebService的接口方式在目前很多系统中应该依然能看到，例如很多SAP的对外接口，还有我们曾接入辉瑞的供应商接口，也是采用WebService接口方式。
当数字化建设项目开始全面铺开，进行建设的时候，大家发现以前信息化的数据接口方式在目前数字化中显得力不从心，如：数字化建设中数据量会明显的成指数级别的增长，数据在不同系统直接的传递是基本要求，因此数据传输的实时性也是系统必备的能力，这样的需求之下，传统的信息化接口实现方式不能再继续被使用，这时候就提出了RESTful的接口方式逐步作为事实接口标准，现在各个系统对接的时候，大家基本上都会默认使用的RESTful的方式。但是数字化系统中大量的系统都通过接口方式相互调用，数据的交互已经成为基本功能，因此对于数据接口的管理、接口数据的传输等内容，提出了更高的管理性和运维的需求。我曾在《数字化建设（二）- 设计方案》中明确提出基础平台的建设内容，其中就包括ESB系统这种专门用于数据接口的系统的建设内容。这里ESB的出发点其实就是对于多个系统之间的管理性和运维需求，通过ESB系统，可以实现各个系统接口的管理化，可以了解到每个系统的接口内容等信息，同时也可以通过ESB系统实现接口数据的数据重发、数据映射等较为个性化的需求。 通过以上的内容实施，虽然在新建的数字化系统中基本已经实现接口的统一管理，但是对于老系统，或是对于早期的系统，或是部分并不具备这种接口能力的系统，又有了新的要求。这时候，在互联网行业中风行的数据中台方案被作为救命稻草，开始引入到各种数字化系统架构中。我当然知道数据中台在互联网行业中原本的出发点和应用方式，其实它原本是在实现一种开发和业务的变革，但是实际上可以去看引入所谓数据中台产品的厂商、公司、或是单位，他们数据中台的使用场景和出发点是不是就是我所说的不同系统数据共享？不只是数据中台产品，有相当一部分大数据平台，也都是作为数据接口的中间平台被引入到各个公司中使用的。因为大数据平台中的最重要的数据分析能力，需要极强的行业沉淀和业务属性支撑，绝大部分大数据平台公司能有几个行业内业务解决方案专家，不要说行业内解决方案专家，很多方案设计人员能懂客户的基本业务，已经算是合格的供应商，就这样上线的产品，能帮助客户做出什么核心业务的数据分析？早年很多大数据平台都是针对于电商、互联网风控等行业，是因为这类行业的模型、算法、监控内容都已经在各个互联网大厂中形成了固定的模式和统一的处理方案，所以被大数据平台拿来作为标准品进行销售。但是当这几个标准行业的客户已经趋于饱和之后，有部分大数据公司开始动歪脑筋，推出了所谓的针对于工业、制造业大数据分析平台，在极力鼓吹所谓的数据分析发现故障点、数据分析提效等概念，导致现在的很多的数据采集平台、MES系统、MOM都受到其影响，开始吹嘘所谓的数据分析能力，例如设备预测性维护，甚至有些客户在我们交流的时候，都会提到所谓的设备预测性维护，这种不切实际的扯淡概念真是让我们深受其害。这里我简单来说一下设备预测性维护的内容，我就不说那些非标设备，就说最简单、最常见的CNC加工机床。CNC加工机床中，加工过程中刀片断裂是一种很常见的故障，如果要实现预测性维护，目前业务比较常用的是几种刀片监测方案：声纹、振动、超声波。这三种方案面临的问题都是基准数据需要大量的标准数据输入，然后训练模型以得到标准，就这个过程基本上都是需要不断的投入研发人员、业务专家、生产专家等多种人员，才有可能得到一个较为稳定的、可用的预测性维护方案；这还是最常见的设备，算是已经有很多人已经趟过无数次路后做出来的标准方案，有很多设备，例如我们为某企业服务的设备，这类设备都是采用工控机+电气、电力仪表设备作为其生产设备，所谓的设备预测性维护连方案都编不出来。但是很多产品上来就说自己做设备预测性维护，这就是数字化公司的外行销售在忽悠一个企业外行数字化部门的准确体现。但是大数据产品买了就要有实用，因此很多大数据平台的第一步都会将各个系统的数据通过接口方式接入，接入之后，将数据进行沉淀，然后在其他系统需要的时候，再将数据分享出去，这样看来，似乎显得这种大数据平台也是很有作用，但是实际来看，这种在实际业务中的能力和它所应承担的业务能力基本上没什么关系。 上面都扯远了，我们回到数据接口的正题。总结一下，数字化建设中，整体的接口方案在各种系统和配合，以及多种中间件系统的加持下，一般形成如下的解决方案：
前面两个章节我们介绍了接口的规划和接口的实现，在本章中，我们就针对上面的所将的内容，做出一份完整接口规约方案，方便客户在要求供应商，或是建设方内容进行设计和规划的时候，作为参考内容。在我们设计系统的时候，接口我们一直是作为很重要的一部分设计内容来处理，这部分内容我也曾在《信息化、数字化系统设计原则》文章中进行描述，这里我就将当时的设计原则进行细化描述。一般我们设计系统接口的时候，会考虑以下几点：
接口管理细化，其本质是为管理、运维人员提供功能支撑，在接口管理细化中，要求所有的系统接口信息都可以在系统中明确获知，接口信息内容包括系统有哪些接口在提供数据，接口的使用方式谁，以及可以提供功能随时将超出范围，或是未规划的接口进行停用和删除。
接口协议细化要求系统中提供的所有接口内容协议内容必须准确可靠，协议内容包括提供数据的方式，提供数据的格式、提供接口的数据内容、字段、以及数据含义，同时可以明确的确认接口为不同系统共享数据的内容，如多个系统共享一个接口，每个系统是否是有获取相同的数据内容。
接口审计细化是接口安全性的一个基础保障，也出现接口数据安全后，回溯、调查数据范围、评估数据影响的重要途径。在这一个设计中，在接口可以看到每次的数据数据调用、数据分享、数据传输的详细内容，包括数据的时间和对方系统的实时响应数据。通过此功能设计，帮助运维人员随时监控敏感数据、保密数据的扩散范围，对数据安全做出及时的调整和汇报。
接口安全性保障一直以来我认为是一个基础性的要求，因为无限制的使用接口数据在任何一个场景来说似乎都无法想象。但是实际上这么多年项目的场景告诉我，接口的安全保障性在绝大部分项目中都为零，尤其是在公司内部使用系统中，绝大部分的系统都是在“裸奔”。这样说起来总是有很多的开发人员、设计人员都会说那是因为你遇到的公司不专业等等。其实实际上这么多项目来说，合作过的厂商大大小小也有上百家了，绝大部分在都会将接口安全性作为一个可有可无的选项。或许这样就能理解出现这种现象问题的原因。当你只和一个系统做对接的时候，如果对方OAuth2的接口权限校验方案，你可能会说这是标准的对接验证方案，还夸人家做的规范。但是当你系统的上游系统有十几个，下游系统也有十几个的时候，就算都是OAuth2的权限校验方案，你可能都会有点抓狂的心态，而实际项目中，全都是这种校验方案基本是不可能的，不同的项目肯定是有不同的校验方案，也就意味着你要实现多种校验方案，但是这时候，总设计告诉你，要不我们取消接口安全校验吧，反正系统部署于客户内外，不能对外开放，你是不是觉得这简直是你的救命恩人？ 但是在我的设计方案中，我会将接口安全性保障作为一个基础必备的设计存在，除非有客户明确的告知，否则我一定需要基础的安全校验。我一个朋友在某公司做开发，他们公司早年开发的产品本意是要求部署到医院内网中， 不对外开放，因此数据接口并未做安全性校验。然后实际上销售、现场实施在项目实施过程中，只要有客户需求，随意部署，很多都部署在外网。这些系统已经运行十多年，已经不知道有多少系统和他们系统做了集成，然而今年发生了重大安全事件，因为被某医院发现他们系统多年来数据接口未做任何的安全防护，病人数据已经不知道丢失多少，要求他们立刻修复问题。但是实际上可以看出，其实没有修复的可能，因为他们系统自己都不知道有多少系统做了接口，他们一旦加入权限，预计用了他们系统的医院有科室的业务直接全部停摆，这是不可想像的。
接口运维系统是接口设计中，一定要考虑到公司、企业的运维人员需求，这些运维人员是系统接口管理部分的最终使用人员，因此需要对他们的运维需求得以满足。例如：可以对接口的错误数据进行监测，提供重发、漏发监测、补发等接口运维功能。
接口数据范围细化是应对于数据安全、数据管控要求最有效的手段。当对接口数据有数据安全是需求的时候，需要将数据范围、数据内容划分为不同的安全等级，或是对数据内容做到数据部分隔离，这部分的功能需求都需要对接口数据的范围进行细化。这一点在很多ESB平台、数据中台产品中都未体现，某些数据管控平台到时已经注意到这种情况，提供了数据接口范围细化功能。我们系统在设计过程中，也是通过是接口数据范围细化的设计加上接口审计的细化，这两部分功能共同为客户提供数据管控服务。
数据稳定性保障算是最为基础的保障功能了，虽然基础，但是在实际项目过程中，开发人员、设计人员在此功能的设计中并未投入过多的设计和开发考量，导致接口稳定性并不高。以最简单接口数据传递为例，大部分设计人员仅仅会将接口作为业务数据的一种输入方式，并不会做额外的设计，但是实际上，接口的数据模式和客户输入的方式有明显差异，最简单如：数据量、数据处理能力的差异。因此我们常常会看到这样的情况，当接口数据一旦超过一定的数据量，业务系统的处理能力会跟不上，从而出现各种卡死、响应缓慢、甚至无响应的情况。这种情况大部分都会被开发人员或是设计人员以数据量多、情况偶尔出现的说辞略过而不处理。这就是典型的接口稳定性问题。其实也很容易理解这类行为，为了这种偶尔出现的数据情况，需要做出的开发工作量会明显高于其直接将数据传入业务系统的开发方式，但是获得效益也并不能得到客户的认可，因此开发人员、设计人员都会在这方面能省则省。我们在设计的过程中，一般会直接要求设计人员将这种情况在设计中避免，不给开发人员有选择的权利，通过设计方案约束，直接提高接口稳定性。
接口扩展性基本上目前绝大部分系统都不会考虑。因为这部分功能完全是吃力不讨好，客户不认可，设计人员、开发人员白白浪费的工作量。更主要的是，从公司的角度来说，接口扩展开发是自己系统运维的一个重要的收入来源，而且在一定程度上还是限制客户更换运维商的手段，无论从哪种角度来说，做接口扩展性完全是吃力不讨好的事情。 其实我们在设计系统的时候，接口扩展性也是作为隐藏功能，交由公司内部的人员使用，也不会交给客户直接使用。但是我这里依然将接口扩展性作为一个规约，是希望设计人员、架构人员在设计的过程中，需要对这个点也需要有所考量，不一定要交给客户直接使用，但是提前考虑扩展性需求，对后期系统降低接口扩展的复杂度和开发工作量，都有着明显的好处。因为如果真的客户愿意花钱给你让你做接口扩展，你总不能整个接口重新再开发一遍吧，这种架构和设计方案也太差、太不稳定了吧。
信息化、数字化系统的接口在系统建设过程中一直是一个边缘性的存在，大部分架构和设计人员并不会在这方面花费太多的精力，在实际项目中，也多半是交由开发人员自行发挥即可。但是我们在实际项目中可以看到，现在在数字化建设过程中，接口交互已经变成了一种基本数据交换能力，如果依然使用早年信息化系统建设的思路，数字化系统稳定性、扩展性、运维性，以及数据的安全性等都受到挑战，因此我们可以对数据接口的架构和设计内容给一下关注，以提高自己产品的稳定性，毕竟产品稳定，大家才能避免大部分时间花在无意义的修复数据工作上。
