業務架構的微應用化與技術架構的微服務化

李忠民+++齊占新

摘 要：微服務架構已經在實踐中被普遍應用，國網也在努力實踐“一平臺一系統多場景微應用”的設計理念，但是在微服務架構的實施過程中，作者感覺業界在微服務架構論述上把業務架構和技術架構糅合在一起，概念不是很清晰；同時在實踐過程中作者對微服務的粒度劃分標準有自己一些認識，文章圍繞上述兩點展開討論，談談自己的觀點。

關鍵詞：微服務架構；微應用化；微服務化；微服務粒度

每個新的技術概念的提出都是為了解決應用實踐中面臨的問題，同時新的技術概念往往引起應用實踐模式的轉變，這一點在架構設計領域表現的尤為突出。二者有點像經濟基礎和上層建筑的關系，經濟基礎決定上層建筑，上層建筑反過來又顯著地影響著經濟基礎；同樣，業務架構決定技術架構，技術架構反過來又顯著影響著業務架構，微服務架構的提出和實施，不可避免會要求業務架構做出相應演進。

作者從國網“一平臺一系統多場景微應用”的實施過程中，逐漸認識到微服務架構的實施實際上分為如下兩個部分：業務架構的微應用化；技術架構的微服務化。

下面首先提出微應用、微服務的概念，從而引出業務架構的微應用化和技術架構的微服務化觀點。

1 微服務架構

總結微服務架構的提出者Martin對微服務架構的定義，微服務架構有如下特征：由多個分布式服務組成，多個獨立的服務，共同組成系統；每個服務單獨部署，運行在獨立的進程（容器）里；服務可以獨立設計、開發、部署，可以采用不同的技術路線；分布式的管理。

微服務架構模式有許多優點：拆分單一的復雜性的單體應用為可管理的模塊或服務。單個的服務可以更快的開發，更簡單的理解和維護。每個服務可以由單獨的團隊獨立開發，開發者可以自由地選擇合理的技術，只要服務遵守 API 約定即可。每一個微服務能被獨立部署，讓持續部署成為可能。

可見微服務架構是一個技術概念，是從技術架構角度來提出的一種新架構模式，是一種新的設計、開發、實施、運維的實踐方法，從企業架構（EA）角度分析，應該劃分到技術架構的范疇。

2 微服務

微服務是一個高內聚低耦合IT的實體，有明確的邊界，屬于技術架構的范疇，可獨立設計、開發、測試、部署、運維管理，一般具有自己的表現層、業務層甚至數據庫層，一般每個服務實例運行在一個容器中。

3 微應用

微應用是一個高內聚低耦合的業務實體，有明確的業務邊界，微應用應該是一個完整的、自洽的業務模塊，屬于業務架構的范疇。

微應用是從應用場景中抽象總結出來的一些獨立業務模塊，模塊之間很少相互的業務聯系，即使有也通過工作流等機制進行。

從領域模型的角度來看，微應用應該是居于業務對象和聚合體之上的一個概念，也就是說其粒度要比聚合體更加粗一些，比業務用例也更加粗一些，是相對獨立的一個業務模塊。

從用戶角度看微應用能夠提供用戶要求的某一組服務，為企業創造一個明確的經營價值，達成用戶的一個某個在經營層面可見的目標。

而作為對照，業務用例一般完成某個特定的功能，比如下單、客戶資料修改等，由于粒度過小不能提供一個經營層面可見的價值。

4 微應用和微服務的關系

微應用和微服務都是相對獨立的單元，都具有高內聚低耦合的特征，都有一個明確的邊界。但是二者是不同領域中的概念，從本質上來說是兩個獨立的概念。

微應用是一個業務概念，是有獨立功能，能夠滿足用戶一個完整業務需求的功能，能夠實現一個經營層面可見的目標。微服務是一個IT實體，是能夠獨立開發、測試、部署、運行的模塊，一般依托容器運行。

微應用和微服務沒有一一對應的關系，有一個比較貼切的比喻：二者之間的關系就像領域模型中的業務實體和java對象之間的關系。往往一個微服務實現了幾個微應用，也存在一個微應用跨越幾個微服務的情景。

5 微應用和微服務的劃分標準

引入微服務架構的初衷是降低系統開發和實施過程中的復雜性，使得過程可控，因此從實用主義的角度，從系統生命周期中與系統關系最密切的幾類人員，即分析人員、設計人員、開發人員、運維人員角度來說明微應用和微服務的劃分原則，是比較有實用價值的。此種劃分方式比純粹學術上的研究要有指導意義的多，舉例來說業界曾有觀點：微服務應該細化到每個菜單作為一個微服務的程度，這個觀點明顯是脫離實際，為微而微，望文生義，極大地增加了運維成本和管理成本，是非常教條的。

下面按照以上原則說明微應用和微服務的劃分標準

5.1 微應用的粒度

微應用是處于子系統和業務用例之間的一個模塊級別，其雖然名稱中有“微”，但是不能過于小，否則徒增復雜性，對于架構的優化改進沒有任何助力。

可以把能否提供一個“企業經營管理層面可見的價值”作為識別微應用的主要標準。同樣是對業務進行模塊劃分，具體經辦的業務人員和經營管理人員的視角不同，粒度不同，業務人員從“做什么”入手，因此他們劃分出的單元往往是業務用例級別的，而經營管理人員往往從“有什么用”角度入手，他們劃分出的業務模塊往往是粒度比業務用例稍大。

視角的不同，引起劃分標準和劃分結果的不同，前文已經說了，微應用應該是比業務用例稍大的粒度，以經營管理者的視角對業務進行劃分，是微應用的比較合理的劃分方法。

識別什么是微應用，還與應用系統的設計目標和定位有關，比如同樣是人力資源管理系統，如果系統的重點在于員工檔案管理，則員工培訓業務可以看做一個微應用，但是對于以培訓為重心的人資系統，則把培訓業務分解為多個微應用更加合適。

5.2 微服務的粒度

劃分微服務的標準則有如下幾點：

從設計角度：微服務應該是高內聚低耦合的，有明晰的界面，與外界盡量少的交互。

從開發角度，微服務應該是一個小的團隊、在短時間內可以完成的，保持溝通的高效和管理的低成本。

從運維的角度：微服務的粒度不能太小，種類不能太多，否則會使得系統復雜性和管理成本急劇上升，有違微服務架構的初衷。

6 業務架構的微應用化和技術架構的微服務化

按照架構設計的有關實踐，系統架構分為業務架構、應用架構、技術架構、數據架構、安全架構等幾部分。

如前文所述，微應用是屬于業務架構范疇的概念，微服務是屬于技術架構范疇的概念。故在微服務架構的實施過程中，實際上存在業務架構的微應用化和技術架構的微服務化兩個方面的工作，而業界往往把二者混淆。

6.1 業務架構的微應用化

首先利用傳統的分析方法對企業全局范圍內的業務進行梳理，開發業務架構，然后再進行重構與整合，對業務進行拆分，從中識別出微應用，達到業務架構的微應用化。

微應用化的主要工作是產生微應用清單，定義微應用的業務功能和業務邊界，規范跨越兩個或者多個微應用的業務，對于跨微應用的業務盡量利用工作流等機制實現銜接，從業務層面避免技術實現時的分布式事務產生的可能性，降低實現和實施的復雜性。

6.2 技術架構的微服務化

微服務化的根本原則就是降低設計、開發、測試、實施、運維過程中的復雜性和成本，在微服務化實施過程中會遇到很多問題，其中最具爭議的就是微服務的粒度問題，只要遵循這個基本原則，則尺度就比較好把握。

微服務化架構的實施涉及到設計、開發、部署、運維等各個方面。

6.2.1 設計過程

微服務可以分為兩類：應用層微服務：實現了業務邏輯，可以認為這部分微服務是微應用的實現，但沒有必要和微應用一一對應。

基礎層微服務：實現了公共設施和公共模塊。

設計過程是在業務微應用化的基礎上展開的，但是微應用和微服務不必要一一對應，微服務的設計過程就是需要對業務進行拆分和分層：拆分：參照微應用進行拆分，構建應用層微服務集群。分層：梳理和抽取核心應用、公共應用，作為獨立的服務下沉到核心和公共能力層。

當然設計過程中還要解決很多其他問題，如服務注冊、服務注冊、服務間通訊機制等問題。

6.2.2 開發過程

開發過程中首要原則就是接口先行，面向接口編程，首先需要把接口識別和定義出來，然后雙方基于接口進行開發，合理控制團隊規模和開發周期，降低管理成本，提升產能。

6.2.3 部署過程

部署過程要利用工具進行自動化部署。

部署原則：容器化、獨立部署、基礎設施自動化。

6.2.4 運維過程

運維過程要充分利用工具實現自動化運維。