基于NDC的航司PSS及电商的SOA技术转型 （1）

1) 航司传统PSS与GDS的数字化转型是大势所趋，但是路漫漫其修远兮。虽然航空业拥有较高的IT和信息化水平，但是固有的业务壁垒往往不能让新的IT技术和思路，尤其互联网的理念得到很好的发展。同时虽然IATA推出NDC及ONE Order很久了，但是真正业界的投产，个人感觉还赶不上区块链的半年的演变。

2) 同时由于国内草台班子式的开发团队和IT理念与国外的不同，就对于最简单，已经有近乎20年的Web Service还重复着不知所云的忽悠，把SOA，ESB，REST，微服务，Serverless等等混为一谈，以为做个Spring Framework的RESTful API就能够微服务了。而忽略了各个技术概念的本质和核心思想，更忽略了上面这些都是概念和架构思想，更忽略了与其相辅相成的一些设计理念，例如DDD等。

3) 更有甚者认为微服务在航司的应用就是IATA的NDC了。做些RESTful API就是微服务了。

这篇和后续文章主要描述个人认为在航司投产一些服务化产品，尤其参考NDC规范和IT理念的关键技术思路（注：不包含任何航司电商内部业务实现和传统PSS转型的内容）

Web Service

Web Service, 在国内被翻译成“Web服务”，“网络服务”....等等，我还记得研究生毕业的时候被导师折磨了半天，要我明确和清晰的翻译“Web Service”。但是我还是奉劝各位，对于国外这些技术术语还是老老实实用英语吧，什么SOA，ESB，REST等等，能不翻译就不翻译，翻译了之后反而丧失了其含义，同时让“年轻人”更迷惑，搞的他们貌似懂还装专家，其实自己都没搞明白是什么。

各位有兴趣还老老实实看看Wiki的翻译吧，最好不看百度百科：

Two major classes of web services:

a）REST-compliant web services, in which the primary purpose of the service is to manipulate XML representations of web resources using a uniform set of "stateless" operations; 

Web service APIs that adhere to the REST architectural constraints are called RESTful APIs.

b) arbitrary web services, in which the service may expose an arbitrary set of operations.

—W3C, Web Services Architecture[2]

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

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

就这副图而言，其清晰的描述了两种不同的Web Service的特点，如果只针对HTTP通讯协议，其只有一轻一重，一通用一专用的区别。但是摆脱HTTP协议，那么RESTful API就无能为力了。

Web Service不仅仅是HTTP，更关键的是Contract/契约

那对于IATA的NDC的规范，一个Order Management服务从IT的角度拆解为如下内容。

传统Web Service应用场景

如下所示，一个Web Service的描述性文件WSDL包含一系列强制的信息，其能够更规范性和清晰的描述数据传输的规范和要求。

个人认为，对于航司这种复杂的业务及数据交换，在内部，其实很多时候在对外发布的场景，传统的Web Service拥有独一无二的优势。

所以不要以节省几行代码，或快速上线为理由，直接就RESTful API了。那未来的维护，服务治理及管理等等可不是节省下来的这点时间能够解决的。至少你还要写接口文档吧，至少你还要给别人写调用案例吧，只要你还要处理输入异常吧，你变化contract信息也还要考虑下游消费者吧.....

同时各位也能够体会到，即使RESTful API，现在也慢慢更关注Contract First方式了，例如Swagger，更例如之前WADL。

还有人说RESTful API能够减少传输的数据量，但是你需要想想，对于企业内部，乃至外部很多场景，带宽及数据量能造成多大的性能压力，就为了区区几十个字节和几十毫秒的性能，就丢失了数据的精度，类型等等元数据信息是否值得。

所以“没有规矩不成方圆”，Contract/契约的重要性在Web Service领域不言而喻，即使20-30年前的串口通讯，大家都还定义和遵守数据交换规则了。

永远Contract First

盗用很久很久之前自己画的一幅图，当初缺失深恶痛绝WSDL，WSDL First，看到哪些Code First的开发模式和项目欣喜若狂。

但是随着近10年的项目经验，真心感觉现在越来越需要Contract First。从之前的WADL到Swagger，都在规范化接口规范。

因为再如何Code First，实际生产环境下，再有好的接口文档，都还是需要代码进行数据的校验。那为什么不从一开始就把这些基础的是做好呢？？？

当初Web Service的开发时候感觉Microsoft和其WCF等的限制太强，但是回过头来看看，现在RESTful API的框架和代码结构，未免太开放了。Web Service终究是“Interface”，“Interface”定义的就是规范。其实没有多少创造性而言。你们看看大量的公司，安排写接口的人都是怎样的水平，就是在拼劳动力。那为什么不标准化的方式，将框架建好，让这些劳动力就只关心他能关心和掌控的那些。

让所谓的架构师，设计人员，将“Interface”定义好，让测试，下游系统能够在定义文档后同步开展工作。不仅仅节省时间，更关键的是使得设计即为交付和评审依据。