咱们为什么停用微供职？

　　正在 Botify，咱们工程团队的主旨代价观之一是 ownership。咱们付与工程和产物团队自立权以及灵敏性，让它们具有自身的项目并告终这些项目。然而，跟着咱们正在更大的技能栈上作事，团队界限也越来越大，咱们起先碰到极少合于奈何共享作事成绩的题目。

　　2016 年岁终，咱们思付与工程师和产物司理更多的 local ownership，从而能速捷轻松地将他们的产物和技能栈参加运用。为此，咱们决心将 Django 操纵次第拆分为微供职。

　　这个故事叙述了咱们是如何打击，以及此刻咱们为何又将这些供职迁回到单体操纵。同时，咱们还会花些时辰来分享咱们的体味教训。

　　正在深刻商榷前，我思夸大下：本文的宗旨并非责怪微供职。正在 Botify，咱们的理念是“运用最适合的东西”——咱们以为，微供职并非目前办理咱们题宗旨妥善东西。

　　最初，简陋先容下 Botify 的史乘。Botify 于 2012 年正在 Python/Django 技能栈上创修。到 2016 岁首，全盘 Botify 平台都是通过咱们 Django 操纵次第的负载平衡集群供给供职。当时，咱们有一个约莫 15 人的产物和工程团队。

　　抬高开采速率：咱们欲望节减前端和后端之间的依赖联系，并补充 local ownership，从而将开采主体节造为一个幼团队；

　　同一技能：咱们正在巴黎雇用 Python/Django 工程师越来越多障碍，因此咱们就思，前后端都同一运用 JavaScript 会让雇用作事更容易，由于咱们正在转向“全栈”JavaScript 云云一个简单的脚色。

　　咱们决心从身份验证和授权栈入手杀青第一个微供职。咱们以为，该当从幼处动手，将 Django 操纵次第现时的逐一面效力蜕变到微供职中。咱们创修了一个幼型的 JavaScript 团队，担当杀青 NodeJS 后端，用于管理用户及其帐户和权限。咱们称之为 Customer Success。

　　当你像咱们相通，正在人工身分的驱动下做出技能决议时，你很速就会碰到题目。新团队的机合和流程很难与现有的团队并行不悖。因为特点是独立开采的，很速就涌现了学问分裂。微供职内部的东西没法共享，而跨栈代码审查的缺失让咱们感到遗失了 ownership。

　　你也许曾经谨慎到，正在上面的架构中，微供职 Customer Success 并非全部隔断。从单体到微供职存正在后端到后端的通讯，反之亦然。这并不全部是坏事（类似还很常见），但这照样会低重职能，并正在两个供职之间创修依赖联系。从悠长来看，这还意味着更杂乱的机造，如 circuit breakers 和优美的供职降级（为保障寻常运转时辰和可用性）。

　　咱们还看到，正在该形式下，咱们重要的联系数据库是共享的。正在数据库内部，极少表被映照到 Django 和 Express/Sequelize 的模子。换句话说，篡改共享表的形式必要对微供职和单体举办同步篡改。这是由倒霉的界限隔断所导致的。

　　跟着时辰的推移，咱们学会了奈何牢固地构修和铺排咱们的 Django 操纵次第，不过，对付每个新的技能栈，咱们必需从头独揽这个流程。固然正在微供职情况中，独立铺排是一个主旨上风，但与铺排微供职比拟，咱们照样对铺排单体更有决心。然而，咱们花了较量少的时辰就为咱们的微供职杀青了牢固、通畅的自愿化铺排。

　　正在平日作事中，咱们碰到的题目越来越多，为了让架构更有用，咱们必要不时地篡改办理计划。时代，咱们针对 Django 技能栈做了极少作事，改正代码、笼盖率、可测试性、依赖联系和职能。

　　微供职技能栈是从现时风行的框架和开采团队最熟习的框架当拣选的。然而，正在 Botify，咱们信任，要为适合的作事选取适合的东西：适合的东西不愿定是最有名的东西，也不愿定是咱们曾经晓得的东西。

　　咱们确定，是期间有劲地（从头）斟酌咱们的微供职架构和 Customer Success 后端了。

　　鉴于每天都要正在 JavaScript 身份验证后端和 Django 模块之间频仍地来回切换，咱们把工程师们蚁合正在一同，量度该架构的优偏差以及潜正在的迁徙本钱。

　　咱们做出斗胆选取，将身份验证后端从头到场到 Django 单体。