作者：張允君，衛潔，付小攀，彭霄

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

0　引言

隨著信息化的發展，信息化建設對于企業發展與經營管理起到了明顯積極正向的作用與促進，企業對信息化也提出了更高的要求，諸如：快速響應業務需求，IT 架構彈性擴展、系統應用場景化等。

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

微服務架構理念首先被國外企業應用，如Amazon、eBay 等。近2 年，國內一些創新企業開始嘗試采用微服務架構替換傳統IT 架構（SOA 架構）。伴隨微服務架構應用的逐步深入，與微服務相當的一個概念“微應用”應運而生，但目前尚未有權威機構對此概念進行定義。

基于微服務架構等理念，結合應用實踐，微應用是指采用微服務架構理念的一種軟件形式。具備以下關鍵特征：由一組后臺微服務及前端應用界面組合而成；具有交互界面可以直接面向終端用戶；以領域驅動設計（Domain-Driven Design，DDD）為指導思想進行設計；可以按需靈活組合后端微服務以滿足多場景業務需求。

1　國內外微服務架構研究應用概況

1.1　業界關注熱度分析

近幾年，微服務受業界關注的熱度持續攀升（見圖1、2）。

圖1 和圖2 首先體現了微服務概念受的關注度在持續穩步提升；其次，從一定程度上說明微服務架構理念也正在被更為廣泛地認可；最后，從一定程度上說明受信息化發展需求地驅動，微服務架構已經被較為廣泛地認為是一種潛在解決方案或思路。

1.2　部分企業研究概況

據不完全統計，目前國內外已有較多企業在開展或已實現微應用/ 微服務架構的研究、實施、落地應用工作。互聯網類公司在信息化架構方面步伐較快，起到了預研究、探索、引領的作用。信息化應用方與提供方都在向微服務架構方向行進。部分有代表性的公司/ 企業分析如下。

1）eBay。eBay 公司自1995 年起經歷數代信息化架構演進，從單體架構演進至SOA 架構，歷時3 年于2014 年完成了從SOA 架構向微服務架構的演進。

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

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

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

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

2　特定企業部分特征

并非所有的企業都適合采用微服務架構理念開展信息化建設工作，并非所有的企業在微服務架構落地過程中的思路、方法、關注點都完全相同，同時，微服務架構理念并非適用于所有應用場景。本文相關結論與建議適用于具有以下特征的相關企業。

2.1　企業組織特征

1）集團性質企業。表現為以總部為核心、多層次的組織結構；在內部的管理體制上，表現為企業集團中各成員企業，既保持相對獨立的地位，又實行統一領導和分層管理的制度，建立了集權與分權相結合的領導體制。

2）金字塔型集團。金字塔型結構又稱持股型結構，是標準的產權控制模式；意味著上層組織對下層單位有強管控能力，采用強管控的模式進行經營管理。

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

2.2　信息化相關特征

1）信息化應用程度深。企業已經開展了較長時間（3 年及以上）的信息化建設、運維工作，企業內部當前的信息化架構為SOA 或帶有SOA 架構的混合架構。

2）信息化應用場景多。從崗位角色覆蓋面而言，企業內部的大部分崗位或角色都有需要通過信息化手段完成的經營、管理的需求或要求。從信息化層次結構而言，應用場景涵蓋實施操作層、經營管理層、戰略決策層等多個層面。

3）信息化需求變動頻繁。受各類因素驅動，信息化相關業務需求變動頻繁，且希望信息化變動需求能夠在較短（以周為單位）時間內得到響應與落地應用。

3　遠光軟件應用微化實踐

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

3.1　微應用生態圈的組成

落地微服務架構，首先要認識到微應用實際上是一個生態圈，生態圈中包含的關鍵主體有：微應用平臺、核心開發團隊、平臺運維團隊、核心應用者、微應用消費者、平臺運營團隊（見圖3）。

1）微應用平臺是指用于微應用產品全生命周期的集設計、開發、集成、運維、運營于一體的綜合性平臺；是將康威法則、領域驅動設計、分而治之、KISS原則等方法論/ 指導思想充分融入的平臺類開放型產品，是微應用生態圈的核心。

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

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

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

5）微應用消費者是微應用產品的消費方，消費具體的微應用產品，直接或間接參與微應用產品或微應用平臺的優化改進。

6）平臺運營團隊主要負責平臺的宣傳、推廣、培訓及應用情況分析；協助平臺需求收集，潤滑生態鏈中的各個環節，推進平臺的完善與提升，保障平臺的整體生態運作積極向上。

3.2　微服務架構的統一認識

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

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

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

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

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

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

3.3　微應用平臺的構建

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

3.3.1　開發運維中心

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

3.3.2　微應用運行中心

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

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

3.3.3　微應用運營中心

微應用運營中心主要負責微應用產品的運營相關工作，主要包括微應用商店、API 商店、微應用生態管理3 部分。微應用商店界面示意如圖5 所示。

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

2）API 商店為企業應用提供標準的訪問接口，對各種服務接口進行統一管理。在平臺底層整合了各種基礎服務，實現了統一的API 訪問機制。API商店實現對API 接口的發布、注冊、查詢、調試、授權、統計、分析等一系列精細化管理。

3）微應用生態管理主要是實現對具體微應用的應用情況進行統計分析以輔助其生命周期的決策管理。具體監控指標包括：評價情況、日活量、更新維護情況等。

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

3.4　微應用平臺的應用

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

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

2）多重角色式應用。不同的平臺應用者在應用微應用平臺的過程中要求也不同，對于內部的平臺應用者應該同時承擔多重角色，既要盡到一個平臺應用者的義務，更要做到一個微應用平臺的優質用戶。包括不限于：應用平臺的過程中對于發現的平臺的問題需要起到承擔反饋問題、提出建議、協助跟進、完成改進等作用。

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

4　結語

結合相關理論的研究以及實踐過程中的經歷，總結出以下相關經驗。

1）良好生態需統一全員認識。構建良好的微服務架構生態需要統一全員認識，推進過程中可能會遇到困難阻擾，需攜手共進、攻關克難。

2）保持常態化經營生態圈。微服務架構是體系工程，并非一蹴而就，需要以常態化的方式經營整個生態圈。

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

4）重視配套體系制度落實。能夠科學合理的基于微應用平臺進行微應用產品的研發同樣也是至關重要的要素。需要一套相應的配套體系制度（包括辦法、規范和標準）以約束微應用產品研發全過程。

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

本文摘自《電力信息與通信技術》