写点什么

单体到微服务是一个演化过程,别在一开始就过度设计

  • 2019-01-22
  • 本文字数:1905 字

    阅读完需:约 6 分钟

单体到微服务是一个演化过程,别在一开始就过度设计

大多数应用程序(可能是其中的 90%)采用了单体架构。为了避免过度工程化,我们应该从一个简单的架构开始,并根据需求进行演变。在 Reactive Summit 2018 大会上,Randy Shoup 在演讲中分享了他与小公司一起,逐步发展成为大型全球性互联网公司的经验,以及它们的架构是如何进行演变的,并从 IT 专业的角度为创办新公司或推出新产品提出了一些建议。


Shoup 曾在 eBay、谷歌和 Stitch Fix 工作,目前是WeWork的工程副总裁。他例举的第一个例子是 eBay,从 1995 年开始,作为一个为期三天的周末项目,不是作为业务的概念证明(PoC),而是为了弄清楚是否有可能在网上做一些有趣的事情。今天,他们正在对基础设施进行第 5 次完全重写,Shoup 将该公司的架构描述为多语言微服务集,并补充说 Twitter 和亚马逊都经历了类似的演变。


Shoup 认为,从某种形式的单体架构开始,最后得到一组微服务,这是大公司的常见演变模式。Shoup 还指出,这种模式包含了两个部分——没有人从一开始就采用微服务架构,而是达到一定规模后才走向微服务。


Shoup 所提到的公司都非常庞大,他指出,这些公司的架构并不完全适用于大多数其他公司。大多数应用程序采用单体架构就足够了,Shoup 建议,在构建新应用程序或系统时先从简单的架构开始,并根据需要改进架构。他说:


如果你到后面不后悔早期的技术决策,那么你之前可能过度工程化了。


Shoup 认为,大多数公司和产品的常见演化曲线包括构思和启动阶段,分布式系统可能还包含伸缩阶段,以及优化阶段:



在构思阶段,我们不应该考虑架构问题,而只是进行原型设计。为避免过度工程化,我们应该不断问自己:“我们要解决什么问题?”这个阶段的目标是尽可能快地探索解决方案,并以最低成本:


  • 找到商业模式;

  • 找到契合的产品市场;

  • 吸引我们的第一批客户。


他建议我们,如果有可能,尽量避免使用任何技术,但可以使用谷歌广告来验证是否有用户点击,或使用原型或 Excel 电子表格。


进入启动阶段,目标变成了满足近期的客户需求,并尽可能以低成本来实现目标。在这个阶段,团队通常由 4 到 6 个人组成。他们的工作时间很短,可能只需要 3 到 4 个月,因为在这个阶段往往很难预先知道要构建哪些功能。我们只需要少量足以让我们前进的架构。Shoup 强调,它个阶段不要考虑伸缩性问题,我们应该使用简单而熟悉的技术,这绝对是一个单体架构——单个应用程序和单个数据库。基础设施应该尽可能小,而且不需要自己构建。相反,他建议使用平台即服务(PaaS)或类似的技术。


在这个阶段使用单体架构的优势包括:


  • 简单;

  • 速度快,因为它只有进程内延迟;

  • 你将获得单个构建部署单元;

  • 节省资源。


除了缺乏可伸缩性和存在单点故障之外,单体架构的主要缺点是缺乏模块化能力。虽然可以进行模块化,但它需要额外的编程和团队纪律。Shoup 指出,在这个阶段,这些都不是问题。但他认为,当我们需要为扩展做准备时,单体架构的组件化或模块化就变得有必要了。这将为在未来修改或替换服务提供便利。


对于我们何时需要重构单体,Shoup 列出了一些指标:


  • 速度:由于耦合和缺乏隔离,导致交付速度减慢;

  • 伸缩:垂直伸缩不再有效,或者系统的不同部分需要独立伸缩;

  • 部署:系统不同部分的演化速度不一样,因此需要独立部署。


在进入扩展阶段时,我们的目标是保持业务的快速增长以及应用程序能够正常运行。在组织方面,我们现在通常会增加团队数量,并扩大工作时间范围。通常还需要引入可重复的过程。


在技​​术方面,扩展阶段通常意味着转向可扩展的技术。通常,我们开始从单体中分离出服务,并且尝试减少单个数据库的负载,例如为某些数据创建只读副本。通常也会将一些服务(如支付和计费等特殊服务)分离出来,并引入事件队列或消息总线。


Shoup 认为,这个时候通常也需要考虑我们是否应该将单体分解成小型的独立组件,也就是微服务。我们还必须考虑现在使用的单个存储器是否仍然合适。在纽约 2017 QCon 大会上,Shoup 展示了如何将单体应用程序增量迁移为微服务和几个独立的存储。


The Art of Scalability”一书描述了一种三维可伸缩性模型(AKF Scale Cube),其中三个轴分别代表了不同类型的缩放:


  • X:水平复制和克隆;

  • Y:功能分解和分割(微服务);

  • Z:水平数据分区(分片)。


最后一个是优化阶段,Shoup 强调,这个阶段是成功的标志。此时的目标是保留功能,使用更少的资源,可能会减少团队。工作时间范围更长,可能是 2 到 5 年。


Shoup 总结说,在这种情况下,进行重构其实是一件好事:


重新构建系统是成功的标志,而不是失败。


业务发展得很好,你也有资源去做重构。这并不是说你一定要进行重构,而是你已经到了需要进行重构的时候。


查看英文原文https://www.infoq.com/news/2019/01/rearchitecture-system-success


2019-01-22 14:497893
用户头像

发布了 731 篇内容, 共 432.3 次阅读, 收获喜欢 1997 次。

关注

评论 2 条评论

发布
用户头像
有些是为了练练手或绩效而引进微服务
2019-02-01 14:34
回复
用户头像
很多公司根本就不需要分布式,不需要微服务,对单体应用做良好的设计,在需要的时候水平伸缩足以应对了。
2019-01-23 09:40
回复
没有更多了
发现更多内容

京东T9裂墙力荐的82万字spring cloud微服务和分布式系统实践文档

Java 程序员 后端

从 0 到 1,带你解剖 MVP 的神秘之处,并自己动手实现 MVP !

Java 程序员 后端

从一次线下读书会获得的收获,linux使用教程

Java 程序员 后端

京东T7架构师手写的10万字Spring Boot详细学习笔记+源码免费下载

Java 程序员 后端

从Mybatis源码到Spring动态数据源底层原理分析系列一、Mybatis初始化源码浅析

Java 程序员 后端

互联网架构“高并发”到底怎么玩,用Elasticsearch搞定日均1亿订单查询

Java 程序员 后端

五分钟看穿Java并发相关概念,并发原来如此简单,linux学习步骤

Java 后端

京东面试,这个问题让我与50万擦肩而过,帮忙看看,mysql下载教程window10

Java 程序员 后端

什么是接口的幂等性,如何实现接口幂等性?,java微服务架构视频下载

Java 程序员 后端

今年,我在字节跳动面试了九次【已意向书,mongodb入门pdf

Java 程序员 后端

CANN 5.0黑科技解密 | 算力虚拟化,让AI算力“物尽其用”

华为云开发者联盟

AI 算力 CANN 昇腾 算力虚拟化

Vue进阶(幺伍伍):vue-resource 拦截器 interceptors 使用

No Silver Bullet

Vue vue-resource 10月月更

人到中年的焦虑,Java面试第一问就是做过什么最有难度的项目

Java 程序员 后端

人工智能 - 语音识别的技术原理是什么,Java理论知识思维导图

Java 程序员 后端

什么神仙笔记!阿里P9用39实例+1项目讲明白了Spring Cloud家族

Java 程序员 后端

什么?这个岗位薪资秒杀一众程序员?,java技术面试常见问题

Java 程序员 后端

京东前端面经(123面详细),进阶学习工作最全指南

Java 程序员 后端

京东十年T8架构师手撕MySQL:手写666页核心知识,超85,java在线编译器实现原理

Java 程序员 后端

从Java小白到拿到30k offer,分享自己的学习路程,java基础案例教程pdf百度云

Java 程序员 后端

架构实战营-毕业总结

王晓宇

架构实战营

从小公司跳槽到阿里,靠着刷多套面试题,成功拿到蚂蚁金服P7Offer

Java 程序员 后端

五位阿里大牛联手撰写的《深入浅出Java多线程》,java开发视频直播

Java 程序员 后端

五分钟带你了解Seata分布式事务,java基础菜鸟教程txt

Java 程序员 后端

从单体式架构迁移到微服务架构,3年Java开发工程师面试经验分享

Java 程序员 后端

从构建小系统到架构分布式大系统,Spring Boot2的精髓全在这里了

Java 程序员 后端

互联网寒冬下!疫情又遭滑铁卢!从裁员到斩获新offer我经历了什么

Java 程序员 后端

人性的弱点-读书笔记,java面试题大汇总小山博客

Java 程序员 后端

什么是 MySQL 全局锁、表锁、行锁,Java高级开发岗必问知识点

Java 程序员 后端

今日头条一面:十道经典面试题解析,Redis如何实现高可扩展

Java 程序员 后端

从Mybatis源码到Spring动态数据源底层原理分析系列二、Mybatis执行器源码分析

Java 程序员 后端

京东三面被惨虐:索引+数据库,kafka入门与实践epub

Java 程序员 后端

单体到微服务是一个演化过程,别在一开始就过度设计_架构_Jan Stenberg_InfoQ精选文章