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