转载

考虑把大型项目拆解成微服务吗？

【编者的话】本文理性的讨论了拆解大型项目到微服务的过程，讨论了拆解过程中会遇到的问题和编程语言的选择，并给出了作者自己的建议。

微服务是处理臃肿、凌乱系统的一剂良药。然而，拆解一个大型项目为一系列的微服务所付出的代价是值得的吗?现在存在一些优点和缺点，那么微服务的哪些特点吸引了众多公司和开发人员呢?

最常见的应用场景是将一个大型系统切换到基于微服务的基础设施。我倾向将这个过程称为“分解”应用程序,因为我们把紧耦合的代码分解成多个小的服务。这包括了从仅添加一两个微服务到完全重构主要应用程序到微服务架构。

简而言之,我相信分解一个大型系统为微服务组合是值得的。然而,这是一个长期投资,可能需要一段时间才能得到回报。每个项目或公司在这一过程中都会有不同的经验和教训。这里有一些共同的主题，它们也是我最近在分解大型项目到微服务过程中遇到的。

放慢节奏

在开发软件的过程中，我们通常切分大型的任务为小的部分，便于一步一步实施。采用微服务时，与这个过程非常相似。我们需要分解大的项目为一系列的微服务。很多方面，我们像堆砌木桩一样处理它们：我们需要随时间的推移而添加组成部分，将项目分解成丰富且有用的多个组成部分。

当你首次介绍微服务思想给开发团队时，可能他们会很容易接受。微服务是开发社区中的发展趋势，于是人们都渴望试一下。更夸张的趋势甚至会变成“能够改变app中一个功能而不影响其他200项功能，这不是很棒么？”

然而,实现松耦合和独立应用的过程远不止两周。可能需要花费数个月甚至数年来解耦合你的应用程序到不同的功能服务。

将项目分解作为一项长期的任务是非常重要的。客户和投资者并不在意你是否将已有的功能拆分为微服务。他们只是关心是否你在如期地产出。当已经感受到微服务架构的威力，你和你的团队需要推动其发展。同样，这也是一种技术债务。

这也就是为什么需要花费时间去解体大型项目。把拆解项目作为一个长期项目的时候，可能需要花费多年时间才能得到相应的收益。每一部分代码的拆分都应该作为一个重要决定。在你拆解速度过快时，可能会产生严重的问题。

自由通常不是免费的

微服务架构可以采用不同的开发语言和框架实现。微服务限制一组有限的编程语言来共享应用程序，允许开发人员使用，并且只能用这些。

对于开发者来说，这可以引出很多非常激动人心的决定。但是，你可能希望在选择一门新编程语言或者框架来实现微服务时有所收敛。

学习新的编程语言或者框架对于个人经验来讲是非常有帮助的。同时开发者也很有兴趣去学习。尽管我可能满足于采用某些语言和框架来创作自己的私有项目，但是，在生产环境这个场景下，可能是完全不同的情况。

你和你的同事可能觉得用Rust语言写个服务是个好主意。从纸面上来讲，这个主意看上去很好。你可以用一个非常棒的语言去实现，同时让你的业务达到一个更好的境地。

值得注意的是，在你的团队和同事在实现它的时候，没有什么是一成不变的。团队生产是一件取决于你是否要去选择的事情。目前，你的公司可能具备资源和技能去采用Rust来创造一个高效的微服务。但是，你的团队是否会在Rust服务上进行持续投入？这依赖于在微服务上的投入，你可能发现自己已经完全归属在微服务上了。

当你选择一门编程语言，你其实是在抉择未来是否继续投入。抛开你当前团队的规模和状态的情况下，最差的情况是你可能朝着一个令人沮丧的方向并且浪费了大量的开发资源。

DevOps的负担

当你决定去拆分一个项目时，我强烈推荐增加在DevOps上的投入。微服务的显著特点是他们在持续部署上的稳定。这里面还有很多其他的说法。当服务准备完毕时，微服务使你可以快速的部署。这对于部署过程是非常好的，因为你不需要重新部署一整套应用。

这只是理论上的情况。

事实上，创建和维护的服务越多，部署环节自然会越多。你需要能够在有限时间内有效的部署多个服务。如果只有有限个开发人员培训过部署方式，事情可能会失控。

这就是为什么要教会开发者具备从开发到部署代码的能力。理想情况是，他们可以便捷的部署代码并监控。他们还应该具备突发情况下部署和掌控服务的能力。此外，开发者应该熟悉微服务及对常规生产环境故障的感知力。我经历过许多的部署错误，如果开发人员熟悉这些故障，解决起来会更快。这可能是几秒钟宕机到几分钟宕机的差别。

此外，这个事情的复杂度可能会因为稳定性和语言多样性而加重。再次重申一下，并不是所有的新语言和框架在部署上像其在开发上那么方便。明智的选择是在承担较小风险的同时，采用较先进的语言和框架，毕竟它们可能不是为生产环境而准备的。