大型線上系統遷移爲分佈式系統案例

背景

我所在的部門其中重要的一項工做就是對接社區項目新的業務需求，社區項目已經維護N多年了。到14年初的時候社區的解決方案中已經有一百多個工程，每打開或編譯一次解決方案都須要等很長的時間。當時就出現這樣的狀況，幾乎沒有項目經理可以面面俱到的理清楚社區解決方案的全部代碼。同時，在現有社區上作簡單修改也是一件很麻煩的事情，並且每次升級社區都會很危險，整個社區項目正在走向腐朽。在這樣的狀況下，部門總監決定對現有社區項目遷移爲分佈式系統。

爲何是分佈式系統

社區之因此代碼量大是由於業務邏輯多、雜而且多種業務之間的代碼相互引用，因此明確業務主線、分拆業務主線、下降業務主線之間的耦合度成了首要的任務。分佈式系統恰巧能很好的爲分拆業務主線，協調業務系統交互提供友好的指導。

最終社區分拆爲遊戲、計費、安全、推廣、帳號五大業務系統。每一個系統提供UI功能站點（UI功能站點的特色是提供可供用戶使用的功能界面，而且包含業務邏輯實現），同時爲了便於其餘業務系統使用其業務邏輯，每一個系統還須要提供業務服務站點。服務站點分爲兩類，一類是可調用其餘服務站點的interface站點，還有一種是不可調用其餘業務系統的module站點，這樣作的主要目的是爲了使接口站點、頁面站點的調用關係清晰，便於之後的開發和維護。

遷移中可預見的問題

因爲社區是線上系統，因此大的改動會帶來發生線上故障的風險。同時在遷移過程當中產品部門會不斷的提出新的需求，產品的需求的優先級很是高，換句話說咱們一邊要作遷移的工做一邊還要對接新需求。最重要的是部分代碼的代碼結構會變，簡單的代碼合不可以解決問題，某個時間段內須要對接兩份代碼。固然我並非在叫苦，我只是想說整個遷移的過程會很痛苦。

遷移過程

第一階段

這一階段的主要任務是分拆代碼，將每一個子系統原有的代碼移到新的解決方案中，若是須要調用其餘子系統的代碼則跨解決方案引用老的工程。這一階段特色是不對對現有的代碼作太多的改動，只是簡單的把以前的代碼移到新的工程裏並改動類的命名空間，在這一過程當中若是有新的需求須要對接兩份代碼。這一階段開發完成後，須要QA人員測一遍全部業務流程並將新代碼編譯的組件上傳到生產環境。

第二階段

 這一階段的主要目標就是由引用老的工程改成調用其餘業務系統提供的接口併爲其餘系統提供接口。首先，以業務系統爲單位，找到全部引用其餘業務系統的代碼，並整理成文檔。緊接着就是在會上相應子系統的項目經理記錄都有哪些系統用到本身負責的系統，並記錄調用本身功能的業務流程，還須要消化並剔除重複的需本身提供的接口。接下來的工做就是提供接口了，各個系統的開發人員開發相應系統的接口。這一階段開發完成後，須要QA人員測一遍全部業務流程並將新的代碼上傳到生產環境。

爲了便於其餘系統的接入，每一個接口站點須要提供一個SDK，SDK的主要工做就是爲調用網絡接口和將返回值映射爲.NET對象，這樣一個子系統想使用其餘系統的功能就很是方便，這也是社區爲SOA中高互操做性作的努力。

這樣保持業務的事物性

當各系統的QA人員測試完個接口的功能和壓力以後，各系統供用戶使用的UI站點就須要移出對老工程的引用，改成調用相應的接口了，這時候咱們碰到一個問題，就是現有的系統不可以支持事物，原本想引入WS-*，可是WS-*效率實在過低了點，結合咱們當前實際狀況，咱們引入了重試以保證每次業務流程都必定能完成，即若是調用相應的業務系統，調用不成功或者業務系統返回的失敗，重試服務就會在兩天以內調用16次相應的接口以保證確保通知到了該系統。

爲何要分爲兩個階段

可能有人會問，爲何非要分爲兩個階段呢，而且每一個階段都須要上生產環境，幹嗎不直接改完以後上傳到生產環境。其實這樣作的目的是爲了平攤風險，將風險平攤到每一個階段。這裏的平攤風險並非上到生產環境就沒風險了，分兩個階段遷移，每一階段的故障要低於無階段遷移，避免因線上問題過多而致使必須回滾生產環境版本的狀況發生。

末尾

社區遷移完成以後，研發的並行度提升了，每一個系統能夠單獨進行伸縮。從項目經理的角度來看，負責的業務流程和項目清晰明確。從開發人員的角度來看，所面對的項目不復雜。因此說不論是從項目上講仍是從管理上都達到了鬆耦合目的。