前言

現在已經到了一個后端開發人員如果說自己沒搞過微服務就out的時候了，前一段時間參加公司組織的微服務的相關培訓，正好借著這個機會把我們這些年的微服務遷移程序梳理一下，要不然過一段時間也許這些程序就真的成為黑歷史無人知曉了，

時間軸

2013年正式介入軟體開發，UAV系統OSGI+NFDW系統SSH雙框架起步，直接扯著蛋上天了
2014年，KSXT系統，嘗試引入maven
2016年6月，SCU系統，廢棄OSGI，引入jenkins，轉向Springboot+jpa，開始服務切分，與外協合作接觸docker，嘗試docker化，對接類和配置實作服務路由
2016年10月，ZHJK分模塊拆分，形成分布式系統，自己實作了類似于Feign的通訊工具類
2017年，GZ-SSJK，Spring boot+eureka+config+nginx，形成為微服務的雛形
2018年，UAV系統重構，借助Spring boot+eureka+config+nginx+Dashboard+zipkin形成微服務雛形
2018年，HSMB系統，SpringCloud全家桶，config+euerka+zuul+feign+mybatisplus+k8s,在開發環境下搭建了整套的基于k8s的CI/CD集群，發現計算資源不足
2019年，DXAL系統，SpringCloud全家桶，config+euerka+zuul+feign
2019年，ISS系統，SpringCloud全家桶，config+euerka+zuul+feign
2019年，GX-SSJK，直接復制GZ實時監控
2020年，UMP平臺，nacos+zuul+feign+k8s+skywalking+Prometheus
2020年，YN-SSJK，純鏡像化+docker-compose
2020年，SBH-SSJK，多模塊化改造+純鏡像化+docker-compose
2020年，JGDQ系統，nacos+zuul+feign+docker-compose
2020年，DC系統，回傳模塊化的單體應用

UAV架構
UAV
PS：IDE運行
NFDW架構

在這里插入圖片描述

SCU架構，單體應用+分布式雛形
在這里插入圖片描述
ZHJK架構，分布式系統+注冊中心+配置中心

SBH-SSJK架構，徹底服務化

在這里插入圖片描述

DC架構，單體應用

在這里插入圖片描述
一個jar包直接搞定，

缺乏必要的理由
為什么要進行微服務改造，相信業界已經有不少大佬說過了，但他們的原因對于你來說是否真的合適，
基礎服務準備不足
最開始SCU系統純靠手工部署，六七服務已經能把人搞得要崩潰了，由于服務之間又有一定的依賴關系，啟動順序也讓人抓狂，這也是后來上docker-compose與k8s的原因，微服務的構建一定要依賴基礎設施完成的，要不然iDE切專案來一個個構建真的是要瘋了，純手工的情況下，開發環境下沒有32g機器根本啟動不起來，這也是引入jenkins和docker以及harbor的原因，
服務拆解的過細
在微服務化的拆解程序中，SSJK以及UAV-Reborn按照慣性思維進行的拆解，形成了10多個服務，但是開發人員只是有三到四個人的情況下，完全hold不住，開發進行的非常快，但測驗和部署非常費勁，除了問題排查難度極高，
技術培訓沒有跟上
還是剛剛UAV重構前要是能夠對開發團隊進行一次為期三到四天的微服務整體性的培訓局面絕對將不一樣，
當你手上只有錘子的時候，看什么都是釘子
不要啥事都要上微服務，小心上癮，

你的專案是一個長期維護的系統，且維護最好由你的團隊來進行，如果你的系統每次都是領導參觀的時候才啟動一次，那不如搞一個虛擬機部署好，
足夠的硬體資源能夠支持你的基礎設施，最好由專門的基礎平臺團隊來支持，開發環境包括但不限于，持續集成系統，版本控制系統，k8集群，開發節點，測驗節點，日志聚合節點，skywalking節點，監控節點，資料集群，生產環境除了部署機器外，還要擁有監控集群，日志聚合和分析集群，日志追蹤集群，這個對于互聯網來說其實問題不大，畢竟云原生時代已經來到，但對于ToB企業來說挑戰可不小，由于各種各樣的原因可能是與互聯網隔絕的環境，光是搭建研發環境就夠崩潰的，至于如何能把服務部署到用戶那就更是一門學問了，
你的研發團隊擁有足夠的能力能夠hold住微服務的技術堆疊，如果你的團隊只有五個人，但是要hold住25個服務，那只能希望你的成員都是阿里的水平而且例外穩定，.

掌握微服務技術堆疊，專案啟動時做好容量評估和架構演進設計，實施程序注重模塊切分和解耦合，保證能夠在必要的時候將應用轉向微服務架構，

轉載請註明出處，本文鏈接：https://www.uj5u.com/qianduan/170125.html

標籤：其他