大部分公司並不需要微服務

本來之前標題的名字是不要被技術buzzword誤導，覺得還是得標題黨一些，:)，請大家諒解，技術圈時長會不斷的產生一些新的buzzword，很容易被誤導，最可怕的是一些技術團隊在沒搞明白的情況下，就按buzzword去做或者去靠攏，好像生怕如果自己做的技術和buzzword不相關或者不一樣，就很low一樣，感覺這現象在技術圈太常見了，有些看的不太爽，寫篇文章來講講自己的觀點。

作為技術圈的我們大家，對各種buzzword一定要慎重，了解它產生的背景，可執行的各種前提和條件，技術始終是為公司的戰略而服務的，buzzword是不是真的給你的場景帶來了幫助，要想清楚，拿時下比較流行的微服務、AI、AR/VR來說說吧。

說到微服務這個buzzword，必須承認到現在為止我都沒搞明白和服務化的區別，我都搞不太清楚淘寶在2008年做的服務化改造後形成的SOA體系到底是不是和現在的這個buzzword就是一回事，在各種文章里，微服務簡直就被宣傳的像是技術界一些場景的救世主，直接誤導了很多同學上來就必搞微服務體系，但不知道有多少同學仔細想過有沒有必要，對業務發展來說採用微服務到底是幫助還是變成了阻礙，在互聯網類型快速迭代的業務中，業務的迭代效率是核心問題，以我自己的認知，對服務化我的觀點一直是如果能不進這個坑，最好不進，一個單一應用的複雜度遠比N個應用組成的分布式系統簡單、快速多了，一旦進入分布式的坑，在技術上就不得不有比較大的投入，而對於一些還處於中小規模的公司而言，我覺得完全沒有必要，Google的Jeff Dean在一次分享時講到他對於Google做服務化的觀點：讓Google具備了千人並行協作開發的能力，在看到這觀點以前，我一直覺得服務化重點解的是水平伸縮能力的問題，其次是並行協作的問題，但我現在基本更加贊同服務化重點是讓一家公司具備了百人以上的並行協作開發能力，我認為在幾十個研發同學的情況下，並行協作開發不會成為太大問題，這個時候的並行協作上的一些投入會遠比進入服務化後的投入小很多，所以以前有一些朋友問我公司到底要不要改變為服務化時，我都問兩問題：1. 公司研發團隊現在總共多少人？ 2. 目前的水平伸縮瓶頸是？ 如果在這兩個問題上服務化並不是核心的瓶頸，或者只需要付出少量的人或機器代價就可以解決，我會強烈建議不要做服務化，所以拜託受微服務這個buzzword誘惑的同學們，請大家在採用這樣的架構前一定，千萬要慎重思考，策略應該是以盡量不採用去推導會產生的代價和問題，如果這個代價和問題並不是那麼大，就不要用，除非真的萬不得已，那就請做好組織、團隊人員方面的布局，以真正的做好服務化，不要讓這個東西最後變成業務發展的障礙。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！