江苏龙网

  1. 首页 > 人文 > >

InfoQ|我们为什么停用微服务？( 二 )


我们颠覆了最初驱使我们采用微服务的模式 。
微服务技术栈是从当前流行的框架和开发团队最熟悉的框架中选取的 。 然而 ， 在Botify ， 我们坚信 ， 要为合适的工作选择合适的工具：合适的工具不一定是最著名的工具 ， 也不一定是我们已经知道的工具 。
我们确定 ， 是时候认真地（重新）考虑我们的微服务架构和CustomerSuccess后端了 。
去而复返 ， 重回单体鉴于每天都要在JavaScript身份验证后端和Django模块之间频繁地来回切换 ， 我们把工程师们召集在一起 ， 权衡该架构的优缺点以及潜在的迁移成本 。
我们做出大胆选择 ， 将身份验证后端重新加入到Django单体中 ， 并重新生成了我们在2016年从Django转换到Node的API端点 。 为什么要重新采用以前的做法？下面是其中一些原因 。
为恰当的问题选择恰当的方案重要的是要记住我们的用例以及Botify为谁服务 。 我们的平台是一个企业级B2B服务 ， 帮助Web上最大的网站改善他们的SEO 。 我们的主要挑战在于对客户数据的分析 ， 而不是我们的流量：我们每个月要处理PB级的数据 ， 在一些长期运行的任务上 ， 比如爬取或处理数据 。
不过 ， 我们不需要巨大的面向用户的流量 ， 因为在撰写本文时 ， 我们的用户主要是Web上大型站点的SEO经理 。 处理用户相关数据的微服务架构旨在服务于高流量的B2C平台 ， 而Botify的挑战在于动态地聚合数以GB的SEO数据 ， 让其在几秒钟内可用 。 对大约一万名客户的元数据以毫秒为单位进行响应 ， 这项任务无需高度可伸缩的微服务架构 。 恰恰相反 ， 我们的后端到后端通信减慢了这些简单的检索过程 ， 花费了更多时间 。
共享资源意味着同步部署举个例子 ， 最近的一个项目是删除一个无人维护的依赖项 ， 该依赖项会将JSON数据库列作为文本处理 ， 以便利用PostgreSQL中内置的列类型jsonb 。
然而 ， 这些文本列是在两个代码库之间共享的 ， 逐步迁移非常麻烦 。 同步部署多个后端很容易出错 ， 尤其是在规模大并存在负载均衡的情况下 ， 这与微服务最初的好处背道而驰 。 在Botify ， 我们总是喜欢用这个警示性的故事来说明我们不喜欢同步部署 。 这是个有趣的故事 ， 如果你有时间的话 ， 可以一读 。
分离的代码库淡化了知识、ownership和联系微服务最初由少数人实现 ， 是为了保护新来者不受无人维护的代码库的影响 ， 同样的人处理了所有的演进 。 这种现象违背了我们的代码评审理念：任何人都能够评审并理解正在发生的事情 。 在Botify ， 我们喜欢开放式的工作方法 ， 这样 ， 团队中的任何人都可以查看所有代码并发表评论或提出建议 。 使用单独的技术栈、团队和语言 ， 这让我们失去了团队合作和严格评审给开发团队带来的许多好处 。
以上这些促使我们停用身份验证微服务并将其端点迁回Django单体的主要原因 。
停用微服务停用微服务非常简单 ， 有许多方法可供选择 。
我们希望在终止CustomerSuccess后端时 ， 所作的更改尽可能少 ， 这意味着要模拟微服务的行为 ， 在单体中逐个重写API端点并切换路由 。 这样 ， 更改只会影响API ， 而不影响前端 ， 从而避免可怕的同步部署或API版本控制 。
以下是我们停用微服务所采取的步骤：
识别路由：列出微服务提供的所有API路由 ， 确定它们的用途和目标 。 先处理简单的情况：有些路由可能没用 ， 或者没有必要 。
在目标后端创建路由：最麻烦的工作是在目标代码库中编写相同的逻辑 。 相同的输入 ， 相同的输出 ， 还要最小化切换风险 。
Y分支（Y-branch）调用 ， 比较结果：设置一个简单的分支系统 ， 使用两个后端并比较响应 ， 以发现不一致的地方 。
根据QA反馈 ， 进行修复：QA大量而广泛地审查逻辑 ， 以发现任何遗留的Bug 。
逐步扩大Y分支范围 ， 以使用新迁移的逻辑 。


推荐阅读


上一篇：有趣随风玩|今天首销的华为畅享Z究竟有何魔法？，三颗摄像头实现四摄功能

下一篇：太平洋电脑网|现在怎么样了？，继第一颗3D打印心脏问世后