扫二维码与项目经理沟通
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流
小编给大家分享一下php需要采用微服务吗，相信大部分人都还不怎么了解，因此分享这篇文章给大家参考一下，希望大家阅读完这篇文章后大有收获，下面让我们一起去了解一下吧！
技术圈时常会不断的产生一些新的buzzword，很容易被误导，最可怕的是一些技术团队在没搞明白的情况下，就按buzzword去做或者去靠拢，好像生怕如果自己做的技术和buzzword不相关或者不一样，就很low一样，感觉这现象在技术圈太常见了，有些看的不太爽，写篇文章来讲讲自己的观点。
说到微服务这个buzzword，必须承认到现在为止我都没搞明白和服务化的区别，我都搞不太清楚淘宝在2008年做的服务化改造后形成的SOA体系到底是不是和现在的这个buzzword就是一回事，在各种文章里，微服务简直就被宣传的像是技术界一些场景的救世主，直接误导了很多同学上来就必搞微服务体系。
但不知道有多少同学仔细想过有没有必要，对业务发展来说采用微服务到底是帮助还是变成了阻碍，在互联网类型快速迭代的业务中，业务的迭代效率是核心问题。
以我自己的认知，对服务化我的观点一直是如果能不进这个坑，最好不进，一个单一应用的复杂度远比N个应用组成的分布式系统简单、快速多了，一旦进入分布式的坑，在技术上就不得不有比较大的投入。
而对于一些还处于中小规模的公司而言，我觉得完全没有必要，Google的Jeff Dean在一次分享时讲到他对于Google做服务化的观点：
让Google具备了千人并行协作开发的能力，在看到这观点以前，我一直觉得服务化重点解的是水平伸缩能力的问题，其次是并行协作的问题。
但我现在基本更加赞同服务化重点是让一家公司具备了百人以上的并行协作开发能力，我认为在几十个研发同学的情况下，并行协作开发不会成为太大问题，这个时候的并行协作上的一些投入会远比进入服务化后的投入小很多。
所以以前有一些朋友问我公司到底要不要改变为服务化时，我都问两问题：
公司研发团队现在总共多少人？
目前的水平伸缩瓶颈是？
如果在这两个问题上服务化并不是核心的瓶颈，或者只需要付出少量的人或机器代价就可以解决，我会强烈建议不要做服务化，所以拜托受微服务这个buzzword诱惑的同学们，请大家在采用这样的架构前一定，千万要慎重思考，策略应该是以尽量不采用去推导会产生的代价和问题，如果这个代价和问题并不是那么大，就不要用。
除非真的万不得已，那就请做好组织、团队人员方面的布局，以真正的做好服务化，不要让这个东西最后变成业务发展的障碍。
以上是php需要采用微服务吗的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注创新互联网站制作公司行业资讯频道！
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流
微信二维码
移动版官网