分布式系统

这篇文章我们继续聊聊《深入分布式缓存:从原理到实践》这本书。本书的核心是介绍在分布式系统中如何使用缓存,在深入了解缓存的使用之前,我们先来了解缓存的使用方:分布式系统。

遗憾的是,书里虽然介绍了一些分布式系统的概念、理论和实践,却没有解释究竟什么样的系统是分布式系统,以及使用分布式系统的原因,所以这篇文章,我会结合自己的工作经验,谈一谈自己对于这两个问题的理解。

最通俗的解释

一听到“分布式”这个三个字,很多人就会觉得很高大上,很难理解,其实并不是这样的,对于分布式系统有一个非常通俗有趣的解释。

小饭店的厨房原来只有一个厨师,切菜洗菜炒菜全干。后来客人多了,厨师忙不过来,为了提高效率,老板将工作细分,请了配菜工负责切菜,洗菜工负责洗菜,而厨师就只用专门负责炒菜了。

上面这个例子里,我们可以把厨师、配菜工、洗菜工都当做一个个独立的系统。

一开始是厨师承担了所有的工作,计算机行业将这种系统称为“单体系统”。

后来分工细了,厨师、配菜工、洗菜工之间形成了一种互相配合,互相牵制的合作关系,这种关系就是”分布式”关系,而组成这种关系的系统被称为“分布式系统”。

由此我们可以总结出分布式系统的几个特点:

  1. 任务分工。一个完整的工作/任务不是由某一个单体系统承担,而需要多个系统共同承担,每个系统承担其中的一部分工作。
  2. 协调连接。不同的系统之间要能够互相通信,这样才能让数据和状态在不同系统之间流转。

有的同学看到这里可能会问,如果不将工作细分,而是多雇几个厨师,也能提高工作效率,这样的情况算作分布式么?

这样情况不能算作分布式,对此计算机行业有另外一个专有名词:集群。就是同时部署多台执行相同工作/任务的系统。

即使是一些计算机的从业人员,也会不小心将“分布式”和“集群”混为一谈。

尽管如此,“分布式”和“集群”往往是同时出现的。比如为了进一步提高效率,老板可以雇佣3个厨师,2个配菜工,2个洗菜工同时在厨房里干活。

为什么要用分布式系统架构

20世纪90年以前,软件系统大多是单体架构的,那个时候软件功能相对简单,一个单体架构的系统就能够满足大多数的需求。

90年代以后,随着软件技术的不断发展,系统规模越来越大,功能越来越复杂,对性能的要求也越来越高,逐渐就演化出了SOA-基于服务的架构,SOA可以算作分布式架构的鼻祖。

但是SOA过于复杂,厚重了,因此对于SOA的优化也在不断进行中。

进入2010年后,出现了微服务架构,这个架构将分布式系统的应用推向了一个新高度。现在,对于软件企业,尤其是大型互联网软件企业而言,微服务架构已经成为首选的系统架构。

使用分布式系统主要有两方面原因。

  • 提高系统性能。系统需要处理的业务量越来越大,一台机器的性能已经无法满足了,我们需要多台机器才能应对大规模的应用场景。所以,我们需要垂直或者水平拆分业务系统,让其变成一个分布式架构。
  • 提高系统可用性。传统的单体系统,所有业务功能都在一个系统中,一旦系统出现单点故障,整个业务功能都不能正常执行。所以,我们需要通过分布式架构来冗余系统,消除单点故障,提高系统可用性。

除此之外,使用分布式系统还能带来很多其它优点,比如:

  • 更容易扩展。
  • 模块间可以是异构的,适用场景更加丰富。

不过分布式架构也不是完美的,与单体架构相比,它也存在着一些缺点,比如:

  • 部署更加复杂。系统模块的增加,以及个模块之间存在错综复杂的依赖关系,使得发布部署更加耗时,难度更高。
  • 增加了通讯时间消耗。数据和状态的需要通过网络通信在各模块间流转,增加了时间成本。

下表为我们展示了单体架构与分布式架构的优缺点比较。

20180121001

总结

从前面的内容中,我们了解到分布式系统虽然解决了性能高可用的问题,但也带来了其它很多新问题,无论是系统设计、研发、测试还是运维,相比单体架构都复杂了很多,真可谓是按下葫芦起了瓢。

但这也是一个生态系统在进化过程必然经历的过程。就像人类社会,不也是从简单的部落形态,发展到复杂的国家形态么?虽然我们失去了部落形态中的一些优势,但是整体人类社会是在不断进步的。

所以我相信,随着计算机技术的不断发展,未来还会有更加智能、更加复杂的架构出现,这既是我们计算机从业者的挑战,也是我们的机会。

最后给大家留一个问题,共同探讨。最近非常火热的区块链技术,你觉得它是一种分布式架构么,为什么?

上篇本地缓存
下篇缓存为王