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

除此之外，尚有许多全局性的题目无法获得解答。

• 让差异的团队认真处理赏罚差异的营业是否合适现实?
• 我们可否在规模和微处事之间对成果举办清楚分别?
• 是否全部团队都有足够的事变量，会不会呈现某些团队很安逸的环境?
• 个体团队会不会被会萃如山的高优先级事变压得喘不外气?
• 阻碍我们拆分单系一切的题目是否也会让率领层难以分派事变?
• 率领层对这种转变感乐趣吗?

微处事迁徙是件大工作，在几个月的时刻里，全部开拓职员都遏制开拓新成果，并在许多先决前提都还不满意的环境下开始拆解单系一切。为了做这件事而做，我们并没有想过是否真的有须要。

这不只不是从 A 到 B 的题目，反而是一种倒退。我们先是建设微处事，然后搭建基本办法，还忽略了重组团队布局。假如我们先按照营业存眷点重组团队，然后筹备好基本办法，这就为微处事的天然呈现做好了筹备。一旦呈现任何新的营业题目，就可以将它们直接放到新的处事中。

在拆分微处事时，我们必需预先确定每个微处事的巨细。关于微处事巨细这个题目，有许多彼此抵牾的提议。有人提议微处事应该足够大，大到可以由一个团队认真开拓;另一些人则提议微处事应该足够小，小到可以在脑筋里显露出处事布局，乃至小到可以在两周内重写;尚有一些人提议，应该与营业巨细相仿。

率领层抉择基于我们的规模模子来拆分微处事，假如尚有题目，就继承把它们拆分成更小的处事。这导致了上面提到的一些题目。过后看来，假如我们先把先决前提筹备好，并让微处事天然而然地呈现，最终也许会获得合适现实的微处事巨细。

打消打算

跟着微处事宣布日子的邻近，我们的团队发明白越来越多题目。我们做出了更多妥协，微处事带给我们的甜头也进一步消散殆尽。从开始实现微处事的第一个 sprint 开始，已经已往了四天，但我们如故看不到什么收成，反而题目越来越多。我们召开了一次集会会议，不管率领层想要什么，关于这条路是否要继承走下去，谜底都写在每个开拓职员的脸上。最终，我们打消了转向微处事的打算。

做什么来取代微处事?

由于之前把全部精神都放在了怎样转向微处事上，以是没有花时刻研究其他更换方案。但在放弃微处事之后，我们开始研究其他更换方案。最终，我们没有将单体拆分成微处事，而是将它拆分成多个项目。这种拆分为我们提供了一些特另外布局，我们可以更轻易地看出那边存在耦合和一再，没有特另外承担，也不必要面临微处事架构中存在的题目。

另外，这种布局让我们的规模模子变得越发清楚，可以或许更轻易地评估哪些部门可以被拆分成微处事。假如某些部门被证明是一个吻合的微处事候选工具，这个部门就可以从单体中剥离出来，成为一个微处事。

结论

率领层抉择转向微处事，但没有思量到近况和必要面临的挑衅。颠末评估，我们发明微处事并不得当，我们必要做出大量妥协。这些妥协导致无法得到微处事的甜头，以是转向微处事对我们来说是一种丧失。

在抉择转向微处事时，我们并没有评估团队布局等非技能方面的题目。颠末几个月的调研和全力，我们最终放弃了这个设法，并用剩下的时刻对“单体”举办了一些小的重构。

【编辑保举】

1. 不完全猜测：2020年将风行何种编程技能？
2. JavaScript 的一些常用计划模式
3. 粉丝相关链，10亿数据，怎样计划？
4. 技醒目货总结：漫衍式体系常见同步机制
5. Java计划模式、框架、架构、平台之间的相关

（编辑：湖南网）

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