• 日本核爆受害者启动环球航海 呼吁废核 2019-02-26
  • 武汉今秋迎11.5万名小学新生 “房户一致”优先 2019-02-26
  • 单体架构与微服务架构对比,为什么采用微服务架构

    管理员账号

    黑龙江时时时彩结果 www.fcyww.com 2018-11-14

    微服务架构给我们带来收益的同时,也会带来副作用,我们应该在什么阶段采用微服务架构?如何拆分微服务架构?拆分粒度多大比较合适?本文内容从问题开始,带你深入微服务架构的多个角落。

    1 单体架构与微服务架构

    就像很难用一个绝对的方式去判断架构好坏一样,在大多数场景下,我们也很难从一个外部的视角去判断服务拆分粒度的合理性,需要对上下文非常了解才能做出一个好决策。例如,团队规模多大,代码规模多大,有没有平台化,有没有工具链,是否需要持续交付,团队文化如何等。因此,一个外部的架构师是很难在短时间内将架构规划合理的,这需要一个过程,当真正了解这一切之后,不断权衡才能最终确定。在规划之前,有必要参考下面这张表,综合各方面的情况,最终做出决策。

    单体架构与微服务架构对比

    2 什么时候开始微服务架构

    产品初期优先选择单体架构。面对一个新的领域,对业务的理解很难在开始阶段就比较清晰,往往是经过一段时间之后,才能逐步弄清楚。很多时候,从一个已有的单体架构中逐步划分服务,要比一开始就构建微服务简单得多。另外,在资源受限的情况下,采用微服务架构风险较大,很多优势无法体现,性能上的劣势反而会比较明显。

    单体、组件化、微服务架构成本趋势,如下图。当业务复杂度达到一定程度后,微服务架构消耗的成本才会体现优势,并不是所有的场景都适合采用微服务架构,服务的划分应逐步进行,持续演进。产品初期业务复杂度不高的时候,应该尽量采用单体架构。

    单体、组件化、微服务架构成本趋势

    摘自Martin Fowler 博客的内容简单翻译如下。

    当我听到关于使用微服务架构的故事的时候,我注意到了一种通用的模式。

    1.几乎所有成功的微服务架构都是从一个巨大的单体架构开始的,并且都是由于单体架构太大而被拆分为微服务架构。

    2.几乎在所有我听说过从一开始就构建为微服务架构的故事中,最终都有人遇到了巨大的麻烦。
    在服务划分之前,应该保证基础设施及公共基础服务已经准备完毕??梢酝ü嗫乜焖俣ㄎ还收?,通过工具自动化部署、管理服务,通过服务化框架降低服务开发的复杂度,通过灰度发布提升可用性,通过资源调度服务快速申请、释放资源,通过弹性伸缩快速扩展应用。

    3 如何决定微服务架构的拆分粒度

    微服务架构中的微字,并不代表足够小,应该解释为合适。但是“合适”过于含糊,每个人理解的合适都不尽相同。实际上,有时候对于一个对业务理解不够深入,对团队情况又不是很了解的人,根本无权协助确定服务的粒度??銮?,就算本团队的架构师,也很难确定粒度。随着业务发展,开发人员水平的提升,粒度可能会发生变化。这是一个磨合的过程,一个不断演进的过程,没有绝对的对与错。

    如果实在找不到合适的依据,可以参考下表。决策占比是从通用的角度考虑,并不适用所有的情况,某些公司认为团队规模是决定性的,也有些公司认为架构演进是决定性的,还有些公司认为交付速度是决定性的,找到那个你认为的决定性因素,去做合理的拆分即可。

    微服务拆分粒度决策参考表

    本文选自《持续演进的Cloud Native:云原生架构下微服务最佳实践》,作者王启军,电子工业出版社10月出版。

    作者从全局视角出发,全面阐释Cloud Native 的关键技术,以及其衍生出来的工具、团队文化等核心要素,对于正在部署微服务架构或开展云原生业务的企业和组织而言,终于有了面向落地的务实参考和全面指导。

    读者评论

    相关博文

    • 为什么你会觉得微服务架构很别扭

      为什么你会觉得微服务架构很别扭

      管理员账号 2018-11-16

      很多系统迁移到微服务架构之后,并没有明显感觉到微服务架构带来的优势,反而觉得带来了更高的复杂度,王启军在《持续演进的Cloud Native》书中总结了七种微服务架构没能发挥出固有优势的原因,看看自己“中枪”了没! 1、用传统方式...

      管理员账号 2018-11-16
      132 0 0 0
  • 日本核爆受害者启动环球航海 呼吁废核 2019-02-26
  • 武汉今秋迎11.5万名小学新生 “房户一致”优先 2019-02-26