随着数字化的发展，企业内部聚集的IT系统越来越多，各系统之间往往彼此独立，但业务又需要许多相互关联的系统共同组成或推动。此时，API 作为各业务系统的看门人和连接器发挥着关键作用，能够实现更灵活、敏捷、轻量级的系统和业务的连接和集成。这也使得针对 API 的管理与集成编排，成为几乎每个组织在数字化转型过程中的重要课题。
API主导的B2B集成指的是使用各种API（应用程序接口）集成不同B2B系统和流程的现代化集成方式。这种架构风格侧重于将复杂的系统分解成可重复使用的、可管理的各种API来进行集成方案的设计。
01 API与EDI
EDI是一种批量、异步的数据交互技术。而API恰恰相反，能即时对数据进行更新和响应，支持实时的交互。以API为驱动的集成能帮助企业与贸易伙伴实时同步数据，实现流程可视化，促进相互协作，提升运营效率，从而更快做出业务决策。
API主导的B2B集成特别强调了使用API作为建立跨企业连接和系统集成的主要机制，是一种强化B2B集成的战略方法。
通过消除点对点的集成增强集中式集成。API主导的B2B集成优先建立一个抽取底层系统的API层，满足标准化通讯和数据交互。这种集成方式带来诸多优势，比如通过系统、应用程序和贸易伙伴集成增加灵活性、可扩展性以及可重用性。
在线上零售领域，标准的EDI传输，如采购订单、到货通知、发票、订单确认等业务数据的交互通常是贸易伙伴间使用最频繁的。通过API无缝集成EDI数据和电商平台，零售商能够获得产品信息的有效同步，实时更新的库存以及订单追踪。API和EDI技术结合的集成场景为线上零售用户提供了精确、更新的信息，优化客户体验。
当今，大型线上零售商如亚马逊、沃尔玛等在传统EDI
02 API究竟有什么价值？
例如，开发人员通过使用一体化API全生命周期管理，能够了解和分析整套 API和 Web 服务，最大化提高团队的工作效率；API能够推动新应用程序的快速落地，满足客户的业务创新需求；API可以作为商品进行发布与交易，帮助企业构建新的变现渠道等。
API已成为企业业务的创新收割器、商业生态的连接纽带。作为企业整体战略的重要组成部分，API战略是决定企业是否可以引领未来市场的必要条件，其推进也将是一个长期持续的艰巨任务。
激活：如何最高效地激活API价值？
根据CIO需求场景、管理与运营痛点，实现API管理与集成编排这两大核心能力，从而支持应用程序、数据和各种业务交互能力，能够极大推动企业API战略落地，加速企业向数字化转型。
基于API化解耦、微服务化、能力化的三层架构设计理念，通过API全生命周期管理和应用集成编排能力，帮助企业零代码实现数据、应用、系统的快速连接和敏捷集成，实现IT业务系统之间的整合、复用、开放和共享，赋能企业业务创新与数字化转型。
03 API功能设计，提供4大能力中心
设计中心
轻量级的低代码API开发系统，通过插件化无代码或低代码，实现业务数据的快速服务化发布，并通过API网关发布给第三方业务系统或企事业单位进行调用。系统可以通过多种手段快速发布API服务，从而提升客户现有数据共享和交换效率，同时降低API服务的开发成本
管理中心
提供以RESTful API为主的设计、创建、测试、版本控制、部署、集成、管理、运维、下线等API全生命周期管理，从而帮助企业获得运营洞察，进一步优化流程、改进产品与服务模式，提高企业商业价值
监控中心
作为整个数聚蜂巢业务运行的可视化平台，是业务运行状态展现和问题定位、调试必不可少的模块。主要有多维统计分析、资产关系分析、监控和告警管理、日志管理、调用链路分析、数据溯源等功能
开放与共享
通过API生产者、运营者、消费者三种角色，联结不同业务和IT部门，构建API生态，实现API资源自助化，快速响应业务迭代与创新发展。对企业内部可以减少重复造轮子，提升跨部门、业务的沟通效率；对企业外部完善API生态，实现上下游渠道的无缝对接，高效协同
04 API与应用场景，满足不同业务需求
原有系统优化:通过API化解耦与API全生命周期管理，实现对原有系统的实时监控、数据管理、提质增效
新老系统衔接:通过无代码敏捷集成编排平台，对不同系统的数据、应用按照统一标准，进行采集汇聚，消除系统间的数据鸿沟，实现整体架构统一，节省系统维护成本
应用创新:通过资源复用，大幅提升系统集成和服务交付能力，摆脱对系统供应商的依赖，快速、自主控制业务需求交付
打通系统信息孤岛，加速转型:API管理应适配多种组织模式，支持多租户、多环境，如集团分子公司、国内国外等业务模式；支持多云模式部署，实现云上云下、跨云跨网互连互通，实现企业上下游渠道、内外部资源对接，协同
05 API为微服务搭建桥梁
随着微服务的越来越流行，越来越多的公司开始实行微服务架构，相对于单一应用架构，微服务将复杂性拆分并且打散到一个个粒度更加细分的应用中，极大了减少了开发中单个服务的复杂性，开发人员只需要面向专注单一业务场景编程，从技术开发角度，单一服务代码量上减少很多，从业务角度上，业务复杂性的降低降低了需求的沟通成本，然而，整体业务复杂性依然存在，当我们需要接入或者依赖其他服务时，通常作为接入方来说，我们不需要深入了解服务提供方的业务，此时API成为了开发人员间的沟通语言。
良好的API设计，能极大地减少沟通成本，甚至有时候可以代替文档，尤其是对于基础性服务来说，服务的可扩展性有时候体现在API的可扩展性，我曾经参与过一个基础业务微服务的业务升级，由于旧版本的API划分不够清晰，部分API存在重复性，后面不得不对大部分API进行重构（替换为新版本的API），仅仅在服务消费方升级这个阶段就持续1-2个月之久，在这个过程中也不断对API设计中存在的一些问题以及应该遵循哪些原则进行了一些思考。
在敏捷开发的大浪潮下，产品上通常要求快速迭代，面对一个新的需求，如果需要开发新的接口，通常在表结构完成设计后，开发人员就需要完成API设计并交付消费方（即服务的调用方或者依赖方，文中其余部分均表示此含义），在技术联调前，消费方可以Mock接口来完成调试。所以通常来说，API先与服务交付，之后再完成编码，测试，调试等工作。
当然，由于可能在需求细节，技术实现方面可能在实现过程中发现需求需要调整，或者API接口的调整，最初版本的API可能是不成熟的，导致我们经常在API调整或者演化过程中在API维护方面存在很多遗漏，所以API最初交付后的维护是持续性的工作。
API设计常见问题
在我们设计API过程中由于存在经验的缺失，或者由于多次交接，或者由于经历多次需求的变更，导致服务的API慢慢腐化，带来以下常见的问题。
被遗忘的注释，注释通常描述了API的功能以及参数说明，以及如何接入，甚至给出简单示例，过于详细的注释会带来一定的反作用，例如因为新需求带来了内部逻辑的调整，但是由于未及时对API的注释进行更新，会给新接入的调用方带来潜在的风险。所以不仅仅需要为API提供完整清晰的注释，当内部逻辑变更时，作为开发人员通常也需要评估API层面的变更，包括注释。
接口数量持续膨胀，有很多原因带来接口数量的膨胀，可能是接口升级，但是旧接口无法直接下线，所以会提供一个功能类似的新接口；可能是新接管一个服务由于对业务不了解，面对新需求直接开发新接口；可能是接口分类划分不合理，或者数据模型混乱导致API划分混乱，出现API功能重复，最后导致一个场景多个API接口都可以满足，这样很明显是应该避免的。解决这些问题都需要建立在对业务充分理解的基础上，下文的设计原则会针对这类问题给出解决方案。
缺乏有效测试，很多开发人员往往忽略对于接口的测试，无论是内部逻辑细节的单元测试，还是接口层面的测试，都是服务健壮性的一个有效保证，如果无法对接口进行有效测试，不仅是不负责任的体现，而且还会经常被线上bug困扰。
06 API设计原则
简单且专注
简单：在面向对象设计原则中，第一条是单一职责原则，同样适用于API设计，我们的主体对象就是业务模型，API就是封装内部逻辑后对外界开放的功能。保证API的简单和职责单一，能够避免解决上文中提到的接口数量膨胀问题。那如何才能实现API职责单一，需要我们在定义接口时能够准确识别出接口之间的关联性和边界，对于API如何划分可以通过以下角度：
按照业务主体划分，不一样的业务主体采用不一样的接口类
查询类和修改类的接口分离；通常来说我们对于数据的查询场景远大于修改的场景，而且查询有多种多样的业务场景，对于数据的修改请求通常来源于业务后台人员对数据进行修改，此时的业务逻辑也通常会更加特殊（例如有很多额外数据校验），所以建议修改类和查询类API尽量分离，甚至可以将业务配置后台类查询和普通业务查询分离以至于能够适应各自的业务变更。
专注：一个单一接口的场景是基于业务抽象后专注于某一个场景并且互相不重合的，这样才能保证接口的粒度足够小，尤其是对于基础类服务，接口粒度的划分能保证接口是纯粹的且互相独立的，这样才不至于在需求变化涉及过多接口的变动（除非是对业务模型有较大的调整），另外要说明的是，内部逻辑的业务数据模型（POJO类）和API数据模型（DTO）有时候出现差异，否则可能需要消费者理解服务的业务模型才能正确的使用接口，这就要求在API设计中开发人员需要明确应该提供哪些数据模型给消费者，在此前提下更加有助于我们保证单一接口的专注。
良好的注释
注释应该包含哪些；接口的使用场景，参数的说明，在接口类说明中可以给出接口文档链接地址，方便调用方查看
参数的说明；包含参数代表的含义，参数的类型按照Javadoc link规范，参数是否为空，特殊值说明
过期说明；如果接口已经过期，需要给出过期说明，对于 Java 来时就是@Deprecated注解，并给出切换接口说明，如果条件允许可以推动调用方进行接口迁移，后续对旧接口下线
扩展性
唯一不变的是变化，接口也会一直演化，我们不提倡过度提前设计，但是在演化过程中要始终保持接口的可扩展性。
多参数结构与单一参数类结构通常来说，如果一个接口的参数小于三个，那么建议使用多参数接口，这样做到直观简洁 如果一个接口的参数较多而且后续可能经常出现变动，为了便于扩展和兼容，会将参数封装到一个类结构中，记得同样对每个字段给出完整的注释说明。
类复用噩梦在单一参数类结构下，我经常看到多个存在明显功能差异的接口频繁复用一个结构体，甚至接口参数和返回值都复用一个DTO，为了保证兼容，又不得不在同一个DTO内不断加字段，久而久之维护成本持续增高，这是一种不合理的类设计，如果遵守专注原则，这个问题很多时候可以避免。
兼容性
接口逻辑或者参数变更时，需要对旧的接口保持兼容，这个是API变更时一定要遵守的原则之一，而且要通过接口测试来验证兼容性。
是否要新增接口，当面对一个新的需求时，为了避免对旧接口直接修改，有的开发人员会统一提供新的接口，如果并非逻辑上发生较大的变更，这样做会提高API的维护成本，后续如果不对API进行重构，新增加的维护成本将远大于最开始节省的开发成本，例如需要对某个参数增加有效校验，那么我们需要对两个接口的API实现都做修改，而且是重复性的代码，而且我们的影响范围已经成了两个接口，这样影响范围的扩大也带来了更多的潜在风险。当然在某些场景例如接口逻辑出现大的调整，API重构等情况下，更好的方法是提供新的接口，并推动服务消费者使用新的API，最后慢慢下线旧的API，这样才能遵循简单和专注的原则。
完善的测试
单元测试，完善的单元测试能保证代码的健壮性，提前在编码阶段发现并解决潜在的bug，单元测试是一个开发人员的必备能力。
接口和场景测试，接口测试包含内部逻辑验证，异常输入，并发等场景下对单一接口的验证，如果要对API进行完整的逻辑验证，需要开发人员构造完整的测试数据（通常包含scheme.sql和data.sql文件），尤其是对于基础服务，需要对某些复杂业务场景下联合多个接口完成某个场景的测试，并对中间的数据和输出进行Assert确认，这样也会代码一定的测试代码维护成本，需要开发人员进行利弊权衡。
重视文档
良好的注释和文档能减少大部分和服务消费者的沟通工作，也避免了一些错误的接口使用。没有人希望每次都需要在IM工具上浪费大量口水或者需要当面询问才知道如何正确使用API，也没有开发者愿意每天重复回答如何调用提供的接口。
对于接口文档，可以是采用Javadoc这样简单的方式，也可以是通过wiki来集中管理，可以是markdown文档，也有很多的开源系系统例如Swagger，yapi，eolinker等；微服务的架构极大的加强了沟通的成本，这也是微服务架构的一个弊端，但是合理的利用工具 可以减少不必要的沟通。
作为微服务之间的桥梁，API设计和维护是微服务架构中很重要的一个环节，每个开发人员不仅仅需要良好的代码规范，也需要建立并遵守API设计规范。API设计能力在微服务架构中作为软实力的一个部分，需要开发人员有一定的设计经验的积累，同时，只有不断的思考和总结才能更加深入的理解。
07 微服务架构的适用性
企业不一定要使用微服务架构，因为其是否适合取决于企业的业务需求和技术架构。微服务架构是一种分布式系统架构，将应用程序拆分成多个小型服务，每个服务都能够独立运行、可独立部署、独立维护和扩展。这种架构可以提高系统的灵活性、可扩展性、可维护性和可靠性。
但是，微服务架构也存在一些缺点，如服务间通信的复杂性、部署和管理的复杂性、网络延迟等问题。因此，在考虑采用微服务架构时，企业需要权衡其优缺点并评估其在自身应用程序中的实际效果。
在某些情况下，微服务架构可能并不适用。例如，对于小型应用程序或具有相对稳定业务流程的应用程序，采用微服务架构可能会增加不必要的复杂性和成本。而对于大型、高度动态和需要快速扩展的应用程序，采用微服务架构可能能够更好地满足需求。
因此，在决定是否使用微服务架构时，企业需要评估其需要满足的业务需求、系统规模、组织文化、技术能力和资源等因素，并进行全面的风险评估和成本收益分析。
08 微服务架构和传统架构各有其优劣点
微服务架构的优点：
灵活性：微服务架构将应用程序拆分成多个小型服务，这些服务能够独立运行、可独立部署、独立维护和扩展，从而使得应用程序更加灵活。
可扩展性：在微服务架构中，每个服务都有自己的进程或容器，并且可以动态地进行伸缩。这样能够更好地支持应用程序的扩展和分布式部署。
弹性和鲁棒性：通过微服务架构，应用程序的不同部分能够独立处理失败和错误，并通过异步消息传递机制来完成解耦，从而提高系统的弹性和鲁棒性。
传统架构的优点：
简单性：由于传统架构是单体应用程序，因此，开发和管理相对简单。此外，在传统架构中，服务间的通信也相对简单。
性能：在某些情况下，传统架构可能比微服务架构更具有性能优势，特别是在处理大量数据时。
易于部署和维护：由于传统架构是单体应用程序，因此，应用程序的部署和维护也相对容易。
结论：微服务架构和传统架构各有其优劣点，没有一种架构可以适用于所有情况。因此，在选择架构时，需要根据应用程序的需求和规模来评估不同架构的优缺点，并选择最适合自己业务的架构。
同类文章
精彩导读
热门资讯
关注我们
