微服務轉型的三大誤區，避坑指南→
導讀
本篇文章為博雲微服務轉型系列第二篇文章。
在之前文章中我們講到企業的數字化轉型（詳情回顧：農商行數字化轉型的煩惱），通常兩種技術的運用代表著數字化轉型的實踐，一種是容器技術，一種是微服務技術。容器技術的建設和使用都是運維，因此更容易快速上手和建設。但是，微服務技術就不同了，微服務架構的起點是研發，治理卻在運維，架構回饋和改進又要回到研發（當然這是傳統的企業管理模式下的），所以傳統企業在微服務化建設時，會遇到很多微服務的相關問題和誤區。
本文我們將對微服務化轉型的常見誤區進行了整理，並分享一些如何避開這些誤區的建議和想法。
通常企業的數字化轉型和系統的微服務化改造很容易被放在一起討論，這樣的說法是把微服務放到了一個系統級別，也就成為了一個部門或一個團隊的任務。這其實就是一個企業剛開始做微服務轉型的最大誤區。
微服務化轉型是企業級的改造工程，而具體的落實才是系統的改造，只關注於系統的微服務化改造，難免會「守一隅而遺萬方」。其實，企業微服務化轉型的很多誤區都是這樣產生的。
01 微服務拆分的誤區
博雲一直為企業提供微服務拆分的諮詢服務，所以經常會接到微服務拆分的項目。有些客戶通常只要諮詢、只要方法論、只要單個系統拆分的服務，這樣的方式其實都走入了微服務建設的誤區。例如，我們之前遇到一個大企的微服務化轉型項目，涉及近百個業務系統的微服務改造建設。面對這麼大的微服務化建設，客戶的想法卻很簡單，計劃整體改造分成三步：
第一步：找一個對微服務拆分比較專業的公司，幫忙做第一個系統的拆分工作，並學習微服務拆分的精髓。
第二步：在諮詢公司的幫助下，自行拆分二三十個業務系統，作為練兵。
第三步：擺脫諮詢公司的幫助，拆分改造剩下的系統。
很明顯，這是為了拆分而拆分。這樣的建設相當於是單體應用系統平等地置換成微服務系統的應用，導致單體應用的優勢沒有了，而微服務的優勢也並沒有體現出來。可以預見，如果繼續這樣建設會出現很多麻煩：
-
業務系統由近百個變成近千個，完全顛覆了原來的管理模式。以前只需要在資源層面、網路層面的監控運維，而對於現在服務層面的觀測簡直束手無策。
-
如果只是單系統的考慮拆分，那麼微服務帶來的消耗是會增加的。微服務的拆分將一個運行程式拆成了十幾個，還要依賴於必要的組件，如註冊中心、配置中心、網關，當然每個都需要考慮高可用，那麼在資源消耗上，將增加不止一倍的消耗，這樣算來，整個企業的微服務改造，將可能會多改造出一個機房來。
-
剛剛提到監控運維，其實運維層面還有更多的問題。上百個系統，近千個服務，再加上分散式的部署方式，將有幾千個運行程式的部署和升級迭代，這絕對不容小覷。
-
每個改造、建設，或者變革，都會被問到一個收益的問題，投入大量的人力、物力、財力，我們想要看到的是回報，而這種方式的拆分將只有投入。
微服務化轉型，或者說微服務化建設，絕對不等於微服務的拆分。微服務的拆分僅針對於某一個系統，或者幾個系統，跟架構師、研發人員比較密切相關。而微服務化的建設，其實針對的是整個企業的管理、運維，並關係到所有的微服務系統的研發和運維團隊。所以企業在做微服務化轉型的時候，我們應該把握微服務的優勢，發揮其長處，彌補其不足。
不要把微服務建設，做成了微服務批量拆分，這是要注意的第一個誤區。
02 微服務化建設的誤區
談到這裡似乎應該說：「不要為了微服務而微服務」，但實際上為了微服務而建設微服務也不是問題，因為雲原生理念與技術的普及已經如火如荼，所以熟悉相關技術也是勢在必行。
很多企業看到了微服務的前景，也開始在架構、研發等部門中，建設一些微服務治理平台或者微服務運行觀測平台，但是通常這類的試驗性質的項目都存在很多誤區。
經常遇到的疑問：微服務是用來解決什麼問題的，或者能帶來什麼樣收益？於是企業從各方面尋找可以優化的點，比如性能優化、資源節省、運維成本、管理難度，但是這一圈下來發現收益全部是負增長。性能由於加入檢測探針，增加性能消耗；資源由於增加很多治理組件，增加資源消耗；運維和管理更是幾何倍增長。因此，有些企業在建設一期的微服務平台之後，遷入或者甚至都沒有遷入一個微服務系統的時候，就認為微服務化沒有成果，從此中斷。
另外，企業在做微服務化嘗試的時候，通常都會拆分一個不是很關鍵的業務系統，以此來測試微服務化是否真的如互聯網上炒得那麼火熱，那麼有用。然而，這個很不關鍵的業務系統在嘗試微服務化之後，企業會輕易地得出一些 「結論」：
· 微服務的分散式似乎也沒什麼特別，反而帶來了分散式的各種問題。
· 微服務的限流熔斷一般用不著，用了還有可能影響正常業務。
· 微服務的觀測也沒啥用，如果不是出問題，平常根本沒人看。
不僅是上面的兩個理解誤區，我們在做微服務類的項目時也遇到過很多比較有前瞻性的客戶，但是完全按照客戶的要求去建設的平台，卻似乎不是很實用。等過兩年之後，客戶發現建設微服務還是很必要，於是總結之前的經驗，覺得還是需要大廠來建設，因此只好花幾倍的錢找大廠來做，而實際上再次建設可能還會遇到之前同樣的問題，反而 「勞民傷財」 。其實主要原因還是沒有把握住微服務的根本。
微服務解決的根本問題，總結一下其實是業務系統運行中由量變引起的一系列問題，量變引起質變，最終通過微服務的架構解決。如果業務訪問量不夠，那就不會用到限流熔斷；如果應用服務數量不多，那就不需要統一管理和運行觀測；如果服務變更不頻繁，那也就不需要持續發布、灰度發布等。
微服務的優勢在單一且沒有業務量的系統中，完全不能發揮其長處，反而單體應用的優勢更明顯。這也正是微服務建設中最大的誤區。
03 微服務治理平台的誤區
當我們聊到微服務的時候，很多人第一印象就是拆分，一個拆成多個，這就是微服務。那麼微服務治理、或者微服務運行平台，就是用來解決微服務拆成多個以後帶來的問題。
具體問題有通訊互訪、流量保障、關係網路、運行狀態、分散式事務、性能觀測、故障定位、灰度發布等，很多方案都是由開源技術提供，比如微服務框架、APM 一些開源組件。
那麼微服務治理平台就是開源組件的聯合嗎？在微服務治理中，開源組件有：
-
微服務框架（其實不屬於組件）：在治理方面主要提供微服務的通訊、負載均衡等，如 SpringCloud、Dubbo；
-
註冊中心：提供服務註冊發現機制，如 Nacos、Consul 等。
-
服務流量限制：通常有限流、熔斷、降級等功能，如使用 Hystrix 組件。
-
配置中心：提供統一的配置管理，尤其是分散式服務下，服務配置的統一變更，如 Apollo。
-
服務觀測：主要是 API 維度、服務維度的性能監控，服務間關係拓撲，鏈路追蹤、日誌追蹤等功能，目前使用最多的是 Skywalking。
當然還有網關、分散式任務調度、分散式事務等組件，這些組件都是微服務運行所依賴的。
那這些組件的聯合就可以做到微服務的治理了嗎？其實微服務治理平台，主要還是管理，以業務視角的系統、應用的管理是治理平台最大的價值。註冊中心提供的是全量的服務資訊，配置中心也有全量的服務配置，但全都是技術角度的依賴工具，而不是管理工具。
我們剛剛提到微服務的量變引起的管理困難，在所有的開源工具中，都不能得到解決。無論是服務列表、服務配置、服務拓撲，我們要的不是技術角度的功能實現，而是業務角度的管理觀測。開源的工具不是治理，如果立項，可別踩這坑。
綜上所述，微服務化轉型所有的誤區，其實都是因為對微服務的認識不夠和對微服務的規劃不明確導致的。那麼微服務化建設應該從哪些方面入手才是正確的建設方向，才能保證持續的進步，才能少踩坑，少走彎路？我們將在之後的文章中為大家分享正確的微服務轉型的建設思路，敬請期待。
