说到微服务这个buzzword，必须承认到现在为止我都没搞明白和服务化的区别，我都搞不太清楚淘宝在2008年做的服务化改造后形成的SOA体系到底是不是和现在的这个buzzword就是一回事，在各种文章里，微服务简直就被宣传的像是技术界一些场景的救世主，直接误导了很多同学上来就必搞微服务体系。 （推荐学习：PHP视频教程）
但不知道有多少同学仔细想过有没有必要，对业务发展来说采用微服务到底是帮助还是变成了阻碍，在互联网类型快速迭代的业务中，业务的迭代效率是核心问题。
以我自己的认知，对服务化我的观点一直是如果能不进这个坑，最好不进，一个单一应用的复杂度远比N个应用组成的分布式系统简单、快速多了，一旦进入分布式的坑，在技术上就不得不有比较大的投入。
而对于一些还处于中小规模的公司而言，我觉得完全没有必要，Google的Jeff Dean在一次分享时讲到他对于Google做服务化的观点：
让Google具备了千人并行协作开发的能力，在看到这观点以前，我一直觉得服务化重点解的是水平伸缩能力的问题，其次是并行协作的问题。
但我现在基本更加赞同服务化重点是让一家公司具备了百人以上的并行协作开发能力，我认为在几十个研发同学的情况下，并行协作开发不会成为太大问题，这个时候的并行协作上的一些投入会远比进入服务化后的投入小很多。
所以以前有一些朋友问我公司到底要不要改变为服务化时，我都问两问题：
公司研发团队现在总共多少人？
目前的水平伸缩瓶颈是？
如果在这两个问题上服务化并不是核心的瓶颈，或者只需要付出少量的人或机器代价就可以解决，我会强烈建议不要做服务化，所以拜托受微服务这个buzzword诱惑的同学们，请大家在采用这样的架构前一定，千万要慎重思考，策略应该是以尽量不采用去推导会产生的代价和问题，如果这个代价和问题并不是那么大，就不要用。
除非真的万不得已，那就请做好组织、团队人员方面的布局，以真正的做好服务化，不要让这个东西最后变成业务发展的障碍。
下载本文