前言
最近幾年，樓主在微服務領域作過一些架構設計，針對新老服務如何微服務化積累必定經驗，現分享給你們，但願對你們有用。同時歡迎頭條的朋友在評論區留言，共同討論微服務該如何演進。html
1、平臺微服務改造方案
一、啓動方式前端
啓動方式改成spring-boot啓動，需修改pom文件，修改以前的配置文件加載方式。html5
Springboot打包能夠打成jar， 也能夠打出包含jsp的war，可是war的打包方式目前沒有研究。配置文件能夠合併，也能夠加載指定文件。web
二、服務劃分redis
須要新增多個服務，如服務發現、服務網關、配置中心服務、負載均衡等，須要用到spring-cloud。除此以外，若是不手動啓動中止服務、方便管理，還須要一些自動化管理部署工具（Docker + k8s）。spring
平臺具體的功能被劃分爲如下4個服務數據庫
三、登陸認證npm
登陸認證由網關配合認證服務共同完成。各服務自己上跟認證相關的配置也須要更改。編程
四、前端展現json
採用Angular2+Bootstrap+H5展現View層，淘汰jsp。
五、代碼結構
六、MVC框架
業務邏輯層（service）保持不變；數據訪問層改爲JPA實現（repository）；controller層改爲restful風格，struts的所有改爲rest的springmvc。
使用spring-data技術，在此基礎上擴展了其基類方法。支持如下多種查詢方式：
在configuration類上添加@enableJpaRepository註解
@configuration
@enableJpaRepository(basePackages={「xxx」}, repositoryFactoryBeanClass=BaseRepositoryFactoryBean.calss)
public class Application {
…
}
二、編寫的repository接口都繼承自BaseRepository接口
七、單元測試與集成測試
目前前端後端分組，原則上前端單元測試不依賴於後臺數據，先後端定義好json數據格式，以便前端獨立測試。
前端用karma進行單元測試；後端用mock+postman進行單元測試。
八、數據庫設計
九、關於工程切換和數據源切換
目前基本上是一個服務訪問一個數據源。
十、上下文
AuthenticationHolder來獲取當前登陸用戶信息。
十一、服務間調用
服務的api在實現時，都是經過rest方式來實現。經過spring-cloud-feign技術做爲http客戶端調用遠程http服務。服務端接口暴露方式以下：
客戶端調用方式以下：
@Autowired
private LogRemoteService service; // 遠程服務
凡是涉及到兩個服務的之間API接口調用，不能使用以前的pom引入，改成服務間調用的方式。因此須要兩個服務都引用共同的實體，共用的實體須要提取出來。系統參數和字典、操做日誌都須要改爲微服務
十二、緩存框架
使用redis + ehcache兩級緩存，原理以下：
添加數據時，在緩存到遠程redis的同時，緩存一份到本地進程ehcache（此處的ehcache不用作集羣，避免組播帶來的開銷），取緩存的時候會先取本地，沒有會向redis請求，這樣會減小應用服務器<–>緩存服務器redis之間的網絡開銷。（見下圖，爲了減小get這幾條網絡傳輸，咱們會在每一個應用服務器上增長本地的ehcache緩存做爲二級緩存，即第一次get到的數據存入ehcache，後面output輸出便可從本地ehcache中獲取，不用再訪問redis了，因此就減小了之後get的網絡開銷。get開銷只要一次，後續不須要了，除非本地緩存過時須要再get。
1三、操做日誌切面處理
操做日誌切面處理。以前核心包有些service用到記錄操做日誌、和當前用戶的方法都須要改。
第一步，定義註解類註解類Logging
第二步，服務定義切面
@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){
…
}
}
1四、分佈式異常與事務
調用其餘服務異常時，該業務是否繼續進行問題須要作特殊處理。而分佈式事物的回滾問題，目前尚未研究，要實現可能代碼寫的時候要麻煩些，須要考慮各類狀況，爲了回滾也須要記錄操做前的數據。
1五、統一返回碼處理
爲了提升先後端的交互體驗，對後臺返回的數據和異常進行了統一封裝。並根據不一樣類型的返回值定義了一系列的返回碼。
後端返回值格式以下：
｛
「code「: 「10001「,
「message「: 「code重複，不能保存！「,
「data「:null
｝
其中：code代碼返回碼，message代碼提示信息，data表明返回數據。以上是一個校驗異常的示例。返回碼定義列表以下：
2、前端框架設計
一、背景
在過去的幾年，前端技術飛速發展，涌現了不少優秀的框架，新興的前端技術主要有如下特色：
用戶體驗
從html5產生以來，隨着富客戶端技術的多種多樣，用戶體驗變得愈來愈重要。頁面的美觀性、響應速度、內存消耗性能優劣等成爲客戶選擇產品很是重要的因素。
組件化
利潤最大化的兩個主要途徑是減小部署成本、提升開發效率；而提升開發效率的兩個主要途徑就是加快開發速度，減小變動代價。JavaScript組件化的目標是清晰的職責，鬆耦合，便於單元測試和重複利用，提升開發效率。
MV*框架
相似於後端的分層，前端也大體分爲三層，從發展上經歷了由MVC --> MVP --> MVVM的轉換，MV*表明這三者及相似框架。MV*框架的理念是把前端按照職責分層，每一層都相對比較獨立，有本身的價值，也有各自發揮的餘地。
工程化
一個符合工程化要求的軟件系統(前端)須要包含的要素：
開發規範；模塊化開發；組件化開發；組件倉庫；性能優化；項目部署；開發流程；開發工具。
二、目標
搭建前端框架，制定開發規範及開發流程
選用目前應用最廣，有着良好的開源社區及技術支持的MV*框架，結合公司後臺管理類系統的特色，進行技術選型及框架設計。在編程模型肯定之後，制定前端開發流程及開發規範。
搭建符合前端框架的開發環境及開發、打包、發佈工具
根據前端開發、部署及測試等需求，創建前端的開發工具、開發環境、打包及部署等工具。
基於界面交互風格，開發通用組件庫
爲了提升應用開發效率，須要創建一套頁面組件庫，知足應用開發的各個場景。
創建一套優秀用戶體驗的界面交互風格及視覺效果
創建優秀的前端框架能夠支持更加豐富的頁面交互效果，提升響應速度，提高用戶體驗。可是沒有良好的交互及視覺效果設計，這一切用戶是很難感覺到的，因此前端的交互風格及視覺效果是不可或缺的一部分。
三、技術選型
基於目標經過技術調研並結合公司實際狀況選取以下前端技術棧：
前端新的框架層出不窮，爲何最終會選擇Angular，主要有如下幾方面的緣由：
整合性（ALL-IN-ONE）。它涵蓋了M、V、C/VM等各個層面，不須要組合、評估其它技術就能完成大部分前端開發任務，能夠有效下降決策成本，提升決策速度。
組件化。Angular原生支持組件化開發，便於代碼解耦和複用，提升開發效率。
全生命週期支持。一個優秀的框架須要對分工提供良好的支持，每一個人均可以先從一些簡單任務開始，逐步的從修改一個文件擴大到修改一個目錄再到獨立實現一個特性。Angular是一個大型開源項目，並獲得了Google的鼎力支持，學習成本相對較低，可讓新人快速融入項目組，貢獻生產力。
支持單元測試和e2e測試。Angular對單元測試和e2e測試更加友好，能夠更快速地編寫測試代碼，完成自動化測試。
四、界面設計
設計原則
對應用系統的功能可以一目瞭然、不須要多少培訓就能夠方便使用該應用系統，一直是作好用戶界面的最終目標！
本系統堅持圖形用戶界面（GUI）設計原則：
設計時首先關注用戶及其業務，而不是技術如何實現
UI設計簡潔美觀，視覺元素清晰
採用蘋果灰的配色方案以及親和力比較強的「桔色#ff9900」爲主體色。
可理解性操做思惟
行爲、反饋、可視化展示和信息等一系列活動，應該有合理的順序，很容易記得，容易放置在內容中。
可配置性
容許簡單的個性化配置、設置或新配置。
界面以及操做一致性
引導性術語描述，引導用戶行爲
一方面爲：幫助信息，輔助用戶完成操做的提示信息；另外一方面爲：用戶操做結果的反饋信息（多爲彈出提示框形式出現）。
五、設計規範
六、框架結構
如上圖爲前端總體框架結構，包括：
入口文件：index.html同時也是應用程序首頁面。index.html中能夠定義系統的全局的樣式。
appModule：系統的根模塊，Angular 應用是模塊化的，每一個應用至少有一個跟模塊。
homeModule：系統界面框架模塊，包括左側菜單欄、頂部導航欄以及中間內容區。
sysModule：平臺安全框架模塊。
otherModule：其它應用模塊。
base/constants：平臺提供的基類以及常量。
組件庫：組件庫爲平臺搭建的通用組件，知足應用開發的經常使用場景，能夠做爲第三方依賴包集成到應用開發中，提升應用產品開發效率。
目前，組件庫的開發已完成80%左右，能夠知足應用基本業務場景，後續還須要不斷地擴充、完善和優化，讓組件庫更方便、易用。
七、工程化
工程化的主要目的是提升效率、下降成本，所以前端工程化也是必不可少的一部分，前面提到了工程化的幾個要素，針對這幾個要素提出了咱們的解決方案：
開發規範
定義前端開發規範文檔，並經過TSLint和codelyzer對代碼進行檢查。
模塊化開發
利用Angular的module功能對不一樣的應用模塊採用模塊化開發。
組件化開發
Angular原生支持組件化開發，下降代碼的耦合性，提升代碼可複用性。
組件倉庫
利用cnpm搭建私服，全部組件庫在cnpm私服中統一管理。
開發流程
定義開發流程，明確職責和協同，明確目標，提升開發效率。（目前，開發流程尚未徹底固化下來，仍須要進一步完善）
開發工具
平臺組完成開發語言、開發工具、測試工具、發佈工具等選型，全部應用產品按照規範統一開發工具。
性能優化
頁面的響應時間對於用戶是很是重要的，所以前端的性能優化（按需加載、延遲加載、代碼壓縮、緩存等）是很重要的一部分，目前這部分考慮的比較少，後續會重點考慮前端性能優化內容。
3、後端框架設計
一、 服務拆分
公共服務
二、公共組件
三、開發靜態視圖
平臺基礎框架
平臺基礎框架提供公共的API供業務開發者調用，讓他們關注與業務層面的代碼實現，而不是平臺底層框架實現。
平臺基礎框架包括：
1) 基礎核心（app-cloud-framework-core）
提供數據庫訪問配置、Base基類(Service、Repository)、實體、工具、註解、切面、常量功能等
2) 控制層（app-cloud-framework-mvc）
提供控制層基類（Controller）、獲取認證用戶功能等。
以下圖所示：
平臺基礎服務
平臺基礎服務存在的目的是爲用戶提供訪問入口、安全認證；爲服務提供註冊與發現、負載均衡、熔斷、配置等功能。
平臺基礎服務包括：
1) 認證服務（app-cloud-cloudware-authserver）
用於實現用戶單點登陸和退出。
2) 配置中心服務（app-cloud-cloudware-configserver）
用於管理各個服務的配置文件管理。
3) 註冊與發現服務（app-cloud-cloudware-discovery）
用於管理服務的註冊與發現。
4) 網關服務（app-cloud-cloudware-gateway）
實現用戶統一入口訪問，動態路由，安全認證等。
以下圖所示：
4、持續構建與交付
Jenkins
Jenkins與Gitlab、Docker、Sonar配合完成服務源代碼的校驗、構建和發佈。
最終構件分爲兩個部分：
Docker鏡像
二進制包（例如jar）
成果展現
服務源代碼構建任務清單：
app-cloud-cloudware-authserver（認證服務源代碼構建任務）
app-cloud-cloudware-configserver（配置中心服務構源代碼建任務）
app-cloud-cloudware-discovery（服務註冊與發現源代碼構建任務）
app-cloud-cloudware-gateway（服務網關源代碼構建任務）
app-cloud-param-service（公用參數服務源代碼構建任務）
app-cloud-security-service（安全框架服務源代碼構建任務）
其餘服務
基礎框架源代碼構建任務清單：
app-cloud-framework（基礎框架源代碼構建任務）
app-cloud-platformwork（平臺框架源代碼構建任務）
以下圖所示：
例子：編譯服務網關源代碼
把服務網關打成鏡像，上傳到鏡像庫。
Gitlab
Gitlab是一個版本控制管理系統。實現一個自託管的Git項目倉庫，可經過Web界面進行訪問公開的或者私人項目。它擁有與Github相似的功能，可以瀏覽源代碼，管理缺陷和註釋。能夠管理團隊對倉庫的訪問，它很是易於瀏覽提交過的版本並提供一個文件歷史庫。
以下圖：
例子：安全框架服務源碼
咱們規定，一個完整的微服務，其靜態視圖包含以下幾個部分：
1.Dockerfile文件
用於建立Docker鏡像，實現微服務容器化部署。
2.api目錄
對外暴露服務的api接口訪問地址。例如咱們想獲取張三的用戶信息，就能夠調用用戶信息的API接口，請求地址爲http://localhost/security-service/user/vi/000809
3.config目錄
用於配置數據庫訪問、服務啓動時配置參數加載以及api接口受權訪問控制。
4.repository目錄
數據的訪問層，提供訪問數據庫數據的接口
5. 實體目錄（獨立項目，經過pom引入）
用於處理實體與數據庫表映射關係；api資源受權訪問控制；爲repository層提供數據封裝體。
6. service目錄
用於處理具體業務的邏輯
7. 啓動類Application
Maven私服庫
Docker私服庫
鏡像項目
平臺鏡像項目
安全框架服務鏡像地址
5、我的開發環境配置清單
本文分享自微信公衆號 - 架構薈萃（dwooola）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。