基于SpringCloud的航運EDI平臺IT生態環境設計

文/張樹新 吳海斌 蒙輝 湯麥倫

引言

EDI電子數據交換技術在航運中擁有無可取代的地位。航運EDI主要服務于貿易商、海關、商檢、港口、航運企業、貨代、船代等企業部門，然而，由于企業部門使用的EDI標準不一致，航運EDI交換自動化程度較低，國內目前僅上海億通國際建有較為成熟的航運EDI交換中心，主要通過協議適配、管道、字典等技術手段實現報文語義識別及格式轉換[1]。

作為最新一代云計算技術框架，SpringCloud 為開發者提供了在分布式系統（配置管理、服務發現、熔斷、路由、微代理、控制總線、一次性token、全居瑣、leader選舉、分布式session、集群狀態）中快速構建的工具，使用Spring Cloud的開發者可以快速地啟動服務或構建應用，同時能夠快速和云平臺資源進行對接[2]。SpringCloud作為新生的微服務框架，相比阿里巴巴Dubbo等RPC框架， Spring Cloud提供的全套分布式系統解決方案更利于構建完整的IT生態環境。

本文通過分析航運EDI平臺單節點系統存在的痛點，并對采用新技術后開發測試、實施運維、集成擴展過程存在的問題進行分析，提出云計算時代IT生態環境的規劃愿景，然后基于SpringCloud分布式架構構建完整的云生態環境，最終實現降低專業人員技術門檻、提供靈活高效的運維環境，達成平臺具備持續集成和交付能力的目標。

一、EDI平臺現狀及問題

目前國內航運EDI平臺大多仍處于單節點系統或小工具層面，制約其發展的原因不外乎EDI標準不統一及現有平臺技術發展緩慢。

技術發展緩慢并不是因為EDI核心技術復雜或是共性技術無法應用，相反EDI核心技術非常簡單，也正是因此，EDI系統、小工具在小范圍內應用良好。

小系統、小工具適應面有限，航運對通用性強的平臺級EDI有著迫切的需求，如何適應繁雜不一的標準，不斷接納新的標準，打造開放統一的一站式交換環境，一直是平臺級EDI努力的方向。

EDI平臺的開放性是個復雜、綜合、長期的命題，也為了有效降低成本，在新技術應用上，EDI平臺從未放慢追隨的腳步，而新技術的應用帶來了學習成本增加、專業技術人員難覓、運維復雜度增加、集成擴展不易等問題，應用新技術的副作用將開發運維成本逐漸推高，甚至超過全新開發的成本，而違背了使用新技術的初衷。正是這樣的客觀情況，航運EDI平臺技術的發展相對緩慢。

當然，部分平臺也順應發展，逐步應用SOA架構、阿里巴巴的Duboo微服務架構、IaaS基礎云、Docker容器等新技術，很大程度上，新技術地使用降低了平臺開發技術門檻，提升了平臺的擴展性及可維護性，但當IT人員從這些新技術上獲得便利、敏捷的同時，新技術的生態鏈連貫性不足、可靠性未經歷考驗，這都是制約平臺技術更新換代的最大痛點。

究其根源，不是新技術不適用，而是每項新技術僅能解決軟件工程的某一方面的問題，但平臺不單只是軟件工程，而是集開發、測試、部署、運維、集成等一系列的工作的IT生態圈，航運EDI平臺缺少的是一個連貫性好、技術門檻低、開放性佳、可方便擴展、能在未來5到10年內適用技術發展的IT生態環境。

二、EDI平臺云生態愿景規劃

良好的IT生態應該是簡單地開發、完善地測試、快捷地實施、連貫高效地運維、持續地集成、持續地交付，這些應該都是云化的，各個階段都有完善的解決方案和工具支持，這就是EDI平臺云生態的愿景。

開放方面，應使用市場成熟、生命力旺盛、學習成本低、具備良好延續性的技術。開發語言、框架應是當下流行的技術，智力資源易于從高校或社會中獲取，擁有一定的社區群體，遇到問題能有多渠道途徑解決，且開發人員應不需要很高深的專業開發能力，經過簡單培訓即可參與并完成功能服務開發，平臺應能方便地拆分模塊外包開發，并順利組裝對接。

測試方面，應具備與單元測試、自動化測試、回歸測試工具良好結合的能力。

運維方面，新技術不應導致運維成本增加，而應盡可能融合云計算、容器、自動化技術提高系統可用性、魯棒性，降低運維難度及人力需求。各微服務模塊能通過Docker實現云環境自動化部署，各微服務具備路由及負載均衡能力，整體平臺不存在單點故障，支持不停機平滑升級、快速高效地運維配置熱更新、版本控制。

集成擴展方面，平臺應可以從最小化系統功能進行搭建，逐漸集成擴展堆積新功能模塊，而不影響平臺代碼可維護性及運行效率，并能通過簡單硬件擴展提升平臺服務能力。

三、基于SpringCloud的IT生態環境設計

航運EDI平臺從單節點系統向SOA架構變革的過程，隨著服務的增多，逐漸暴露出管理難的問題，在考察對比了阿里巴巴的Duboo服務治理架構及SpringCloud分布式架構后，最終選定了SpringCloud架構作為構建平臺云生態環境的基礎。

這里簡單介紹基于SpringCloud的總體架構設計，重點介紹平臺開發及運維生態環境的規劃設計。

圖1

3.1 平臺整體架構設計

圖1 為平臺整體架構[2][3]：

考慮到需構建結構完善、智力密集、人工成本合理、能應對人才流動性沖擊、可持續發展的開發團隊，因此，選擇生命力頑強、延續性好的通用性技術以降低學習門檻、應對沖擊是至關重要的，這里選擇了Java開發語言、Spring體系作為基礎搭建開發生態環境，Java及Spring已經成就的大生態環境，能很好地解決組建、運營開發團隊遇到的問題。

同樣是在底層的平臺運行生態環境，這里選擇IaaS基礎云、Docker容器技術進行搭建，經過近10年的發展，IaaS和PaaS云技術已經落地成熟，IaaS與Docker完美結合，SpringCloud通過SpringBoot與Docker無縫對接，在這些技術的基礎上，可極大地降低平臺部署運維難度，終結了起早貪黑、提醒吊膽、全天候值守的運維時代，是一個較為完美的平臺運行生態環境[2][4][7]。

服務層采用為微服務架構的設計思想，微服務較SOA架構更輕量級，是對SOA架構的更小劃分，將SOA的思想融入到單個業務系統內部，實現真正的組件化[5]，這里構建了用戶、日志、審計、權限、文件、報文協議適配器、報文解析器、主數據字典、報文生成器等微服務，各服務獨立成系統，擁有自己的數據庫，業務邏輯。這樣的服務生態環境設計，能很好地將平臺復雜的功能分解成一個個功能獨立的單表維護組件，符合軟件工程總體規劃分步實施的原則，讓開發外包、通過簡單擴充智力資源提高開發效率成為可能，且隨著微服務的組件化，服務的復用度、開發難度大大降低[3]。

隨著微服務架構的應用，勢必導致服務碎片化，管理難度會隨著微服務的增加而呈現幾何級增長，為了解決這一問題，這里構建了服務管理生態環境，包含配置管理、服務發現、熔斷控制、服務路由、負載均衡，服務狀態監控，服務路徑跟蹤、ESB總線等，將微服務的變化產生的漣漪進行有效監控，結合IaaS和PaaS的高可用特性，通過簡單地重啟、重新部署等方式解決服務生存周期出現的問題[8]。

整個EDI平臺生態環境還包括自動化測試構建、平臺健康管理生態等等，這里就不過多介紹了。

3.2 平臺開發生態環境設計

為確保航運EDI平臺能順利更新換代，平臺開發環境的生態體系至關重要。

1.選擇Sping家族產品，可有效解決技術門檻、學習環境、資源獲取、人才需求、疑難解決等問題，這為開發生態環境打下了良好的基礎。Sping系列架構從2004年至今，其引領的SSH儼然已成為JAVA學習的必修課程，作為SpringCloud底層的SpringBoot更是將Spring的學習門檻降低到了極致。

2.通過Spring Cloud Netflix組件輕松實現服務治理，解決SOA架構下服務調用困難的問題。使用Eureka可完成服務的注冊和發現，使用Zuul網關實現服務的路由及訪問，使用Feign實現服務間的互訪，使用Hystrix組件實現斷路器模式，解決微服務下單點故障傳播后的“雪崩”問題[6]。

3.使用Spring Cloud Bus 將分布式的節點和輕量的消息代理連接起來，通過消息總線的模式，結合異步執行，解決服務串行調用開銷過大導致的性能問題，并能在消息總線上方便地實現微服務的熱插拔，在松耦合的環境下，解決平臺基礎擴展及動態交付問題[6]。

4.SpringCloud通過SVN與Jenkins、harbor結合，可實現與Docker的無縫對接，實現自動化構建部署，打造高效的開發編譯環境。

通過以上設計，平臺將具備完善的開發環境生態鏈，即獲得了便利、敏捷，又解決開發混亂、管理困難的問題，形成健壯的開發生態環境，而不至于因某個服務或個人的異常而影響整個平臺質量。

3.3 平臺運維生態環境設計

運維作為整個生態環境里的重要組成部分，對航運EDI平臺至關重要。系統的性能、穩定性、可靠性、不間斷的服務、無縫升級，都是航運EDI平臺所必須的，這些將是構建運維生態環境的重要考量因素[9]。

1.通過Ribbon組件提供的負載均衡功能，可通過Docker在很短時間內拉起多個相同功能的服務，共同注冊到Eureka上，實現服務的負載均衡，可有效解決系統性能瓶頸問題[7][10]。

2.通過Ribbon負載均衡組件結合Hystrix斷路器組件，可輕松實現服務的高可用，確保業務的穩定連貫，讓不間斷服務成為可能，在此基礎上，單服務的無縫升級也能輕松實現，分布式服務優勢在運維生態上得到完美體現。

3.Hystrix Dashboard監控面板及Turbine監控聚合組件無需做過多的配置就可以實現對所有微服務實例的運行狀態、性能、服務調用消耗等信息進行統一查看，讓運維更精準及時。

4.微服務運維過程中，最繁瑣的當屬服務配置更新，當微服務數量達到一次程度時，對所有服務進行一次配置更新不但費時費力，還容易出錯，管理相當困難，Spring Cloud Config提供了服務配置中心的管理概念，可與SVN、Git進行結合，對環境配置進行版本管理，與Spring Cloud Bus總線結合后，還能實現微服務配置的自動批量更新，這是運維生態環境的有力支撐[2]。

5.隨著EDI業務的不斷擴張，服務之間互相調用會越來越復雜，業務邏輯層的一個接口可能需要很多個服務協同才能完成這個接口功能，如果鏈路上任何一個服務出現問題或者網絡超時，都會形成導致接口調用失敗，Spring Cloud Sleuth提供在分布式系統中追蹤服務調用的解決方案，以及可視化的呈現。

通過這些有益的設計，平臺具備簡單、高效的運維生態環境。

四、結束語

本文較為寬泛的對航運EDI平臺提出了IT生態環境設計，而SpringCloud作為新生分布式架構套件，具有連貫性好、健壯性強、全組件化的優點，且文中設計的IT生態環境在眾多行業中具有共性，有著非常強的應用價值。

[1]倪瑩瑩，王曉峰，畢坤.基于模式類的航運EDI共享系統的設計與實現[J].上海海事大學學報， 2016.

[2]Pivotal Software， Inc..Spring Cloud[J].http://projects.spring.io/spring-cloud/.2017.

[3]郭棟，王偉，曾國蓀.一種基于微服務架構的新型云件PaaS平臺[J].信息網絡安全， 2015.

[4]shuijieshuijie.Spring Cloud和dubbo對比[J].http://blog.csdn.net/shuijieshuijie/article/details/53133082.2016.

[5]風的姿態.我所理解的SOA和微服務[J].http://www.cnblogs.com/fengzheng/p/5847441.html.2016.

[6]Long J.Building Microservices with Spring Cloud - O’Reilly Media Free， Live Events[J].2017.

[7]師德清.基于Docker的PaaS架構設計研究[J].信息與電腦(理論版)，2017.

[8]謝璐俊，楊鶴彪.基于Dubbox的分布式服務架構設計與實現[J/OL].軟件導刊，2016.

[9]蔣煒，劉遠，王寧.電力企業一體化云運維管理平臺研究[J].信息通信，2015.

[10]陳世宜，葉德建.基于SOA架構的新型云平臺服務管理中間件[J].微型電腦應用，2016.