要想下班早，微服務架構少不了

網上流傳著很多關于程序員和產品經理的段子，比如有程序員為了應對產品經理的需求變更，連續通宵加班改代碼，都累暈過去了，怎么都叫不醒，最后產品經理喊了一句：“小程，我這里有兩個需求還要再改改，你看看怎么改？”程序員嘭的一下就彈起來了，說：“你還有什么要求，我還可以，我還能改，下班前就能改完。”

這些雖然是段子，但是在現實生活中，需求也是隨著用戶的使用不斷變更的，程序員經常要面對各種各樣的需求變更，那么，怎么讓我們更快的適應這些需求變更，更快的迭代交互版本呢？非常火熱的微服務和微服務架構，又能給我們的軟件開發帶來什么好處和方便呢？不著急，后面慢慢道來。

舉個例子，最開始，張三和李四看到最近微商很火，他們也想開發一個微信小程序做微商，線上賣貨，把家鄉的特產賣出去，最開始需求就很簡單，有一個微信小程序，用戶可以在小程序上瀏覽和選購商品就可以，在后臺，需要管理商品、用戶和訂單數據。張三作為程序員梳理了一下，主要有如下功能點：

小程序前端：

用戶注冊、登錄

商品展示

下單購買

后臺：

用戶管理

商品管理

訂單管理

整個功能簡單明了，張三作為資深程序員，很快就完成了代碼的開發，在部署時，出于安全考慮，小明還將前端和后臺做了分離部署，很快，小明從華為云上購買了ECS和RDS服務，將開發的應用部署上去，對接好微信小程序平臺，小程序就上線了，整體架構如下圖：

圖1 最開始的整體架構圖

小程序上線以后，由于家鄉的特產原生態、質量好、風味佳，大受歡迎，顧客們好評如潮，張三和李四開始躺著數錢，做夢都笑不醒。可是好景不長，看到他們做的這么紅火，其它人也開始抄襲并快速上線，極大的影響了張三他們的收入，在殘酷的競爭壓力下，張三和李四決定做一些營銷活動，來發展和留住客戶，增加收入。營銷活動主要有如下的內容：

拓展商品品類：以商城的形式銷售其它廠家的商品

拓展渠道：新增網頁版入口和單獨的APP入口，即上線網頁版、上線獨立APP等；

促銷活動：比如滿減、打折、充值優惠、會員優惠、會員積分兌換等

精準營銷：購買一些三方數據，根據用戶畫像進行推送等等。

這些擴展的需求都需要開發程序來支持，張三這個時候就忙不過來了，因此他們新招了一個程序員王五，來一起開發，這次進行了分工，王五主要負責數據分析、會員業務及APP和網頁版的開發，張三負責促銷活動相關功能的開發。由于要快速上線，張三和王五頭腦風暴了一把以后，大致對系統做了一下劃分，主要把促銷管理、數據分析、會員管理、對接第三方廠家數據等放到后臺里，網頁和移動端APP另外搭建，忙活了一個多星期，張三和王五完成了基本功能的開發，當前的整體架構如下：

圖2 增加促銷和單獨入口后的架構圖

這一階段存在很多不合理的地方：

小程序、APP和網站3個前端分別開發，有較多的重復開發工作。

所有數據都存在一個數據庫中，促銷時訂單數據等的訪問影響會員管理等數據訪問的性能，出現過促銷時用戶無法充會員的情況，流失收入

數據共享有時是通過數據庫共享的，有些又通過應用間的接口來提供，應用間相互耦合，依賴關系混亂。

單個應用上不停的擴充功能，應用功能越來越多，代碼也越來越多，維護和開發都越來越復雜，且應用上線周期變長，上線后如有問題影響變大。

后臺之間相互影響，用戶管理影響會員管理，訂單管理也會影響用戶和會員管理，后臺邏輯混亂，維護坤看。

數據庫表結構被多個應用依賴，無法重構和優化。

數據分析使用數據庫存儲數據來實現，且與實時業務庫在同一個庫，數據分析消耗大量的數據庫性能，影響業務訪問數據庫的性能，頁面出現卡頓等。

生產環境的維護變得困難，生產環境的升級變更變得困難，由于不解耦，修改功能后需要前端和后臺同時上線，變更時會影響用戶使用，需要停服變更等，這樣變更時間就只能放到凌晨，開發和運維都很累。

在后臺中的公共功能開發，出現程序員之間相互推諉的情況，每個人都覺得公共功能應該有對方開發，自己只做自己負責的業務開發，要不就是都單獨開發，代碼冗余越來越多。

雖然存在著很多問題，但也不能否認這一階段的成果：程序員們快速的完成了系統的開發，并適應業務的變化，完成了新的業務開發，不過因為都是快速開發上線，開發過程中都容易只著眼于快速實現業務功能，容易陷入局部、短淺的思維方式，針對功能妥協，缺乏全局的、長遠的設計，也缺乏對擴展性、性能等的設計和考慮，長此以往，系統建設將會越來越困難，甚至陷入不斷推翻、重建的循環。

張三和王五都是有追求的程序員，他們對現狀不滿，當線上運行稍微穩定以后，他們去學習了業界流行的微服務架構，并系統的開始對商城進行梳理，開始梳理系統的整體架構并進行微服務改造，他們開始對系統進行抽象，他們重新梳理了商城的業務邏輯，抽象出公共的能力，做成公共的微服務，主要如下：

用戶服務

會員服務

商品服務

訂單服務

促銷服務

數據分析服務

抽象完成后，各個應用服務只需要從公共服務獲取所需的數據，刪除了大量的冗余代碼。然后針對之前數據庫性能瓶頸問題和數據管理混亂和數據庫表結構復雜的問題，張三他們分析，如果繼續保持共用數據庫，則整個架構會持續的僵化，失去了微服務設計的意義，因此他們一鼓作氣，將數據庫也進行了拆分，并引入了消息隊列實現系統的解耦和通信的實時性，引入數據倉庫來進行數據分析，梳理完后的整體架構如下：

圖3 微服務改造和數據庫分離后的架構圖

如上圖，完全拆分后各個服務可以采用異構的技術，每個服務可以使用獨立的技術棧單獨開發，每個服務都可以單獨的部署上線。比如數據分析服務可以使用華為云數據倉庫作為持久化層，以便于高效地做一些統計計算；商品服務和會員服務訪問頻率比較大，因此使用華為云DCS來作為緩存，加入了緩存機制等。微服務之間使用了華為云的DMS來進行消息通信，提升了消息通信的速度同時服務間實現了更好的解耦。微服務架構要求服務都單獨的使用數據庫，優點是明顯的，服務間完全隔離，但數據庫拆分也有一些問題和挑戰：比如說跨庫級聯的需求，通過服務查詢數據顆粒度的粗細問題等。但是這些問題可以通過合理的設計來解決。總體來說，數據庫拆分是一個利大于弊的。

微服務架構還有一個技術外的好處，它使整個系統的分工更加明確，責任更加清晰，每個人專心負責為其他人提供更好的服務。在單體應用的時代，公共的業務功能經常沒有明確的歸屬。最后要么各做各的，每個人都重新實現了一遍；要么是隨機一個人（一般是能力比較強或者比較熱心的人）做到他負責的應用里面。在后者的情況下，這個人在負責自己應用之外，還要額外負責給別人提供這些公共的功能——而這個功能本來是無人負責的，僅僅因為他能力較強/比較熱心，就莫名地背鍋（這種情況還被美其名曰能者多勞）。結果最后大家都不愿意提供公共的功能。長此以往，團隊里的人漸漸變得各自為政，不再關心全局的架構設計。

從這個角度上看，使用微服務架構同時也需要組織結構做相應的調整。所以說做微服務改造需要管理者的支持。改造完成后，張三和王五分清楚各自的鍋。兩人十分滿意，對系統和當前的開發模式都很滿意。

但是，微服務架構調整完以后，就沒有其他問題了嗎？未完待續……

附：華為云現在提供微服務專家服務，為云為客戶提供專屬微服務咨詢服務，以“適用性評估，目標制定，差距分析，試點實施，效果評估，經驗固化”全面指導為設計思路，協助客戶高效、低成本的完成微服務規范、工具、平臺和流程等整套體系建設，提升業務創新效率。

【參考資料】

華為云微服務專家服務

微服務架構-https://insights.thoughtworks.cn/microservices-martin-fowler/

Wiki百科微服務：https://zh.wikipedia.org/wiki/%E5%BE%AE%E6%9C%8D%E5%8B%99

自動化測試 軟件開發

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。