前言

        前面分享了Web Service，NDC Adapter，AIDM等一系列技术、产品、规范的想法。同时在其他文章也专门分享了Microservices的架构和思路。如下将对另外一个概念Open APIs，以及全局的几块融合逻辑架构分享一下设计和见解。

Open APIs

        Open APIs是个IT术语和应用协同模式。具体的介绍不在此篇鏖述，但是奉劝各位，尤其是航司的专家，直接去看Wiki的概念，或如下各个GDS和前驱航司的官网介绍。https://en.wikipedia.org/wiki/Open_API

Open APIs的官网：https://www.openapis.org/

（Leo：其目的是通过规范性的模板、流程、代码等等提高API开发的质量和敏捷度，更关键的是Contract-First的本质。这个是国内绝大部分开发人员不理解或不懂的地方。SOAP Web Service在过去的若干年中，提升的不仅仅是系统对接能力，和与之而来的SOA等架构理念，更告诉大家规范和接口的契约的重要性。JSON是数据承载的载体，但是其缺少了Metadata，也就丧失了作为契约的价值。）

OpenAPI Specification (OAS)：https://github.com/OAI/OpenAPI-Specification

（Leo：没有办法，此处还要提及Swagger，一个近乎10年前的概念了。这个是趋势、更是必须。没有规矩不成方圆，尤其是那些航司准备投产Open APIs的场景。要养严格要求航司的开发人员，乃至设计人员，更尤其是外包人员。如果还再继续Code-First的开发模式，航司是不完全不可能构建一整套强壮而清晰的API体系的。）

IATA Related: http://www.iata.org/whatwedo/stb/Documents/OpenAPI.pdf

（Leo：反而IATA对于此部分的描述较少，因为API颗粒度太高了，而且是技术为导向的实现。而且在技术领域，尤其是开源技术领域，已经在IATA关注它之前有了极大发展。）

SITA API: https://www.developer.aero/

（Leo：改版了几次了，这个是我14年才开始关注的，但是看到这些成果，当时真是欣喜若狂，而且那个时候还支持个人用户订阅。）

Lufthansa Open API: https://developer.lufthansa.com

Air France-KLM API: https://developer.airfranceklm.com/

（Leo：两个比较大的航司前驱，尤其可以参考其NDC的API的思路。）

Airline Open APIs策略

        航司推及Open APIs将是一个极大的模式改变，因为Open APIs的本质是在受限的平台上公开的、规范的像商品买卖一样交易“服务的使用”。为了方便理解，就将其想成一个Apple Store: 

        a) Apple公司提供开发SDK、提供基础接口及架构平台、提供由其开发的APPs；

        b) 但是Apple授权任何注册并获得许可的第三方个人/机构/组织/公司等，基于上面SDK/平台/规范/接口等，开发属于自己的第三方APPs；

        c) 但是如果期望能够被其他第三方所使用或消费，则需要上传并获得Apple的合规审批，从而才能APPs上架销售；

        d) Apple并提供不间断的第三方APPs测评和审计，随时根据具体问题和实际情况，选择下架某APPs；

        e) 第三方在其APPs上架并销售及用户下载使用后，根据实际情况从Apple获取必要的费用。

        所以航司的Open APIs就是将上面的Apple换成具体航司或GDS，上面的APPs换成APIs，别无他意。

        其关键的一个模式就是“协同”开发，鼓励第三方使用航司已经准备好的基础APIs，开发更有针对性的APIs和构建更贴近真实场景的APPs。（Leo：可以认为就是传统SOA基础上的服务编排。）

        但是其另外一个关键理念“开放”，则需要航司认真考虑了，其不是简单的开放几个退改签的接口，是应该全部业务流程原子化之后的暴露和分享。并且是直达C端。这个理念的认可是需要航司决策层来指定的，此处不评Open APIs是好是坏。

Airline Open APIs HLSD

        对于一个期望建设和投产Open APIs的航司，那其需要哪些逻辑部件和关键支撑、尤其是内部逻辑关系，下面给各位一个全局的概念。

（Leo：因为个别航司，尤其国内的一些特点，不一定100%适用，但是思路是不变的。另外已经基于此在阿里云服务器上搭建一原型演示系统，正在不断完善和稳定中。）

关键组建

a) Airline Backend Service & Core Systems

        航司后台的各类系统、服务、应用经过SOA改造之后，或可以直接暴露数据库访问而大而全的传统航司的资产。

        对于航司电商来说，其关键的资产就是PSS领域的各类即有功能。

b) Edge Service & Internal Service

        主要随着航司B2C的发展，大量的情况需要对C端的需求进行一对一的服务支持，而且颗粒度明显高于传统航司资产-Backend Service能够提供，同时还包含性能、数据安全性及完整性等一些特殊要求。

所以在此基础上航司开发了大量的服务化的实现，但是有直接对外部暴露和被使用的 - Edge Service，也有在内部作为服务编排和调用的 - Internal Service。

        这两部分都必须在航司现有的Microservices Technical Platform的支撑下，和严格遵守其技术及管理规范、以及开发策略。

c) Enterprise Core Digital Assets

        Edge Service & Internal Service这两部分就组成了航司核心的数字资产。其是航司关键业务的封装和暴露、其拥有强大及高可用用的特质、其拥有完备的IT运维支撑、其的设计/开发/发布/上线等有严格的生命周期管理、其是与航司Backend Service的功能最贴近的服务实现。

d) Microservices Technical Platform

        由注册中心、API网关、分布式配置中心、统一监控及运维中心等组成的技术平台，不仅仅是一些框架和产品的堆砌，更需要将航司对于Microservices的开发策略、规范、生命周期管理、乃至灰度发布等等概念融合并实现其中。

（Leo：由于近期项目的特殊原因，此部分不在此文章深入分享。）

e) API Marketing Platform

        对于Open APIs的实现，最关键的是“服务治理”，但是其本质就参考上述Apple Store的概念，是一个商品是服务的“货架管理”。但是由于API的特质，和Open APIs所倡导的理念，则需要完整的架构乃至产品体系支撑：API Manager。

        https://en.wikipedia.org/wiki/API_management

        推荐几个产品和开源的国外API Manager，航司具体选型因人而异，但是一定要认真理解其应该基本的能力和参考上述两个航司的Open API实现。同时必须增强API开发人员和尤其上司内部人员的综合素质：不是简单写两行代码就能够上线一整套协同性的服务的。真对于航司是一个战略，更需要大量人财物时间的投入。

几个关键组成部件：

API Gateway：加密、保护、管理和度量API的调用。提供了一个简单的API代理，拦截API请求，并应用限流和安全检测的等功能。它同样作为API使用统计的工具。

API Publisher：具备API信息注册与发布，共享文档，提供API密钥，收集特性、质量和使用的反馈。

API Store：API的消费者，应用系统注册、服务发现和订阅API、评估，并与API Publish进行交互。

API Manager Analytics：提供统计图表，针对预设的事件和日志分析具备告警机制

f) Value-added Service

        一切新开发的，基于Open APIs的Microservices实现，其都是增值服务。但是对于企业核心数字资产的修改，以及在其上的编排或者重构，则必须有航司的核心数字资产服务团队进行评估，以保证数字资产的统一管理和持续维护。

核心数字资产微服务到NDC的实现

        那对于NDC的实现，其并不直接隶属于企业核心数字资产的一部分。因为其是遵守特定规范的存在，而不是航司；同时其是SOAP Web Service的实现，而不是RESTful Service

；另外其业务和数据的体量巨大。（Leo：任何看过或开发过NDC服务接口的人都清楚，一个RQ有多少字段，如果全部Setter则需要900+次。）

        企业核心数字资产是对于业务完整性深入考虑后的最小原子封装。即应用DDD的Microservices的标准实现。其对外的使用和暴露均由Microservices Technical Platform统一管理和暴露。NDC实现只能通过服务注册及发现中心提供的服务黄页，经由API Gateway的路由才能访问关键的业务服务实现。

        由于Microservices的高颗粒度，NDC的Block特质，则其中需要一个比较厚重的编排及适配层，这也就是我之前介绍老东家NDC Adapter的作用和定位了。

Airline Open APIs的实现

        规范的做法和路径，必须是构建其完备的事业核心数字资产，用于高效的保护和持续的迭代核心数字化能力。

        航司的Open APIs不同于其他行业，乃至IT或互联网企业。单凭某IT服务商的热情，航司是没有办法建立合理、健壮、有竞争力、和品牌化的Open APIs的。就好比有人能够提供一个很好的货柜，但是你拿不出任何商品摆在上面，也是徒劳。即使上架了，后续商品的进销存是否能够支撑也需要考虑。

 所以：

a) 首要是构建Microservices Technical Platform和全套的管理及生命周期规范，有效的保护核心数字资产及延续性的迭代。

b) 明确Expose哪些和怎样Expose这些核心数字资产。

c) 定义服务商品上架下架等全面的管理及运维体系。

d) 核心数字资产经由Microservices Technical Platform中的API Gateway集中注册及发布到API Manager。

e) 文档化服务契约等必要描述及上架销售。

f) 宣传并吸引第三方协同开发，构建整套生态环境。

结论 - 航司的“内容”建设

        看似简单的SOA，RESTful Service，其实真正落实到航司的特定场景和全球性经济中，就没有那么简单了。NDC是一个接口的实现规范，所以他最依赖于”内容“，很多航司从第一时间就去构建NDC，在没有类似NDC Adapter的这样的工具和思路的指引下，其实是很痛苦的。Open APIs已经在很多前驱的航司投产了，应该有很多航司也蠢蠢欲动，但是华丽的新装需要有内在的支撑，其也需要”内容“。

        于此同时，即使建设Open API，这不仅仅是市场策略等的能力、更需要国际接轨的能力、全球规范的理解能力、全面的IT技能、资深的架构及管理人员、持之以恒的迭代。