微服务平台改造落地解决方案设计
前言
最近幾年,樓主在微服務(wù)領(lǐng)域做過一些架構(gòu)設(shè)計(jì),針對新老服務(wù)如何微服務(wù)化積累一定經(jīng)驗(yàn),現(xiàn)分享給大家,希望對大家有用。同時(shí)歡迎頭條的朋友在評論區(qū)留言,共同討論微服務(wù)該如何演進(jìn)。
一、平臺微服務(wù)改造方案
1、啟動方式
啟動方式改為spring-boot啟動,需修改pom文件,修改之前的配置文件加載方式。
Springboot打包可以打成jar, 也可以打出包含jsp的war,但是war的打包方式目前沒有研究。配置文件可以合并,也可以加載指定文件。
2、服務(wù)劃分
需要新增多個(gè)服務(wù),如服務(wù)發(fā)現(xiàn)、服務(wù)網(wǎng)關(guān)、配置中心服務(wù)、負(fù)載均衡等,需要用到spring-cloud。除此之外,如果不手動啟動停止服務(wù)、方便管理,還需要一些自動化管理部署工具(Docker + k8s)。
平臺具體的功能被劃分為以下4個(gè)服務(wù)
3、登錄認(rèn)證
登錄認(rèn)證由網(wǎng)關(guān)配合認(rèn)證服務(wù)共同完成。各服務(wù)本身上跟認(rèn)證相關(guān)的配置也需要更改。
4、前端展示
采用Angular2+Bootstrap+H5展示View層,淘汰jsp。
5、代碼結(jié)構(gòu)
6、MVC框架
業(yè)務(wù)邏輯層(service)保持不變;數(shù)據(jù)訪問層改成JPA實(shí)現(xiàn)(repository);controller層改成restful風(fēng)格,struts的全部改成rest的springmvc。
使用spring-data技術(shù),在此基礎(chǔ)上擴(kuò)展了其基類方法。支持以下多種查詢方式:
在configuration類上添加@enableJpaRepository注解
@configuration @enableJpaRepository(basePackages={“xxx”}, repositoryFactoryBeanClass=BaseRepositoryFactoryBean.calss) public class Application {… }2、編寫的repository接口都繼承自BaseRepository接口
7、單元測試與集成測試
目前前端后端分組,原則上前端單元測試不依賴于后臺數(shù)據(jù),前后端定義好json數(shù)據(jù)格式,以便前端獨(dú)立測試。
前端用karma進(jìn)行單元測試;后端用mock+postman進(jìn)行單元測試。
8、數(shù)據(jù)庫設(shè)計(jì)
9、關(guān)于工程切換和數(shù)據(jù)源切換
目前基本上是一個(gè)服務(wù)訪問一個(gè)數(shù)據(jù)源。
10、上下文
AuthenticationHolder來獲取當(dāng)前登錄用戶信息。
11、服務(wù)間調(diào)用
服務(wù)的api在實(shí)現(xiàn)時(shí),都是通過rest方式來實(shí)現(xiàn)。通過spring-cloud-feign技術(shù)作為http客戶端調(diào)用遠(yuǎn)程http服務(wù)。服務(wù)端接口暴露方式如下:
客戶端調(diào)用方式如下:
@Autowired private LogRemoteService service; // 遠(yuǎn)程服務(wù)凡是涉及到兩個(gè)服務(wù)的之間API接口調(diào)用,不能使用之前的pom引入,改為服務(wù)間調(diào)用的方式。所以需要兩個(gè)服務(wù)都引用共同的實(shí)體,共用的實(shí)體需要提取出來。系統(tǒng)參數(shù)和字典、操作日志都需要改成微服務(wù)
12、緩存框架
使用redis + ehcache兩級緩存,原理如下:
添加數(shù)據(jù)時(shí),在緩存到遠(yuǎn)程redis的同時(shí),緩存一份到本地進(jìn)程ehcache(此處的ehcache不用做集群,避免組播帶來的開銷),取緩存的時(shí)候會先取本地,沒有會向redis請求,這樣會減少應(yīng)用服務(wù)器<–>緩存服務(wù)器redis之間的網(wǎng)絡(luò)開銷。(見下圖,為了減少get這幾條網(wǎng)絡(luò)傳輸,我們會在每個(gè)應(yīng)用服務(wù)器上增加本地的ehcache緩存作為二級緩存,即第一次get到的數(shù)據(jù)存入ehcache,后面output輸出即可從本地ehcache中獲取,不用再訪問redis了,所以就減少了以后get的網(wǎng)絡(luò)開銷。get開銷只要一次,后續(xù)不需要了,除非本地緩存過期需要再get。
13、操作日志切面處理
操作日志切面處理。之前核心包有些service用到記錄操作日志、和當(dāng)前用戶的方法都需要改。
第一步,定義注解類注解類Logging
第二步,服務(wù)定義切面
@Aspect @Component public class LogAspect {… }第三步,在需要記錄操作日志的方法上添加注解
@RestController @RequestMapping(value = "/xxx") public class xxxController {@Logging(title="查詢訂單列表操作", data="查詢類型為{0}訂單")@RequestMapping( value="/showData", method = RequestMethod.GET)public ResponseEntity<String> showData(String tupe){…} }14、分布式異常與事務(wù)
調(diào)用其他服務(wù)異常時(shí),該業(yè)務(wù)是否繼續(xù)進(jìn)行問題需要做特殊處理。而分布式事物的回滾問題,目前還沒有研究,要實(shí)現(xiàn)可能代碼寫的時(shí)候要麻煩些,需要考慮各種情況,為了回滾也需要記錄操作前的數(shù)據(jù)。
15、統(tǒng)一返回碼處理
為了提高前后端的交互體驗(yàn),對后臺返回的數(shù)據(jù)和異常進(jìn)行了統(tǒng)一封裝。并根據(jù)不同類型的返回值定義了一系列的返回碼。
后端返回值格式如下:
{“code“: “10001“,“message“: “code重復(fù),不能保存!“,“data“:null }其中:code代碼返回碼,message代碼提示信息,data代表返回?cái)?shù)據(jù)。以上是一個(gè)校驗(yàn)異常的示例。返回碼定義列表如下:
?
二、前端框架設(shè)計(jì)
1、背景
在過去的幾年,前端技術(shù)飛速發(fā)展,涌現(xiàn)了很多優(yōu)秀的框架,新興的前端技術(shù)主要有以下特點(diǎn):
-
用戶體驗(yàn)
從html5產(chǎn)生以來,隨著富客戶端技術(shù)的多種多樣,用戶體驗(yàn)變得越來越重要。頁面的美觀性、響應(yīng)速度、內(nèi)存消耗性能優(yōu)劣等成為客戶選擇產(chǎn)品非常重要的因素。
-
組件化
利潤最大化的兩個(gè)主要途徑是減少部署成本、提高開發(fā)效率;而提高開發(fā)效率的兩個(gè)主要途徑就是加快開發(fā)速度,減少變更代價(jià)。JavaScript組件化的目標(biāo)是清晰的職責(zé),松耦合,便于單元測試和重復(fù)利用,提高開發(fā)效率。
-
MV*框架
類似于后端的分層,前端也大致分為三層,從發(fā)展上經(jīng)歷了由MVC --> MVP --> MVVM的轉(zhuǎn)換,MV*代表這三者及類似框架。MV*框架的理念是把前端按照職責(zé)分層,每一層都相對比較獨(dú)立,有自己的價(jià)值,也有各自發(fā)揮的余地。
-
工程化
一個(gè)符合工程化要求的軟件系統(tǒng)(前端)需要包含的要素:
開發(fā)規(guī)范;模塊化開發(fā);組件化開發(fā);組件倉庫;性能優(yōu)化;項(xiàng)目部署;開發(fā)流程;開發(fā)工具。
2、目標(biāo)
-
搭建前端框架,制定開發(fā)規(guī)范及開發(fā)流程
選用目前應(yīng)用最廣,有著良好的開源社區(qū)及技術(shù)支持的MV*框架,結(jié)合公司后臺管理類系統(tǒng)的特點(diǎn),進(jìn)行技術(shù)選型及框架設(shè)計(jì)。在編程模型確定以后,制定前端開發(fā)流程及開發(fā)規(guī)范。
-
搭建符合前端框架的開發(fā)環(huán)境及開發(fā)、打包、發(fā)布工具
根據(jù)前端開發(fā)、部署及測試等需求,建立前端的開發(fā)工具、開發(fā)環(huán)境、打包及部署等工具。
-
基于界面交互風(fēng)格,開發(fā)通用組件庫
為了提高應(yīng)用開發(fā)效率,需要建立一套頁面組件庫,滿足應(yīng)用開發(fā)的各個(gè)場景。
-
建立一套優(yōu)秀用戶體驗(yàn)的界面交互風(fēng)格及視覺效果
建立優(yōu)秀的前端框架可以支持更加豐富的頁面交互效果,提高響應(yīng)速度,提升用戶體驗(yàn)。但是沒有良好的交互及視覺效果設(shè)計(jì),這一切用戶是很難感受到的,所以前端的交互風(fēng)格及視覺效果是不可或缺的一部分。
3、技術(shù)選型
基于目標(biāo)通過技術(shù)調(diào)研并結(jié)合公司實(shí)際情況選取如下前端技術(shù)棧:
前端新的框架層出不窮,為什么最終會選擇Angular,主要有以下幾方面的原因:
-
整合性(ALL-IN-ONE)。它涵蓋了M、V、C/VM等各個(gè)層面,不需要組合、評估其它技術(shù)就能完成大部分前端開發(fā)任務(wù),可以有效降低決策成本,提高決策速度。
-
組件化。Angular原生支持組件化開發(fā),便于代碼解耦和復(fù)用,提高開發(fā)效率。
-
全生命周期支持。一個(gè)優(yōu)秀的框架需要對分工提供良好的支持,每個(gè)人都可以先從一些簡單任務(wù)開始,逐步的從修改一個(gè)文件擴(kuò)大到修改一個(gè)目錄再到獨(dú)立實(shí)現(xiàn)一個(gè)特性。Angular是一個(gè)大型開源項(xiàng)目,并得到了Google的鼎力支持,學(xué)習(xí)成本相對較低,可以讓新人快速融入項(xiàng)目組,貢獻(xiàn)生產(chǎn)力。
-
支持單元測試和e2e測試。Angular對單元測試和e2e測試更加友好,可以更快速地編寫測試代碼,完成自動化測試。
4、界面設(shè)計(jì)
設(shè)計(jì)原則
對應(yīng)用系統(tǒng)的功能能夠一目了然、不需要多少培訓(xùn)就可以方便使用該應(yīng)用系統(tǒng),一直是做好用戶界面的最終目標(biāo)!
本系統(tǒng)堅(jiān)持圖形用戶界面(GUI)設(shè)計(jì)原則:
-
設(shè)計(jì)時(shí)首先關(guān)注用戶及其業(yè)務(wù),而不是技術(shù)如何實(shí)現(xiàn)
-
UI設(shè)計(jì)簡潔美觀,視覺元素清晰
采用蘋果灰的配色方案以及親和力比較強(qiáng)的“桔色#ff9900”為主體色。
-
可理解性操作思維
行為、反饋、可視化展現(xiàn)和信息等一系列活動,應(yīng)該有合理的順序,很容易記得,容易放置在內(nèi)容中。
-
可配置性
允許簡單的個(gè)性化配置、設(shè)置或新配置。
-
界面以及操作一致性
-
引導(dǎo)性術(shù)語描述,引導(dǎo)用戶行為
一方面為:幫助信息,輔助用戶完成操作的提示信息;另一方面為:用戶操作結(jié)果的反饋信息(多為彈出提示框形式出現(xiàn))。
5、設(shè)計(jì)規(guī)范
?
?
6、框架結(jié)構(gòu)
如上圖為前端整體框架結(jié)構(gòu),包括:
-
入口文件:index.html同時(shí)也是應(yīng)用程序首頁面。index.html中可以定義系統(tǒng)的全局的樣式。
-
appModule:系統(tǒng)的根模塊,Angular 應(yīng)用是模塊化的,每個(gè)應(yīng)用至少有一個(gè)跟模塊。
-
homeModule:系統(tǒng)界面框架模塊,包括左側(cè)菜單欄、頂部導(dǎo)航欄以及中間內(nèi)容區(qū)。
-
sysModule:平臺安全框架模塊。
-
otherModule:其它應(yīng)用模塊。
-
base/constants:平臺提供的基類以及常量。
-
組件庫:組件庫為平臺搭建的通用組件,滿足應(yīng)用開發(fā)的常用場景,可以作為第三方依賴包集成到應(yīng)用開發(fā)中,提高應(yīng)用產(chǎn)品開發(fā)效率。
目前,組件庫的開發(fā)已完成80%左右,可以滿足應(yīng)用基本業(yè)務(wù)場景,后續(xù)還需要不斷地?cái)U(kuò)充、完善和優(yōu)化,讓組件庫更方便、易用。
7、工程化
工程化的主要目的是提高效率、降低成本,因此前端工程化也是必不可少的一部分,前面提到了工程化的幾個(gè)要素,針對這幾個(gè)要素提出了我們的解決方案:
-
開發(fā)規(guī)范
定義前端開發(fā)規(guī)范文檔,并通過TSLint和codelyzer對代碼進(jìn)行檢查。
-
模塊化開發(fā)
利用Angular的module功能對不同的應(yīng)用模塊采用模塊化開發(fā)。
-
組件化開發(fā)
Angular原生支持組件化開發(fā),降低代碼的耦合性,提高代碼可復(fù)用性。
-
組件倉庫
利用cnpm搭建私服,所有組件庫在cnpm私服中統(tǒng)一管理。
-
開發(fā)流程
定義開發(fā)流程,明確職責(zé)和協(xié)同,明確目標(biāo),提高開發(fā)效率。(目前,開發(fā)流程還沒有完全固化下來,仍需要進(jìn)一步完善)
-
開發(fā)工具
平臺組完成開發(fā)語言、開發(fā)工具、測試工具、發(fā)布工具等選型,所有應(yīng)用產(chǎn)品按照規(guī)范統(tǒng)一開發(fā)工具。
-
性能優(yōu)化
頁面的響應(yīng)時(shí)間對于用戶是非常重要的,因此前端的性能優(yōu)化(按需加載、延遲加載、代碼壓縮、緩存等)是很重要的一部分,目前這部分考慮的比較少,后續(xù)會重點(diǎn)考慮前端性能優(yōu)化內(nèi)容。
三、后端框架設(shè)計(jì)
1、 服務(wù)拆分
公共服務(wù)
2、公共組件
3、開發(fā)靜態(tài)視圖
平臺基礎(chǔ)框架
平臺基礎(chǔ)框架提供公共的API供業(yè)務(wù)開發(fā)者調(diào)用,讓他們關(guān)注與業(yè)務(wù)層面的代碼實(shí)現(xiàn),而不是平臺底層框架實(shí)現(xiàn)。
平臺基礎(chǔ)框架包括:
1) 基礎(chǔ)核心(app-cloud-framework-core)
提供數(shù)據(jù)庫訪問配置、Base基類(Service、Repository)、實(shí)體、工具、注解、切面、常量功能等
2) 控制層(app-cloud-framework-mvc)
提供控制層基類(Controller)、獲取認(rèn)證用戶功能等。
如下圖所示:
平臺基礎(chǔ)服務(wù)
平臺基礎(chǔ)服務(wù)存在的目的是為用戶提供訪問入口、安全認(rèn)證;為服務(wù)提供注冊與發(fā)現(xiàn)、負(fù)載均衡、熔斷、配置等功能。
平臺基礎(chǔ)服務(wù)包括:
1) 認(rèn)證服務(wù)(app-cloud-cloudware-authserver)
用于實(shí)現(xiàn)用戶單點(diǎn)登錄和退出。
2) 配置中心服務(wù)(app-cloud-cloudware-configserver)
用于管理各個(gè)服務(wù)的配置文件管理。
3) 注冊與發(fā)現(xiàn)服務(wù)(app-cloud-cloudware-discovery)
用于管理服務(wù)的注冊與發(fā)現(xiàn)。
4) 網(wǎng)關(guān)服務(wù)(app-cloud-cloudware-gateway)
實(shí)現(xiàn)用戶統(tǒng)一入口訪問,動態(tài)路由,安全認(rèn)證等。
如下圖所示:
?
四、持續(xù)構(gòu)建與交付
Jenkins
Jenkins與Gitlab、Docker、Sonar配合完成服務(wù)源代碼的校驗(yàn)、構(gòu)建和發(fā)布。
最終構(gòu)件分為兩個(gè)部分:
Docker鏡像
二進(jìn)制包(例如jar)
成果展示
服務(wù)源代碼構(gòu)建任務(wù)清單:
app-cloud-cloudware-authserver(認(rèn)證服務(wù)源代碼構(gòu)建任務(wù))
app-cloud-cloudware-configserver(配置中心服務(wù)構(gòu)源代碼建任務(wù))
app-cloud-cloudware-discovery(服務(wù)注冊與發(fā)現(xiàn)源代碼構(gòu)建任務(wù))
app-cloud-cloudware-gateway(服務(wù)網(wǎng)關(guān)源代碼構(gòu)建任務(wù))
app-cloud-param-service(公用參數(shù)服務(wù)源代碼構(gòu)建任務(wù))
app-cloud-security-service(安全框架服務(wù)源代碼構(gòu)建任務(wù))
其他服務(wù)
基礎(chǔ)框架源代碼構(gòu)建任務(wù)清單:
app-cloud-framework(基礎(chǔ)框架源代碼構(gòu)建任務(wù))
app-cloud-platformwork(平臺框架源代碼構(gòu)建任務(wù))
如下圖所示:
例子:編譯服務(wù)網(wǎng)關(guān)源代碼
把服務(wù)網(wǎng)關(guān)打成鏡像,上傳到鏡像庫。
?
Gitlab
Gitlab是一個(gè)版本控制管理系統(tǒng)。實(shí)現(xiàn)一個(gè)自托管的Git項(xiàng)目倉庫,可通過Web界面進(jìn)行訪問公開的或者私人項(xiàng)目。它擁有與Github類似的功能,能夠?yàn)g覽源代碼,管理缺陷和注釋。可以管理團(tuán)隊(duì)對倉庫的訪問,它非常易于瀏覽提交過的版本并提供一個(gè)文件歷史庫。
如下圖:
例子:安全框架服務(wù)源碼
我們規(guī)定,一個(gè)完整的微服務(wù),其靜態(tài)視圖包含如下幾個(gè)部分:
1.Dockerfile文件
用于創(chuàng)建Docker鏡像,實(shí)現(xiàn)微服務(wù)容器化部署。
2.api目錄
對外暴露服務(wù)的api接口訪問地址。例如我們想獲取張三的用戶信息,就可以調(diào)用用戶信息的API接口,請求地址為http://localhost/security-service/user/vi/000809
3.config目錄
用于配置數(shù)據(jù)庫訪問、服務(wù)啟動時(shí)配置參數(shù)加載以及api接口授權(quán)訪問控制。
4.repository目錄
數(shù)據(jù)的訪問層,提供訪問數(shù)據(jù)庫數(shù)據(jù)的接口
5. 實(shí)體目錄(獨(dú)立項(xiàng)目,通過pom引入)
用于處理實(shí)體與數(shù)據(jù)庫表映射關(guān)系;api資源授權(quán)訪問控制;為repository層提供數(shù)據(jù)封裝體。
6. service目錄
用于處理具體業(yè)務(wù)的邏輯
7. 啟動類Application
Maven私服庫
Docker私服庫
鏡像項(xiàng)目
平臺鏡像項(xiàng)目
安全框架服務(wù)鏡像地址
?
五、個(gè)人開發(fā)環(huán)境配置清單
總結(jié)
以上是生活随笔為你收集整理的微服务平台改造落地解决方案设计的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Java 泛型背后的原理是什么?
- 下一篇: Log4j2异步日志背后的数字