江苏龙网

  1. 首页 > 人文 > >

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

作者|David翻译|平川策划|万佳
在Botify ， 我们工程团队的核心价值观之一是ownership 。 我们赋予工程和产品团队自主权以及灵活性 ， 让它们拥有自己的项目并完成这些项目 。 然而 ， 随着我们在更大的技术栈上工作 ， 团队规模也越来越大 ， 我们开始遇到一些关于如何共享工作成果的问题 。
2016年年底 ， 我们想赋予工程师和产品经理更多的localownership ， 从而能快速轻松地将他们的产品和技术栈投入使用 。 为此 ， 我们决定将Django应用程序拆分为微服务 。
这个故事阐述了我们是怎样失败 ， 以及如今我们为何又将这些服务迁回到单体应用 。 同时 ， 我们还会花些时间来分享我们的经验教训 。
在深入讨论前 ， 我想强调下：本文的目的并非指责微服务 。 在Botify ， 我们的理念是“使用最合适的工具”——我们认为 ， 微服务并非此刻解决我们问题的适当工具 。
开启微服务之旅首先 ， 简单介绍下Botify的历史 。 Botify于2012年在Python/Django技术栈上创建 。 到2016年初 ， 整个Botify平台都是通过我们Django应用程序的负载均衡集群提供服务 。 当时 ， 我们有一个大约15人的产品和工程团队 。
为什么选择微服务？以下两个目标促使我们评估在技术栈中使用微服务的可能性：
提高开发速度：我们希望减少前端和后端之间的依赖关系 ， 并增加localownership ， 从而将开发主体限定为一个小团队；
统一技术：我们在巴黎招聘Python/Django工程师越来越多困难 ， 所以我们就想 ， 前后端都统一使用JavaScript会让招聘工作更容易 ， 因为我们在转向“全栈”JavaScript这样一个单一的角色 。
梦想要大 ， 但要从小事做起我们决定从身份验证和授权栈入手实现第一个微服务 。 我们认为 ， 应该从小处着手 ， 将Django应用程序当前的一部分功能转移到微服务中 。 我们创建了一个小型的JavaScript团队 ， 负责实现NodeJS后端 ， 用于处理用户及其帐户和权限 。 我们称之为CustomerSuccess 。
InfoQ|我们为什么停用微服务？
文章图片
使用微服务的BotifyAPI架构概要痛点组织当你像我们一样 ， 在人为因素的驱动下做出技术决策时 ， 你很快就会遇到问题 。 新团队的组织和流程很难与现有的团队并行不悖 。 由于特性是独立开发的 ， 很快就出现了知识分化 。 微服务内部的东西没法共享 ， 而跨栈代码审查的缺失让我们觉得失去了ownership 。
隔离你可能已经注意到 ， 在上面的架构中 ， 微服务CustomerSuccess并非完全隔离 。 从单体到微服务存在后端到后端的通信 ， 反之亦然 。 这并不完全是坏事（似乎还很常见） ， 但这还是会降低性能 ， 并在两个服务之间创建依赖关系 。 从长远来看 ， 这还意味着更复杂的机制 ， 如circuitbreakers和优雅的服务降级（为保证正常运行时间和可用性） 。
我们还看到 ， 在该模式下 ， 我们主要的关系数据库是共享的 。 在数据库内部 ， 一些表被映射到Django和Express/Sequelize的模型 。 换句话说 ， 修改共享表的模式需要对微服务和单体进行同步修改 。 这是由糟糕的领域隔离所导致的 。
工具随着时间的推移 ， 我们学会了如何健壮地构建和部署我们的Django应用程序 ， 但是 ， 对于每个新的技术栈 ， 我们必须重新掌握这个过程 。 虽然在微服务环境中 ， 独立部署是一个核心优势 ， 但与部署微服务相比 ， 我们还是对部署单体更有信心 。 不过 ， 我们花了比较少的时间就为我们的微服务实现了健壮、流畅的自动化部署 。
在日常工作中 ， 我们遇到的问题越来越多 ， 为了让架构更有效 ， 我们需要不断地修改解决方案 。 期间 ， 我们针对Django技术栈做了一些工作 ， 改进代码、覆盖率、可测试性、依赖关系和性能 。


推荐阅读


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

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