【正文】 改善，但另一些時(shí)候只是在浪費(fèi)資源。通常，下注越大，越難以回頭。這又是一個(gè)逐步遷移的好處。 開(kāi)啟新的方式 在遷移的時(shí)候，有多種選項(xiàng)和路徑。對(duì)每一種方式而言，都不會(huì)完全平滑，因此可能會(huì)在使用一個(gè)方式后發(fā)現(xiàn)這種方式并不是最好的，然后更換另一個(gè)方式實(shí)現(xiàn)。建議嘗試將這種變化融入到 文化之中，采用這種不斷進(jìn)取的文化，敢于嘗試新的東西，那么在需要更改方向的時(shí)候會(huì)變得更加自然。 總結(jié) 這一章介紹了為什么需要使用微服務(wù)架構(gòu)，以及哪些因素可以用來(lái)對(duì)實(shí)現(xiàn)順序進(jìn)行排序。當(dāng)企業(yè)在決策是否需要向微服務(wù)遷移時(shí)，需要回答三個(gè)問(wèn)題： 希望從微服務(wù)中獲得什么 ? 是否考慮過(guò)微服務(wù)之外的其它替代方案 ? 怎么衡量遷移起到了成效 ? 遷移過(guò)程可能會(huì)花費(fèi)很長(zhǎng)的時(shí)間，但實(shí)際工作中，客戶不會(huì)給我們這么多的時(shí)間。遷移只有在發(fā)布到生產(chǎn)環(huán)境后才能表示一個(gè)階段的結(jié)束。這就需要一系列的技術(shù)手段來(lái)讓微服務(wù)應(yīng)用和單體應(yīng)用協(xié)同工作。接下來(lái)的內(nèi)容就會(huì)對(duì)這些技術(shù)進(jìn)行介紹。 第三篇：技改之路：從單塊應(yīng)用到微服務(wù) ,我的血淚總結(jié) 技改之路：從單塊應(yīng)用到微服務(wù)，我的血淚總結(jié) 20210523 張輝清技改是技術(shù)改造的簡(jiǎn)稱，是技術(shù)的蛻變。本文指的是在公司技術(shù)發(fā)展的某個(gè)瓶頸階段，按原有開(kāi)發(fā)和組織方式已經(jīng)無(wú)法玩下去，這時(shí)公司希望引進(jìn)架構(gòu)師或技術(shù) 牛人，來(lái)破解當(dāng)前困局。技術(shù)改造，對(duì)于公司和技術(shù)人員而言都非常難得，參與者多，主導(dǎo)者少。我有幸前后主導(dǎo)過(guò) 3 次 OTA 系統(tǒng)的技改，規(guī)模有大有小，每次環(huán)境和問(wèn)題雖不一樣，但還是有套路可循。《技改之路》少講技術(shù)多講路，我們不過(guò)多的關(guān)注技術(shù)細(xì)節(jié)和中間件的實(shí)現(xiàn)，而重點(diǎn)講述技術(shù)改造的過(guò)程和思考，以下是本次分享的 Topic：系統(tǒng)背景前期工作技改實(shí)施總結(jié) 技術(shù)規(guī)模公司 B2B 機(jī)票分銷平臺(tái)資本原始積累，財(cái)務(wù)良好，一直 200+ 100+庫(kù)， 1萬(wàn) +表研發(fā)規(guī)模 200人左右服務(wù)器有 200臺(tái)左右 此案例是一個(gè)中等規(guī)模的電子商務(wù)公司，老板白手起家，資本原始積累，現(xiàn)在賺錢的互聯(lián)網(wǎng)公司很少哦。公司從 2021 年的幾個(gè)研發(fā)人員，到技改前的 200 個(gè)左右研發(fā)人員，業(yè)務(wù)發(fā)展良好，是國(guó)內(nèi)領(lǐng)先的B2B 機(jī)票分銷平臺(tái)，互聯(lián)網(wǎng)名聲雖不大，但處于悶聲發(fā)大財(cái)?shù)臓顟B(tài)。 公司之前嘗試過(guò) 2 次系統(tǒng)重建，請(qǐng)了一批批的牛人，前后經(jīng)歷過(guò)4 年。公司消耗大，但都以失敗告終。此案例是我本人的第 2 次技改，效果不錯(cuò)，整體進(jìn)展順利，團(tuán)隊(duì)技術(shù)水平也有 1~2 個(gè)檔次的提升，算是比較成功的實(shí)踐。另外，因?yàn)榘咐^(guò)于真實(shí)，有些 UML 會(huì)打上馬賽克，請(qǐng)多諒解。 單塊應(yīng)用 3 不合理，主平臺(tái)體量太大，其它又過(guò)??； 技術(shù)過(guò)舊：使用 7 年以前的技術(shù)，主平臺(tái)采用單塊應(yīng)用，且體量共存：版本混亂，只敢添加，不敢修改；整個(gè)系統(tǒng)非常脆弱，問(wèn)題多，訪問(wèn)量一大就掛； 管理問(wèn)題：發(fā)布困難、測(cè)試?yán)щy、修改困難、排錯(cuò)困難。 架構(gòu)部組建成立架構(gòu)部： 內(nèi)招幾名老程序員，外招幾個(gè)架構(gòu)師培養(yǎng)： 內(nèi)部走出去，提高眼界；外部牛人請(qǐng)進(jìn)來(lái)，落地了解歷史和業(yè)務(wù)制度： 項(xiàng)目管理 +知識(shí)分享： JIRA+WIKI團(tuán)隊(duì)建設(shè)、技術(shù)分享、工程師文化 總體規(guī)劃 架構(gòu)是演化出來(lái)的還是設(shè)計(jì)出來(lái)的？對(duì)于創(chuàng)業(yè)場(chǎng)景，創(chuàng)業(yè)本身就是在未知中尋找機(jī)會(huì)，將不清楚變?yōu)榍宄到y(tǒng)的架構(gòu)自然是演化出來(lái)的，而對(duì)于技術(shù)改造或 Google 搜索等復(fù)雜工程場(chǎng)景，系統(tǒng)的架構(gòu)當(dāng) 1 個(gè)多月的時(shí)間，對(duì)項(xiàng)目做了總體的規(guī)劃，然后對(duì)內(nèi)宣講推廣，讓每一個(gè)參與者了解自已的目標(biāo)和價(jià)值。不手握地圖，你怎知站對(duì)了位置！ 、中間件構(gòu)建我們構(gòu)建的中間件有： job/redis/centerLog/業(yè)務(wù)監(jiān)控 metrics/dashboad/調(diào)試工具windbg/rabbitMQ/ORM 工具 dapper/MongoDB/jetermclient/公共類庫(kù)jFX/zookeeper/openTSDB/HBase/searcher 工具 solr/元數(shù)據(jù)管理DDM/DLL 管理 nuget/自動(dòng)發(fā)布 Jenkins/微服務(wù)架構(gòu) JSOA/中間件是應(yīng)用系統(tǒng)的基礎(chǔ)設(shè)施，是應(yīng)用的裝備和工具。農(nóng)村建住房是一塊磚一塊磚的往上壘，城市建大 house 則是先打地基，然后再建主框架，最后才是壘磚，所以中間件的建設(shè)是大中型系統(tǒng)建設(shè)的前提。 以上中件間的 構(gòu)建過(guò)程貫穿于整個(gè)技改的生命周期，每一個(gè)中間件可能需要花 1~2 個(gè)月，它們大部分都基于開(kāi)源。請(qǐng)關(guān)注上面的順序，直面當(dāng)前的問(wèn)題，按需快速構(gòu)建和推動(dòng)。雖然使用開(kāi)源，但中件間的引進(jìn)和改造有自已的一套流程：調(diào)查 =試用 =選型 =深入研究=demo=wiki=分享推廣 =業(yè)務(wù)系統(tǒng)試用 =改進(jìn)完善 =大規(guī)模推廣。 中間件的構(gòu)建和增加，不僅對(duì)當(dāng)前業(yè)務(wù)系統(tǒng)影響較小，還可以解決一部分業(yè)務(wù)難題，減輕數(shù)據(jù)庫(kù)的壓力。同時(shí)它還有利于建立技術(shù)氛圍和分享機(jī)制。一支有激情、愛(ài)技術(shù)的研發(fā)團(tuán)隊(duì)，對(duì)技改的具體實(shí)施是非常重要的。 三、技改實(shí)施 數(shù)據(jù)庫(kù)改造 當(dāng)面對(duì) 100個(gè)多庫(kù)時(shí)，我認(rèn)為系統(tǒng)架構(gòu)師關(guān)注到數(shù)據(jù)庫(kù)級(jí)別即可，建庫(kù)拆庫(kù)。數(shù)據(jù)庫(kù)按模塊整體遷移，其實(shí)并沒(méi)有想象中那么難，理想情況下只需修改數(shù)據(jù)庫(kù)的鏈接，而對(duì)于表和字段的優(yōu)化，可由應(yīng)用架構(gòu)師或技術(shù)主管，以 SOA 收口或應(yīng)用重構(gòu)來(lái)實(shí)現(xiàn)。 數(shù)據(jù)庫(kù)如何做到可伸縮，可大可小方便拆分呢，思考如下： ，一個(gè)框即可以是一個(gè)庫(kù)，也可以是一個(gè)模塊，還可以是一個(gè)表，根據(jù)當(dāng)前業(yè)務(wù)規(guī)模和系統(tǒng)復(fù)雜度來(lái)實(shí)現(xiàn)； ：產(chǎn)品、用戶 、訂單、結(jié)算、基礎(chǔ)設(shè)施。它們?cè)缙诳梢允且粋€(gè)庫(kù)，里面有 5 個(gè)模塊，中期可以分為 5 個(gè)庫(kù)，后期則可以更底級(jí)別分為更多的庫(kù)； ：數(shù)據(jù)庫(kù)名：業(yè)務(wù)線縮寫(xiě) +庫(kù)名；模塊名：參考大 ER圖 +專業(yè)詞匯縮寫(xiě)；表名：模塊縮寫(xiě) +表名；自增編號(hào)：表名 +ID； 塊內(nèi)可多表聯(lián)接，模塊間減少聯(lián)接，數(shù)據(jù)庫(kù)間不允許聯(lián)接； Owner 組，原則上只允許一個(gè)團(tuán)隊(duì)才能 Create，其它團(tuán)隊(duì)訪問(wèn)需要分級(jí)控制， L1 為接口， L2 為只讀庫(kù)，L3 為直接讀寫(xiě)“寫(xiě)庫(kù)”。數(shù)據(jù)庫(kù)規(guī)劃 數(shù)據(jù)庫(kù)是整個(gè)信息系統(tǒng) 中生命周期最長(zhǎng)、最難修改的部分。所以讓時(shí)間來(lái)解決時(shí)間的問(wèn)題，要加強(qiáng)設(shè)計(jì)，具體實(shí)施過(guò)程如下： ，我們就新建立了一批庫(kù)，這在早期還遭到 DBA的抱怨； ，新表按新規(guī)則創(chuàng)建，特殊情況走特珠審批； 3.去 SP 去關(guān)聯(lián)，讓數(shù)據(jù)庫(kù)減少計(jì)算，回歸存儲(chǔ)本質(zhì)； ，改表改字段，采用模塊整體遷移或應(yīng)用重構(gòu)； ，再去看數(shù)據(jù)庫(kù)，發(fā)現(xiàn)在沒(méi)有特別立項(xiàng)和驅(qū)動(dòng)的情況下，已接近一半的表在新庫(kù)中。數(shù)據(jù)變遷 狀態(tài)圖是數(shù)據(jù)的變遷，是數(shù)據(jù)與行為的互動(dòng)，數(shù)據(jù)的 變化會(huì)引起行為的變化，行為的變化會(huì)產(chǎn)生數(shù)據(jù)的不同。上圖是國(guó)內(nèi)的訂單狀態(tài)變遷圖，它的價(jià)值不僅屬于數(shù)據(jù)庫(kù)層，還在于 SOA 服務(wù)化和核心業(yè)務(wù)流程。 服務(wù)改造 服務(wù)是動(dòng)詞，是行為或活動(dòng)的抽象，它的價(jià)值在于業(yè)務(wù)邏輯或行為的重用，具體實(shí)施過(guò)程如下： ，在設(shè)計(jì)階段使用 Excel 表格； Request/Response 規(guī)范； ，因沒(méi)有直接可見(jiàn)的業(yè)務(wù)價(jià)值輸出，最好以工單或項(xiàng)目來(lái)落地； ，早期沒(méi)有工具時(shí)，使用WIKI 做簡(jiǎn)單管理，后期使用專業(yè)的服務(wù)治理工具 。領(lǐng)域模型 沒(méi)有領(lǐng)域圖的架構(gòu)設(shè)計(jì)都是耍流氓，我們畫(huà)領(lǐng)域圖的架構(gòu)師是 2位老員工，沒(méi)有多少高大上，甚至于他們之前沒(méi)有畫(huà)過(guò) UML，但我們的狀態(tài)圖和領(lǐng)域模型都是出自他們之手。其實(shí)畫(huà)領(lǐng)域圖的關(guān)鍵是懂事物本身，并知道它們的關(guān)系。我們的領(lǐng)域圖與業(yè)務(wù)模型中的 5 大業(yè)務(wù)流程一一對(duì)應(yīng)，包括：預(yù)訂流程，訂單處理流程，產(chǎn)品供應(yīng)流程，財(cái)務(wù)結(jié)算流程，賬戶管理流程。微服務(wù) 我們的微服務(wù) 是基于 ServiceStack 當(dāng)時(shí)最新的版本號(hào) 實(shí)現(xiàn)的，它本身支持輕量級(jí)協(xié)議和 Metadata，以及 Swagger，是微服務(wù)的一種架構(gòu)實(shí)現(xiàn)。另外，它還可以再擴(kuò)展以 APIGateway的方式實(shí)現(xiàn) OpenAPI。 微服務(wù) MSA與我們之前的 SOA、 ESB 有什么區(qū)別呢？ ESB有總線和聰明的管道管理能力； SOA 弱化了中間的管道和總線，強(qiáng)化了兩端； 微服務(wù) MSA使用通用的輕量級(jí)協(xié)議和更加 web 化（ RESTFUL 應(yīng)用架構(gòu)改造 系統(tǒng)是什么？系統(tǒng) =元素 +關(guān)系。應(yīng)用架構(gòu)是什么？應(yīng)用架構(gòu) =應(yīng)用+架構(gòu)。應(yīng)用就是系統(tǒng)的最小單元，應(yīng)用分級(jí)和應(yīng)用編號(hào)則構(gòu)成了應(yīng)用關(guān)系即應(yīng)用的架構(gòu)，它有利于應(yīng)用的管理、交互和追蹤。應(yīng)用分為產(chǎn)品線，子系統(tǒng)和應(yīng)用 3 級(jí)，每一級(jí)編號(hào)為 2 位，如 100206。應(yīng)用要從用戶的視角出發(fā)，先有用戶，然后有應(yīng)用功能，這樣才是以用戶為中心去構(gòu)建系統(tǒng)。 組織架構(gòu)微調(diào) 組織架構(gòu)沒(méi)有最佳實(shí)踐，只有適合于自已當(dāng)前的選擇，以下是組織架構(gòu)與技術(shù)架構(gòu)對(duì)齊方面的思考： ： UED； 2.軟件開(kāi)發(fā)與硬件相分離： 運(yùn)維； ：架構(gòu)部； ，實(shí)施，驗(yàn)收相分離：每業(yè)務(wù)線分產(chǎn)品組、開(kāi)發(fā)組、測(cè)試組； ：預(yù)訂組、產(chǎn)品組、訂單組； ：測(cè)試、產(chǎn)品、開(kāi)發(fā)、輪流主持，設(shè)委員長(zhǎng)； 四、總結(jié) 過(guò)程總結(jié) 第一步總體規(guī)劃：手握地圖，明確路線；第二步數(shù)據(jù)庫(kù)：建庫(kù)拆庫(kù)，去 join去 SP；第三步中間件：按需構(gòu)建，先增加常用；第四步服務(wù)：技改 =工單，有業(yè)務(wù)價(jià)值輸出；第五步應(yīng)用：拆應(yīng)用，建門戶 Portal，重構(gòu)應(yīng)用； 第六步組織架 構(gòu)微調(diào)：組架技術(shù)與組織架構(gòu)對(duì)齊，技改之后調(diào)整；第七步固化：框架化，自動(dòng)化，管理過(guò)程工具化如 DevOps。 經(jīng)驗(yàn)感悟 于高級(jí)階段，方便行為的重用，是深層次優(yōu)化，但太慢了； 從當(dāng)前問(wèn)題或故障入手，要先滅火，逆向分析 dump 工具很重要；歷史要尊重，早期不可做大的改動(dòng)，不能過(guò)多地影響現(xiàn)有業(yè)務(wù)。建議只做加法，建新庫(kù)和新中間件，這樣就不會(huì)有太多阻力和負(fù)擔(dān)； 一般不能全部重建，除非系統(tǒng)較小，系統(tǒng)規(guī)模大時(shí)只能拆分后分步重構(gòu)；技術(shù)并不 是技改過(guò)程中最復(fù)雜的，人和事及關(guān)系才是麻煩的部分，歷史問(wèn)題的后面是人； 每次環(huán)境和問(wèn)題都不一樣，要有準(zhǔn)備脫一層皮的心態(tài)。 通盤無(wú)妙招 技改是大折騰，于公司于個(gè)人而言都是，小改怡情，大改傷身，我們應(yīng)該避免大的技術(shù)改造，但此現(xiàn)象又比較常見(jiàn)，特別是業(yè)務(wù)發(fā)展 發(fā)生，基于自然的演化來(lái)實(shí)現(xiàn)技術(shù)的演進(jìn)。 怎樣才能通盤無(wú)妙招，系統(tǒng)良性長(zhǎng)久的發(fā)展？我們需要兩個(gè)力量，一個(gè)是技術(shù) ，一個(gè)是業(yè)務(wù)，如果只重視業(yè)務(wù)，而很容易在技術(shù)上積勞成疾，如果完全技術(shù)驅(qū)動(dòng)，則又容易忘記業(yè)務(wù)目標(biāo)。所以它們應(yīng)該相伴相生，共同發(fā)展，在大的技術(shù)改造實(shí)施之后，在框架和流程相對(duì)固化后，小的技術(shù)重構(gòu)項(xiàng)目應(yīng)該長(zhǎng)期存在，這樣才能良性循環(huán)，讓系統(tǒng)進(jìn)入自然演進(jìn)的狀態(tài)。 互動(dòng)問(wèn)答 問(wèn)題：請(qǐng)問(wèn)張老師如果再來(lái)一次技改你會(huì)怎么做？在你做過(guò)的技改過(guò)程中你覺(jué)得你最大的收獲是什么？覺(jué)得做的不好的又是什么？ 這個(gè)問(wèn)題非常好，為了更好回答您的問(wèn)題，我簡(jiǎn)單介紹一下本人的 3 次技改經(jīng)歷。我的第 1 次技改是重建，項(xiàng)目從 10 月份到第二年 8月，歷史 10 個(gè)月，可以說(shuō)是技術(shù)成功項(xiàng)目失敗。第 2 次技改是重構(gòu)，只管技術(shù)，少管人和業(yè)務(wù)，整體效果好，可以歸結(jié)為成功。第 3 次技改還是重構(gòu)，既管技術(shù)又管人，且業(yè)務(wù)處于高速發(fā)展期，資源少，可以總結(jié)為技術(shù)與業(yè)務(wù)相伴相生，技術(shù)效果一般。 如果以后還有機(jī)會(huì)，自已就不再直接負(fù)責(zé)了，實(shí)在是太累，從內(nèi)外各招幾個(gè)架構(gòu)師，并按上面的工作流程和方式，然后把握好技術(shù)與業(yè)務(wù)的關(guān)系和資源占用即可。回到具體問(wèn) 題： 如果再來(lái)一次，我會(huì)多參考第 2 次技改經(jīng)驗(yàn)，即 PPT 分享的過(guò)程不好的地方：要更多的關(guān)注業(yè)務(wù)，以及平衡好業(yè)務(wù)與技術(shù)的關(guān)系。問(wèn)題：?jiǎn)螇K應(yīng)用向微服務(wù)遷移時(shí)，平滑過(guò)渡有什么技巧？如何解決分布式事務(wù)一致性呢？還有關(guān)于微服務(wù)持續(xù)交付、測(cè)試、監(jiān)控（語(yǔ)義監(jiān)控）方面有落地工具嗎？ ：直面當(dāng)前系統(tǒng)的問(wèn)題，不斷有價(jià)值輸出，然后參考上面的過(guò)程總結(jié)，先規(guī)劃，然后中間件和數(shù)據(jù)庫(kù)，最后是服務(wù)和應(yīng)用； ：使用替代方案，如最終一 致； 工具： MSA與 SOA的治理沒(méi)有本質(zhì)差別，還是 DevOps/Trace/Metrics/，我們使用的是 ServiceStack/JMetrics/CenterLog/Jenkins/。 問(wèn)題：如果舊有模塊關(guān)聯(lián)復(fù)雜，又影響現(xiàn)有系統(tǒng)性能，相關(guān)開(kāi)發(fā)人員流失，不好梳理，改造有風(fēng)險(xiǎn)，重寫(xiě)老板不答應(yīng)，該如何取舍呢 ? 障 ,逆向分析 dump工具； 相關(guān)開(kāi)發(fā)人員流失：引進(jìn)中件間，建立分享機(jī)制和學(xué)習(xí)型團(tuán)隊(duì)，講技改總體規(guī)劃，讓每個(gè)人了解自已 的價(jià)值和目標(biāo)； 不好梳理，改造有風(fēng)險(xiǎn)：內(nèi)招幾個(gè)老員工成為應(yīng)用架構(gòu)師； 重寫(xiě)老板