方志寧，謝 華，張金營，曹亞南

（1.國電電力發(fā)展股份有限公司，北京 100101；2.國能信控互聯(lián)技術有限公司，北京 102209）

0 引言

企業(yè)因受制于傳統(tǒng)IT技術的影響，多沿用傳統(tǒng)單體式架構進行一系列平臺構建等開發(fā)工作[1]，但是隨著工業(yè)技術的不斷發(fā)展和迭代，企業(yè)信息化建設愈發(fā)趨向一體化，傳統(tǒng)IT架構無法應對當前業(yè)務數(shù)據(jù)幾何倍增長，應用服務不斷延伸迭代的情況[2]。單體式架構系統(tǒng)其拓展性低，開發(fā)工作重復嚴重，運維難度大，代碼耦合程度高等弊端日益顯著[3]，前中期系統(tǒng)平臺的開發(fā)和后期運維工作難度急劇上升。

為改善現(xiàn)階段平臺系統(tǒng)開發(fā)工作和運維工作內(nèi)容重復、難度過大等問題，本文一改傳統(tǒng)使用單體式架構中心化開發(fā)建設系統(tǒng)的理念，將復雜應用細粒化劃分服務[4]，提出基于微服務架構搭建的統(tǒng)一應用開發(fā)平臺。在平臺設計中，將一個復雜進程拆分成數(shù)個甚至數(shù)十個相互之間具有獨立性的組件，相關功能組件封裝成單一業(yè)務服務，在進行拓展時只操作對應功能的微服務，而非類似單體式架構需要將應用程序堆棧進行整體處理[5]。應用組件化，組件服務化，將軟件產(chǎn)品開發(fā)中重復繁瑣的步驟抽離出來，讓開發(fā)更簡單、更快速。

國內(nèi)外企業(yè)越來越多采用新型微服務架構搭建系統(tǒng)框架[6]，國內(nèi)外成功代表案例諸如Alibaba、京東、Walmart、Amazon等。眾多國內(nèi)外企業(yè)成功案例表明，微服務架構作為一種系統(tǒng)框架在解決如今復雜業(yè)務導致的諸多問題上具有極為強大的能力。

文獻[7,8]介紹了系統(tǒng)架構的演變及微服務架構的優(yōu)缺點，文獻[9-11]結合實踐案例進行分析。本文提出了基于微服務架構的統(tǒng)一應用開發(fā)平臺，針對該平臺的開發(fā)可有效提高應用開發(fā)效率，降低系統(tǒng)運維難度。

1 微服務架構

2012年3月類似最初版本的微服務架構概念在Agile India中被Fred George描述，在演講中他描述了2005年～2009年間Fred George團隊實踐分析一百萬行的傳統(tǒng)程序代碼，最終將其分解為兩百余個類似于微服務組件的經(jīng)歷。盡管演講中并未明確提出微服務架構這一名詞概念，但是最初版本的微服務架構概念在Fred George的經(jīng)歷中已現(xiàn)雛形。

微服務架構總的來說是一種特殊的面向服務架構（SOA），是指將復雜應用進程細?；瘎澐殖芍痪哂袉我还δ艿慕M件，根據(jù)組件的各自功能將其封裝成離散的、可獨立部署的微服務，進而實現(xiàn)服務間的解耦。開發(fā)時不同服務可選擇不同的開發(fā)技術，服務邊界明確，不同服務間可以通過直接使用REST/JSON等輕量級通信協(xié)議進行協(xié)調(diào)溝通，避免了使用企業(yè)服務總線（ESB）所帶來的上限問題。在實際生產(chǎn)中，業(yè)務進程由一組服務相互配合而成，開發(fā)過程中將相關業(yè)務邏輯結合數(shù)據(jù)組合成獨立業(yè)務部署單元。

微服務架構本質(zhì)是由多個服務組合成的分布式系統(tǒng)，基于微服務架構開發(fā)框架目的是在不影響其它應用組件的情況下，更快地實現(xiàn)新功能的拓展和老功能的迭代，降低系統(tǒng)運維難度。

現(xiàn)對微服務架構主要特性總結為以下6方面：

1）技術多元：微服務架構下，團隊開發(fā)服務時可以根據(jù)當前技術員技術偏重以及行業(yè)發(fā)展情況，選擇合適的技術棧進行開發(fā)。

2）粒度可控：將復雜應用程序分解為應用服務或者可獨立部署的組件時，根據(jù)劃分業(yè)務服務的復雜程度可以人為地控制微服務框架的粒度。

3）拓展強大：將服務組合成應用后，將整個應用完整地復制到不同的節(jié)點可實現(xiàn)應用進程的橫向拓展，每個應用都可以根據(jù)實際生產(chǎn)需求進行拓展。

4）去中心化：避免企業(yè)服務總線的瓶頸缺點，服務之間通過輕量化通信協(xié)議相互協(xié)調(diào)，且各個服務可獨立部署。

5）快速開發(fā)：根據(jù)應用進程所需業(yè)務功能將各個微服務接口連接，可實現(xiàn)快速地開發(fā)應用進程。

6）自治應用：服務的邊界確定，暴露固定接口，每個微服務可獨立封裝業(yè)務邏輯，以獨立進程運行，所以具備可獨立開發(fā)、測試和部署的能力。平臺開發(fā)應用高內(nèi)聚，低耦合，應用間具備一定的自治能力。

2 基于微服務架構的統(tǒng)一應用開發(fā)平臺

統(tǒng)一應用開發(fā)平臺構架于國電電力大數(shù)據(jù)（Hadoop）下的一個應用快速開發(fā)平臺。此平臺在設計過程中總結各方面的應用案例，結合研究人員多年開發(fā)經(jīng)驗，推翻了以往的傳統(tǒng)架構。在對平臺的設計中采用了微服務架構，同時將平臺定位為低代碼開發(fā)平臺，極大地提升了開發(fā)效率。該應用開發(fā)平臺全面支持應用監(jiān)控與追蹤、服務治理、配置管理、去中心化的服務組件、負載均衡可靠性保障等多種特性。

2.1 平臺介紹

統(tǒng)一應用開發(fā)平臺微服務架構如圖1。平臺開發(fā)設計定位于后臺開發(fā)框架和企業(yè)級快速開發(fā)解決方案，在數(shù)字化高速發(fā)展的今天，供需兩側程序員數(shù)量及質(zhì)量不對等，需大于供，因此平臺的開發(fā)方式選用了低代碼開發(fā)，易于開發(fā)設計應用進程。平臺支持分布式部署，采用松耦合設計，微內(nèi)核和插件架構，去中心化管理。平臺整體設計與開發(fā)遵循了Spring Cloud的技術開發(fā)路線，從功能上涵蓋了統(tǒng)一身份認證、電子表單、工作流引擎、組態(tài)工具等應用開發(fā)組件；平臺集成了數(shù)字化應用商店和工程項目開發(fā)的全生命周期的管理。在平臺的設計過程中也針對平臺的安全方面做了對應設計，例如平臺采取統(tǒng)一身份認證，設置密碼策略、安全審計、日志收集等眾多安全選項，極大地降低了微服務系統(tǒng)架構分布式部署這種模式所帶來的安全風險。

圖1 統(tǒng)一應用開發(fā)平臺微服務架構Fig.1 Microservice architecture of unified application development platform

2.2 平臺核心功能研究

統(tǒng)一應用開發(fā)平臺核心功能體現(xiàn)在如下8個方面：

1）低代碼開發(fā)

平臺的低代碼開發(fā)是基于對象模型驅(qū)動的，其中包括了對象建模、權限建模、流程建模、上層表單建模、報表建模、擴展規(guī)則建模6種建模能力，通過API接口驅(qū)動前后端進行整合，體現(xiàn)出SOA分層架構。低代碼開發(fā)中在對核心的對象建模驅(qū)動完成后，繼續(xù)向下層生成了數(shù)據(jù)庫表和數(shù)據(jù)對象，同時向上打開了標準的API接口服務，從而推動上層的自定義和表單建模。在此過程中可以綁定底層對象開放的API接口，也可以集成拓展規(guī)則建模能力，在建模結束后提供拓展相應的報表建模能力。

2）流程引擎

流程引擎是低代碼開發(fā)的核心，是將業(yè)務服務按照設定的固定路徑進行流轉(zhuǎn)，將服務應用步驟轉(zhuǎn)換成計算機能理解的形式。在開發(fā)過程中，通過拖拽進行流程設計，流程服務化，獨立部署。通過連接服務節(jié)點實現(xiàn)應用鏈式結構，每個連接節(jié)點作為當前鏈頭節(jié)點，服務內(nèi)包含下層連接節(jié)點索引，實現(xiàn)應用進程流程可視化。

3）統(tǒng)一認證

統(tǒng)一認證模式通過統(tǒng)一身份認證實現(xiàn)。平臺統(tǒng)一身份認證采用層次式結構，將平臺統(tǒng)一認證分為三層次的層級結構，分別為數(shù)據(jù)層、認證通道層、認證接口層。在平臺中，統(tǒng)一身份認證的主要功能模塊有兩種，分別為用于進行統(tǒng)一認證的身份認證模塊和應用內(nèi)進行權限設定的權限管理模塊，通過調(diào)用兩個功能模塊隔離異常登錄行為，確保平臺身份安全。建立自動化的賬號同步體系，達到在平臺中單點登錄后可跨應用認證的賬號同步體系，同時在不同業(yè)務進程內(nèi)自行設定權限控制，以實現(xiàn)對用戶的權限管理。

4）組態(tài)能力

平臺中的組態(tài)能力是指與硬部件組裝類似的，通過在系統(tǒng)中預設封裝好的“軟部件”，應用中通過拖動對應的2D圖像進行對業(yè)務框架的一個搭建，搭建好框架后只需設置好軟部件參數(shù)即可將搭建的程序投入使用。組態(tài)能力提供了平臺無代碼開發(fā)的功能，同時組態(tài)軟件也提供了相應的編程手段，可實現(xiàn)無代碼開發(fā)與常規(guī)代碼開發(fā)的協(xié)調(diào)合作。同時平臺對接了不同的數(shù)據(jù)源，在大屏以及監(jiān)控方面可以實現(xiàn)廣泛的應用。

5）定時任務管理

平臺在采取基于數(shù)據(jù)庫動態(tài)配置的方法對任務實行動態(tài)管理。平臺對任務進行管理時，摒棄了傳統(tǒng)方法中在代碼程序明確固定表達式的方法，采用了基于數(shù)據(jù)庫讀取定時任務的設定執(zhí)行時間的方法。在對任務進行修改時，無需對系統(tǒng)進行重啟，降低了運維和追蹤的難度。平臺統(tǒng)一管理定時任務，提供了統(tǒng)一的開發(fā)標準，提供了可視化界面，系統(tǒng)在開發(fā)應用時的效率得到大幅度提升，相關工作步驟得到有效優(yōu)化。

6）文檔儲存組件

平臺提供了高性能、分布式的對象儲存能力。平臺將數(shù)據(jù)儲存在一組分布式獨立部署的服務器中，通過獨立服務器分擔系統(tǒng)數(shù)據(jù)儲存負荷，因此系統(tǒng)結構具備強拓展性。平臺通過查詢服務器的位置信息定位所需的儲存信息，根據(jù)不同場所部署相應功能的服務器，再通過軟件將服務器連接成高性能邏輯池。平臺所使用文件儲存架構具備高度可靠性，支持多種儲存服務，例如支持Hadoop組件HDFS。

7）工程項目管理

針對平臺開發(fā)的項目進行項目生命周期管理，制定為國電電力業(yè)務軟件開發(fā)的規(guī)范編制。其中包括：應用開發(fā)統(tǒng)一規(guī)范、應用開發(fā)UI設計規(guī)范、應用開發(fā)編碼規(guī)范、應用開發(fā)數(shù)據(jù)庫設計規(guī)范、應用開發(fā)集成規(guī)范、應用分類標識規(guī)范、應用功能與權限標識規(guī)范。對業(yè)務軟件的開發(fā)制定出一整套全方位的標準，統(tǒng)一代碼風格，提供開發(fā)約束，降低服務開發(fā)團隊間的交流成本。

8）應用商店

平臺開發(fā)團隊通過Html、JavaScript、CSS等技術開發(fā)出應用商店體系。通過將平臺開發(fā)的應用以及公共業(yè)務應用等進行收納，通過統(tǒng)一標準進行管理，形成應用商店體系，方便用戶下載使用各類業(yè)務應用。應用商店提供給用戶統(tǒng)一入口，通過用戶統(tǒng)一身份認證可快速接入入口，找到應用后無需再次登入，即用即取。

圖2 平臺總體服務架構設計Fig.2 Overall service architecture design of the platform

2.3 平臺總體架構設計

統(tǒng)一應用開發(fā)平臺開發(fā)設計遵循Spring Cloud的技術開發(fā)路線，平臺核心功能作為公共組件，可封裝組成微服務，組件服務化。

微服務的核心是將進程劃分成多個獨立服務，并要求服務之間具備松耦合等特性，要求整體架構更徹底地去中心化。Spring Cloud是分布式微服務架構的一站式解決方案[10]，Spring Cloud提供了一套十分通俗易懂、應用方便的編程模型，Spring Cloud在總體架構設計中基于Spring Boot的基礎上可以輕松構建微服務。

平臺基于Spring Boot提供微服務開發(fā)組件，客戶端發(fā)送Restful風格的Web請求。請求通過Nginx服務端負載均衡器分配節(jié)點向網(wǎng)關發(fā)送API調(diào)用，Spring Cloud Gateway收到調(diào)用請求后對信息進行二次處理，完成后向Nacos注冊中心查詢微服務地址。注冊中心返回微服務HTTP地址后，Spring Cloud Gateway對其進行服務調(diào)用，根據(jù)調(diào)用微服務所需數(shù)據(jù)，從數(shù)據(jù)總線中獲取對應數(shù)據(jù)。

在去中心化的架構中，對于注冊發(fā)現(xiàn)還是中心化的。平臺通過將注冊中心集群化處理，在微服務端設置微服務目錄和微服務列表的緩存，避免注冊中心宕機后整個微服務調(diào)用失敗的發(fā)生。

平臺使用了Spring Boot Admin、Sleuth Zipjkin、Hystrix、Sentinel實現(xiàn)對平臺的監(jiān)控保護：

1）Spring Boot Admin作為當前的主流開源項目，應用程序端的Admin Client通過基于HTTP實現(xiàn)的RESTful協(xié)議使用注冊中心，或者通過Admin Server注冊實現(xiàn)監(jiān)控管理應用程序的功能。

2）Sleuth Zipjkin通過將分布式請求還原成調(diào)用鏈路，同時在鏈路上生成Trace ID和Span ID進行日志記錄，以達到展現(xiàn)原分布式請求調(diào)用信息的目的，并且提供API供客戶端查詢追蹤數(shù)據(jù)。同時提供UI組件，使客戶端便捷實現(xiàn)對請求的搜索跟蹤、分析分布式請求，調(diào)用鏈路日志明細等服務。

3）Hystrix（斷路器）使用基于異常比率的熔斷降級策略，通過線程池或者信號量隔離的隔離策略隔離訪問遠程系統(tǒng)、服務和第三方庫。

4）Sentinel使用基于響應時間、異常比率和異常數(shù)的熔斷降級策略，通過信號量隔離進行限流功能。

Nacos Config配置中心提供Serve端和Client端，Serve端提供配置文件儲存，并通過HTTP向與開發(fā)段分離的配置中心提供基于微服務的API。Client端設置在各個微服務端，通過接口接收配置修改數(shù)據(jù)后，依據(jù)接收到的數(shù)據(jù)初始化對應微服務應用，并向數(shù)據(jù)庫發(fā)送修改的配置屬性記錄。在使用Spring Cloud開發(fā)框架引用管控、治理方面內(nèi)容時，傳統(tǒng)的開發(fā)方式為在開發(fā)階段就考慮實現(xiàn)相應接口并且組建相應的配置文件，但到服務治理開發(fā)階段時，開發(fā)端和服務的管控治理端嚴重耦合，想要修改就需修改開發(fā)源碼并對服務重新部署。微服務在開發(fā)端的重點為實現(xiàn)微服務必備的業(yè)務功能，同時暴露相應接口，對于微服務組件以及API服務接口的管控治理方面的能力應在去中心化的服務治理端實現(xiàn)，與開發(fā)端主要職能分離。平臺采用運行態(tài)的配置模式，可以動態(tài)地調(diào)整配置參數(shù)，對管控治理端的修改也無需再對服務重新部署。

平臺通過在微服務組件端下發(fā)一個代理，通過對流量的攔截，達到良好的相關管控和治理能力。例如微服務A調(diào)用微服務B時，應靈活可配置，通過配置調(diào)用過程中相關日志的審計與記錄、配置具體熔斷規(guī)則等方式，達到“訪問安全，數(shù)據(jù)安全”的目標，后期不需要對微服務本身再做修改。

3 結語

本文提出的統(tǒng)一應用開發(fā)平臺是基于微服務架構相關技術來設計和實現(xiàn)的，旨在解決單體式架構拓展性低，部分開發(fā)工作重復嚴重，運維難度大，代碼耦合程度高等問題，可以有效地支撐業(yè)務開發(fā)團隊快速地構建微服務；提出了統(tǒng)一的開發(fā)標準，增強了系統(tǒng)的安全與穩(wěn)定，具有良好的拓展性。