分布式系统架构的冰与火

  • 陈皓

2018 年 1 月 16 日

话题:语言 & 开发架构

更多左耳朵耗子的独家干货,请订阅极客时间出品的陈皓全年专栏《左耳听风》,一次订阅、永久阅读。即日起,戳此订阅立享以下两大福利:

福利一:原价 ¥199/ 年,极客时间新用户注册立减 ¥30

福利二:每邀请一位好友购买,你可获得 36 元现金返现,多邀多得,上不封顶,立即提现(提现流程:极客时间服务号 - 我的 - 现金奖励提现)

看新闻很累?看技术新闻更累?试试下载 InfoQ 手机客户端,每天上下班路上听新闻,有趣还有料!

本文首发于陈皓(网名“左耳朵耗子”)在极客时间 App 上开始的全年独家专栏《左耳听风》,是《分布式系统架构的本质》7 篇系列文章的第一篇,更多文章,正在专栏更新。

点击此处,或扫描下图二维码订阅,永久阅读专栏内所有内容。

最近几年,我们一直在谈论各式各样的架构,如高并发架构、异地多活架构、容器化架构、微服务架构、高可用架构、弹性化架构等。还有和这些架构相关的管理型的技术方法,如 DevOps、应用监控、自动化运维、SOA 服务治理、去 IOE 等。面对这么多纷乱的技术,我看到很多团队或是公司都是一个一个地去做这些技术,非常辛苦,也非常累。这样的做法就像我们在撑开一张网里面一个一个的网眼。

其实,只要我们能够找到这张网的“纲”,我们就能比较方便和自如地打开整张网了。那么,这张“分布式大网”的总线——“纲”在哪里呢?我希望通过这一系列文章可以让你找到这个“纲”,从而能让你更好更有效率地做好架构和工程。

首先,我们需要阐述一下为什么需要分布式系统,而不是传统的单体架构。也许这对你来说已经不是什么问题了,但是请允许我在这里重新说明一下。使用分布式系统主要有两方面原因。

  • 增大系统容量。我们的业务量越来越大,而要能应对越来越大的业务量,一台机器的性能已经无法满足了,我们需要多台机器才能应对大规模的应用场景。所以,我们需要垂直或是水平拆分业务系统,让其变成一个分布式的架构。

  • 加强系统可用。我们的业务越来越关键,需要提高整个系统架构的可用性,这就意味着架构中不能存在单点故障。这样,整个系统不会因为一台机器出故障而导致整体不可用。所以,需要通过分布式架构来冗余系统以消除单点故障,从而提高系统的可用性。

当然,分布式系统还有一些优势,比如:

  • 因为模块化,所以系统模块重用度更高;
  • 因为软件服务模块被拆分,开发和发布速度可以并行而变得更快;

  • 系统扩展性更高;

  • 团队协作流程也会得到改善;

  • ……

不过,这个世界上不存在完美的技术方案,采用任何技术方案都是“按下葫芦浮起瓢”,都是有得有失,都是一种 trade-off。也就是说,分布式系统在消除上述问题的同时,也给我们带来了其他的问题。因此,我们需要清楚地知道分布式系统所带来的问题。

下面这个表格比较了单体应用和分布式架构的优缺点。

从上面的表格我们可以看到,分布式系统虽然有一些优势,但也存在一些问题。

  • 架构设计变得复杂(尤其是其中的分布式事务)。

  • 部署单个服务会比较快,但是如果一次部署需要多个服务,部署会变得复杂。

  • 系统的吞吐量会变大,但是响应时间会变长。

  • 运维复杂度会因为服务变多而变得很复杂。

  • 架构复杂导致学习曲线变大。

  • 测试和查错的复杂度增大。

  • 技术可以很多样,这会带来维护和运维的复杂度。

  • 管理分布式系统中的服务和调度变得困难和复杂。

也就是说,分布式系统架构的难点在于系统设计,以及管理和运维。所以,分布式架构解决了“单点”和“性能容量”的问题,但却新增了一堆问题。而对于这些新增的问题,还会衍生出更多的子问题,这就需要我们不断地用各式各样的技术和手段来解决这些问题。

以上仅为文章的一部分,欲阅读全文,还请点击链接关注『左耳听风』专栏,在试读文章模块,继续阅读。本文是《分布式系统架构的本质》7 篇系列文章的第一篇,更多文章,正在专栏更新,扫描下图二维码订阅,永久阅读专栏内所有内容,可在 PC、微信和 App 中随时阅读。

语言 & 开发架构