1) 航司傳統(tǒng)PSS與GDS的數字化轉型是大勢所趨橘霎,但是路漫漫其修遠兮。雖然航空業(yè)擁有較高的IT和信息化水平厂抖,但是固有的業(yè)務壁壘往往不能讓新的IT技術和思路,尤其互聯(lián)網的理念得到很好的發(fā)展克懊。同時雖然IATA推出NDC及ONE Order很久了忱辅,但是真正業(yè)界的投產七蜘,個人感覺還趕不上區(qū)塊鏈的半年的演變。
2) 同時由于國內草臺班子式的開發(fā)團隊和IT理念與國外的不同墙懂,就對于最簡單橡卤,已經有近乎20年的Web Service還重復著不知所云的忽悠,把SOA损搬,ESB碧库,REST,微服務巧勤,Serverless等等混為一談嵌灰,以為做個Spring Framework的RESTful API就能夠微服務了。而忽略了各個技術概念的本質和核心思想颅悉,更忽略了上面這些都是概念和架構思想沽瞭,更忽略了與其相輔相成的一些設計理念,例如DDD等剩瓶。
3) 更有甚者認為微服務在航司的應用就是IATA的NDC了驹溃。做些RESTful API就是微服務了。
這篇和后續(xù)文章主要描述個人認為在航司投產一些服務化產品延曙,尤其參考NDC規(guī)范和IT理念的關鍵技術思路(注:不包含任何航司電商內部業(yè)務實現(xiàn)和傳統(tǒng)PSS轉型的內容)
Web Service
Web Service, 在國內被翻譯成“Web服務”豌鹤,“網絡服務”....等等,我還記得研究生畢業(yè)的時候被導師折磨了半天枝缔,要我明確和清晰的翻譯“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通訊協(xié)議寓调,其只有一輕一重锌唾,一通用一專用的區(qū)別。但是擺脫HTTP協(xié)議,那么RESTful API就無能為力了晌涕。
Web Service不僅僅是HTTP滋捶,更關鍵的是Contract/契約
那對于IATA的NDC的規(guī)范,一個Order Management服務從IT的角度拆解為如下內容余黎。
傳統(tǒng)Web Service應用場景
如下所示重窟,一個Web Service的描述性文件WSDL包含一系列強制的信息,其能夠更規(guī)范性和清晰的描述數據傳輸的規(guī)范和要求惧财。
個人認為巡扇,對于航司這種復雜的業(yè)務及數據交換,在內部垮衷,其實很多時候在對外發(fā)布的場景厅翔,傳統(tǒng)的Web Service擁有獨一無二的優(yōu)勢。
所以不要以節(jié)省幾行代碼帘靡,或快速上線為理由知给,直接就RESTful API了。那未來的維護描姚,服務治理及管理等等可不是節(jié)省下來的這點時間能夠解決的涩赢。至少你還要寫接口文檔吧,至少你還要給別人寫調用案例吧轩勘,只要你還要處理輸入異常吧筒扒,你變化contract信息也還要考慮下游消費者吧.....
同時各位也能夠體會到,即使RESTful API绊寻,現(xiàn)在也慢慢更關注Contract First方式了花墩,例如Swagger,更例如之前WADL澄步。
還有人說RESTful API能夠減少傳輸的數據量冰蘑,但是你需要想想,對于企業(yè)內部村缸,乃至外部很多場景祠肥,帶寬及數據量能造成多大的性能壓力,就為了區(qū)區(qū)幾十個字節(jié)和幾十毫秒的性能梯皿,就丟失了數據的精度仇箱,類型等等元數據信息是否值得。
所以“沒有規(guī)矩不成方圓”东羹,Contract/契約的重要性在Web Service領域不言而喻剂桥,即使20-30年前的串口通訊,大家都還定義和遵守數據交換規(guī)則了属提。
永遠Contract First
盜用很久很久之前自己畫的一幅圖权逗,當初缺失深惡痛絕WSDL,WSDL First,看到哪些Code First的開發(fā)模式和項目欣喜若狂斟薇。
但是隨著近10年的項目經驗火惊,真心感覺現(xiàn)在越來越需要Contract First。從之前的WADL到Swagger奔垦,都在規(guī)范化接口規(guī)范。
因為再如何Code First尸疆,實際生產環(huán)境下椿猎,再有好的接口文檔,都還是需要代碼進行數據的校驗寿弱。那為什么不從一開始就把這些基礎的是做好呢犯眠??症革?
當初Web Service的開發(fā)時候感覺Microsoft和其WCF等的限制太強筐咧,但是回過頭來看看,現(xiàn)在RESTful API的框架和代碼結構噪矛,未免太開放了量蕊。Web Service終究是“Interface”,“Interface”定義的就是規(guī)范艇挨。其實沒有多少創(chuàng)造性而言残炮。你們看看大量的公司,安排寫接口的人都是怎樣的水平缩滨,就是在拼勞動力势就。那為什么不標準化的方式,將框架建好脉漏,讓這些勞動力就只關心他能關心和掌控的那些苞冯。
讓所謂的架構師,設計人員侧巨,將“Interface”定義好舅锄,讓測試,下游系統(tǒng)能夠在定義文檔后同步開展工作刃泡。不僅僅節(jié)省時間巧娱,更關鍵的是使得設計即為交付和評審依據。