傳統應用系統架構的瓶頸

曾經為物業管理公司架構設計並領導開發過一個網際網路+物業增值服務平臺專案，剛接手這個系統的時候，這個平臺在最初的1.0版本採用的是比較標準的單體應用，Java、Tomcat、MySQL，功能服務也比較簡單，主要還是物業報修相關，不過在我接手後，客戶就開始了2.0的規劃，這就包括了物業繳費、物業通知、線上禮品兌換，因此我們延續這個架構完成了2.0版本的上線。

如下圖所示：從架構角度上看，兩臺Tomcat組成了兩套互為備份的APP伺服器，部署業務服務，形成服務冗餘的可靠性保障，Nginx伺服器作為均衡負載對兩臺APP伺服器實現輪詢訪問，也能提升請求效能，最終由APP服務讀寫MySQL資料庫。

2.0上線後系統一直表現穩定，不過已經出現了一些開發維護方面比較吃力的端倪，主要問題在於物業相關服務、支付相關服務、商品增值服務並不在一個領域，不同領域問題自然就會涉及更復雜的相關負責人協調，不同服務的更新發布節奏也不同，每次進行微量更新的時間點，都要向所有管理人員打招呼，有時候也會比較尷尬。

例如：我們近期接到了商業擴充部的需求，需要我們增加了一個積分活動，升級程式完成開發測試後，釋出過程需要暫停服務15-30分鐘，當我們通知到所有負責人後，這時候集團的物業管理公司的負責人就會問，我們最近沒有啥新需求啊，咋又讓我們給業主發通知呢？

不過還好，問題不算太大，PM用微笑能解決的，我們就不讓程式設計師加班熬夜想解決辦法了。

那麼問題就來了，若平臺再壓上更重的稻草咋辦？果然，系統應用磨合期剛過不久之後，客戶就提出了3.0升級計劃，其一：這次要將物業管理系統徹底推倒重來，與我們的網際網路物業增值平臺進行融合，其二：線上禮品兌換服務徹底升級為社群內線上零售系統，其三：支付系統對接銀行系統，代理銀行的金融增值產品。

從專案參與面的角度看，與平臺專案交涉的客戶方不僅物業管理公司人員全部納入到使用者範圍，而且又增加了銀行客戶、社群加盟商等。

作為架構師的我，遇到了極大的壓力，若專案在3.0的升級設計上，還是延續原來的系統架構接著開發，那麼這種錯綜複雜的關係就不可控了，這也是目前整個開發組的共識！

因此我必須開始嘗試新的方案，微服務架構自然而然地出現在了我的視線範圍，我亟待透過微服務架構的方式來解救日益臨近懸崖的專案。

微服務架構的切分方法

解決微服務架構問題的關鍵還是如何進行整體平臺的微服務化切分，形成大小適中，獨立性強的可執行服務，微服務的切分方法模式告訴我們可以透過：操作端切分法、領域模型切分法、業務主線切分法、使用者群體切分法、效能熱點切分法等方法模式進行平臺的微服務化劃分，不過實際運用上不是非黑即白，必須基於實用性，架構上應具有包容度。

例如：我們平臺運維過程中最關注的一項需求就是不同領域的業務負責人之間儘量不要因為系統升級維護相互影響，那麼我們就可以重點考慮基於領域模型和操作端(管理端)混合的方式來切分，第二關注點在於平臺架構受外部系統的影響儘量不要相互干擾，比如像支付系統、物業管理系統、物流平臺、銀行金融介面等，這些外部系統總是會與領域模型緊密結合。

基於上面兩點的強烈關注，另外也要從微服務的粒度不能過細去考慮，否則我們作為一個小型團隊，人手上不應一次性維護過多微服務，過多微服務又會導致更復雜的服務間互動所帶來的升級維護成本。

因此我們粗粒度的劃分為物業服務、支付金融、社群商業、平臺資源四塊微服務，那麼不同微服務會負責關係密切的外部系統。如下圖所示：

這種方式就完全讓不同微服務針對到了不同的業務責任人，物業管理公司、銀行、商業擴充部以及平臺內部運維管理。

這種微服務架構的升級變遷所帶來的技術支撐問題那就是資料庫的切分、業務閘道器的引入和容器技術的使用。

資料庫切分邏輯

首先是資料庫的切分問題，如下圖所示：

早期涉足微服務的架構師系統喜歡用單庫這種思路來進行劃分，這樣微服務化的效率最高，不過恰恰是這種設計會導致微服務運算元據表的責任邊界極為模糊。這就會逐漸形成一種危害——分散式環境的資料一致性要求。

例如：物業繳費呼叫支付模組，儘管跨越了兩個微服務，但是程式設計師為了圖省事，將所有支付返回的資料操作由物業繳費模組進行了資料庫的寫入，只不過通知支付金融微服務向銀行系統做同步，但是物業模組恰恰在完成資料寫入庫的過程中，支付系統出現了故障，此時平臺的資料庫已經寫入支付資料，但是無法通知支付金融微服務向銀行系統同步資料，這就是資料不一致了。

若微服務對於資料庫的操作，是完全從物理隔離上獨立劃分，那麼這個操作就一定是在支付模組上完成，必然能保證微服務故障前後的資料一致性。

另外一個重要因素就是任意服務對資料庫的訪問壓力都會導致整體服務的下降，反過來講，若資料庫保持獨立，任意微服務出現故障，至少部分服務仍能繼續維持，例如：物業報修並不會因為支付金融微服務崩潰而受到影響。

因此微服務應該越保持獨立性越好！

因此我們需要針對資料庫進行了劃分，這就形成了下圖中的微服務架構，我們可以看到基本上每個微服務都會對應屬於自己的資料庫。

這個資料層面的切分過程需要考慮兩點：

(1)遺留資料庫的遷移問題，一般有兩種思路，一種是進行平滑遷移不影響系統的正常使用，類似於空中加油，另一種是一次性研發完成後，離線ETL，並做公測，公測完成後再統一替換。

第一種非常麻煩，主要是針對7x24小時線上的高可用性平臺，例如：網際網路電商、公共事業服務、網際網路醫療系統等，一般也會用到大資料技術配合ETL來做。

不過我們還好，物業增值業務沒有那麼嚴苛的高可用性需求，我們選擇了第二種方式。

(2) 資料切分之後，必然涉及資料事務操作從原來的單庫事務轉變成了目前多庫的分散式事務，這塊主要還是用到了TCC(Try/Confirm/Cancel)進行多個微服務的TCC，如下圖所示：

我們在進行物業繳費過程中透過TCC框架對物業服務微服務和另外一個支付金融微服務的物業繳費模組、網際網路支付模組適配了Try-Confirm-Cancel的編碼規範，也就是進行了準備階段-提交階段的兩階段提交，這樣就能基本保證物業繳費資料和支付資料的分散式一致性。

後續

前面提到過對於微服務的架構除了資料庫的切分遷移之外，另外有兩個部分：其一就是業務閘道器在微服務中起到的作用，其二就是容器技術，為什麼容器技術在微服務中非常重要，就是因為容器對伺服器資源進行了合理的隔離，形成了容器間相互獨立的程式服務，這就極大促進了微服務的部署效果。這兩部分的內容我再抽時間聊聊我在專案中的實戰經驗。