在我最初接觸微服務的很長一段時間里，有兩類問題都困擾着我和團隊，這是讓我印象最深的兩類問題：
- 沒有配合微服務理念的團隊
- 沒有配合微服務理念的基礎設施
后來，在和一些搞了微服務的同行多次交流后，發現他們當初也面臨和我類似的問題。
這次就寫寫我最早搞微服務遇到的問題。
有些問題放到現在來說，已經有解決辦法了，已經算不上問題了。但是無論怎樣，這些問題如果能提前意識到，早做准備，會為將來搞微服務的同仁們省下許多的力氣。
所以，這篇文章我會着重談下這兩類問題。
一、沒有配合微服務理念的團隊
當年，我還是一個小開發團隊的組長，組里將近 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. 一些關鍵技術何時引入的問題
有些關鍵技術，我們是逐漸引入的。
因為，引入一個新技術，對我們無論是開發還是維護，引入便利性的同時可能也會引入復雜性。
比如容器技術，我們就是搞了很久了才慢慢引入的。引入容器技術后，很多問題（例如網絡、內存）我們就要多想一層，看看是不是因為容器導致了其他問題。
總之，對於一個正在運營的系統，我個人認為引入新技術需要謹慎評估。
最后
以上寫的主要是我和團隊的經歷，可能你會覺得是一家之言。沒關系，說的不對的，歡迎指正，虛心接受；說的對的，希望能讓給大家一些借鑒
對於一個服務一個數據庫說到現在，我說了為什么要分服務，以及如何落地還有帶來的一些問題。
對於這種模式，它引入的問題其實非常多，一本書可能都說不完，這里只是舉了一些我遇到的一些我記憶里很深刻的問題。
那么，把一套系統改造成一套微服務就需要分服務和分庫就完了嗎？解決分服務和分庫帶來的一些問題就完了嗎？
那可不是，因為有些問題非得引入一些新的模式才能最好最省心的解決，只有把多種微服務的模式配合起來，才能讓微服務這個生態完全的運轉起來去替代以前的單體項目生態。
在后面的文章里，我會講解該怎么用模式去解決一些棘手的性能問題，怎么用模式去平衡讀寫負載失衡的問題等等。只有通過模式把分服務引起的各種開發問題解決了，一套微服務系統我們才能說架構完全成功了，所以，我會以我的架構經驗去把整套微服務架構通過模式去講清楚一套微服務到底應該如何架構。
你好，我是四猿外。
一家上市公司的技術總監，管理的技術團隊一百余人。
我從一名非計算機專業的畢業生，轉行到程序員，一路打拼，一路成長。
我會通過公眾號，
把自己的成長故事寫成文章，
把枯燥的技術文章寫成故事。
我建了一個讀者交流群，里面大部分是程序員，一起聊技術、工作、八卦。歡迎加我微信，拉你入群。
