为什么放弃了微服务？是哪些原因导致的？

除此之外，还有很多全局性的问题无法得到解答。

• 让不同的团队负责处理不同的业务是否切合实际?
• 我们能否在领域和微服务之间对功能进行清晰划分?
• 是否所有团队都有足够的工作量，会不会出现某些团队很清闲的情况?
• 个别团队会不会被堆积如山的高优先级工作压得喘不过气?
• 阻碍我们拆分单体系统的问题是否也会让领导层难以分配工作?
• 领导层对这种转变感兴趣吗?

微服务迁移是件大事情，在几个月的时间里，所有开发人员都停止开发新功能，并在很多先决条件都还不满足的情况下开始拆解单体系统。为了做这件事而做，我们并没有想过是否真的有必要。

这不仅不是从 A 到 B 的问题，反而是一种倒退。我们先是创建微服务，然后搭建基础设施，还忽略了重组团队结构。如果我们先根据业务关注点重组团队，然后准备好基础设施，这就为微服务的自然出现做好了准备。一旦出现任何新的业务问题，就可以将它们直接放到新的服务中。

在拆分微服务时，我们必须预先确定每个微服务的大小。关于微服务大小这个问题，有很多相互矛盾的建议。有人建议微服务应该足够大，大到可以由一个团队负责开发;另一些人则建议微服务应该足够小，小到可以在脑子里浮现出服务结构，甚至小到可以在两周内重写;还有一些人建议，应该与业务大小相仿。

领导层决定基于我们的领域模型来拆分微服务，如果还有问题，就继续把它们拆分成更小的服务。这导致了上面提到的一些问题。事后看来，如果我们先把先决条件准备好，并让微服务自然而然地出现，最终可能会得到切合实际的微服务大小。

取消计划

随着微服务发布日子的临近，我们的团队发现了越来越多问题。我们做出了更多妥协，微服务带给我们的好处也进一步消失殆尽。从开始实现微服务的第一个 sprint 开始，已经过去了四天，但我们仍然看不到什么收获，反而问题越来越多。我们召开了一次会议，不管领导层想要什么，关于这条路是否要继续走下去，答案都写在每个开发人员的脸上。最终，我们取消了转向微服务的计划。

做什么来代替微服务?

因为之前把所有精力都放在了如何转向微服务上，所以没有花时间研究其他替代方案。但在放弃微服务之后，我们开始研究其他替代方案。最终，我们没有将单体拆分成微服务，而是将它拆分成多个项目。这种拆分为我们提供了一些额外的结构，我们可以更容易地看出哪里存在耦合和重复，没有额外的负担，也不需要面对微服务架构中存在的问题。

此外，这种结构让我们的领域模型变得更加清晰，能够更容易地评估哪些部分可以被拆分成微服务。如果某些部分被证明是一个合适的微服务候选对象，这个部分就可以从单体中剥离出来，成为一个微服务。

结论

领导层决定转向微服务，但没有考虑到现状和需要面对的挑战。经过评估，我们发现微服务并不适合，我们需要做出大量妥协。这些妥协导致无法获得微服务的好处，所以转向微服务对我们来说是一种损失。

在决定转向微服务时，我们并没有评估团队结构等非技术方面的问题。经过几个月的调研和努力，我们最终放弃了这个想法，并用剩下的时间对“单体”进行了一些小的重构。

【编辑推荐】

1. 不完全预测：2020年将流行何种编程技术？
2. JavaScript 的一些常用设计模式
3. 粉丝关系链，10亿数据，如何设计？
4. 技术干货总结：分布式系统常见同步机制
5. Java设计模式、框架、架构、平台之间的关系

（编辑：新余站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!