文/呂亮亮
隨著信息科技的發(fā)展,石油化工企業(yè)內(nèi)部部署了大量的信息系統(tǒng)用于處理日常業(yè)務(wù),比如為了滿足生產(chǎn)需要,石油化工企業(yè)引入了各種自動化生產(chǎn)系統(tǒng)用于生產(chǎn)過程的管理,監(jiān)督和監(jiān)控。目前各企業(yè)內(nèi)部已部署了超過一百個應(yīng)用系統(tǒng)。隨著應(yīng)用系統(tǒng)的快速增加以及規(guī)模日益復(fù)雜,功能模塊之間的邊界劃分越來越模糊,造成很多功能的重復(fù)以及架構(gòu)復(fù)雜化的問題。但是靠單個系統(tǒng)的獨立使用、獨立實現(xiàn)的方式已經(jīng)不能滿足石油化工企業(yè)的生產(chǎn)需要,因此需要一種新的軟件架構(gòu)來改變當(dāng)前的系統(tǒng)開發(fā)模式,提供系統(tǒng)的質(zhì)量以及生產(chǎn)效率。提升軟件復(fù)用性,從面向過程發(fā)展到面向?qū)ο?,再到現(xiàn)在的微服務(wù),微服務(wù)架構(gòu)是一種非常高效的軟件復(fù)用方式,在實際的業(yè)務(wù)中得到了大量的應(yīng)用。
信息系統(tǒng)的建設(shè)具有一定的歷史發(fā)展軌跡,最開始為了解決企業(yè)內(nèi)部的信息管理問題發(fā)展出了ERP系統(tǒng)。隨著企業(yè)辦公自動化需求的增長又演化出了OA系統(tǒng)。隨著客戶關(guān)系管理的需要又發(fā)展出了CRM系統(tǒng)。由于這些系統(tǒng)開發(fā)的時間不一樣,開發(fā)的架構(gòu)不一樣,因此隨著時間的演進,各種系統(tǒng)之間的集成成了新系統(tǒng)開發(fā)面臨的一道難題。
微服務(wù)的概念是Martin Fowler在2014年拋出,用于解決各種異構(gòu)系統(tǒng)的集成問題。最早微服務(wù)架構(gòu)概念的誕生,便是Martin Fowler所在的公司Thoughtworks在集成各個企業(yè)系統(tǒng)時提出的一種解決方案。為了能夠有效的解耦企業(yè)中互相依賴的系統(tǒng),Thoughtworks提出了一種應(yīng)用服務(wù)單一化的解決方案來形成一套簡潔、高彈性的系統(tǒng)架構(gòu)。微服務(wù)架構(gòu)靈活的運用了虛擬容器的概念,將以前單一的應(yīng)用比如CRM等使用獨立的容器進行隔離,然后通過對外暴露API的方式來對其他系統(tǒng)提供服務(wù)。一般而言對外API采用HTTP API等輕量級的解決方案。由于虛擬容器采用了Doker等技術(shù),因此十分便于進行自動化的集成、部署以及運維,并且成功的解決了異構(gòu)系統(tǒng)的問題。
微服務(wù)的架構(gòu)需要將不同的應(yīng)用進行微服務(wù)化,從而實現(xiàn)自動化的部署以及快速迭代開發(fā)。一般而言在設(shè)計微服務(wù)的架構(gòu)時需要滿足如下原則:
(1)單一職責(zé)原則。也就是每一個應(yīng)用或者服務(wù)只做一件事,集中精力解決自身的業(yè)務(wù)邏輯。比如crm系統(tǒng)只負責(zé)對客戶相關(guān)的數(shù)據(jù)進行處理,而不用負責(zé)客戶報表的分析。
(2)獨立服務(wù)原則。也就是每一個微服務(wù)是一個獨立的開發(fā)組建,具有獨立的開發(fā)、測試、部署、運維、持續(xù)集成、優(yōu)化等體系,類似一個獨立的軟件,對依賴進行解耦合。
(3)通信的輕量級架構(gòu)。微服務(wù)任務(wù)不同服務(wù)或者模塊之間的通信應(yīng)該是輕量的,不應(yīng)該過多的耗費系統(tǒng)資源。同時通信方式需要跨語言、跨平臺。
(4)明確的接口定義。在微服務(wù)架構(gòu)下,不同的模塊通過調(diào)用接口來進行交互。為了對接口依賴進行解耦合,在設(shè)計接口時,要盡量通用,防止某個服務(wù)接口的修改影響到整個系統(tǒng)的運行。
微服務(wù)具有如下優(yōu)點:
(1)易于開發(fā)和維護,由于微服務(wù)的單一、獨立、輕量的特點,在開發(fā)單獨的微服務(wù)時業(yè)務(wù)功能清晰、代碼復(fù)用性高。開發(fā)、測試、部署的自動化能力強,因此十分有利于開發(fā)及運維。
(2)服務(wù)的速度快、效率高。由于微服務(wù)業(yè)務(wù)邏輯的簡潔性,系統(tǒng)耗費資源有限,因此單一的微服務(wù)運行效率較高。
(3)易于升級及修改。由于微服務(wù)的輕量級特性以及接口的明確性,當(dāng)某一個服務(wù)出現(xiàn)bug后,不會影響當(dāng)整個系統(tǒng)的穩(wěn)定性。同時由于獨立性原則,在修改bug后能夠快速進行部署及持續(xù)集成,修復(fù)問題。
(4)技術(shù)的多樣性。由于微服務(wù)的跨語言、跨平臺特性,因此開發(fā)微服務(wù)時并不局限在某一個特定的語言上。不管是java還是node.js,只要在開發(fā)時滿足微服務(wù)的架構(gòu),那么可以方便的進行相互的替換,降低開發(fā)成本。
(5)按需伸縮,由于各個模塊的獨立性,當(dāng)對某個模塊進行擴展時,不會對系統(tǒng)的整體帶來影響。
圖1:微服務(wù)應(yīng)用架構(gòu)設(shè)計
針對目前企業(yè)內(nèi)部系統(tǒng)眾多,架構(gòu)不統(tǒng)一,重復(fù)較多的情況,本文為企業(yè)內(nèi)部系統(tǒng)設(shè)計了微服務(wù)架構(gòu),統(tǒng)一各系統(tǒng)的服務(wù)標(biāo)準(zhǔn),架構(gòu)的邏輯設(shè)計如圖1所示。
整個架構(gòu)分為三層體系,核心層負責(zé)實現(xiàn)各個服務(wù),同時提供運維監(jiān)控手段對服務(wù)進行監(jiān)控。集成層將各個業(yè)務(wù)系統(tǒng)提供的服務(wù)接口進行集成,形成統(tǒng)一的服務(wù)標(biāo)準(zhǔn)為應(yīng)用層提供服務(wù)。前端應(yīng)用層通過服務(wù)路由、負載均衡等手段來負責(zé)服務(wù)的分發(fā)。針對企業(yè)內(nèi)部系統(tǒng)較多的問題,首先對各個系統(tǒng)的業(yè)務(wù)功能進行定位。對業(yè)務(wù)系統(tǒng)對外提供的服務(wù)進行標(biāo)準(zhǔn)化。其次建立統(tǒng)一的服務(wù)注冊中心,將業(yè)務(wù)系統(tǒng)的服務(wù)在注冊中心進行服務(wù),當(dāng)其他系統(tǒng)需要在線調(diào)用服務(wù)時,在注冊中心的服務(wù)目錄中進行查找,匹配需要的服務(wù)。具體的技術(shù)架構(gòu)如圖2所示。
使用AMQP作為服務(wù)標(biāo)準(zhǔn)化的中間組件進行服務(wù)的注冊、標(biāo)準(zhǔn)化及分發(fā)。使用MongoDB存儲服務(wù)的相關(guān)信息。使用Elasticsearch對服務(wù)進行搜索管理。在服務(wù)接口層,各個系統(tǒng)使用Restful接口進行調(diào)用,Restful可以有效的解決異構(gòu)系統(tǒng)、不同平臺以及不同開發(fā)語言的問題,同時使用Redis對服務(wù)調(diào)用進行緩存,提高系統(tǒng)的效率。日志系統(tǒng)使用Flume,可以支持海量的日志讀寫。使用Docker作為容器來獨立部署各個服務(wù),Docker是為應(yīng)用提供隔離的環(huán)境,并跟蹤文件系統(tǒng)的變化,獨立于主機操作系統(tǒng)的配置。同時Docker的使用讓該系統(tǒng)的自動部署、自動監(jiān)控成為可能,讓企業(yè)從手工運維轉(zhuǎn)型為Devops的方式自動進行。
圖2:微服務(wù)技術(shù)架構(gòu)圖
隨著石油化工企業(yè)信息系統(tǒng)的發(fā)展,各類信息系統(tǒng)變得越來越臃腫,很難持續(xù)、高效的為企業(yè)帶來業(yè)務(wù)價值。而且隨著企業(yè)信息架構(gòu)的混亂,嚴(yán)重的影響著開發(fā)效率、運維管理效率,為企業(yè)帶來了諸多隱患。為解決石油化工企業(yè)中不斷增加的系統(tǒng)應(yīng)用所帶來的重復(fù)率增加、系統(tǒng)架構(gòu)混亂的問題,本文采用微服務(wù)的架構(gòu)理念對企業(yè)的系統(tǒng)架構(gòu)進行了重構(gòu),將應(yīng)用系統(tǒng)進行解耦,使用微服務(wù)的方式統(tǒng)一企業(yè)的服務(wù)。同時針對設(shè)計的微服務(wù)架構(gòu),本文使用Docker等技術(shù)介紹該架構(gòu)的實施方法,有效的提高了企業(yè)信息系統(tǒng)的擴展性。通過微服務(wù)架構(gòu)的重構(gòu),企業(yè)的信息化架構(gòu)變得清晰明了,IT開發(fā)效率得到了較大提升,隨著運維管理自動化的部署,企業(yè)的運維安全水平也得到了較大的提升。隨著微服務(wù)的獨立部署,有效的滿足了各個業(yè)務(wù)部門的需求,實現(xiàn)了企業(yè)的價值。