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