在我最初接觸微服務的很長一段時間裡，有兩類問題都困擾著我和團隊，這是讓我印象最深的兩類問題：
- 沒有配合微服務理念的團隊
- 沒有配合微服務理念的基礎設施
後來，在和一些搞了微服務的同行多次交流後，發現他們當初也面臨和我類似的問題。
這次就寫寫我最早搞微服務遇到的問題。
有些問題放到現在來說，已經有解決辦法了，已經算不上問題了。但是無論怎樣，這些問題如果能提前意識到，早做準備，會為將來搞微服務的同仁們省下許多的力氣。
所以，這篇文章我會著重談下這兩類問題。
一、沒有配合微服務理念的團隊
當年，我還是一個小開發團隊的組長，組裡將近 10 個程式設計師，維護著一個龐大的單體系統。
那時微服務剛出來不久，各種評估後，我們認為把系統拆分成微服務可以帶來更大的好處。
但是，對於微服務中提到的團隊自治這點，由於當時的職位和經驗限制，也無法貫徹這一理念，結果，最後就是把自己折騰了底兒掉。
在談團隊自治的問題之前，我先說說拆分微服務的時候，我們當時的整體交付流程是什麼樣的。
整體流程很簡單，業務提需求給我們開發團隊，然後開發團隊收到業務需求後開發、測試，最後上線。
我們上線流程也比較傳統，先是開發人員把應用打包然後上傳到一個運維團隊規定的路徑，然後才由運維團隊釋出到生產伺服器上。
這種模式開始沒什麼大問題，可是隨著我們拆分服務越拆越多，問題出現了。
我們負責的系統很重要，本身上線比較頻繁。再搞了微服務之後，因為服務多了，伺服器也多了，使得上線部署變得更繁瑣。
這逐漸導致運維團隊本就不富餘的人手更加捉襟見肘，他們只能加班。結果就是，996 成了家常便飯，運維人員對此頗有怨言。
頻繁上線不但連累了運維兄弟，還拖累了其他團隊——由於運維人手不足，又導致了我們團隊和其他團隊專案上線經常出現衝突。
衝突發生後，因為我們的專案是公司核心專案，很自然的，優先順序我們會佔一些便宜。
其他團隊的上線只能不斷的調整去和我們錯開，或者加班等我們上線後，再由運維安排他們的專案上線。
可見，在我搞微服務初期，微服務劃分的快速迭代始終因為團隊劃分和微服務本身的理念不匹配，導致處處受挫。
如果你要全權負責一套微服務專案的時候，一定要萬分注意。因為你本身的團隊和微服務理念中的團隊自治是不匹配的，這會導致你自己微服務專案的維護出現各種各樣問題。
對於這類問題，我建議在初期你就要有所考慮。因為這個風險，或許是技術人員不可控的。
二、沒有配合微服務理念的基礎設施
在一開始，由於我們的微服務是從單體專案逐漸剝離開來的，所以，在這個時候，服務只有 3、4 個。
但是隨著對業務理解越來越深入，開發人員也對服務落地越來越熟悉，服務劃分的速度也越來越快了。在很短的時間內，服務一下子從三四個，猛增為了近二十個。
這時候，面對猛然暴增的服務，我一下子不知所措了。
除了上面說到的運維上線的問題，還出現了很多我從未經歷過的問題。
1. 定位問題成了一件很奢侈的事
通過採用上線模板和其他工具，好不容易緩解了運維問題。還沒輕鬆幾天，緊接著，故障處理又出現問題了。
開始的時候，服務數量少，定位問題，大概稍微琢磨下，就能判斷出來。但是，隨著服務越分越多，定位問題就很麻煩了。
例如出問題後查日誌，原來的服務數量少，查日誌直接上伺服器就查了。但是，現在服務有接近二十個，還沒算叢集。挨個伺服器查日誌定位問題，那幾乎不可能。
2. 不能再這樣了，不然失敗就在眼前
後來，我下了決心，在解決這些問題之前，堅決不能再拆新的服務了。
我主動去和領導溝通了這些問題，得到了領導的支援。然後，又拉著領導和業務團隊磨了好幾次，終於也讓他們同意暫時降低一段時間提需求的頻率。
總算能騰出精力解決問題了。
3. 關於問題的思考
這些問題，我統統歸類為基礎設施的問題。其實，那時候雖然微服務生態還沒有完全清晰，但是，我本身大概也總結出了一些套路。
我把需要的基礎設施分成了兩個類別:
- 部署釋出
- 日常運維
然後，我分別對這兩類基礎設施的需求又做了進一步的細化。下面把當時我做的最緊急的一些基礎設施需求列了出來:
4. 我控制不了這些問題……
但是，這裡依然還有問題。
比如，這些工具理論上是屬於基礎設施，是不是需要運維團隊來維護？可是運維團隊已經對我們的各種上線需求不勝其煩了。
又比如，這些工具當時不成熟，我們還得自己開發改進，而這又要靠誰呢？
當時沒有辦法，我只能咬牙自己帶了幾個人，把這些額外的工作承擔了下來，由我們幾個人專門開發和維護這些工具。
一直到後來，市面上有了成熟的工具鏈，我本身也升職，可以對技術團隊整體去貫徹 DevOps 理念了，才真的從這些任務中解脫開來。
5. 基礎設施決定上層建築啊，同志們
我知道很多公司是技術自己提出來微服務的，提出來的時候，你一定要清楚，微服務這套體系本身，
把以前單體系統的複雜度轉移到了技術基礎設施上。
很多工作其實是需要自動化的。在踏進微服務這個神坑前，一定要考慮清楚：公司有沒有合適的基礎設施？
三、落地需要妥協的其他的一些細節問題
微服務理論看上去是很完美的，但是，在現實落地，其實還會有許許多多不太可能馬上完美貼合微服務理論的問題。
我大概列舉幾個重要的:
1. 資料庫劃分的問題
老實講，我們們這篇文章本來就是在說一個服務一個資料庫的模式。那麼按理來講，嚴格符合這個模式是最好的。但是，實際落地來講，中間有太多的彎彎繞繞了。
比如，我們的服務需要劃分成四五十個服務，這個時候，資料庫劃分成同樣的四五十個庫就不合適了。因為這會引入如下的三個問題:
-
資料庫管理過於複雜——這個是很顯然的問題，管理幾個資料庫和管理幾十個資料庫，需要投入的人力物力是完全不一樣的。每一臺資料庫本身就是個很複雜的系統，數量越多，出問題的機率也越大，監控難度也越大。
-
分散式一致性實現太過複雜——資料庫數量上來了，因為業務需要，協調資料一致性從原先需要協調幾個資料庫的狀態變成了需要同時協調幾十個。複雜度一下子上去了，這也會造成很多不必要的技術問題。
-
跨庫查詢相當不方便——這個問題也是一樣的，當我們服務劃分後，資料庫如果也劃分的過細，那麼以前需要跨幾個庫查詢的業務，就可能變成需要跨十幾個庫查詢。
所以，就落地的時候來講，還是需要有個業務域的概念。這也是為什麼微服務總和領域驅動設計繫結在一起，因為人家天然有個業務域的概念。
這時候，就可以考慮某些業務域，共享一些資料庫。比如，訂單業務域可以每個服務對應一臺資料庫，但是，使用者業務域可能就可以共享那麼一臺資料庫。
2. 開發框架的問題
我搞微服務比較早，所以，開始做的時候，就是用了 Spring 的框架，然後每個 Tomcat 後面放個服務。
那時候，維護起來真麻煩。因為 Tomcat 本身多了，又和應用不是一體的，同時維護 Tomcat 和應用，非常難受。
後來有了 SpringBoot，情況好了很多。再後來，我們也嘗試使用了一陣子 Dubbo。
其實各有自己的不足。
SpringBoot 的不足主要是，用了 SpringBoot，很多時候就不得不用更多的 Spring 其他元件，哪怕它的一些元件很不讓人滿意。感覺專案中處處 Spring，非得走 Spring 那套規則不可。
Dubbo 的不足主要是能配合的元件很少，我們用 Dubbo 其實很早，但是為了和 Dubbo 配合，有些時候還得做很多額外的開發。比如，當時 Dubbo 本身服務跟蹤，也沒有通過 RabbitMQ 通訊的元件，我們都需要自己開發。
所以，當你要選框架的時候，要考慮清楚，因為微服務本身是一大套生態。如果框架本身選用不合適，後期就得靠自己的技術能力去做硬調整。
3. 一些關鍵技術何時引入的問題
有些關鍵技術，我們是逐漸引入的。
因為，引入一個新技術，對我們無論是開發還是維護，引入便利性的同時可能也會引入複雜性。
比如容器技術，我們就是搞了很久了才慢慢引入的。引入容器技術後，很多問題（例如網路、記憶體）我們就要多想一層，看看是不是因為容器導致了其他問題。
總之，對於一個正在運營的系統，我個人認為引入新技術需要謹慎評估。
最後
以上寫的主要是我和團隊的經歷，可能你會覺得是一家之言。沒關係，說的不對的，歡迎指正，虛心接受；說的對的，希望能讓給大家一些借鑑
對於一個服務一個資料庫說到現在，我說了為什麼要分服務，以及如何落地還有帶來的一些問題。
對於這種模式，它引入的問題其實非常多，一本書可能都說不完，這裡只是舉了一些我遇到的一些我記憶裡很深刻的問題。
那麼，把一套系統改造成一套微服務就需要分服務和分庫就完了嗎？解決分服務和分庫帶來的一些問題就完了嗎？
那可不是，因為有些問題非得引入一些新的模式才能最好最省心的解決，只有把多種微服務的模式配合起來，才能讓微服務這個生態完全的運轉起來去替代以前的單體專案生態。
在後面的文章裡，我會講解該怎麼用模式去解決一些棘手的效能問題，怎麼用模式去平衡讀寫負載失衡的問題等等。只有通過模式把分服務引起的各種開發問題解決了，一套微服務系統我們才能說架構完全成功了，所以，我會以我的架構經驗去把整套微服務架構通過模式去講清楚一套微服務到底應該如何架構。
你好，我是四猿外。
一家上市公司的技術總監，管理的技術團隊一百餘人。
我從一名非計算機專業的畢業生，轉行到程式設計師，一路打拼，一路成長。
我會通過公眾號，
把自己的成長故事寫成文章，
把枯燥的技術文章寫成故事。
我建了一個讀者交流群，裡面大部分是程式設計師，一起聊技術、工作、八卦。歡迎加我微信，拉你入群。
