作者：張允君，衛(wèi)潔，付小攀，彭霄

（遠光軟件股份有限公司）

0　引言

隨著信息化的發(fā)展，信息化建設(shè)對于企業(yè)發(fā)展與經(jīng)營管理起到了明顯積極正向的作用與促進，企業(yè)對信息化也提出了更高的要求，諸如：快速響應(yīng)業(yè)務(wù)需求，IT 架構(gòu)彈性擴展、系統(tǒng)應(yīng)用場景化等。

IT 業(yè)界各大公司及資深專家都在探索研究相應(yīng)的解決思路與配套方案。2012 年5 月Martin fowler發(fā)文首提微服務(wù)架構(gòu)概念，指出微服務(wù)是一個架構(gòu)風(fēng)格與設(shè)計理念，可以是一種企業(yè)信息化架構(gòu)模式，也可以是一個信息系統(tǒng)的架構(gòu)模式。一個大型應(yīng)用由一套微服務(wù)組成，系統(tǒng)中的每個微服務(wù)可被獨立部署，每個微服務(wù)之間是松耦合的，并以輕量級機制進行通信。每個微服務(wù)僅關(guān)注于完成一件任務(wù)，代表某個場景的業(yè)務(wù)能力。一個服務(wù)能夠被其團隊在2 周之內(nèi)重寫，這樣規(guī)模的服務(wù)可稱為微服務(wù)，以便滿足敏捷、快速交付的需要。

微服務(wù)架構(gòu)理念首先被國外企業(yè)應(yīng)用，如Amazon、eBay 等。近2 年，國內(nèi)一些創(chuàng)新企業(yè)開始嘗試采用微服務(wù)架構(gòu)替換傳統(tǒng)IT 架構(gòu)（SOA 架構(gòu)）。伴隨微服務(wù)架構(gòu)應(yīng)用的逐步深入，與微服務(wù)相當(dāng)?shù)囊粋€概念“微應(yīng)用”應(yīng)運而生，但目前尚未有權(quán)威機構(gòu)對此概念進行定義。

基于微服務(wù)架構(gòu)等理念，結(jié)合應(yīng)用實踐，微應(yīng)用是指采用微服務(wù)架構(gòu)理念的一種軟件形式。具備以下關(guān)鍵特征：由一組后臺微服務(wù)及前端應(yīng)用界面組合而成；具有交互界面可以直接面向終端用戶；以領(lǐng)域驅(qū)動設(shè)計（Domain-Driven Design，DDD）為指導(dǎo)思想進行設(shè)計；可以按需靈活組合后端微服務(wù)以滿足多場景業(yè)務(wù)需求。

1　國內(nèi)外微服務(wù)架構(gòu)研究應(yīng)用概況

1.1　業(yè)界關(guān)注熱度分析

近幾年，微服務(wù)受業(yè)界關(guān)注的熱度持續(xù)攀升（見圖1、2）。

圖1 和圖2 首先體現(xiàn)了微服務(wù)概念受的關(guān)注度在持續(xù)穩(wěn)步提升；其次，從一定程度上說明微服務(wù)架構(gòu)理念也正在被更為廣泛地認可；最后，從一定程度上說明受信息化發(fā)展需求地驅(qū)動，微服務(wù)架構(gòu)已經(jīng)被較為廣泛地認為是一種潛在解決方案或思路。

1.2　部分企業(yè)研究概況

據(jù)不完全統(tǒng)計，目前國內(nèi)外已有較多企業(yè)在開展或已實現(xiàn)微應(yīng)用/ 微服務(wù)架構(gòu)的研究、實施、落地應(yīng)用工作。互聯(lián)網(wǎng)類公司在信息化架構(gòu)方面步伐較快，起到了預(yù)研究、探索、引領(lǐng)的作用。信息化應(yīng)用方與提供方都在向微服務(wù)架構(gòu)方向行進。部分有代表性的公司/ 企業(yè)分析如下。

1）eBay。eBay 公司自1995 年起經(jīng)歷數(shù)代信息化架構(gòu)演進，從單體架構(gòu)演進至SOA 架構(gòu)，歷時3 年于2014 年完成了從SOA 架構(gòu)向微服務(wù)架構(gòu)的演進。

2）Amazon。Amazon 公司自1995 年起經(jīng)歷多輪信息化規(guī)劃、改造、整合、融合及架構(gòu)演進。大體是從單體架構(gòu)演進至SOA 架構(gòu)、SOA 架構(gòu)融合單體架構(gòu)、SOA 架構(gòu)改造優(yōu)化（云化等），歷時3 年于2014 年完成大部分核心應(yīng)用系統(tǒng)的微應(yīng)用化，并正在開展全面微服務(wù)架構(gòu)化的演進工作。

3）阿里巴巴。阿里巴巴公司自1999 年起，信息化建設(shè)從無到有，完成多輪信息化規(guī)劃、建設(shè)、整合、融合及架構(gòu)演進。大體是從單一網(wǎng)站到單體架構(gòu)，從單體架構(gòu)到SOA 架構(gòu)，從SOA 架構(gòu)到混合架構(gòu)，從混合架構(gòu)經(jīng)歷規(guī)劃、整合、融合到SOA 架構(gòu)，從SOA 架構(gòu)向微服務(wù)架構(gòu)演進，目前正處于SOA 架構(gòu)與微服務(wù)架構(gòu)的混合架構(gòu)中，并正在開展全面微服務(wù)架構(gòu)化的演進工作。

4）遠光軟件股份有限公司。遠光軟件股份有限公司自1998 年成立，致力于電力行業(yè)集團資源管理軟件研發(fā)供應(yīng)，經(jīng)歷了企業(yè)本身以及所服務(wù)大客戶的多輪信息化架構(gòu)演進，并于2013 年起研究微服務(wù)架構(gòu)，目前正在開展全面以“微服務(wù)+ 云平臺”為整體理念的企業(yè)微服務(wù)架構(gòu)演進工作。

5）國家電網(wǎng)公司。國家電網(wǎng)公司自成立起，經(jīng)過多年信息化建設(shè)，完成多輪信息化規(guī)劃、建設(shè)、整合、融合及架構(gòu)演進。2006 年起，歷經(jīng)SG186、SGERP、集中部署等工程建設(shè)，充分引入SOA 架構(gòu)理念，已實現(xiàn)“縱向貫通、橫向集成”。目前正在開展微服務(wù)架構(gòu)的研究與實踐嘗試工作。

2　特定企業(yè)部分特征

并非所有的企業(yè)都適合采用微服務(wù)架構(gòu)理念開展信息化建設(shè)工作，并非所有的企業(yè)在微服務(wù)架構(gòu)落地過程中的思路、方法、關(guān)注點都完全相同，同時，微服務(wù)架構(gòu)理念并非適用于所有應(yīng)用場景。本文相關(guān)結(jié)論與建議適用于具有以下特征的相關(guān)企業(yè)。

2.1　企業(yè)組織特征

1）集團性質(zhì)企業(yè)。表現(xiàn)為以總部為核心、多層次的組織結(jié)構(gòu)；在內(nèi)部的管理體制上，表現(xiàn)為企業(yè)集團中各成員企業(yè)，既保持相對獨立的地位，又實行統(tǒng)一領(lǐng)導(dǎo)和分層管理的制度，建立了集權(quán)與分權(quán)相結(jié)合的領(lǐng)導(dǎo)體制。

2）金字塔型集團。金字塔型結(jié)構(gòu)又稱持股型結(jié)構(gòu)，是標(biāo)準(zhǔn)的產(chǎn)權(quán)控制模式；意味著上層組織對下層單位有強管控能力，采用強管控的模式進行經(jīng)營管理。

3）具備一定研發(fā)實力。企業(yè)內(nèi)部具有一定的研發(fā)實力，可以獨立完成或借助外力完成信息化軟件的需求、設(shè)計、研發(fā)、運維。

2.2　信息化相關(guān)特征

1）信息化應(yīng)用程度深。企業(yè)已經(jīng)開展了較長時間（3 年及以上）的信息化建設(shè)、運維工作，企業(yè)內(nèi)部當(dāng)前的信息化架構(gòu)為SOA 或帶有SOA 架構(gòu)的混合架構(gòu)。

2）信息化應(yīng)用場景多。從崗位角色覆蓋面而言，企業(yè)內(nèi)部的大部分崗位或角色都有需要通過信息化手段完成的經(jīng)營、管理的需求或要求。從信息化層次結(jié)構(gòu)而言，應(yīng)用場景涵蓋實施操作層、經(jīng)營管理層、戰(zhàn)略決策層等多個層面。

3）信息化需求變動頻繁。受各類因素驅(qū)動，信息化相關(guān)業(yè)務(wù)需求變動頻繁，且希望信息化變動需求能夠在較短（以周為單位）時間內(nèi)得到響應(yīng)與落地應(yīng)用。

3　遠光軟件應(yīng)用微化實踐

在確定了采用微服務(wù)架構(gòu)方案后，從傳統(tǒng)架構(gòu)演進至微服務(wù)架構(gòu)是一個系統(tǒng)工程。結(jié)合遠光軟件股份有限公司的實踐過程進行分析，應(yīng)用微化實踐過程中的推進思路與實踐步驟。

3.1　微應(yīng)用生態(tài)圈的組成

落地微服務(wù)架構(gòu)，首先要認識到微應(yīng)用實際上是一個生態(tài)圈，生態(tài)圈中包含的關(guān)鍵主體有：微應(yīng)用平臺、核心開發(fā)團隊、平臺運維團隊、核心應(yīng)用者、微應(yīng)用消費者、平臺運營團隊（見圖3）。

1）微應(yīng)用平臺是指用于微應(yīng)用產(chǎn)品全生命周期的集設(shè)計、開發(fā)、集成、運維、運營于一體的綜合性平臺；是將康威法則、領(lǐng)域驅(qū)動設(shè)計、分而治之、KISS原則等方法論/ 指導(dǎo)思想充分融入的平臺類開放型產(chǎn)品，是微應(yīng)用生態(tài)圈的核心。

2）核心開發(fā)團隊主要負責(zé)微應(yīng)用平臺的需求、設(shè)計、研發(fā)、應(yīng)用、協(xié)助運維等主要工作，達到產(chǎn)品功能與非功能方面的螺旋上升的目的。微應(yīng)用平臺本身不輸出直接面向終端消費者的具體微應(yīng)用產(chǎn)品。

3）平臺運維團隊主要負責(zé)平臺的消缺，更為重要的是分析缺陷提出優(yōu)化整改意見，并跟進落實產(chǎn)品的優(yōu)化整改情況。

4）核心應(yīng)用者主要負責(zé)基于微應(yīng)用平臺進行平臺的微應(yīng)用產(chǎn)品研發(fā)，輸出微應(yīng)用產(chǎn)品；可以是個體、團隊、產(chǎn)品研發(fā)商，他們是微應(yīng)用平臺的二次加工方，基于平臺加工出可以面向終端消費者的具體微應(yīng)用產(chǎn)品。

5）微應(yīng)用消費者是微應(yīng)用產(chǎn)品的消費方，消費具體的微應(yīng)用產(chǎn)品，直接或間接參與微應(yīng)用產(chǎn)品或微應(yīng)用平臺的優(yōu)化改進。

6）平臺運營團隊主要負責(zé)平臺的宣傳、推廣、培訓(xùn)及應(yīng)用情況分析；協(xié)助平臺需求收集，潤滑生態(tài)鏈中的各個環(huán)節(jié)，推進平臺的完善與提升，保障平臺的整體生態(tài)運作積極向上。

3.2　微服務(wù)架構(gòu)的統(tǒng)一認識

微服務(wù)架構(gòu)落地是一個系統(tǒng)工程，參與這個工程的人員必然不少，本例中據(jù)不完全統(tǒng)計（未統(tǒng)計微應(yīng)用消費者數(shù)量）參與人員多達700 余人，其中包含工程決策鏈10 余人、核心開發(fā)團隊100 余人、平臺應(yīng)用者500 余人、平臺經(jīng)營團隊60 余人、平臺維護團隊40 余人。

統(tǒng)一工程參與各方的認識與思想也就成為這個工程能否順利推進最后成功落地的前提。統(tǒng)一認識過程中主要有以下幾部分需要重點關(guān)注。

1）工程決策鏈，認可重視。對于軟件供應(yīng)商而言，擬開展微服務(wù)架構(gòu)落地工程，向工程決策鏈上的各級干系人說明工程的必要性、意義、推進思路、預(yù)期成效等事項的重要性。需要達到?jīng)Q策鏈各級干系人認可此工程項目并重視項目的推進進展的目的。

2）平臺研發(fā)方，認識統(tǒng)一。平臺研發(fā)方（主要包括：核心開發(fā)團隊、平臺運營團隊、平臺運維團隊）是工程項目的主體核心輸出物——微應(yīng)用平臺的產(chǎn)出方。平臺類產(chǎn)品的非功能性要求要高于一般產(chǎn)品，需要具有相對更高的產(chǎn)品意識進行產(chǎn)品的研發(fā)、經(jīng)營、維護。需統(tǒng)一此部分人員的認識，以保障核心輸出物的嚴(yán)標(biāo)準(zhǔn)、高質(zhì)量的目標(biāo)。

3）核心應(yīng)用者，宣貫統(tǒng)一。核心應(yīng)用者是具體微應(yīng)用的締造者，是面向終端用戶的產(chǎn)品研發(fā)方。除了傳統(tǒng)的產(chǎn)品意識外，基于微應(yīng)用平臺的研發(fā)，還需要做到以下幾方面的意識統(tǒng)一。主要包括：基于現(xiàn)有微應(yīng)用平臺實現(xiàn)、遵從統(tǒng)一技術(shù)路線、遵守相關(guān)開發(fā)規(guī)范、秉持“微”理念（即：基于特定角色、特定場景的應(yīng)用，同時業(yè)務(wù)上要保障一個業(yè)務(wù)場景的完整性）、積極參與平臺的優(yōu)化完善。

4）應(yīng)用消費者，宣貫認可。應(yīng)用消費者是微應(yīng)用產(chǎn)品的終端，產(chǎn)品應(yīng)用前后有大量的宣貫工作需要開展以達到消費者認可愿意為其買單的目的。產(chǎn)品應(yīng)用前，需要說服消費者嘗試新模式、新產(chǎn)品，打動消費者，最終接受微服務(wù)架構(gòu)下的微應(yīng)用產(chǎn)品。產(chǎn)品應(yīng)用后，需要做到讓消費者切實感受到與以往不同的產(chǎn)品應(yīng)用體驗，達到并愿意代為宣傳推薦的目標(biāo)。

3.3　微應(yīng)用平臺的構(gòu)建

微應(yīng)用平臺是微應(yīng)用生態(tài)圈的核心，微應(yīng)用平臺健壯與否、功能完備與否很大程度上決定了項目是否爛尾。本案中微應(yīng)用平臺架構(gòu)如圖4 所示。

3.3.1　開發(fā)運維中心

DevOps（Development 和Operations 的組合）是一組過程、方法與系統(tǒng)的統(tǒng)稱，用于促進開發(fā)、技術(shù)運維和質(zhì)量保障部門之間的溝通、協(xié)作與整合。它的出現(xiàn)是由于軟件行業(yè)日益清晰地認識到：為了按時交付軟件產(chǎn)品和服務(wù)，開發(fā)和運維工作必須緊密合作。平臺應(yīng)用者、平臺運維團隊可以基于此模塊進行快速、高效的協(xié)作，最終實現(xiàn)需求的快速響應(yīng)與交付。

3.3.2　微應(yīng)用運行中心

將微服務(wù)打包成獨立部署的載體，這個載體可以部署在常規(guī)的服務(wù)器或虛擬化資源或一體機之上，實現(xiàn)計算能力的水平拓展和微應(yīng)用間數(shù)據(jù)的隔離。其中封裝了Web 應(yīng)用服務(wù)器、服務(wù)注冊發(fā)現(xiàn)、輕量級RPC 和服務(wù)調(diào)用的負載均衡策略等功能組件。微應(yīng)用由內(nèi)嵌的Web 容器統(tǒng)一管理生命周期，提供應(yīng)用部署、日志管理等組件，支持在運行時動態(tài)調(diào)整參數(shù)以提高JVM 性能。可以通過微應(yīng)用中心輕松實現(xiàn)微應(yīng)用程序的嵌入，開發(fā)者可以直接將容器的操作包含在程序邏輯中，而不需要應(yīng)用程序做出任何修改。傳統(tǒng)架構(gòu)模式下是將應(yīng)用部署在容器中，而微應(yīng)用是將容器嵌入到應(yīng)用中。

其中，API 網(wǎng)關(guān)主要負責(zé)封裝內(nèi)部系統(tǒng)的架構(gòu)，并且提供API 給各個客戶端；負責(zé)請求轉(zhuǎn)發(fā)、合成和協(xié)議轉(zhuǎn)換；授權(quán)、監(jiān)控、負載均衡、緩存、請求分片和管理、靜態(tài)響應(yīng)處理等工作。微應(yīng)用與微服務(wù)是指具體的可以響應(yīng)終端用戶的業(yè)務(wù)請求的應(yīng)用程序或后臺服務(wù)。基礎(chǔ)服務(wù)主要是指微應(yīng)用平臺本身正常運行所依賴或提升管理能力的底層服務(wù)，如熔斷與降級管理服務(wù)、注冊與發(fā)現(xiàn)服務(wù)、通信與安全服務(wù)、監(jiān)控服務(wù)等。運監(jiān)自動化主要是用于與開發(fā)運維中心、微應(yīng)用運營中心間通信聯(lián)動的組件。

3.3.3　微應(yīng)用運營中心

微應(yīng)用運營中心主要負責(zé)微應(yīng)用產(chǎn)品的運營相關(guān)工作，主要包括微應(yīng)用商店、API 商店、微應(yīng)用生態(tài)管理3 部分。微應(yīng)用商店界面示意如圖5 所示。

1）微應(yīng)用商店作為微應(yīng)用的分發(fā)入口，供用戶便捷預(yù)覽、選擇、安裝和使用微應(yīng)用，同時管理微應(yīng)用的全生命周期，包括微應(yīng)用的上架、審核、統(tǒng)計、下架等功能。

2）API 商店為企業(yè)應(yīng)用提供標(biāo)準(zhǔn)的訪問接口，對各種服務(wù)接口進行統(tǒng)一管理。在平臺底層整合了各種基礎(chǔ)服務(wù)，實現(xiàn)了統(tǒng)一的API 訪問機制。API商店實現(xiàn)對API 接口的發(fā)布、注冊、查詢、調(diào)試、授權(quán)、統(tǒng)計、分析等一系列精細化管理。

3）微應(yīng)用生態(tài)管理主要是實現(xiàn)對具體微應(yīng)用的應(yīng)用情況進行統(tǒng)計分析以輔助其生命周期的決策管理。具體監(jiān)控指標(biāo)包括：評價情況、日活量、更新維護情況等。

指導(dǎo)思想與方法論：是指需要融入到平臺基因與血液里的理念，主要包括康威法則、領(lǐng)域驅(qū)動設(shè)計、分而治之、KISS 原則等。對于不同的企業(yè)，指導(dǎo)思想與方法論不一定完全相同。分析企業(yè)中當(dāng)前在哪些方面處于短板，并進行強化應(yīng)用。

3.4　微應(yīng)用平臺的應(yīng)用

在實際項目推進過程中，微應(yīng)用平臺的應(yīng)用是項目成功與否的關(guān)鍵所在。對于平臺的應(yīng)用應(yīng)重點關(guān)注以下3 個方面。

1）按相關(guān)規(guī)范使用。在推廣微應(yīng)用平臺至平臺應(yīng)用者之前，需要制定一套相應(yīng)的辦法、規(guī)范和標(biāo)準(zhǔn)（以下簡稱規(guī)范）以約束微應(yīng)用產(chǎn)品研發(fā)全過程。這個過程中需要開展以下工作：配套規(guī)范解讀；配套規(guī)范監(jiān)督，為減輕監(jiān)督成本、提升監(jiān)督效率，此部分工作最好能通過信息化手段實現(xiàn)，做到將規(guī)范融合進平臺則是最理想的狀態(tài)；規(guī)范持續(xù)完善，規(guī)范制定后不應(yīng)該是一成不變的，而是應(yīng)根據(jù)事情情況隨需而動、持續(xù)完善，因此需要對應(yīng)的機制與組織跟進落實此類事項。

2）多重角色式應(yīng)用。不同的平臺應(yīng)用者在應(yīng)用微應(yīng)用平臺的過程中要求也不同，對于內(nèi)部的平臺應(yīng)用者應(yīng)該同時承擔(dān)多重角色，既要盡到一個平臺應(yīng)用者的義務(wù)，更要做到一個微應(yīng)用平臺的優(yōu)質(zhì)用戶。包括不限于：應(yīng)用平臺的過程中對于發(fā)現(xiàn)的平臺的問題需要起到承擔(dān)反饋問題、提出建議、協(xié)助跟進、完成改進等作用。

3）蔓延式擴大范圍。主要是指微應(yīng)用平臺首版本發(fā)布后，不應(yīng)急于將平臺推廣至過多的平臺應(yīng)用者，而應(yīng)采用逐步蔓延、分批推進的方式，在平臺足夠完善后，最終達到全面應(yīng)用的目的。蔓延順序可參考按研發(fā)團隊內(nèi)部應(yīng)用、責(zé)任部門內(nèi)部應(yīng)用、企業(yè)內(nèi)部應(yīng)用、外部研發(fā)個體應(yīng)用、外部研發(fā)團隊?wèi)?yīng)用、外部研發(fā)產(chǎn)品研發(fā)商應(yīng)用順序依次推廣。

4　結(jié)語

結(jié)合相關(guān)理論的研究以及實踐過程中的經(jīng)歷，總結(jié)出以下相關(guān)經(jīng)驗。

1）良好生態(tài)需統(tǒng)一全員認識。構(gòu)建良好的微服務(wù)架構(gòu)生態(tài)需要統(tǒng)一全員認識，推進過程中可能會遇到困難阻擾，需攜手共進、攻關(guān)克難。

2）保持常態(tài)化經(jīng)營生態(tài)圈。微服務(wù)架構(gòu)是體系工程，并非一蹴而就，需要以常態(tài)化的方式經(jīng)營整個生態(tài)圈。

3）“微應(yīng)用+ 云平臺”模式。數(shù)字時代的到來，“微應(yīng)用+ 云平臺”模式將成為企業(yè)信息化建設(shè)的核心工作。云平臺主要是指微應(yīng)用平臺，微應(yīng)用是指具體的微應(yīng)用產(chǎn)品。應(yīng)該將可抽象、復(fù)用的組件、控件、服務(wù)、接口標(biāo)準(zhǔn)化通過平臺層提供給各平臺應(yīng)用者，再由平臺應(yīng)用者基于平臺完成具體微應(yīng)用產(chǎn)品研發(fā)。平臺層專注于基礎(chǔ)技術(shù)服務(wù)及基礎(chǔ)業(yè)務(wù)組件的抽象；應(yīng)用層專注于具體的業(yè)務(wù)規(guī)則、業(yè)務(wù)邏輯、交互方式及用戶體驗。

4）重視配套體系制度落實。能夠科學(xué)合理的基于微應(yīng)用平臺進行微應(yīng)用產(chǎn)品的研發(fā)同樣也是至關(guān)重要的要素。需要一套相應(yīng)的配套體系制度（包括辦法、規(guī)范和標(biāo)準(zhǔn)）以約束微應(yīng)用產(chǎn)品研發(fā)全過程。

5）架構(gòu)無最優(yōu)只有最適合。隨著云計算技術(shù)的逐步成熟、穩(wěn)定，為進一步簡化系統(tǒng)復(fù)雜性和提升產(chǎn)品研發(fā)迭代速度，已有部分企業(yè)開始越過微服務(wù)架構(gòu)在研究應(yīng)用無服務(wù)架構(gòu)。IT 技術(shù)架構(gòu)演進速度很快，并非是選最新的技術(shù)架構(gòu)即是最好的，并非所有應(yīng)用場景都適合采用微服務(wù)架構(gòu)理念。具體應(yīng)該選用哪種技術(shù)架構(gòu)，需要視市場環(huán)境、企業(yè)環(huán)境、應(yīng)用環(huán)境、應(yīng)用場景等多重因素確定。

本文摘自《電力信息與通信技術(shù)》