微服务本质上是分布式系统，所以在分布式系统中遇到的难点，在微服务中都会遇到，分布式系统进程间的通信保证，网络开销以及事务处理从来都是难题
微服务的流行，离不开容器化和云生态，离不开gRPC，ServiceMesh，云原生等新技术的崛起以及实际生产应用。换言之，你需要了解乃至熟知这些技术，毕竟传统的单体应用只需要更多的专注于应用层面
微服务架构带来过多的运维操作，需要团队具备一定的 DevOps 技能，在运维层面开销会很大
治理中心（包括基础设施架构，集合着CICD，监控等微服务必要的非功能性需求）
测试将会是非常难，因为它不再是端到端，还很大可能会存在多版本的不同服务带来不同的测试场景
这些挑战，分析一下本质，就是对人的要求更高了，所以说采用微服务并不仅仅是技术层面带来的冲击，更多的是对人带来的思想/能力冲击。
微服务的解剖在实践微服务的过程中，可以划分为三部曲：
服务划分
服务开发
服务治理
这三部也是涵盖了微服务架构落地的全部步骤，每一步都会有不同的指导方法论用于区别于传统的开发思想，后续将会基于这些步骤结合流行的方法学来指导我们服务落地。
总结微服务不是银弹！
我特别喜欢说的一句话是：任何的技术，都是有适用场景的。所以我很喜欢看到那些能基于目前的痛点以及中长期的发展所面临的问题分析， 对比单体架构和微服务架构带来的收益比。
我们需要的是思考技术能带来的价值，而不是为技术疯狂。
任何的技术手段，都是用来服务业务的，能支撑业务创造价值的，才是好技术，否则这些技术一文不值。
不管黑猫白猫，捉到老鼠的就是好猫！
微服务架构也不例外。
所以当你想要采用微服务时，问一下自己这些问题：
为什么团队想要采用微服务？采用后团队将能得到什么？（说明充分了解了单体/微服务的优缺点，并能清晰了解到业务以及团队在中长期所面临的问题点）
是否组织结构以及文化底蕴有一定的支撑？（团队是否能经得起微服务所带来的冲击）
是否有一定的技术基础支撑？（说明能对微服务的所面临的技术挑战有了一定的认识）
当你能做到对以上问题都有清晰答案后，且仍然决定采用微服务架构，说明你已经对微服务所带来的收益比有了自己的判断。
Last but not least在将组织推向微服务道路之前，最重要的决策人理解了“为什么是微服务”，而不是“为什么不是微服务”。