探討微服務在燃氣企業數字化轉型中的實踐應用

陳徐棟

（江陰天力燃氣有限公司，江蘇 無錫214400）

隨著大數據、人工智能、云計算等新技術的高速發展并且逐步向產業和行業下沉，數字化的浪潮已經不可避免地到來，城燃企業也同樣面臨著向新興數字化轉型的迫切需求。而在數字化轉型中，IT的轉型或升級是數字化轉型之路上最重要的革新力量。

數字化的本質，是通過上述新技術與企業的業務進行深度融合來實現商業模式的創新以及企業效率的提升，核心就是快速響應和準確洞察。但城燃企業傳統的煙囪式信息化架構，往往無法滿足這樣快速接入、融合支撐[1]、彈性擴展等的需求。

那么如何打破煙囪式架構、釋放數字資產的價值呢？運用“去中心化”的微服務架構，為應對這樣的挑戰提供了一個很好的解決方案。

1 微服務

1.1 微服務定義及概述

2014年，MartinFowler與JamesLewis共同提出了微服務（Microservices）的概念，定義了微服務是由以單一應用程序構成的小服務，自己擁有自己的進程與輕量化處理，服務依業務功能設計，以全自動的方式部署，與其他服務使用HTTPAPI通信。同時服務會使用最小規模的集中管理（例如Docker容器）能力，服務可以用不同的編程語言與數據庫等組件實現[2]。

通俗點講，微服務就是把傳統的單體應用根據實際的情況進行解耦，拆分成一個個單獨的服務，每個服務專注于做特定的事，提供特定的服務。這樣的服務都可以單獨進行部署及迭代，并且能夠更加根據實際情況擁有自身對應的數據庫。比如可以將原來應用中的銷售功能解耦拆分出來形成一個單獨的微服務，這樣做的好處在于，如果遇到類似于調價前用戶集中搶購的情況，只要對銷售服務資源進行調整即可。

1.2 微服務特點

微服務架構具有低耦合、組件化、獨立部署、獨立擴展、去中心化等特點，主要體現在以下方面：①服務粒度小。一個系統被解構為多個顆粒度較小的服務，每個微服務的可維護性和開發效率較高。②獨立進程和部署。每一個服務都可以獨立部署及獨立運行，這種方式能夠實現靈活的代碼組織和敏捷開發，降低了業務迭代時服務發布的風險，擴展性也很強。③去中心化。每個微服務可以根據自身的特性和整體發展的需要，自由選擇最適合的技術棧。

1.3 微服務優缺點

相比傳統架構，微服務具備以下優勢：①由于服務足夠小，因此易于被理解，也易于開發、維護以及迭代更新；②各服務間獨立性強，易于部署；③由于每個服務較小且獨立，易于在橫向縱向上擴展，也易于按需求對硬件資源進行擴容，因此可擴展性較強；④各服務可以用不同的語言開發，數據庫也可不同，兼容性強；⑤可使開發團隊職責清晰，與IT組織的匹配性更強。當然，微服務架構也存在一些缺點，諸如它有分布式系統固有的復雜性，對運維的要求也較高。

2 實踐應用-技術框架

2.1 架構設計及搭建

首先對燃氣企業最復雜最重要的主營業務系統（物聯網表營銷系統）進行了改造，將原先復雜龐大的單體業務系統進行解耦并微服務化，并選擇了spring boot來進行開發，最終完成的智慧燃氣云系統架構，如圖1所示。

從圖1中可以看出，整個微服務架構的訪問鏈路為：外部請求（web/app）—負載均衡—服務網關（API GateWay）—內部微服務—數據及消息，其中各微服務與APIGatway之間的調用，則會通過統一的服務注冊配置中心來完成。

圖1 智慧燃氣云系統架構

2.2 微服務的服務網關（APIGatway）

燃氣公司的業務功能繁多，可提供的服務也非常多，但顯然客戶端是不需要和每一個服務逐一打交道的，這就需要一個統一的對外入口，在這里搭建了微服務的服務網關（APIGatway）。APIGatway主要包含了對請求的路由和過濾兩個功能，它能動態地將外部請求路由到所需要的的內部微服務集群中，是實現外部訪問統一入口的基礎過濾器。這樣，雖然內部微服務是一個復雜的分布式網狀結構，但外部通過網關來看是一個整體，屏蔽了內部服務的復雜性。APIGatway還具有鑒權、限流、安全等功能。同時，由于它對外暴露的唯一接口，所有的外部請求都將通過它來訪問，為了應對高并發、高可用，需要對APIGatway進行集群形式的部署，并在前端搭建Nginx（應用層）/SLB（網絡層）來進行負載均衡。以上的APIGatway采用了SpringcloudNetflix框架的組件Zuul來實現網關服務。

2.3 微服務的服務注冊與發現

對原先的業務進行了解耦微服務化，這樣就形成了二十幾個微服務組成的微服務集群，那么這些服務之間的通信，就需要服務提供方注冊報告服務地址以及服務調用方能發現服務目標，因此引入了Eureka來進行所有微服務的注冊發現管理。首先搭建EurekaServer以提供服務注冊服務，所有微服務啟動后都會在EurekaServer進行注冊，并通過Eureka Client連接到EurekaServer后定時發送心跳。Eureka默認心跳周期是30s，表明服務仍處于存活狀態，如果連續3次未收到心跳，才會判斷服務死亡然后將之從注冊中刪除。

2.4 熔斷降級監控

新的微服務架構其實是一個分布式系統，同時微服務之間存在著復雜的依賴關系，依賴的調用不可避免地會存在超時、異常、失敗等問題，很可能某個服務的一次延時就會在短時間內耗盡系統資源并導致整體服務崩潰。為解決這樣的雪崩效應，搭建了Hystrix來進行容錯處理，它可以通過熔斷、隔離、回退、降級、限流等機制，對整個微服務集群進行彈性容錯保護，以保證系統的穩定性。

3 實踐應用及效果

在沒有采用微服務架構前，公司的營銷系統平臺采用的是傳統的架構，如圖2所示。

圖2 公司的營銷系統平臺架構

從圖2中可以看到，原來的所有技術架構以及業務應用還是沿襲著傳統的煙囪式的、單一的部署方式，存在著諸多弊端：①集中式架構無法適應技術的發展。無論是大數據分析的需求，還是物聯網帶來的海量數據，這些新的情況都需要向分布式架構部署轉變。②單體架構的業務應用無法面對公司的發展及市場的競爭。原先單體架構對于適應業務的高并發需求、橫向擴展性等非常有限，業務的處理規模及發展也存在著瓶頸，受到了極大的限制。③后期迭代及擴展效率低下。隨著業務的不斷發展，業務平臺也不斷地進行迭代更新，功能越來越多，軟件代碼也越來越復雜。原先的架構導致這些代碼都融合在一個應用程序中，該應用中的各項功能服務之間的邏輯關系也都是在一起的，這就導致如果面臨功能擴展或者邏輯調整，整個迭代的復雜程度會越來越大，時間周期也會越來越長，效率會急劇降低，代碼的可維護性下降，并且建設和維護成本會顯著上升。同時在原先的架構中，一個應用程序中的各項功能服務一般都是訪問同一個數據庫，那么如果遇上服務或者數據庫發生問題，則極易造成全局性的問題。現在按照上文所述的微服務架構，對整個“物聯網表營銷系統”平臺進行了解耦及重構，重構后的業務結構如圖3所示。

圖3 重構后的業務結構圖

從圖3可以看出，前端請求和后端的業務服務中間通過網關來轉接，后面的業務服務由原來的一個笨重的整體轉變為各司其職的狀態，每個業務服務只專注于自身服務范圍內的職責。實踐中根據公司具體的業務現狀以及整體的信息化建設現狀，將原先的業務平臺進行了合理的解耦，比如通訊采集微服務僅負責與各種物聯網設備進行通訊并采集其數據；營收結算微服務負責按照公司的結算規則定期對用戶的繳費用氣情況進行結算；設備微服務負責所有的設備全生命周期管理，包括出入庫、維修等；派單微服務則專門負責整個工單系統的派單、接單、回單等。各微服務系統之間的邏輯關系非常清晰，管理方便。并且能夠根據各種服務的特性，部署不同的數據庫。比如對于這里面海量數據處理以及后續預期擴展性要求較高的物聯網表通訊采集服務選用了MongoDB，對于適用關系型數據庫及穩定性要求較高的其他業務服務選用了Mysql。同時這樣的架構也使故障可隔離，比如假設通訊采集服務發生故障，并不影響其他業務的使用，類似開戶報裝、充值繳費等業務仍舊可以正常運行，而不像以前，一旦發生故障，則所有的業務都將停止，造成巨大的惡劣影響。

改造上線后，最直接的效果就是原先的開發上線周期明顯變得更加敏捷。通過統計了3個月的開發需求迭代記錄發現，顯示由原來的平均32人天/項大幅提升至平均15人天/項，同時，由于微服務架構將相關聯的業務邏輯及數據放在一起形成了獨立的邊界，某些服務的更新不影響其他服務，大大提高了快速交付能力。本案例中，改造后的迭代上線時間也大幅縮短，由原先4～6h大幅縮短至1h以內，這些都意味著今后這個架構平臺對于企業數字化轉型需求的支持能力是顯著提升的。

微服務架構的價值還不僅僅體現在當下，其通過對業務服務的解耦拆分，將不同的業務應用及數據分布式部署在云平臺上，能夠真正發揮云計算的算力，使城燃企業的信息化系統更適合云上生態。同時微服務架構的搭建，還可以使燃氣企業未來能夠更加方便、高效、精準地搭建自己的數據中臺及業務中臺，從而為大數據、AI等數字化轉型新技術提供強有力的支撐，比如通過用戶畫像分析、消費行為分析等實現精準營銷，來賦能城燃企業數字化轉型。

4 結束語

本文通過實踐案例闡述了微服務架構的搭建以及在城燃企業中的具體應用。可以看到，微服務這種去中心化的架構理念不僅能有效解決原先煙囪式架構的各種痛點，也比較契合云計算、大數據分析以及人工智能等新技術的發展，更能夠給未來燃氣企業的業務融合、大數據分析、數據資產化等提供很好的基礎支撐，并為正探索數字化轉型的燃氣企業提供了一種比較適宜的方法。