前言
微服务最近几年大火了一把，这年头还没听过微服务这件事本身已经是个新闻了。推崇微服务的资料博客一抓一大把，本文则想给大家降降温，来说说微服务转型过程中的各种坑和痛苦，最后也给出了一点自己建议。
微服务是好东西，但并不是万能。
仙境中的微服务
微服务一经推出就引发了业界大佬的极力推广，下图就显示了系统的微服务重构过程。
微服务的好处，好处多多多,包括但不限于下面几条：
1.各个模块可以独立的开发，迭代，
2.不同团队之间的技术栈分离，可以根据团队的特点来使用更合适的技术解决问题
3.将系统切分为细粒度的服务，往往意味着更高的可复用性
微服务就像处于仙境之中看上去很美，但实施起来却是另一番景象。
通往仙境的荆棘之路
微服务确实是技术趋势，但通往微服务的道路却不是康庄大道，而是一条充满不确定的荆棘之路，下面就介绍一下转型中的各种痛。
采坑之痛
相比传统的架构，微服务作为新生事物，但其参考资料却十分丰富，事实上是有点太丰富了，去网上随便一搜就是各种博客，参考资料，但其中99%都是停留在很表层的，而且不少还有一些错误。光是从其中筛选出有用的东西就得花不少时间，而且都要亲自建立原型测试一下才能放心， 要想走向微服务化坑是要踩不少的，从一开始的技术选型，到中间的重构和试运行，乃至上线运行以及最后的规模化都是步步惊心啊。
人员之痛
要想转型成功，一支热爱技术和勇于挑战自己的团队是必不可少的。
一般微服务的转型是由团队技术领导（架构师）发起的，而底层的开发者往往不具备相关的技能，这就要求开发团队在较短时间内学习不少新的技术，而这可能对于部分成员是一个巨大的挑战，因此在系统刚刚进入转型期时团队效率下降，bug频出将是一个大概率事件。
这时来自管理层的压力就开始增大，不少团队转型都是在这个阶段半途而废的。同时看着团队各种救火，对于有微服务实际开发经验的人的需求就更加迫切，但靠谱的人往往比金矿还难找，因此这时候会经历一个相当长时间的团队技术断档和人员缺失，各种无奈和妥协。
测试之痛
测试也许是微服务中最大的挑战，在转型前整个系统是一体，这样开发完了后，想测试只需要在开发机器上打包运行，开发人员自己就能初步测一测，发现开发中的问题，然后交给测试人员，测试人员也是扔到测试框架中或直接启动做手工的回归测试就OK。但转型为微服务架构后，开发完成后想在本地启动整个系统那绝对不是一件容易的事，测试人员也面临一样问题，往往在开始阶段每次测试前启动系统就需要花费大量的精力。
微服务中的测试方案目前有下面几个主流方向：
1.共享服务
通过搭建一套完成的共享服务来为开发和测试提供公共的测试基础，开发和测试只需要部署涉及到的服务，通过配置其他服务采用共享服务。
这是一个实施起来最为简单的方案，但问题也是颇多，比如：测试数据问题，多点测试冲突问题以及系统的动态路由和配置问题
2.mock其它服务
相信大家都接触过单元测试中Mock，而这个方案是直接mock与修改服务相关的其它服务，保证了开发和测试之间的独立性和隔离型，同时测试也有了幂等性，在CI/CD中也能顺利的跑起来了。
WireMock是个不错的选择。
3.契约式编程
这个是上一个方案的进一步，从开发阶段就采用契约模式，这样就保证了开发和测试的统一，实践方案也有了不少，这里就不做过多介绍。
建议
1.不要盲目的转向微服务，微服务可能是拯救你的良药但也可能是压垮团队的最后一根稻草。
2.微服务是一个技术体系，需要与之适应的测试，监控，部署，运维完成的技术栈，缺乏这些微服务就是毒药，因此技术团队要做好足够的技术储备。
3.微服务的转型是一个漫长的过程，需要相当多的资源支持和试错的勇气，确保得到管理层的支持。
4.最好找一个全新的小项目来做验证，再考虑再现有系统上推广；
版权声明：本文来源CSDN，感谢博主原创文章，遵循 CC 4.0 by-sa 版权协议，转载请附上原文出处链接和本声明。
原文链接：https://blog.csdn.net/zhaoenweiex/article/details/80033627
站方申明：本站部分内容来自社区用户分享，若涉及侵权，请联系站方删除。
