論微服務(wù)架構(gòu)及其應(yīng)用

1、論微服務(wù)架構(gòu)及其應(yīng)用摘要2016年7月，我所在的公司為全國各級人民檢察院開發(fā)了行賄犯罪檔案互聯(lián) 網(wǎng)查詢系統(tǒng)的產(chǎn)品，我擔(dān)任系統(tǒng)架構(gòu)師職務(wù)，主要負(fù)責(zé)軟件架構(gòu)和安全體系設(shè)計 的工作，該項目是基于互聯(lián)網(wǎng)，為單位、企業(yè)和個人等公眾群體提供7*24小時 的查詢申請服務(wù)，同時兼顧行賄犯罪預(yù)防宣傳。本文結(jié)合作者的實踐，以行賄犯 罪檔案互聯(lián)網(wǎng)查詢系統(tǒng)為例，論述微服務(wù)架構(gòu)及其應(yīng)用。首先概述我參與管理和 開發(fā)，并采用微服務(wù)架構(gòu)開發(fā)的工作，然后具體描述微服務(wù)架構(gòu)的特點，最后結(jié) 合項目描述軟件的架構(gòu)，說明該系統(tǒng)是如何采用微服務(wù)架構(gòu)模式的，并說明采用 微服務(wù)架構(gòu)模式后，在軟件開發(fā)過程中遇到的實際問題和解決方案。經(jīng)過項目組

2、 近一年的努力，本產(chǎn)品已順利開發(fā)完成，目前，已在浙江、云南等多省上線使用， 取得客戶和公司領(lǐng)導(dǎo)的一致好評。正文近年來，隨著互聯(lián)網(wǎng)行業(yè)的迅猛發(fā)展，公司或組織業(yè)務(wù)的不斷擴張，需求的 快速變化以及用戶量的不斷增加，傳統(tǒng)的單塊(Monolithic)軟件架構(gòu)面臨著越 來越多的挑戰(zhàn)，已逐漸無法適應(yīng)互聯(lián)網(wǎng)時代對軟件的要求。在這一背景下，微服 務(wù)架構(gòu)模式(Microservice Architecture Pattern)逐漸流行。它強調(diào)將單一業(yè) 務(wù)功能開發(fā)成微服務(wù)的形式，每個微服務(wù)運行在一個進(jìn)程中；采用HTTP等通信 協(xié)議和輕量級API實現(xiàn)微服務(wù)之間的協(xié)作與通信。這些微服務(wù)可以使用不同的開 發(fā)語言以及不同

3、數(shù)據(jù)存儲技術(shù)，能夠通過自動化部署工具獨立發(fā)布，并保持最低 限制的集中式管理。2015年7月，我所在的公司為全國各級人民檢察院開發(fā)了行賄犯罪檔案互聯(lián) 網(wǎng)查詢系統(tǒng)的產(chǎn)品，我擔(dān)任系統(tǒng)架構(gòu)師職務(wù)，主要負(fù)責(zé)軟件架構(gòu)和安全體系設(shè)計 的工作。本文結(jié)合作者的實踐，論述微服務(wù)架構(gòu)及其應(yīng)用。首先概述我參與管理 和開發(fā)，并采用微服務(wù)架構(gòu)開發(fā)的工作，然后具體描述微服務(wù)架構(gòu)的特點，最后 結(jié)合項目描述軟件的架構(gòu)，說明該架構(gòu)是如何采用微服務(wù)架構(gòu)模式的，并說明采 用微服務(wù)架構(gòu)模式后，在軟件開發(fā)過程中遇到的實際問題和解決方案。項目概述隨著互聯(lián)網(wǎng)的飛速發(fā)展，基于互聯(lián)網(wǎng)平臺建設(shè)行賄犯罪檔案查詢系統(tǒng)(Internet Bribery

4、 Crime Record Query IBCRQ)，為單位、企業(yè)和個人等公 眾群體提供實時、高效、方便的申請查詢服務(wù)，是互聯(lián)網(wǎng)+智慧檢察的深度融合， 也是社會經(jīng)濟發(fā)展的必然趨勢IBCRQ系統(tǒng)的建設(shè)，作為政府采購和招標(biāo)審查的 必經(jīng)關(guān)口，將有行賄犯罪記錄者拒之“門”夕外，大大降低了政府采購、工程建設(shè) 等領(lǐng)域官商勾結(jié)、權(quán)錢交易的幾率，為有效預(yù)防賄賂、震懾犯罪提供了很好的積 極作用IBCRQ系統(tǒng)包括用戶注冊、個人查詢申請、單位查詢申請、集中查詢申 請、異議復(fù)核申請、排號管理、法律知識問答、數(shù)據(jù)交換等業(yè)務(wù)模塊，實際使用 時，用戶可根據(jù)實際情況的需要選擇是否需要用戶注冊、排號管理、法律知識問 答等模塊自

5、由組合，限于篇幅，在此我們不再詳細(xì)介紹各個模塊的功能。微服務(wù)的目的是充分地分解應(yīng)用程序以促進(jìn)敏捷開發(fā)和部署。在IBCRQ系統(tǒng) 項目的管理和開發(fā)中，我們按功能需求將系統(tǒng)劃分為用戶中心、查詢申請、數(shù)據(jù) 交換、預(yù)約排號、法律知識問答5個微服務(wù)，同時將項目團隊劃分為3個小組， 根據(jù)功能的輕重緩急和工作量，安排各個微服務(wù)的研發(fā)。每個小組負(fù)責(zé)一個或多 個組件完整的生命周期，即服務(wù)誰開發(fā)，服務(wù)誰運營。最后各個服務(wù)組件通過 RESTful HTTP協(xié)議和消息路由功能進(jìn)行服務(wù)組裝。微服務(wù)架構(gòu)的特點傳統(tǒng)的單塊軟件架構(gòu)在構(gòu)建部署和擴展伸縮方面有很大的局限性，傳統(tǒng)的單 塊架構(gòu)一般分為客戶端用戶界面、數(shù)據(jù)庫、服務(wù)端應(yīng)用

6、程序三部分。系統(tǒng)中任何 程序的改變都需要整個應(yīng)用重新構(gòu)建和部署新版本。另外傳統(tǒng)的單塊軟件架構(gòu)在 進(jìn)行水平擴展時也只能整個系統(tǒng)擴展，而不能針對某一個功能模塊進(jìn)行擴展。而 微服務(wù)架構(gòu)可以完美的解決統(tǒng)一風(fēng)格架構(gòu)所遇到的種種問題。微服務(wù)架構(gòu)將系統(tǒng) 以組件化的方式分解為多個服務(wù)，服務(wù)之間相對獨立，單一功能的改變只需要重 新構(gòu)建部署相應(yīng)的服務(wù)即可。與單塊架構(gòu)相比，微服務(wù)架構(gòu)有如下的特點：通過服務(wù)實現(xiàn)應(yīng)用的組件化(Componentization Via Services)，在應(yīng)用架構(gòu)設(shè)計中，通過將整體應(yīng)用切分成可獨立部署及升級的微服務(wù)方式， 進(jìn)行組件化設(shè)計。圍繞業(yè)務(wù)能.力組織服務(wù)(Organized Ar

7、ound Business Capabilities)， 微服務(wù)架構(gòu)采取以業(yè)務(wù)能力為出發(fā)點組織服務(wù)的策略，因此微服務(wù)團隊 的組織結(jié)構(gòu)必須是跨功能的、強搭配的DevOps開發(fā)運維一體化團隊，通 常這些團隊不會太大?；A(chǔ)設(shè)施自動化(Infrastructure Automation)，云化及自動化部署等 技術(shù)極大地降低了微服務(wù)構(gòu)建、部署和運維的難度，通過應(yīng)用持續(xù)集成 和持續(xù)交付等方法有助于達(dá)到加速推出市場的目的。故障處理設(shè)計(Design For Failure)，微服務(wù)架構(gòu)所帶來的一個后果是 必須考慮每個服務(wù)的失敗容錯機制。因此微服務(wù)非常重視建立架構(gòu)及業(yè) 務(wù)相關(guān)指標(biāo)的實時監(jiān)控和日志機制。演進(jìn)式的

8、設(shè)計(Evolutionary Design)，微服務(wù)應(yīng)用更注重快速更新，因 此系統(tǒng)的計會隨時間不斷變化及演進(jìn)。微服務(wù)架構(gòu)應(yīng)用在IBCRQ系統(tǒng)中，采用通訊層、業(yè)務(wù)邏輯層、基礎(chǔ)服務(wù)層組成系統(tǒng)的微服務(wù) 架構(gòu)。如下圖所示：RESTRESTRESTIBCRQ系統(tǒng)微服務(wù)框架在微服務(wù)架構(gòu)下，我們選擇RESTful的進(jìn)行通訊。每個微服務(wù)都統(tǒng)一對外提 供REST服務(wù)。無論前端調(diào)用后端服務(wù)還是后端之間的服務(wù)調(diào)用都統(tǒng)一走 RESTful,這樣就統(tǒng)一了協(xié)議棧。微服務(wù)架構(gòu)可以支持各種異構(gòu)系統(tǒng)服務(wù)間的交 互。服務(wù)的注冊與發(fā)現(xiàn)，服務(wù)之間需要創(chuàng)建一種服務(wù)發(fā)現(xiàn)機制，用于幫助服務(wù)之 間互相感知彼此的存在。服務(wù)啟動時會將自身的服

9、務(wù)信息注冊到注冊中心，并訂 閱自己需要消費的服務(wù)。負(fù)載均衡是服務(wù)高可用的保證手段，為了保證高可用，每一個微服務(wù)都需要 部署多個服務(wù)實例來提供服務(wù)。我們主要支持隨機、輪詢、最少鏈接數(shù)的策略將 來自網(wǎng)絡(luò)的請求隨機分配給內(nèi)部中的多個服務(wù)器。目前主流的RPC框架包括dubbo，thrift， grpc等，我們采用dubbo為團隊 提供了一整套序列化，反序列化，網(wǎng)絡(luò)框架，連接池，線程池超時處理等業(yè)務(wù)處 理之外的能力。服務(wù)容錯采用快速失敗，失效切換的策略。如果連續(xù)失敗多次則直接熔斷， 不再發(fā)起調(diào)用。這樣可以避免一個服務(wù)異常拖垮所有依賴于他的服務(wù)。遇到的問題及解決方案在微服務(wù)實踐中，我們主要遇到三個問題，一運維開銷及成本增加，因為每 個微服務(wù)需獨立運行，還可能采用多種語言環(huán)境，這將導(dǎo)致資源開銷大；二代部 分碼重復(fù)，某些底層功能需要被多個服務(wù)所用；第三個問題是難以可視化及全面 測試，在動態(tài)環(huán)境下服務(wù)間的交互會產(chǎn)生非常微妙的行為。因此，首先服務(wù)劃分 應(yīng)盡量合理，不要劃分太細(xì)太多，其次采用公共模塊的方式提供底層服務(wù)，再次 微服務(wù)可通過監(jiān)控發(fā)現(xiàn)生產(chǎn)環(huán)境的異常，進(jìn)而快速回滾，彌補可測性不足的問題。通過項目實