说到微效劳这个buzzword，必需认可到如今为止我都没搞邃晓和效劳化的区分，我都搞不太清晰淘宝在2008年做的效劳化革新后构成的SOA体系究竟是否是和如今的这个buzzword就是一回事，在种种文章里，微效劳几乎就被宣扬的像是手艺界一些场景的救世主，直接误导了许多同砚上来就必搞微效劳体系。 （引荐进修：PHP视频教程）
但不晓得有若干同砚细致想过有无必要，对营业生长来讲采纳微效劳究竟是协助照样变成了停滞，在互联网范例疾速迭代的营业中，营业的迭代效力是中心题目。
以我本身的认知，对效劳化我的看法一向是假如能不进这个坑，最好不进，一个单一运用的复杂度远比N个运用构成的分布式体系简朴、疾速多了，一旦进入分布式的坑，在手艺上就不得不有比较大的投入。
而关于一些还处于中小范围的公司而言，我以为完整没有必要，Google的Jeff Dean在一次分享时讲到他关于Google做效劳化的看法：
让Google具有了千人并行合作开辟的才能，在看到这看法之前，我一向以为效劳化重点解的是程度伸缩才能的题目，其次是并行合作的题目。
但我如今基础越发赞许效劳化重点是让一家公司具有了百人以上的并行合作开辟才能，我以为在几十个研发同砚的情况下，并行合作开辟不会成为太大题目，这个时刻的并行合作上的一些投入会远比进入效劳化后的投入小许多。
所以之前有一些朋侪问我公司究竟要不要改变成效劳化时，我都问两题目：
公司研发团队如今统共若干人？
现在的程度伸缩瓶颈是？
假如在这两个题目上效劳化并非中心的瓶颈，或许只需要支付少许的人或机械价值就能够处理，我会强烈建议不要做效劳化，所以托付受微效劳这个buzzword引诱的同砚们，请人人在采纳如许的架构前肯定，万万要郑重思索，战略应当是以只管不采纳去推导会发生的价值和题目，假如这个价值和题目并非那么大，就不要用。
除非真的万不得已，那就请做好构造、团队职员方面的规划，以真正的做好效劳化，不要让这个东西末了变成营业生长的停滞。
以上就是php有必要微效劳吗的细致内容，更多请关注ki4网别的相干文章！
