企業微服務化勢在必行，這樣改造保你事半功倍

大李是A公司的架構師，正在主導一款線上打車軟件的架構，下面有好幾個團隊一塊兒協做開發，已經忙了好幾個月。

但大李最近有點煩，由於他主導的這個打車軟件出現了不少問題，進展很不順利。競爭對手D公司不斷推出新功能，大李的團隊只能疲於跟隨，同時還得應對內部的各類問題。他感受很疲憊，決定找公司技術總監老張聊聊。

一走進老張辦公室，大李便開門見山地說：「張總，咱們目前的開發速度很難跟上競爭對手的步伐。想找您聊聊看怎麼作才能加快咱們的進度？」

「好啊，那你能把咱們如今的架構先拿出來看看嗎？」老張答道。

因而，大李向老張展現了下面的架構圖：

▲Figure 1 – A公司打車軟件架構▲

老張仔細看了看後說：「目前咱們的軟件架構已經作了數據存儲分離，而且把計算模塊和存儲模塊都搬到了京東智聯雲上，用虛擬機來代替物理機。咱們的計算單元也能夠作橫向擴展來應對高峯流量，架構已經很靈活了，那麼如今面臨的問題是什麼呢？」

大李思索了一下娓娓道來：「咱們如今面臨的問題不少，我印象最深入的大概有這幾類：

1、發佈困難：咱們的計算單元和存儲單元是須要分佈在三個辦公地點的六個團隊共同合做，因此每次發佈版本都會是一個艱難工做。須要高級別的管理人員來統籌發佈計劃，上次發佈就是由您來統一指揮規劃的。

一個模塊的微小問題均可能會致使整個項目延遲，而現實中每一個模塊都會出現問題，因此一般要準備多輪迴歸測試來保證全部模塊都沒有大問題。上次就是小王最後合併進來的計費模塊的代碼竟然影響了客戶管理模塊，而後你們拼命加班測試修復問題仍然延遲兩天交付。

若是任何一個模塊出現了問題，都須要整個應用一塊兒調試，再發布上線。而每一個新版本發佈都會很困難，致使不少小問題的修復都要等很長時間。

2、模塊之間依賴問題：不少模塊都在一臺虛擬機中運行，它們之間的依賴關係錯綜複雜。因此各個模塊的啓動順序很是關鍵，必須十分當心地排列，而每次模塊改動均可能致使啓動順序的更改。啓動順序的問題幾乎每次發佈新版都會有問題。

3、模塊之間優先級問題：一樣由於每一個模塊都在同一臺虛擬機中運行，它們運行的線程優先級會變得很是敏感，須要很是當心地來設置優先級。不然在併發量大的狀況下，互相之間搶佔CPU資源會致使某些模塊得不到CPU資源處理的狀況。爲了調整線程優先級，各個團隊花了大量時間來測試和制定各個線程的優先級，但仍然不能在全部狀況達到預期效果。

_4、擴容難：_在併發量大的狀況下，某些處理單元可能須要擴容。那麼擴容的機器上必須複製全部的模塊。若是任何一個模塊在擴容過程當中出現問題，擴容就會失敗。不須要的模塊進行擴容自己就是一種浪費，而且增長了沒必要要的風險。

全部模塊的數據都存在一樣的存儲節點中，使得計算節點和存儲節點的關係變得很是複雜且難於管理。

5、難於維護：由於整個系統變得很是龐大複雜，各個模塊的關係又錯綜複雜。如今幾乎沒有人能對整個系統的各個部分都瞭解，致使每次改動（新功能或者修復bug）都有可能直到最後才發現有沒考慮到的狀況，加重了發佈的延遲。若是再發生核心人員的離開，將會使這個狀況雪上加霜。上次老金的離職就是個有力證實，他負責的模塊雖然接替的人還比較熟悉，可是和別的模塊的關係很複雜，結果是修復了一個bug，卻引入了兩個新bug。

綜上所述，我認爲必須改變咱們的架構，讓架構更簡單，模塊之間更獨立，更易於維護、發佈和擴容。」

「你說的這些問題其實我也意識到了，最近我正在研究微服務架構和各類微服務平臺。」老張點點頭表示贊同：「根據我初步的研究，若是想解決上述那些問題，就要考慮向微服務架構演進。微服務應該能解決咱們的大部分問題而且能提升咱們的生產力。我給你推薦一篇文章，你能夠先研究一下，回頭咱們再細緻討論。」

微服務小白掃盲：《微服務的理想與現實》

大李聽到老張的回答，一會兒轉憂爲喜：「那太好了！我先回去研究研究。過幾天再找您討論。」

一星期後，大李又找到了老張：「張總，我仔細研究了微服務的理論和框架。按照個人理解，咱們的架構若是能演變成這張微服務架構圖，就差很少能解決咱們目前面臨的問題。」

大李一邊說着，一邊給老張展現他畫出的微服務架構圖：

▲Figure 2 – 微服務架構圖▲

「_從架構圖能夠看出，基本上原來全部的模塊都變成了鬆耦合的微服務，它們均可以進行獨立部署、發佈、擴容_。全部困擾咱們的發佈難、擴容難、模塊CPU資源競爭問題、模塊依賴問題全均可以解決。這樣咱們每一個微服務能夠獨立發佈新版本，新功能的發佈和bug修復的流程都會快不少。」大李眼睛閃着光，興奮地說道。

「同時，獨立部署後也再也不須要進程管理模塊，各個微服務也沒必要共享基礎架構模塊，能夠根據本身的須要來選擇技術。另外由於各個服務如今界限清晰，每一個微服務負責的功能相對簡單內聚，開發人員很容易理解單個模塊內部邏輯，因此維護難問題也能夠獲得很好解決。」大李繼續補充着。

老張的臉上露出了滿意的笑容：「那看起來咱們的問題都獲得瞭解決。另外咱們公司已經開始使用敏捷開發，組建了scrum團隊，而且咱們有了Devops的經驗。因此三地的各個團隊能夠變成獨立的scrum團隊，負責獨立的微服務，這樣人員之間的協同工做問題也能夠獲得解決。那咱們是否是能夠馬上開始微服務化了呢？」

大李的眉頭又皺了起來，難爲地說道：「張總，雖然微服務化很好，咱們確定要朝着這個方向演化。可是微服務也會給咱們帶巨大的挑戰。」

「嗯，天下確定沒有免費的午飯。」老張隨即問道，「說說看，咱們的挑戰主要是什麼？」

大李早已調研清楚，爲老張一一分析：「首先，咱們須要把現有的應用拆分紅多個微服務。這是咱們的業務內容，很是關鍵，須要咱們本身慢慢來作。可是微服務架構自己有不少的東西，好比這張服務註冊發現圖，若是咱們採用springcloud架構，咱們集成後須要本身部署維護註冊中心。而註冊中心集羣也必須是高可用的。若是咱們本身來部署維護註冊中心集羣，那這就是咱們的短板，由於咱們沒有eureka或者consul的專業知識，部署和後期的運維工做都將須要更多的工程師。這將大大增長咱們的成本，咱們的組織結構也會更復雜。」

▲Figure 3 – 服務發現圖▲

「除了註冊中心，還有別的關於微服務基礎架構的問題嗎？」老張問。

大李思考了一下回答道：「還有很多問題，好比咱們拆分紅微服務後，不少服務之間的調用分析是很是須要的東西。因此就須要調用鏈分析，這將讓咱們面臨一樣的問題。好比咱們使用jaeger來做爲調用鏈分析，那麼就像調用鏈這張圖展現的，咱們也須要來維護複雜的jaeger集羣，而且要作到高可用。」

▲Figure 4 – 調用鏈（來自jaeger官網）▲

大李又打開了一張微服務網關的架構圖，指給老張看：「另一個就是微服務網關。我和團隊討論了，微服務化仍是要一步一步來。先把不重要的服務微服務化，一步一步演進，隨着咱們不斷學習，再把重要的模塊微服務化。這樣風險會比較小。因此咱們須要微服務網關來把微服務化的服務暴露給沒有微服務化的應用。例如咱們能夠先把通知服務微服務化，別的核心邏輯不變，能夠經過微服務網關來調用微服務化的通知服務。這樣咱們又須要維護微服務網關集羣了。」

▲Figure 5 – 微服務網關▲

「另外，咱們也須要配置中心集羣來進行配置管理。咱們還須要快速部署咱們的應用到虛擬機上。須要控制檯來進行應用部署、配置、以及服務治理如鑑權路由等管理。」大李繼續補充。

老張聽完大李的介紹後陷入沉思：「你說的這些很是對，看來微服務化仍是給咱們帶來了很大的挑戰。好比微服務網關確實咱們須要考慮慢慢演進架構，來保證服務的穩定性。全部這些都由咱們本身去培養團隊搞，短時間看來不太現實啊，更重要的是咱們更應該專一於咱們本身的服務而不是微服務的基礎設施。」

「那有沒有現成的微服務平臺呢？能替咱們解決這些問題，而咱們本身只專一於本身的業務呢？」大李問。

「這個問題很是好，我據說京東智聯雲推出了一個JDSF微服務平臺，你能夠研究研究。我大概看了一下，感受應該能知足咱們對微服務基礎架構的需求。」老張一邊建議，一邊打開了京東智聯雲的JDSF產品頁給大李看：

掃碼瞭解京東智聯雲 JDSF

大李眼前一亮：「好，我這就去研究一下。」

兩天後，大李興沖沖來到老張的辦公室：「張總，我仔細研究了京東智聯雲JDSF，這個平臺徹底能解決咱們目前對微服務基礎架構的要求。我總結了一下，主要有如下幾點：

• JDSF有註冊中心和配置中心/調用鏈分析/和微服務網關，所有由京東智聯雲來幫助咱們部署和進行後期維護，而且保證高可用。
• JDSF支持SpringCloud、Dubbo、JSF，咱們能夠選擇其中的任何一個，只須要把JDSF SDK集成進來就能夠。
• 咱們能夠上傳jar/war包，而後JDSF能夠幫助咱們部署在虛擬機上，而且支持滾動部署。
• 在微服務控制檯上，能夠輕鬆進行配置管理和服務治理的管理（如鑑權和路由）。就像這個路由圖展現的，咱們能夠進行灰度發佈。

▲Figure 6 – 路由▲

有了這套方案，這樣咱們就能夠輕鬆使用微服務架構來改造咱們的應用了。」

大李興奮地繼續介紹他的想法：「這樣咱們整個架構就會演進到這個最終架構，這裏麪灰色的部分都是京東智聯雲JDSF幫咱們作的事情。而咱們只須要關注本身的業務邏輯就能夠了。完成了這套架構，咱們就能快速發佈新功能，集中精力和D公司在市場上PK。」

▲Figure 7 – A公司最終架構圖▲

「太讚了！我從京東的朋友打聽到他們內部的協同辦公平臺也在用這套微服務平臺，京東但是有幾十萬員工在使用這套協同辦公軟件的。相信咱們也能很快集成完畢的。」老張當下拍板，安排大李當即開始同京東智聯雲一塊兒進行微服務改造。

你的公司是否也面臨着大李和老張同樣的問題？當一個很是複雜的應用須要快速快速響應市場，須要有動態擴容能力，而應用自己面臨不能快速發佈、難於維護等問題，進而不能適應需求時，就須要考慮微服務架構來解決問題。

但須要注意的是，微服務架構雖然能解決問題，但同時也帶來了架構層面的複雜性，而且須要微服務基礎設施的支持，因此也將爲企業架構帶來巨大的挑戰。

京東智聯雲JDSF微服務平臺正是爲了知足微服務化的簡單可行，而提供了基礎組件以及服務治理、應用管理等功能，能夠極大簡化企業微服務轉型而且規避架構轉化中的風險。若是你也對JDSF微服務平臺感興趣，不妨點擊_【閱讀原文】_來試用吧。