在和像“惠行车”这样的做汽车售后市场的伙伴合作之后，【赛合一数据】发现：传统企业在逐步建设自己的数字平台过程中，需要抓住交付基础设施、API和架构治理、数据自服务、创新实验基础设施和监控体系、用户触点技术这五个支柱。其中API、架构治理这些听起来非常技术性的概念与企业的数字化战略之间有着重要的关系。

自20世纪90年代以来，ERP一直是企业信息化的核心问题。然而近年来，在互联网的冲击下，传统企业开始面临新的挑战，特别是在互联网的中央集权效应的影响下，突然被压缩到“生产流通消费”的极度精简的价值链中,具有技术优势和消费者接入的互联网公司很可能形成独特的超级垄断。

为了应对互联网公司的竞争，传统企业最好的办法不是拼出互联网上的技术和流量，而是在自己的领域里奋斗：将自己积累的离线资源转化为在线服务，构建在线生态系统。这个生态系统不仅支持企业的网上业务，而且为上下游企业在线运营提供了一个平台，将离线优势转化为在线优势，以资源优势对抗技术优势。毫无疑问，API是建立这个生态系统的基础。这里顺便说明：汽车售后市场是非常典型的传统和互联网分开的领域，但是很多企业从中找到了节点（API），如“惠行车”接入[赛合一数据]违章查询API接口而改变了传统运营模式，巧妙地将线上线下资源进行整合，实现了互联网+道路的转型。

很显然，由API搭建起来的生态系统构架包括：开发者体验、服务边界、事件驱动构架、公共网关以及微服务SOA拓扑。

开发者体验——在讨论开发人员的经验时，可以考虑开发工具的安装、配置、管理、使用和维护以及开发环境。具体地说，开发环境和测试环境是否可以根据需要弹性地获得，无论是开发/测试基础设施和连续传输线都以源代码的形式提供并完全自动化，是否提供主流开放的支持、是否提供可编程的。安全性、数据访问权限和其他企业规则严重影响开发人员的效率和感受，这是影响开发者体验的因素。

服务边界——与所有面向对象的设计一样，服务的设计应该具有高度的内聚性和低耦合性：仅在一个服务内执行与业务相关的修改，并且服务的修改/部署不需要影响其他服务。在设计原则方面，服务边界应该反映业务边界，而不是仅仅从技术的角度划分服务边界。从业务功能的角度，划分合理的限制上下文，通过域模型和域事件的聚合来划分服务，更可能得出与业务边界一致的服务边界。而后业务目标是驱动全功能集成团队构建要点，从而使业务、技术和团队可以达到三者对齐。

事件驱动构架——使用异步事件机制在服务之间进行通信。对于需要更长时间运行甚至无法立即完成的操作，例如涉及手动操作，使用异步通信是合理的选择。即使不考虑响应的实时性，事件驱动的体系结构也表达了域模型之间的松散耦合：跨域协作以事件而非方法调用的形式表示，系统追求最终的一致性而非强一致性。该结构准确地映射了现实世界中多个相关但独立的团队之间的协作关系，避免了对服务质量指标的依赖，例如其他服务的响应性或可靠性，使服务真正在技术上独立。

公共网关——微服务提供的API的粒度与客户端的粒度不同。因此，客户端通常需要一个请求的多个服务。故有必要为服务提供一层外观封装，并为所有服务用户提供API网关作为单一入口点。 API网关可以通过两种方式处理请求：一种是直接代理/路由到适当的服务；另一个是通过一个请求扇出/分发到多个服务。 API网关可以为不同的客户端提供不同的API，并且可以包括客户端的适配代码。横切要求（例如安全性）也可以在API网关上实现。

微服务SOA拓扑——与传统的SOA架构相比，所谓的“微服务”的最大特点可能是没有重量级ESB。集成代码中存在的复杂逻辑现在被转移到ESB。这个“ESB团队”已经成为IT交付的一个瓶颈：ESB团队需要改变事件相关的变化，而不管发布事件的服务、消费事件的服务，或者编排本身的变化。这个团队积压起来，使得每一个服务和应用都无法提供快速响应。

结语：为了激活企业离线资源并构建行业在线生态系统，IT需要有效的服务API和架构治理方法。以上是【赛合一数据】小编吐血整理之精华，看完别忘了加鸡腿啊。