微服务是处理臃肿、凌乱系统的一剂良药。然而，拆解一个大型项目为一系列的微服务所付出的代价是值得的吗?现在存在一些优点和缺点，那么微服务的哪些特点吸引了众多公司和开发人员呢?
最常见的应用场景是将一个大型系统切换到基于微服务的基础设施。我倾向将这个过程称为“分解”应用程序,因为我们把紧耦合的代码分解成多个小的服务。这包括了从仅添加一两个微服务到完全重构主要应用程序到微服务架构。
简而言之,我相信分解一个大型系统为微服务组合是值得的。然而,这是一个长期投资,可能需要一段时间才能得到回报。每个项目或公司在这一过程中都会有不同的经验和教训。这里有一些共同的主题，它们也是我最近在分解大型项目到微服务过程中遇到的。
放慢节奏
在开发软件的过程中，我们通常切分大型的任务为小的部分，便于一步一步实施。采用微服务时，与这个过程非常相似。我们需要分解大的项目为一系列的微服务。很多方面，我们像堆砌木桩一样处理它们：我们需要随时间的推移而添加组成部分，将项目分解成丰富且有用的多个组成部分。
当你首次介绍微服务思想给开发团队时，可能他们会很容易接受。微服务是开发社区中的发展趋势，于是人们都渴望试一下。更夸张的趋势甚至会变成“能够改变app中一个功能而不影响其他200项功能，这不是很棒么？”
然而,实现松耦合和独立应用的过程远不止两周。可能需要花费数个月甚至数年来解耦合你的应用程序到不同的功能服务。
将项目分解作为一项长期的任务是非常重要的。客户和投资者并不在意你是否将已有的功能拆分为微服务。他们只是关心是否你在如期地产出。当已经感受到微服务架构的威力，你和你的团队需要推动其发展。同样，这也是一种技术债务。
这也就是为什么需要花费时间去解体大型项目。把拆解项目作为一个长期项目的时候，可能需要花费多年时间才能得到相应的收益。每一部分代码的拆分都应该作为一个重要决定。在你拆解速度过快时，可能会产生严重的问题。
自由通常不是免费的
微服务架构可以采用不同的开发语言和框架实现。微服务限制一组有限的编程语言来共享应用程序，允许开发人员使用，并且只能用这些。
对于开发者来说，这可以引出很多非常激动人心的决定。但是，你可能希望在选择一门新编程语言或者框架来实现微服务时有所收敛。
学习新的编程语言或者框架对于个人经验来讲是非常有帮助的。同时开发者也很有兴趣去学习。尽管我可能满足于采用某些语言和框架来创作自己的私有项目，但是，在生产环境这个场景下，可能是完全不同的情况。
你和你的同事可能觉得用Rust语言写个服务是个好主意。从纸面上来讲，这个主意看上去很好。你可以用一个非常棒的语言去实现，同时让你的业务达到一个更好的境地。
值得注意的是，在你的团队和同事在实现它的时候，没有什么是一成不变的。团队生产是一件取决于你是否要去选择的事情。目前，你的公司可能具备资源和技能去采用Rust来创造一个高效的微服务。但是，你的团队是否会在Rust服务上进行持续投入？这依赖于在微服务上的投入，你可能发现自己已经完全归属在微服务上了。
当你选择一门编程语言，你其实是在抉择未来是否继续投入。抛开你当前团队的规模和状态的情况下，最差的情况是你可能朝着一个令人沮丧的方向并且浪费了大量的开发资源。
DevOps的负担
