郭玉芝　唐國城

摘 要：信息時代，各行各業(yè)都在向智能化、信息化轉型。在過去的幾年中，移動互聯網迅速發(fā)展，各大公司的規(guī)模持續(xù)擴大，業(yè)務發(fā)展迅速。與此同時，業(yè)務增多也帶來許多問題，許多業(yè)務需求或者功能需求高度相似，通化程度高，但是由于沒有專門的團隊負責規(guī)劃和開發(fā)，大量系統(tǒng)重復開發(fā)和建設，導致復用性很低。本文探討了傳統(tǒng)微服務架構的劣勢與解決方案，并分析了通過中臺思想將服務組件化，提高服務的可用性和復用性。

關鍵詞：Spring Cloud;微服務;中臺戰(zhàn)略;分布式

中圖分類號：TP311.52 文獻標識碼：A 文章編號：1003-5168（2019）26-0014-03

Analysis of Microservice Architecture

GUO Yuzhi TANG Guocheng

（Qingdao Institute of Technology，Qingdao Shandong 266300）

Abstract： In the information age， all walks of life are transforming into intelligence and information. In the past few years， the mobile Internet has developed rapidly， and the scale of major companies has continued to expand and business has developed rapidly. At the same time， the increase in business has brought many problems. Many business needs or functional requirements are highly similar， and the degree of generalization is high. However， because there is no dedicated team responsible for planning and development， a large number of systems are repeatedly developed and constructed， resulting in low reusability. This paper explored the disadvantages and solutions of the traditional micro-service architecture， and analyzed the componentization of services through the middle-class thinking to improve the usability and reusability of services.

Keywords： Spring Cloud;microservice;middle platform;distributed

早期，為了解決業(yè)務問題，人們只是一味提高傳統(tǒng)的縱向的、高度個性化的業(yè)務處理邏輯與基礎系統(tǒng)的耦合程度，但是沒有考慮后續(xù)系統(tǒng)規(guī)劃，在設計開發(fā)過程中，同一層次系統(tǒng)之間、上下游系統(tǒng)之間的交叉邏輯非常多，導致后續(xù)拓展系統(tǒng)無法復用和迭代。隨著企業(yè)業(yè)務場景的不斷豐富，單純的“前臺+后臺”模式已經無法滿足不斷增長的業(yè)務需求，兩者速率匹配失衡的問題就逐步顯現出來。在日常業(yè)務驅動下，為了盡量保持后臺系統(tǒng)的穩(wěn)定性，同時響應用戶持續(xù)不斷的需求，企業(yè)自然就會將大量業(yè)務邏輯直接寫入前臺系統(tǒng)中，重復開發(fā)，致使前臺系統(tǒng)職責繁重，違反單一職責原則，形成了一個個煙囪式單體應用，最終拖垮前臺系統(tǒng)的用戶響應力。

針對實際業(yè)務中遇到的重復造輪子和煙囪式架構問題，各大企業(yè)需要在系統(tǒng)開發(fā)中提高要求，將各個業(yè)務系統(tǒng)功能盡量抽離，促進業(yè)務系統(tǒng)模塊獨立化、服務化和公共化。為達到服務的復用性，實現服務的組件化，企業(yè)會使用多個小服務組裝單個應用系統(tǒng)。這種業(yè)務系統(tǒng)的服務化能夠有效地解決當前企業(yè)面臨的一系列信息化難題。服務之間通過接口，采用輕量級通信的協調機制，以業(yè)務為中心，構建以服務為單位的獨立的自動化運行機制，實現集中式服務管理。將企業(yè)的業(yè)務系統(tǒng)按照職能、功能劃分為三個層次，契合前、中、后臺的三個不同業(yè)務層次，不同的業(yè)務層次采用完全不同的策略，為技術落地提供了理論支撐。中臺天生就是為前臺服務的，其可以是技術中臺、業(yè)務中臺等，可以更好地服務前臺，做到領域創(chuàng)新，進而更好地響應用戶請求，提高用戶響應力，提高企業(yè)自身的能力，以達到與用戶需求的持續(xù)對接。

1 傳統(tǒng)微服務架構的劣勢及解決方案

1.1 微服務邊界

在微服務實踐落地過程中，一大難點在于模塊之間界面的界定。在模塊的劃分過程中，服務設計容易出現過大或者過小的問題。微服務過大，會產生與單體應用系統(tǒng)類似的不足;微服務過小，大量服務的管理會增加運營的成本和難度。雖然服務是逐步被拆分出來的，但是隨著業(yè)務的演進，企業(yè)需要重新審視服務劃分是否合理。微服務邊界的重新定義一般可以通過如下兩種方式。

1.1.1 領域驅動劃分服務。它是指根據業(yè)務邏輯復雜度，而非數據量、并發(fā)量等相關復雜度劃分服務。該模式適合業(yè)務邏輯復雜度足夠高的場景。但領域驅動本身十分復雜，很多概念比較抽象，應用范圍并不是特別廣泛，所以當業(yè)務復雜度較低時，可以選擇基于數據驅動劃分服務，數據驅動更容易理解和上手。

1.1.2 基于數據驅動劃分服務。它是指通過自下而上的架構設計方法，結合需求分析，確定整體數據結構，根據表之間的關系劃分服務。

1.2 分布式應用的復雜性

當若干系統(tǒng)都處于運行狀態(tài)并且相互調用組成一套業(yè)務系統(tǒng)時，此系統(tǒng)天然具有分布式屬性。與傳統(tǒng)的單體應用架構相比，分布式架構提高了系統(tǒng)的吞吐能力。隨著業(yè)務量的逐漸增大，企業(yè)需要使用多臺機器，采用分布式架構，垂直或是水平地拆分業(yè)務來應對這種大規(guī)模的應用場景。同時，分布式應用可以增加系統(tǒng)的可用性，對于企業(yè)關鍵性業(yè)務，系統(tǒng)需要滿足高可用性，而分布式架構提高了系統(tǒng)的高可用性，系統(tǒng)的模塊化提高了模塊的重用度，同時提高了系統(tǒng)的拓展性以及開發(fā)和發(fā)布的速度。

復雜性是分布式架構應用相比單體式應用的固有特性。架構設計更加復雜，特別是分布式服務，部署變得十分復雜。一個完整的業(yè)務系統(tǒng)需要部署多個服務，并且隨著系統(tǒng)吞吐量的增大，響應時間會變長，技術多樣化，服務變多，運維的復雜度也會提高。分布式應用測試和查錯的復雜度增大，學習成本曲線也增大，各個微服務需要選擇合適的通信協議進行消息傳遞，并完成進程間的通信。如此一來，需要處理消息傳遞中速度過慢或者不可用等局部系統(tǒng)失效問題，企業(yè)必須采用一套完整的機制保證各個服務正常運轉[1]。

1.3 分區(qū)數據庫架構

在分布式系統(tǒng)應用中，各個業(yè)務系統(tǒng)趨于服務化，與之對應的就是每一個服務對應某一個或者多個數據庫系統(tǒng)，即分區(qū)數據庫架構。業(yè)務更新需要考慮分布式數據庫的一致性，某一服務的數據操作可能會影響其他服務的數據，此時需要考慮數據的一致性。當服務的業(yè)務影響到非本服務對應的數據時，企業(yè)需要對不同服務所對應的數據庫進行相關操作，才能確保分布式數據庫系統(tǒng)中不同數據庫下的各種業(yè)務數據的關聯性保持一致。

根據分布式的CAP定理，分布式架構中，系統(tǒng)一般從三方面彼此權衡和考慮：C（一致性）、A（可用性）和P（分區(qū)容錯性）。但是，一般的分布式系統(tǒng)只能最多保證其中兩個。系統(tǒng)作為一個整體，企業(yè)不需要考慮全部，并且CAP理論說明了同時滿足三者是無法做到的，需要根據系列的應用場景選擇AP或者CP，結合業(yè)務綜合考慮，為每個服務系統(tǒng)調用做不同的權衡，解決微服務架構應用中分布式應用的數據一致性問題。

1.4 運維、開發(fā)復雜度增加

一個應用系統(tǒng)業(yè)務的實現需要多個業(yè)務服務子系統(tǒng)的支持，管理運維多個子服務。整個應用系統(tǒng)存在多個子服務系統(tǒng)，那么這若干子系統(tǒng)都將有個性化的配置、部署、拓展和監(jiān)控方案?；谌萜骰夹g，對服務進行管理，通過使用PaaS服務實現服務部署自動化，使用集群化方案進行統(tǒng)一化管理。

2 基于微服務的中臺架構

一說到中臺，人們首先想到的應該是最先在業(yè)界提出“大中臺，小前臺”戰(zhàn)略的阿里。阿里通過多年不懈的努力，在豐富業(yè)務場景和業(yè)務需求的不斷催化滋養(yǎng)下，將技術和業(yè)務能力轉化為一套綜合能力平臺，使整個業(yè)務系統(tǒng)具備了對前臺業(yè)務變化及創(chuàng)新的快速響應能力。中臺戰(zhàn)略作為一座橋梁，不僅連接了靈活的前臺和穩(wěn)定的后臺，還打通了企業(yè)內部各個部門墻的隔閡，豐富和完善了企業(yè)生態(tài)。中臺的核心是提高企業(yè)基礎服務能力，支持前臺小成本地快速創(chuàng)新迭代，提供可以供業(yè)務系統(tǒng)復用的公用能力[2-4]。

基于Spring Cloud全家桶提供的生態(tài)開發(fā)，將整個應用系統(tǒng)拆分并將功能服務化，最終導向服務的組件化，以組件化的方式將服務做到讓各業(yè)務前臺即取即用是中臺戰(zhàn)略的核心思想。傳統(tǒng)的系統(tǒng)間存在耦合性大，牽一發(fā)而動全身的弊端。而組件化設計基于微服務理念針對公共服務進行抽象設計，將抽象出的組件化服務提供給前臺業(yè)務端，中臺即取即用的服務是可復用的服務，服務的高可復用性是從技術層級上針對公共服務的抽象設計能力的一大考驗，企業(yè)需要盡可能地將業(yè)務落地、滿足用戶需求。通過業(yè)務的開放和共享實現服務組件化、可共用的目標是中臺建設的原則。

中臺最重要的作用是持續(xù)提高企業(yè)的用戶響應力，無論是技術中臺、業(yè)務中臺還是組織中臺的建設，從根本上來說，都是為了解決企業(yè)業(yè)務響應力問題，解決創(chuàng)新驅動快速變化的前臺和穩(wěn)定可靠驅動變化周期相對較慢的后臺之間的矛盾，提供一個中間層來適配前臺與后臺的配速問題。在企業(yè)中，中臺的建設不能脫離企業(yè)業(yè)務，要依據企業(yè)自身的業(yè)務落地，不能脫離要解決的現實業(yè)務問題。企業(yè)要先從業(yè)務架構的梳理開始，從痛點出發(fā)，基于自身業(yè)務切實分析，走自身特色的中臺建設道路。中臺戰(zhàn)略忠于敏捷精益端到端、全職能、目標一致的方法論，以市場化產品的要求規(guī)劃技術團隊的工作，激發(fā)團隊的自驅性，提升對業(yè)務的敏感度，使其對工作結果真正負起責任，并獲得收益和認可。

3 結語

從傳統(tǒng)的單例應用開發(fā)模式，轉換到基于Spring Cloud的微服務中臺開發(fā)模式，企業(yè)需要摸索出一條適合自身發(fā)展以及轉型的道路，這不僅僅是技術框架的切換，更是開發(fā)思維的升級和高新技術公司戰(zhàn)略的升級。令人欣喜的是，Spring Cloud飛速發(fā)展，各大企業(yè)基于Spring Cloud開發(fā)出一些服務自身業(yè)務的組件，又將滿足自身業(yè)務場景的業(yè)務組件反饋給社區(qū)，提高了其發(fā)展速度。

路漫漫其修遠兮，好的架構一定是適應業(yè)務發(fā)展的架構，中臺戰(zhàn)略對于企業(yè)來說不是重點。平臺化甚至是中臺化只是企業(yè)提高業(yè)務響應能力和創(chuàng)新能力的手段，中臺建設還是以驅動發(fā)展為主要目標，并不是以實現中臺化為企業(yè)終極目標。

參考文獻：

[1]洪華軍，吳建波，冷文浩.一種基于微服務架構的業(yè)務系統(tǒng)設計與實現[J].計算機與數字工程，2018（1）：149-154.

[2]趙然，朱小勇.微服務架構評述[J].網絡新媒體技術，2019（1）：58-61.

[3]魏文超.基于微服務架構的系統(tǒng)設計與開發(fā)[J].計算機產品與流通，2018（4）：171.

[4]李貞昊.微服務架構的發(fā)展與影響分析[J].信息系統(tǒng)工程，2017（1）：154-155.