引言

最近几年，大家一直在讨论各式各样的架构，如：高并发架构、异地多活架构、容器化架构、微服务架构、高可用架构、弹性化架构。还有这些架构相关的管理型技术方法，如：DevOps、应用监控、自动化运维、SOA服务治理、去IOE等等。面对这么多的纷乱复杂的技术，很多团队都是一个个地去做这些技术，非常辛苦，但结果并不好。

分布式系统架构的目的

首先，我们需要搞清楚的是为什么需要分布式系统，而不是传统的单体架构。其实，使用分布式系统主要有以下几个原因：

增加系统容量：随着业务量越来越大，而要能够应对越来越大的业务量时，一台机器的性能已经无法满足业务的需求了，我们需要多台机器才能应对大规模的应用场景。所以，我们需要垂直或水平拆分业务系统，让其变成一个分布式的架构。
加强系统可用性：由于业务变得越来越关键，需要提高整个系统架构的可用性，这就意味着架构中不能存在单点故障。这样整个系统不会因为一台机器出现故障导致整体不可用。所以需要通过分布式架构来冗余系统以消除单点故障，从而提高系统的可用性。

以上是整个分布式系统架构的主要目的，当然，它还具体一些其它方面的优势，比如：

模块化：分布式系统架构采用的是一个服务一个模块，所以系统模块重用性更高；
持续发布和提高效率：因为软件服务模块初拆分，开发的发布速度可以并行而变得更快；
扩展性高：可支持垂着的水平扩展；
团队协作：由于每一个服务模块都是服务接口的方式暴露的，团队协作流程也会得到改善；
... ...；

分布式架构的难点

不过，这个世界上并不存在完美的技术方案；采用任何一种技术方案都是“按下葫芦浮起瓢”，都是有得有失，都是一种取舍。也就是说，分布式系统在解决上述问题的同时，也给我们带来了其它方面的问题。因此，我们需要清楚地知道分布系统所带来的问题以及如何有效的规避这些问题。

下面的表格是单体应用架构和分布式架构的优缺点的对比情况：

维度指标	单体架构	分布式架构
新功能开发	需要时间	容易开发和实现
部署频率	不经常容易部署	经常发布，部署复杂
隔离性	故障影响范围大	故障影响范围小
架构设计	难度小	难度系数增加
系统性能	响应时间快，吞吐量小	响应时间慢，吞吐量大
系统运维	运维简单	运维复杂
学习成本	学习曲线大（应用逻辑）	学习曲线大（架构逻辑）
技术复杂度	技术单一且封闭	技术多样且开放
测试和查错	简单（日志文件）	复杂（逐个节点排查）
系统扩展性	扩展性很差，容易出现性能瓶颈	扩展性很好
系统管理	重点在于开发成本	重点在于服务治理和调度

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

架构设计变得复杂
部署单个服务会比较快，但是如果一次部署多个服务时，部署会变得复杂。
系统吞吐量会变大，但是响应时间会变长。
运维复杂度会因为服务变多而变得复杂。
架构复杂导致学习曲线变大。
测试和查错的复杂度增大。
技术多样化，这会带来维护和运维的和复杂度。
管理分布式系统中的服务和调度变得困难和复杂。

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

分布式架构技术栈

我们知道构建系统的目的是增加系统容量和提高系统的可用性，转换成技术方面，也就是完成以下两件事：

大流量处理：通过集群技术把大规模并发请求的负载分散到不同的机器上。
关键业务保护：提高后台服务的可用性，把故障隔离起来阻止“多米诺骨牌效应（雪崩效应）”，如果流量过大，需要对业务降级，以保护关键业务流转。

说白了就是干两件事，一是提高整体架构的吞吐量，服务更多的并发和流量，二是为了提高系统的稳定性SLA，让系统的可用性更高。

提高性能的常用技术

缓存系统：加入缓存，可以有效的提高系统的访问能力。从前端的浏览器，到网络，再到后端的服务，底层数据库，文件系统，硬盘和CPU，全部都有缓存，这是提高快速访问能力的最有效的手段。对于分布式系统下的缓存系统，需要一个缓存集群。这其中需要一个代理（Proxy）来做缓存的分片和路由。
负载均衡：它是做水平扩展的关键技术，其可以用多台机器来共同分担一部分的流量请求。常见的负载均衡器可以分为：硬负载（F5）和软负载（Nginx）。
异步调用：异步系统主要通过消息队列对请求做排除处理，这样可以把前端的请求峰值给”削平“了，而后端通过自已能够处理的速度来处理请求。这样可以增加系统的吞吐量，但是实时性就差很多了。同时，还会引入消息丢失的问题，所以要对消息队列做持久化处理，这会造成”有状态“的结点，从而增加了服务调度的难度。
数据分区：数据分区就是把数据按一定的方式分成多个区（比如通过地理位置），不同的数据区分来分担不同区的流量，这需要一个数据路由中间件，会导致跨库的Jion和跨库的事务非常复杂。
数据镜像：数据镜像就是把一个数据库镜像成多份一样的数据，这样就不需要数据路由的中间件了。你可以在任意的结点上进行读写操作，内部会自行的同步数据。然而，数据镜像中最大的问题就是数据一致性的问题。

提高稳定性的常用技术

服务拆分：服务拆分的目的主要有两个：一是为了隔离故障，二是为了重用服务模块。但服务拆分后，会引入服务调用间的依赖问题。
服务冗余：是为了去除单点故障，并可以支持服务的弹性伸缩及故障迁移。然而，对于一些有状态的服务来说这就导致了数据不一致的问题
限流降级：当系统实在扛不住压力时，只能通过限流或者功能降级的方式来停掉一部分服务或拒绝一部分用户，以确保系统不会挂掉，所以限流降级是一种保护措施。
高可用架构：通常来说是从冗余架构的角度来保障可用性。常用的做法有：多租户隔离，灾备多活，数据分区（数据复制保持一致性的集群）。总之，其根本的目的就是不出单点故障。
高可用运维：指的是DevOps中的CI（持续集成）与CD（持续部署）两方面。一个良好的运维应该是一条很流畅的软件发布管线，其中做了足够多的自动化测试，还可以做相应的灰度发布，以及对线上系统的自动化控制。这样做的目的可以保证‘计划内“和”非计划内“的宕机事件的时长最短。

小结

总体来说，分布式系统需要干的就是两件事：一是提高整体架构的吞吐量，服务更多的并发和流量；二是为了是提高系统的稳定性，让系统的可用性更高。

为了达到上述两个主要的目的，列举了并梳理出了其中的技术难点及可能会带来的问题。

分布式系统架构的本质相关推荐

左耳朵耗子：聊聊分布式系统架构
点击关注 InfoQ,置顶公众号程序员的 8 点技术早餐作者|陈皓编辑|杨爽学习任何技术,善于提纲挈领总是事半功倍.学习分布式系统架构也是如此,只要找到这张网的纲,就能更有效率地做好架构和工程 ...
分布式系统架构与云原生—阿里云《云原生架构白皮书》导读
-点击领取<云原生架构白皮书>- 导语: 有幸作为阿里云MVP提前获得了阿里云云原生团队编写的<云原生架构白皮书>,希望通过自己对于云原生的理解为开发者提供一篇观后感或者是能够 ...
《大规模分布式系统架构与设计实战》
<大规模分布式系统架构与设计实战> 基本信息作者: 彭渊丛书名: 大数据技术丛书出版社:机械工业出版社 ISBN:9787111455035 上架时间:2014-2-21 出版日期: ...
分布式系统架构设计三十六式之服务治理 - 第一式 - 隔板模式
导读日拱一卒,功不唐捐,分享是最好的学习,一个知识领域里的 "道法术器" 这四个境界需要从微观.中观以及宏观三个角度来把握.微观是实践,中观讲套路,宏观靠领悟.本系列文 ...
在首席架构师眼里，架构的本质是……
在首席架构师眼里,架构的本质是-- 浏览次数:117次 36 氪 2016年03月03日字号: 大中小分享到:QQ空间新浪微博腾讯微博人人网豆瓣网开心网更多0 编者按:本文作者王庆友,前 1号 ...
分布式系统架构设计36式 – 第0式 - 设计总决
动机在"不易.简易.变易"这三个范畴里,技术是属于"变易"范畴的,其千变万化:"方法论"是属于"简易"范畴的,其具有领 ...
爆肝七天！终于把分布式系统架构整理出来了
随着互联网的不断发展,企业积累的数据越来越多.当单台数据库难以存储海量数据时,人们便开始探索如何将这些数据分散地存储到多台服务器的多台数据库中,逐渐形成了分布式数据库.如果将数据分散存储,对于数据的增 ...
大型互联网分布式系统架构技术要点
大型互联网分布式系统架构技术要点解决问题的通用思路是将分而治之(divide-and-conquer),将大问题分为若干个小问题,各个击破.在大型互联网的架构实践中,无一不体现这种思想. 架构目标 ...
整理下.net分布式系统架构的思路
最近看到有部分招聘信息,要求应聘者说一下分布式系统架构的思路.今天早晨正好有些时间,我也把我们实际在.net方面网站架构的演化路线整理一下,只是我自己的一些想法,欢迎大家批评指正. 首先说明的是.ne ...
美团即时物流的分布式系统架构设计
背景美团外卖已经发展了五年,即时物流探索也经历了3年多的时间,业务从零孵化到初具规模,在整个过程中积累了一些分布式高并发系统的建设经验.最主要的收获包括两点: 即时物流业务对故障和高延迟的容忍度极低 ...

分布式系统架构的本质

引言