不要拖延科罚问题松岛枫av，直到它们变得太大而难以不停。

译自HowToFailatMicroservices，作家AshleyDavis。

莫得东谈主但愿微行状失败。莫得东谈主一运转就盘算这么作念。但鉴于微行状的难度和咱们可能失败的惊东谈主方式，这很容易作念到。

我频繁是微行状的成见者，至少在它们有必要且实施高超的情况下。频繁，我会栽种更低廉、更顺利、更有用地使用微行状的设施，但在本文中，我念念采选不同的方式。我将描写咱们可能在微行状方面失败的多种方式。临了，咱们将望望咱们不错作念些什么来开脱咱们创造的（或者可能是咱们摄取的）地狱。

微行状失败的无数种方式

在开荒中，有好多种失败的方式。以下列表是笔据该领域的陶冶编制的。这些齐是来自真实分娩哄骗形态的真实示例。

我将把通盘这些问题齐与微行状相干起来。但我承认，许多只是无为的开提问题，被微行状引发到了11级。让咱们运转吧。

蔓延科罚问题

在开荒过程中，尤其是在试图快速转移时，你可能会忍不住将非必要问题的科罚推迟到以后。

你恭候科罚基础设施、自动化部署、自动化测试、代码重用等问题的时分越长，这些问题就越树大根深，也越难科罚。跟着你推广微行状的数目，你际遇的任何问题也会随之推广。

陆续出现的问题最终可能会跳跃你的团队科罚问题的才略。此时，你可能会挟恨团队资源不及。淌若你能早点科罚最环节的问题，而不是让它们失控，就好了。

使用分享数据库

淌若唯唯一个对于使用微行状的固定例则，请幸免使用分享数据库。

但也许你错过了备忘录，目下你通盘的微行状齐使用消除个数据库。

目下，你没独特据封装，行状之间高度耦合，单点故障，以及可推广性瓶颈。

恭喜你，你绕过了微行状的许多上风。

尽可能地松开你的微行状

这是微行状，是以咱们应该尽可能地松开它们，对吧？

你可能可爱笔据手艺问题（而不是业务问题）来建模你的行状。举例，你不错为每个数据库查询创建一个微行状（我践诺上见过）。

你可能以为每个数据库查询一个微行状是分离你的数据问题的好设施，但随后你就会念念起这是不可能的，因为你通盘的行状齐分享一个数据库。

将微行状建立在手艺问题上会导致不必要的微型行状，保重老本陆续加多。跟着行状数目的减少，你需要更多行状身手使其宽泛责任——这使得通盘哄骗形态比践诺需要的更复杂，因为你的行状比践诺需要的更小。越来越多的行状会导致通讯旅途呈指数级增长，收集运营老本也大幅加多。

微行状应该笔据业务需求建模，而不是手艺问题。每个行状齐应该具有业务所需的边界，而不是更小。是的，这意味着你的行状将具有多样边界，但那又怎样——莫得东谈主关怀你的行状有多大或多小。

使用手动部署

当有东谈主运转使用你已建立的微行状哄骗形态，你发现我所在他们解释手动部署每个微行状的讲解时，你应该知谈事情进展不得手。

但也许你莫得相识到失误易发的手动部署对开荒过程的负面影响。你的开荒东谈主员将顿然时分在不错幸免的问题上。

自动化部署是咱们必须在唯独少数微行状时就作念好的事情之一。比及你领独特百个微行状时，就会变得愈加困难。

同步部署通盘微行状

你需要完全约束你的微行状哄骗形态的部署吗？你是否但愿部署像单体哄骗形态一样责任？创建一个部署管谈（淌若可能的话，手动管谈），该管谈不错同方式批量部署通盘微行状。很棒的责任。目下，您领有了一个散播式合座。这有点像两者的最坏情况，它松弛了微行状最艰辛的上风之一。当微行状不错孤苦部署，而不是一次性一谈部署时，它会使开荒东谈主员和团队分离，允许他们以我方的速率发布更新，而不会受到部署过程或其他团队的影响。

孤苦的微行状部署速率很快，也不错快速回滚。另一方面，锁步部署速率很慢。每次测试和部署齐需要更长的时分，而且在出现问题时回滚愈加困难。

以锁步方式组织、测试和部署所需的时分会缩短您实行抓续部署的才略。尽管如斯，我猜念念快速反映客户需求的才略对您来说并不艰辛。我但愿您有一个很棒的QA部门。（但似乎莫得东谈主再有QA部门了）。

使测试变得困难松岛枫av

使您的开荒团队难以测试他们的改换，以真实费劲他们的恶果。虽然，在复杂的云环境中责任时，很容易堕入这个陷坑，尤其是在为了完成责任而省俭测试时分的情况下。

在土产货复制复杂的设立可能尽头困难，因此很容易失去在土产货测试的才略，并养成必须先部署身手测试代码改换的坏风气。

土产货测试代码改换是快速开荒速率所必需的。当您的开荒东谈主员被动通过将其（手动！）部署到开荒、QA、测试或登台环境来测试他们的代码时，他们的速率会尽头慢。

通过土产货测试，开荒东谈主员不错进行代码改换独立即看到末端，从而获取快速反馈，并允许快速实验以测试新念念法并快速找到问题的科罚有谋略。开荒东谈主员在云环境中测试他们的代码必须资格通盘部署过程，插入系列即使是轻微的实验性代码改换亦然如斯。在云中（在运行在别东谈主的诡计机上而不是他们的土产货开荒诡计机上），调试代码中的任何问题也会变得愈加困难，更毋庸说由您的手动部署过程引起的问题了。

土产货测试对于快速开荒速率至关艰辛，但还不够。开荒东谈主员还需要探询一个现实的访佛分娩的测试环境。理念念情况下，他们应该粗略在与客户疏导的环境中重现来自客户失误陈述的问题。假定出于安全或狡饰原因，这是不可能的。在这种情况下，他们需要系统和基础设施来尽可能接近地（减去任何私东谈主或个东谈主客户信息）并尽快地复制分娩环境。

淌若您的开荒东谈主员无法简短地重现客户问题，那么客户际遇的问题与开荒东谈主员追查的问题之间将存在浩繁的脱节。淌若开荒东谈主员无法准确可靠地看到客户际遇的践诺问题，他们将破耗时分追查失误的问题。

只关注单位测试

一些团队似乎只知谈单位测试，这很奇怪。他们不知谈还有多样万般的测试手艺吗？

淌若锤子是你的唯一用具，那么每个问题看起来齐像钉子。淌若您只知谈单位测试，那么淌若您只使用测试范围内的多样测试手艺，从单位测试到端到端测试和手动测试，您将调试许多正本不错幸免的问题。

此外，尽管运行速率很快，但单位测试是最耗时的测试编写和保重。我以为单位测试应该保留给业务逻辑。但这意味着将您的业务逻辑从通盘手艺和演示问题中索取出来——这可能是您莫得作念的事情。淌若您念念对任何东西进行单位测试，您可能正在尝试对通盘东西进行单位测试，即使是不值得进行单位测试的代码亦然如斯。

当您将就您的开荒东谈主员将通盘时分齐花在单位测试上时，他们根蒂没或然分去探索更省时的测试形态。有用地使用集成测试、端到端测试、协议测试和快照/输出测试不错以更少的勤勉获取更多覆盖范围。

手动测试仍然很艰辛，我念念说，在莫得为您的产物制定手动测试权术的情况下，您不应该尝试使用自动化测试。投资一个每个东谈主齐不错使用的手动测试权术尽头低廉和容易；它比自动化测试低廉得多。就我个东谈主而言，即使您在通盘自动化测试范围内取凯旋利，我仍然以为它仍然是必要的。

用具不及

任何微行状哄骗形态齐需要普遍的用具。咱们需要用于构建、部署、不停行状、基础设施、测试、调试和可不雅察性的用具。假定您在这些领域短缺饱胀的用具。在这种情况下，它会导致对您的开荒团队形成浩繁的但难以察觉的损耗，他们将在昏昧中摸索，只是为了弄明晰发生了什么，更毋庸说如何科罚问题了。

或然，当用具不存在时，咱们也需要构建用具。幸运的是，大型公司还是为咱们完成了大部单干作，而且有好多好的用具存在（Postman和Backstage齐是例子）。然而，当大型公司莫得为咱们提供行状时，或者淌若咱们是一家大型公司，或者淌若咱们只是试图作念一些不同或特有的事情，而一些定制用具会有所匡助……咱们需要手段和能源来我方构建这些用具（淌若咱们友好，不错将其动作开源供其他东谈主受益）。

手段不及

除了饱胀的用具以外，咱们还需要在使用用具、实践开荒和设想散播式哄骗形态方面具备饱胀的手段。

微行状凯旋需要一种追求手艺超卓并践行抓续更正的文化。淌若您莫得这种文化，您可能会难以将开荒东谈主员擢升到散播式哄骗形态所需的熟习进度。

使一切尽可能复杂

当您使一切尽可能复杂（架构、代码、开荒历程）时，您会给开荒东谈主员带来融会职守，导致他们在琐事和勤苦的责任上顿然不必要的时分。

尽可能多地领有微型行状，以便任何给定的编码任务必须分散到多个行状中。确保每个行状中的代码分散，即使进行最小的改换也需要罢职跨文献的交互收集。使用损坏且有罅隙的抽象，以便这些抽象带来的任何上风齐被它们带来的复杂性所隐蔽。

当您的历程不必要塞复杂时，您的开荒团队将参与一种“历程戏剧”，其中凯旋地罢职历程的复杂章程胜过为客户和企业提供价值。淌若您的开荒东谈主员老是很忙，但险些莫得产生真实的价值，也许是时候重新评估您的历程是如何运作的了。

但愿，我更可爱肤浅的事情。任何当代哄骗形态齐倾向于复杂性，但这并不料味着咱们不可尽可能地追求肤浅性。咱们应该积极不停复杂性，将其阐述为更肤浅的部分，并在使事情更肤浅时使用高超的抽象。

信不信由你，微行状旨在不停复杂性。使用恰当，微行状不会形成特殊的复杂性；它们有助于处理本来就存在的复杂性。然而，淌若使用不当，您的问题将加重。

不要写任何东西

笔据敏捷宣言，责任代码频繁比文档更受接待。这难谈不是一个不写文档的好借口吗？

当哄骗形态变得复杂时，当莫得东谈主知谈它如何运作时，当难以贯通如何测试它时，或者当您但愿新职工玩得抖擞时，文档可能尽头谨慎。但前提是它必须一致。

莫得文档，新斗争哄骗形态或特定微行状（或几个月莫得斗争过这些部分）的开荒东谈主员必须反向工程代码身手了解如何更新和测试它。让您的开荒东谈主员一次又一次地这么作念并不有用。任如何期创建或更新文档的开荒东谈主员齐会匡助改日的开荒东谈主员（以及他们改日的我方）每次复返子系统或行状时齐能更快地启动和运行。

唯独当文档成为您文化中不可或缺且有价值的一部分时，您身手在文档方面取凯旋利。

不要制定改日权术

最终，确保您的哄骗形态演变成一个散播式泥球的最好设施是，不要制定可行的改日权术。

不要制定开荒计策。不要对架构有愿景。不要制定不停手艺债务的权术。事实上，不要将权术传达给团队。不要从团队何处征求对于架构、代码和开荒历程存在问题的反馈。

虽然，莫得权术的顶点反面也可能通常厄运。一个可爱微不雅不停的约束狂架构师可能会以其他方式形成灾难。

咱们需要的是介于以下两者之间的东西：一个陆续适应现实并从寰球中获取新输入的稳健架构愿景，以及一个为开荒东谈主员提供作念出决策和科罚日常问题所需的范围，同期取得抓续进展的愿景。

咱们需要微行状吗？

我还是劝服你消除微行状了吗？望望微行状失败的多样方式（领导一下：我最近在现实中看到了通盘这些失败），你可能会念念知谈为什么有东谈主会推敲使用微行状。

这是一个有用的不雅点。微行状将破耗好多。在采选它们之前，咱们必须粗略为它们提供合理的旨趣。淌若咱们不可讲解注解其益处跳跃老本，那么咱们就莫得旨趣使用微行状。咱们还需要一支领有微行状所需的手段、用具和架构学问的团队。

也即是说，微行状提供了许多克己和有用的用例。公司还是在使用微行状，而且正在以很大的方式失败。使用单体架构可能分歧适，从微行状调换回单体架构可能不可行。咱们还能作念什么？

逃离微行状地狱

淌若咱们正在遭受上述任何或通盘失败，那么还有但愿。有一些具体的设施不错科罚这些问题。

领先要贯通的是，这不短长此即彼。这不单是是微行状与单体架构的问题。在这两个顶点之间存在一个采纳范围，将我方定位在中间某个位置不错让咱们获取微行状和单体架构的最好上风。

第二点需要细心的是，除非组织中符合的级别提供支抓，不然任何事情齐不会改变。或然，这意味着你需要劝服你的共事开荒东谈主员改变的必要性，但更有可能的是，你需要劝服架构师和司理存在问题（或者好多问题，具体情况视情况而定）。淌若高层蛊惑不相识到团队濒临的问题，或者不睬解改变的必要性，那么你鞭策改变的勤勉很可能会让你堕入窘境，而不是匡助团队。

也即是说，以下是一些科罚上述失败的设施：

主动勤勉改善团队的开荒东谈主员体验。尽可能简化和自动化开荒历程。尽可能地赋予你的开荒东谈主员自主权。倾听他们的反馈，并允许他们科罚他们有才略科罚的问题。自得、高效、有用且插足的开荒东谈主员是结束咱们许多更正的环节。

尽早科罚问题，淌若不错的话。不要比及你还是构建了数百个微行状才运转举止。但淌若不是，你必须每天留出时分来更正以下领域：可部署性、可测试性、可调试性和可不雅察性。

基于业务需乞降客户问题对你的软件进行建模；不要基于手艺问题进行建模。不管它目下处于什么景色……在进行改换之前，以正确的方式对任何改换或添加进行建模。

不要让你的行状太小。使用建模来坚信符合的大小，而不是试图使它们尽可能小。推敲合并嗅觉太小或单独无法发达饱胀作用的关联行状。

自动化部署必须完全自动化且极其可靠。淌若不是，这是你应该领先设立的事情，这么团队就不会在可幸免的部署问题上顿然时分。

自动化测试对于推广多个行状的开荒尽头艰辛，我不单是是在驳斥单位测试。学习你能学习的每种测试手艺，并确保团队正在使用最有用的测试套件。为特有的用例构建我方的测试用具，但唯独在托福的价值跳跃构建它们的老本时才这么作念。

重建你的土产货测试才略。淌若你的开荒东谈主员只可在云中复制软件进行测试，那么你将堕入严重窘境。插足必要的时分，让你的开荒东谈主员粗略在提移交码之前，在他们的土产货诡计机上可靠地测试他们的代码改换和添加。淌若系统自己太大而无法在土产货进行测试，那么你必须找到在模拟或模拟其余部分的同期生成系统部分的设施。

不管你是否擅长测试和调试问题以及找出如何科罚问题，这齐会占用普遍的开荒东谈主员时分。淌若你莫得积极地提高哄骗形态的可调试性和可不雅察性，它很可能会朝着失误的所在发展。购买或构建你需要的用具。让你的开荒东谈主员探询分娩或访佛分娩的环境。找到让你的开荒东谈主员简短地复制客户问题的设施，以便为开荒东谈主员提供最好的契机来寻找正确的问题。

不要发怵文档。以与代码疏导的关注度和观赏度来审查和奖励文档。培营养享学问的文化。相识到文档不单是是在维基中记载内容；它不错采选多种形态：

每个仓库齐有高超的描写和自述文献。

可读的代码和代码示例。

测试用例和测试权术。

架构决策记载。

详备的带注目的图表。

里面博客著作。

为团队录制视频供以后不雅看。

勤勉打造手艺超卓和抓续更正的文化。凯旋使用微行状需要使用许多（很棒的）用具，咱们需要一个在散播式哄骗形态开荒各个方面齐领有高手段水平的团队。

通过勤勉排斥不值得的复杂性来积极简化您的哄骗形态。陆续勤勉减少或排斥不必要的复杂代码、架构或历程。这减少了开荒东谈主员日常责任中的融会职守：您但愿他们科罚客户问题，而不是来自不必要复杂性的问题。重构（由可靠的测试支抓）应该是每个开荒东谈主员的日常庆典。淌若他们莫得这么作念，您就不是朝着更顺利、更易于不停的系统前进。相背，您正在走向一个越来越复杂和难以不停的系统。

最终，咱们必须问我方：微行状是否让咱们的开荒东谈主员更容易安全可靠地将有匡助且有价值的功能和设立形态插足分娩？

微行状架构的方针是缩短部署风险。它通过将咱们的部署分袂为小块来结束。由于每个块齐很小，因此更容易贯通、更容易测试，也更容易孤苦部署。当出现问题时，也更容易回滚。

相背，淌若微行状使您的部署变得愈加困难，则意味着您可能以失误的方式使用它们，而且您可能犯了一些或通盘我轮廓的失误。淌若您不肯意投资以使微行状宽泛运行，那么使用单体可能是您的正确采纳。淌若这不可行，请推敲使用夹杂模子，其中包含多样行状大小，从单体到微行状，具体取决于您的需求。

确保凯旋的最艰辛设施

淌若您莫得对哄骗形态有浓烈的愿景或权术，则可能意味着您正在野着失误的方上前进。或者更糟的是，每个开荒东谈主员齐有一个单独的所在。

您领有的任何权术齐必须陆续更新以适应陆续变化的现实。让团队参与创建和更新权术；这是让每个东谈主齐参与其中的最好方式。将权术传达给利益关联者，并确撑抓理层了解其艰辛性。

每个东谈主齐必须参与进来。必须有东谈主为架构的愿景代言，并让每个东谈主齐答允它。只是记载现存架构是不够的；需要有一个改日权术，而且需要由一个不怕深远系统中枢并了解其责任旨趣的东谈主来带头。更宏不雅的学问是从更初级的学问中构建出来的。

本文在云云众生（https://yylives.cc/）首发松岛枫av，接待全球探询。