写点什么

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

  • 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:498066
用户头像

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

关注

评论 2 条评论

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

闲下来的学习时光

Java 程序员 后端

阿里一面就凉了:MySQL+多线程+Redis+算法

Java 程序员 后端

阿里三面:CAP和BASE理论了解么?可以结合实际案例说下?

Java 程序员 后端

一个简单的UserCase,带你认识openLooKeng的行级权限控制

LooK

大数据 openLooKeng

阿里P8大牛整理的300页图解网络知识+计算机底层操作系统

Java 程序员 后端

阿里Redis最全面试全攻略,读完这个就可以和阿里面试官好好聊聊

Java 程序员 后端

阿里P8面试官梳理的2020年999道大厂高频Java面试题(附答案)

Java 程序员 后端

技术为本,中科柏诚致力于打造高效供应链金融平台

联营汇聚

闭关2个月肝完Java7大核心知识(分布式+JVM+Java基础+算法

Java 程序员 后端

阿里Java架构师春招面试高频600题:集合+JVM+Redis+并发

Java 程序员 后端

阿里P8大佬终于把自己珍藏多年581页JavaJDK9学习笔记分享出来了

Java 程序员 后端

阿里P8直接甩我一份Java笔记、面试宝典,当我看到目录的一瞬间,简直怀疑人生!

Java 程序员 后端

阿里P6程序员的Java之路-或许起点不高,但我从未停止我的脚步

Java 程序员 后端

阿里P7告诉你SpringBoot如何防止重复提交?

Java 程序员 后端

阿里一面,给了几条SQL,问需要执行几次树搜索操作?

Java 程序员 后端

阿里P8十年摸爬滚打,告诉你上古程序猿为何反对使用Redis?

Java 程序员 后端

阿里P8架构师汇总了史上101个最牛逼的Java技术点

Java 程序员 后端

阿里二面被问16道 volatile 问题,玩命补充jvm、多线程、高并发

Java 程序员 后端

Python爬虫120例之第20例,1637、一路商机网全站加盟数据采集

梦想橡皮擦

11月日更

阿里P8大牛透出,入职阿里必备12套Java面试题,适合从校招到社招

Java 程序员 后端

用JavaScript访问SAP云平台上的服务遇到跨域问题该怎么办

汪子熙

JavaScript SAP 11月日更 SAP微信集成

安装企业级的dokuwiki文档系统

小鲍侃java

11月日更

阿里P8级大神经验分享,怎样成为一个优秀的架构师?(1)

Java 程序员 后端

鸿蒙轻内核源码分析:虚拟内存

华为云开发者联盟

鸿蒙 内存 虚拟内存 OpenHarmony 轻内核

使用Eclipse连接SAP云平台上的HANA数据库实例

汪子熙

数据库 Cloud SAP 11月日更

我终于知道,中国互联网是怎么弯道超车,干翻美国了!

博文视点Broadview

阿里-美团-字节面试官必问的Mysql锁机制,你真的明白吗

Java 程序员 后端

阿里2020首发一百多道Java高级岗面试题(含答案)

Java 程序员 后端

华为全球技术服务引领行业数智创新,共赢未来

阿里三面面试题:分布式服务注册中心该如何选型?我快哭了

Java 程序员 后端

一周信创舆情观察(11.1~11.7)

统小信uos

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