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

微处事被以为是一种抱负的架构模式，因此，Steven Lemon 地址公司的率领层抉择从单体架构向微处事架构迁徙，这让整个开拓团队在随后的的日子里苦不堪言，七大实际题目摆在眼前无法办理，微处事架构的甜头也没有享受到，并发明这不光单是一个技能题目。最终，整个团队抉择放弃。

率领抉择：迁徙微处事

最近，我地址的开拓团队在求助的交付周期竣事后，有了短暂的苏息机遇。率领层以为可以操作这段时刻将单体架构迁徙至微处事。颠末一个月的调研和筹备之后，我们最终放弃迁徙打算，继承行使原先的单体架构。在我们看来，微处事不只不会帮到我们，反而会对开拓流程造成严峻影响。

微处事被以为是一种抱负的架构模式，但并不得当我们。我们公司的环境是这样的：一共有 200 多名开拓职员，不外我们团队只有 5 小我私人，或许有 5% 的后端开拓事变涉及公司层面的单系一切，这是一个庞大的 C#应用措施。剩下的时刻，我们开拓了本身的两个 Node 处事。

我们团队认真的这两个处事都很小巧，完全可以节制开拓、架构和陈设整个流程。碰着机能题目时，我们会把出产情形中的实例数目增进一倍，直到把底层题目办理。我们险些不与其他团队相助，由于这些处事是用 TypeScript 开拓的，以是我们团队 (首要是前端开拓职员) 可以或许在前端和后端行使沟通的编程说话。最重要的是，我们可以在客户端及后端的验证和陈诉处事中包括伟大的法则计较引擎。总而言之，我们整个团队专注于特定营业。

起首必要声明：我们不喜好开拓单系一切，由于增进新成果、编译和运行测试都很慢，并且架构常常产生变革，在构建进程中总会呈现难以预料的对象。以是，当率领提出迁徙至微处事架构时，我们也赞成了。

为什么选择放弃?

然而， 在整个调研进程中，我们发明白如下七浩劫以办理的题目，这些题目让我们最终选择放弃。

严峻依靠第三方

我们的整体应用措施是一个成立在外部产物之上的自界说 UI 层，集成了自界说营业法则，并提供了用于交互的界面。客户端是一个 UWP 应用措施，尚有一些后端处事，用于在我们和第三方域之间举办转换。

由于大量依靠第三方，我们在举办微处事分别时碰着了一些题目，譬喻，为了让第三方的某个域起浸染，应用措施必需在域之间做一些转换事变，让第三方域看起来像是我们的域的一部门。假如前端和第三方之间只有一个处事，那么这种转换照旧可行的。当我们试图将域分别成多个独立的微处事时，域之间的转换事变带来了许多贫困。好比，微处事分别是否要跟第三方保持同等，并在双方处事之间一再实现前端需求?可能按照本身的原则来分别微处事，并通过一个微处事从第三方的多个域获取数据?这两种要领都违背了微处事原则，而且会导致特另外耦合。

另外，我们常常要与外部方协同事变，由于一些特征要求两边都做出窜改。现实上，外部方成了我们之外的另一个开拓团队。云云细密的相助意味着我们的宣布流程必需与他们保持同步。 微处事的一个甜头是每个团队都可以独立宣布本身的处事，不必要与其他团队举办和谐 ， 但跨团队乃至是跨公司的和谐宣布流程导致我们无法享受到这些甜头。

微处事的焦点头脑之一是冲破“差异层由差异团队认真开拓”的模式。在微处事架构中，每个团队必要处理赏罚与其营业相干的整个技能栈。对付我们来说，由于外部方是一家完全独立的公司，以是举办这种重构是不实际的。

无法有用拆分微处事

我们无法在单系一切中找到可以被明明拆分成微处事的部门。于是，我们随意挑了几个规模模子，获得了一个必要建设的微处事清单，但在着手调研时，我们发明这些微处事之间存在许多共享的营业逻辑和隐式耦合。我们又进一步实行将这些微处事再细分为更小的处事，但这样却带来了 更多耦合、无处不在的动静总线，以及隐藏的通讯大爆炸——一个处事必要与十个乃至更多的微处事通讯。

这些微处事之以是耦合得很锋利并且难以拆分，首要是由于我们原先的单体架构只为一个营业提供处事。UI 应用措施的首要计划方针是将第三方基本应用措施的数据聚合在一路。为了利便用户，我们建设了跨规模的事变流，将分手的成果聚合在一路。

在整个进程，我们并没有正确领略应该奈何拆分微处事，并且低估了正确选择微处事界线的重要性。假如凭证我们的方法来拆分，那么实现一个尺度的成果必要同时修改多个微处事。每个成果都必要差异的微处事团队参加开拓，这就导致单个微处事无法只由某个团队认真。

差异团队共享微处事

我们约莫有 12 名开拓职员在做这件工作，漫衍在两个成果团队和一个支持团队。但我们认真的事变是颠簸的，一个团队不会只认真开拓应用措施的某个部门，两个团队同时修改统一处代码的环境并不少见，以是不能将某个微处事的全部权赋予某个团队。

康威定律指出，软件架构将以一种与组织和团队布局相同的方法增添。假若有许多独立的团队，这些团队可以认真差异的营业存眷点，那么可以思量回收微处事架构。可是，假如只有很少的团队，而且开拓的是同样的成果，那么照旧不要这么做。

平台还没做好筹备

由于有各类百般的题目，至少在 6 个月内，我们必需同时陈设旧的单体应用和新开拓的微处事，无法行使与微处事相干的器材，譬喻容器、Kubernetes、处事总线、API 网关等。没有这些器材，微处事之间的通讯变得越发坚苦。

因此，我们在每个微处事中都包括了共享逻辑。由于未能正确拆分，以是呈现了许多一再事变。譬喻，有一个出格伟大但很重要的营业逻辑，我们不得不在四个微处事中复制、粘贴和维护。

前路迷茫

开拓团队只对接下来 6 个月做什么有大致设法，除此之外就没有其他对象了。营业常常产生变革，需求溘然产生变革的环境并不少见。这种不确定性使微处事的开拓变得越发坚苦，由于无法猜测会呈现什么新状况。譬喻，微处事之间的相关和耦合会一向增添吗?几个月后，我们需不必要花时刻把它们从头毗连在一路?

本年早些时辰，我们已经试着举办微处事观念验证，但跟着营业需求的变革，这被反对了。

时刻太紧

（编辑：湖南网）

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