從單一模式系統(tǒng)架構(gòu)往微服務(wù)架構(gòu)遷移轉(zhuǎn)化技術(shù)研究

王健+李冬睿

摘 要 文章針對目前單一模式系統(tǒng)開發(fā)周期周期長、開發(fā)成本高等困難，將原有系統(tǒng)往微服務(wù)架構(gòu)上遷移提出了幾種解決方案，結(jié)合具體場景，講述了各個環(huán)節(jié)的實現(xiàn)機制。

關(guān)鍵詞 微服務(wù) 單一模式 遷移轉(zhuǎn)化技術(shù)

中圖分類號：TP271.4 文獻標識碼：A DOI：10.16400/j.cnki.kjdkx.2016.09.021

Abstract Aiming at the current development cycle of single mode system of long period， high cost of development difficulties， the original system to the micro service architecture on migration of several solutions are proposed， combined with the specific scene， describes the realization mechanism of each link.

Key words micro service； single mode； migration and transformation technology

1 Web系統(tǒng)架構(gòu)情況概述和分析

目前web系統(tǒng)架構(gòu)具有如下幾個特征：（1）以快速上線，快速迭代方式發(fā)布單一系統(tǒng)為主要模式。單一系統(tǒng)開發(fā)易于調(diào)試，只需要簡單運行此應(yīng)用；易于部署，只需要把打包應(yīng)用拷貝到服務(wù)器端，通過在負載均衡器后端運行多個拷貝無狀態(tài)服務(wù)就可以輕松實現(xiàn)應(yīng)用的橫行擴展。對于中小型web系統(tǒng)開發(fā)周期快，運維門檻低。（2）隨著需求變更，系統(tǒng)逐漸演變的越來越復(fù)制。最主要問題就是這個應(yīng)用太復(fù)雜，以至于任何單個開發(fā)者都不可能搞懂它。因此，修正bug和正確的添加新功能變的非常困難，并且很耗時。另外，如果代碼難于理解，就不可能被正確的修改。最終會走向巨大的、不可理解的泥潭。（3）傳統(tǒng)開發(fā)模式無成本和效率優(yōu)勢，制約企業(yè)發(fā)展。目前單一架構(gòu)應(yīng)用也使得采用新架構(gòu)和語言非常困難。應(yīng)用無法擴展，可靠性很低，最終，敏捷開發(fā)和快速部署變得無法完成。

2 微服務(wù)架構(gòu)處理復(fù)雜事務(wù)

2.1 微服務(wù)架構(gòu)優(yōu)勢

微服務(wù)架構(gòu)將服務(wù)拆分，分別采用相對獨立的服務(wù)對各方面進行管理，彼此之間使用統(tǒng)一的接口來進行交流，架構(gòu)變得復(fù)雜，優(yōu)勢也很明顯（如圖1）。

（1）解決了復(fù)雜性問題。它把龐大的單一模塊應(yīng)用分解為一系列的服務(wù)，同時保持總體功能不變。這個應(yīng)用被分解為多個可管理的分支或服務(wù)，每一個服務(wù)都有良好定義的邊界，以遠程過程調(diào)用（RPC）驅(qū)動或信息驅(qū)動的API的形式；微服務(wù)架構(gòu)模式單一模塊代碼庫，實際很難實現(xiàn)。因此，獨立的服務(wù)開發(fā)速度明顯更快，而且更易理解和維護。

（2）讓每個服務(wù)能夠獨立開發(fā)，開發(fā)者能夠自由選擇可行的技術(shù)，讓服務(wù)來決定API約定。當然，大多數(shù)組織會通過限制技術(shù)選擇來避免完全的失控。然而，這種自由意味著開發(fā)者們不用被迫使用從項目開始就存在的陳舊技術(shù)，他們可以選擇使用當下的技術(shù)編寫一個新的服務(wù)。另外，由于這些服務(wù)本身相對比較小，用新的技術(shù)來重寫舊的服務(wù)也更可行一些。

（3）每個微服務(wù)都能獨立配置，開發(fā)者不必協(xié)調(diào)對于本地服務(wù)配置上的變化，這種變化一旦測試完成就被配置了。舉個例子，UI團隊可以執(zhí)行A|B測試后立刻對UI的變化執(zhí)行迭代。微服務(wù)架構(gòu)模式使不斷地配置成為可能。

（4）讓每個服務(wù)都可以獨立調(diào)整，你可以給每個服務(wù)配置正好滿足容量和可用性限制的實例數(shù)。另外，你也可以使用最適合服務(wù)的資源需求的硬件。舉例說明，你可以在EC2計算優(yōu)化的實例上配置CPU加強的圖片處理服務(wù)，另外給EC2存儲優(yōu)化的實例配置內(nèi)存中的數(shù)據(jù)庫服務(wù)。

2.2 實踐從單一模式系統(tǒng)重構(gòu)到微服務(wù)架構(gòu)系統(tǒng)

為了未來系統(tǒng)的擴展性，對原有龐大的單一模式系統(tǒng)進行微服務(wù)重構(gòu)，既讓人興奮，又充滿挑戰(zhàn)，下文將提到幾種重構(gòu)方案。這里需要強調(diào)下按照微服務(wù)架構(gòu)，重寫全部系統(tǒng)代碼，對任何已經(jīng)在線上運行的中大型web系統(tǒng)來說，都是不可行的，變更風險太大，系統(tǒng)測試不完善會直接導(dǎo)致，系統(tǒng)擋掉，無法對外提供服務(wù)。

2.2.1 停止在單一模式的系統(tǒng)上開發(fā)新業(yè)務(wù)

首先停止讓問題更糟。不要繼續(xù)通過向單一應(yīng)用程序添加代碼的方式來實現(xiàn)新功能。采用某種方式來將新功能實現(xiàn)為獨立的服務(wù)。這可能并不容易。你可能會編寫凌亂的，復(fù)雜的膠水代碼來向單塊應(yīng)用程序集成服務(wù)。但這是打散單塊程序的第一步。

這種方案有2個新增模塊“request router”和“glue code”（如圖2）：

Request Router

前端的請求路由層，用于處理（HTTP）請求，將符合新規(guī)則的請求發(fā)送給新增的服務(wù)，老的請求發(fā)給原有系統(tǒng)。

GlueCode

在程序設(shè)計中，為了讓新服務(wù)可以使用老系統(tǒng)的功能和數(shù)據(jù)設(shè)計編寫的，將不同部分的不兼容的代碼“粘合在一起”。在編寫代碼過程中，粘合代碼為了讓存在的庫或程序間進行交互。這里有3種訪問老系統(tǒng)方案：

（1）給單一系統(tǒng)添加遠程調(diào)用API

可以使用REST HTTP API

或者跨語言調(diào)用框架 Thrift RPC；

（2）直接訪問單一系統(tǒng)數(shù)據(jù)庫；

（3）訪問復(fù)制的同步的單一系統(tǒng)數(shù)據(jù)庫，并保持同步。

利用以往的開發(fā)經(jīng)驗，可以新建一個可伸縮的微服務(wù)，控制住單一系統(tǒng)的復(fù)雜度。

2.2.2抽離web層與業(yè)務(wù)邏輯層

表現(xiàn)層與業(yè)務(wù)邏輯層分離。單一模式系統(tǒng)內(nèi)的架構(gòu)中，調(diào)整本地調(diào)用方法，更改為遠程調(diào)用方法。

典型Web應(yīng)用通常由至少三個不同類型的部分組成（如圖3）：

表示層——處理HTTP請求并實現(xiàn)（REST）API或基于HTML的網(wǎng)頁UI的組件。在一個有復(fù)雜的用戶界面的應(yīng)用中，表達層常常有大量的代碼段。

業(yè)務(wù)邏輯層——是應(yīng)用的核心組件，實現(xiàn)業(yè)務(wù)規(guī)則。

數(shù)據(jù)訪問層——訪問基礎(chǔ)設(shè)施組件的組件，比如數(shù)據(jù)庫和消息代理。

抽離展現(xiàn)層的優(yōu)點：

（1）接口預(yù)先定義，開發(fā)視野提升，需求驅(qū)動。

（2）開發(fā)和設(shè)計工作分離。

（3）利于更快定位性能瓶頸。

3 總結(jié)

單一模式是構(gòu)建企業(yè)級應(yīng)用程序常用的模式。對于小的應(yīng)用程序它很適用：開發(fā)，測試和部署小型的單塊程序相對簡單。但是，對于大型的復(fù)雜的應(yīng)用程序，單一模式會阻礙開發(fā)和部署。如果你經(jīng)常長期的鎖定你的初始技術(shù)選擇，則會使得持續(xù)交付變得困難。對于大型的應(yīng)用程序，更適合適用微服務(wù)架構(gòu)，其將應(yīng)用程序分解為一組服務(wù)。

微服務(wù)架構(gòu)有很多優(yōu)點。例如，單個服務(wù)更容易理解，可以獨立于其它服務(wù)來開發(fā)和部署。也更容易使用新的語言和技術(shù)，因為你可以一次只對一個服務(wù)嘗試新技術(shù)。微服務(wù)架構(gòu)也有一些顯著的缺點。特別是對那些更復(fù)雜，擁有更多變化部分的應(yīng)用程序。你需要高級別的自動化，來高效地使用微服務(wù)。你也需要在開發(fā)微服務(wù)時處理一些復(fù)雜的分布式數(shù)據(jù)管理問題。盡管有這些缺點，微服務(wù)架構(gòu)還是更適用于大型的復(fù)雜的應(yīng)用程序，因為可以快速演化。

參考文獻

[1] 韋伯.帕拉斯泰迪斯.魯濱遜.REST實戰(zhàn)：中文版超媒體和系統(tǒng)架構(gòu).中國：東南大學出版社，2011.

[2] MICROSERVICES From Design to Deployment by Chris Richardson with Floyd Smith.

[3] Building Micorservices by Sam Newman Copyright 2015 Published by OReilly Media.