拆分對象簡介：
公司的一款工作計划管理SaaS軟件，2013年上線，單體架構。起初僅任務管理功能，發展到后來加上了賬號身份權限、Feed流、日周月報、項目管理、計划管理、OKR、消息中心、打賞、貼標簽、評價等等。常用租戶數量1W+
目前的問題：
1. 目前是3個團隊共同維護，經常一個團隊改點東西，需要三個團隊測試同時回歸測試，測試同學苦不堪言
2. 代碼量巨大，構建一次至少20分鍾，降低開發部署效率
3. 作為公司主站，經常因為業務特性升級而發版，造成生產環境不穩定，導致用戶投訴
拆分面臨的挑戰：
1. 穩定！穩定！穩定！這是公司門戶，而且ToB軟件客戶都是付了費的大佬，一旦主站不可訪問導致客戶投訴，直接就是P1問題，輕則考評降級，重則卷鋪蓋走人，不是開玩笑的
2. 由於代碼時間長，中間不知經歷了多少手，代碼內部調用混亂、設計各有特色。
3. 此產品中很多服務作為其他產品的基礎服務，拆分時要保證這些服務仍能正常運行，不能把其他產品搞掛了
4. 產品需要迭代進行，新特性不能停下來
5. 原來的數據存儲是基於SQLServer的，公司要求底層基礎服務統一遷移到ElasticSearch+Cassandra上
簡單說，你以為微服務化是這樣
其實是這樣：
過程大體經歷了如下階段：
1. 代碼規范化、接口隔離（持續了2個月）
即把原來單一結構中，跨領域調用的地方，全部用接口隔離開，使各領域業務代碼內聚
2. 代碼拆分，微服務化（持續了2個月）
在第一步的基礎上，把各領域代碼遷移出來，領域間調用由接口改為微服務。
這個過程中，我們使用了KONG網管進行接口路由。原因有兩點：
1. 由於各服務獨立成站點，各自擁有不同域名，導致前端或其他業務線需要把原來調老域名下接口的改為新域名。而前端、其他業務線資源很難協調，只能把老域名DNS解析到KONG上，然后再由KONG根據路由規則把請求轉到不同服務站點上；
2. 由於我們的URL上帶有租戶ID，因此可以利用KONG上的規則，進行灰度測試。把符合條件的租戶，轉到新站點上，大部分租戶仍然使用原服務，保持穩定。
3. 數據庫拆分（持續1個月）
切換DAO層、平移數據。
這一步要注意的是，使用ElasticSearch代替SQLServer查詢時，由於ElasticSearch自身緩存刷到硬盤需要1秒延遲，許多原本寫完立刻搜的場景需要規避，這是ES自身近實時特性決定的。最簡單的方法是Sleep1秒，也可以使用分布式緩存（Redis）做一層鏡像。
后記：
整個過程耗時接近半年，遷移過程中的壓力是巨大的，特別熬人，可以說是如履薄冰。但遷移完微服務后，各個小組聚焦在自身業務上，可以獨立上線，主站也穩定了，相互間調用支持熔斷限流，調用鏈監控也加上，慢接口一目了然，可以說皆大歡喜。