微服務架構淺析

郭玉芝　唐國城

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

關鍵詞：Spring Cloud;微服務;中臺戰略;分布式

中圖分類號：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

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

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

1 傳統微服務架構的劣勢及解決方案

1.1 微服務邊界

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

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

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

1.2 分布式應用的復雜性

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

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

1.3 分區數據庫架構

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

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

1.4 運維、開發復雜度增加

一個應用系統業務的實現需要多個業務服務子系統的支持，管理運維多個子服務。整個應用系統存在多個子服務系統，那么這若干子系統都將有個性化的配置、部署、拓展和監控方案。基于容器化技術，對服務進行管理，通過使用PaaS服務實現服務部署自動化，使用集群化方案進行統一化管理。

2 基于微服務的中臺架構

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

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

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

3 結語

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

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

參考文獻：

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

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

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

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