1. 分布式系统架构方法论

好久没更新公众号了，好不容易有时间，准备更新一波关于分布性系统架构方法论的知识，请寄好安全带，老司机要开车了，今天第一站：分布式系统架构之出现背景，什么情景下出现的分布式系统架构？

第二站：分布式系统架构之应用场景，在什么场景下适用于分布式系统架构？

第三站：分布式系统架构之维度指标，多维度的展现分布式系统架构体现在那几方面？

第四站：分布式系统架构之技术手段，庞大的分布式系统核心技术栈有哪些？

第五站：分布式系统架构之高性能手段，怎样做到分布式系统的高性能？

第六站：分布式系统架构之高可用手段，怎样做到分布式系统99.99%高可用?

第七站：分布式系统架构之可扩展手段，怎样做到分布式系统可无限水平扩展？

第八站：分布式系统架构之安全手段，怎样做到分布式系统安全健壮？

终点站：分布式系统架构之全链路监控，怎样做到快速定位分布式系统运行出现的错误？

好，首先我们从第一站出发，坐稳，发车了。

 1.1. 分布式系统架构之出现背景

项目初期，由于人力物力，产品需快速上线，抢占市场，这时候往往我们的系统架构是单体的，随着业务的不断发展，流量的增加，数据量的不断增加，当服务器遇到瓶颈时，例如：IO、内存、CPU、磁盘、网卡、带宽。为了满足业务的需求缓解服务器压力，短期方案一般有：优化程序代码、SQL调优，连接池调优，服务器进行垂直升级增加内存，升级CPU、磁盘替换成固态硬盘、带宽升级等操作，但治标不治本不是长久的解决之道。这个时候分布式系统架构自然而然出现了，将系统拆分为子系统，子系统与子系统进行通信。一般拆分的维度有两种：

一：基于业务单元的拆分（业务域）

二：基于API服务的单元拆分（API服务）

具体怎么拆？怎么实施还要根据当前项目的业务来进行拆。了解的分布式系统架构的背景后，我们来到第二站：分布式系统架构之应用场景。

1.2. 分布式系统架构之应用场景

什么情况下，适合用分布式系统架构？不是所有项目一上来就分布式。有些简单的项目例如：权限管理系统、学生管理系统，HR系统、企业管理系统等如果采用分布式系统架构往往适得其反，增加其系统的复杂度，提高成本。所以我们应该从以下纬度来进行分析什么场景适合用分布式系统架构：

一：需求维度

针对业务发展迅速，需求迭代频繁？频繁怎么体现例如一周上线1-2次。这个时候采用分布式系统架构会比较好，为什么比较好？假设采用单体应用，需求迭代频繁，开发需要马不停蹄的进行功能的新增或者修改，代码越堆越多每次维护的人心里肯定mmp的，我X谁TM写的代码怎么这么辣鸡。类似脏话些不说了，老司机都懂的。然后测试成本也很高，有时候你修改的地方，刚好有历史遗留的僵尸bug，推到你身上，你心里又是mmp的感觉。如果采用分布式系统架构，每一到两个人固定负责一个子系统，迭代的时候只需修改自已熟悉的优雅的代码，出了锅也心甘情愿的背。

二：性能维度：

1：吞吐量TPS、QPS上万

2：数据量上千w万

综上所述应用场景不仅要参考第三方还要要结合自已的经验进行综合评估，了解到了分布式系统架构适用的场景接下来第三站：看看分布式系统架构之维度指标。

 1.3. 分布式系统架构之维度指标

分布式系统覆盖的面非常广，具体来说从以下几个维度指标来看分布式系统架：

l 服务调度：服务发现、服务注册、配置管理、弹性伸缩、故障恢复等。

l 资源调度：底层资源的调度使用、如计算资源、网络资源、存储资源等。

l 流量调度：负载均衡、限流，熔断、路由等。

l 数据调度：分库分表、数据迁移、数据副本、数据一致性、分布式事务等。

l 容错处理：隔离性、幂等性、重试、业务补偿、异步、降级等。

l 自动化集成：持续集成、持续部署、全栈监控、调用链跟踪等。

从以上几点可以看出构建一个分布式系统还是相当复杂的。分布式系统架构具体涉及哪些技术栈，请坐稳，老司机加速了来到第四站：分布式系统架构之技术手段。

1.4. 分布式系统架构之技术手段

构建分布式的目的是增加系统系统吞吐量服务更多的并发和流量、增加系统的容量、提高系统的可用性，可扩展性、伸缩性、健壮性、安全等，故需要以下技术手段来支撑分布式系统的构建。

1.5. 分布式系统架构之高性能手段

在日常工作中，我们耳边常常环绕着这些话语，前端同学：我X这个接口慢的一逼啊，后端的同学是不是该优化下啊。后端同学：我艹这个SQL执行了好几秒啊到时候上线了要出事。架构师：我们系统的TPS/QPS要达到5w+。用户：页面卡的一逼啊、什么系统啊，等了好几s页面才刷新出来。以上种种情景是不是历历在目？终究回到了性能这个问题上。

性能从大的维度来讲是服务器的性能如何如何？小的层面来讲是软件软件的性能如何如何？那么提高性能的手段有哪些来，请看下面：

l 服务器无状态化

所谓无状态化，就是每台服务器状态一样，无区别，最能体现就是session共享，不启用服务器的session状态。好处是服务器可以水平无限扩展提高服务器吞吐量。

l 负载均衡

负载均衡本质就是一个任务分发器，将大流量均匀的分摊在业务服务器，从而缓解服务器的压力。当然负载均衡有好几种分发策略，常见的有以下：

轮询、随机法、源地址哈希法、加权轮询、加权随机法、最小连接数法。

l 服务拆分

服务拆分两个目的：一是为了隔离故障，二是为了重用服务模块。但服务拆分完之后，会引入服务调用间的依赖问题。

l 异步化设计

异步化设计保护系统，限流削峰。

l 缓存加速

访问高频的数据存储到缓存作为热数据、避免频繁和数据库连接进行交互。但要注意合理设计redis数据结构、以及缓存雪崩、缓存穿透等问题。

l 其他

以上是大的层面进行优化，小的层面有，SQL性能调优，代码实现的复杂度（时间复杂度、空间复杂度）、同步处理的是不是换成异步处理、连接池性能调优、线程池性能调优、tomcat性能调优、jvm性能调优等。

以上是高性能架构相关的手段，我们的分布式系统不仅要满足高性能还要满足高可用，接下来来到第六站：分布式系统架构之高可用手段

1.6. 分布式系统架构之高可用手段

      记得我所在的项目xxxx系统第一次上线的时候，直接将应用丢到一台服务器上。等  流 量上来的时候，系统开始出现卡顿，直到宕机。最终导致的结果是严重影响业务造成了xxx多少的损失。后来系统改进成集群，保证高可用，线上出事情的概率逐渐减少。现在一般的互联网公司重要系统，禁止单点，所谓单点禁止一台服务器提供服务，必须保证一台服务器挂掉的时候，其他服务器还能继续提供服务。服务器不管是web服务器还是db服务器等都能够水平扩展，支持高可用。常见的分布式系统架构里面高可用手段有以下：

l 服务器可扩展

服务器既可以伸，也可以缩。伸：流量大或者增加的时候可以无限扩展服务器。

例如秒杀活动，流量陡增，活动过后，服务器可缩，减少成本。

l 限流降级

当流量超出了系统能够承受的范围，实在扛不住压力时，只能通过限流或者功能降级的方式来停掉一部分服务，或是拒绝一部分用户，以确保整个架构不会挂掉。

l 熔断处理

l 超时机制

一般是系统调用第三方系统接口会出现超时，这个时候为了不能让第三方系统影响到我们系统，会采取http接口连接超时时间设置、读取超时时间设置。

l 补偿机制

补偿机制在我们的系统也应用的比较广泛，例如实现某个功能点，有自动触发的入口，定时任务每晚12点触发。如果刚好在12点的时候系统升级导致定时任务没执行。为了不影响业务，我们还应增加一个手动操作的补偿机制。

l 重试机制

重试机制设计中比较重要的两个点：

       1：重试次数一般是3次（具体为什么？业界最佳实践，事不过三）。

       2：每重试一次时间成幂次方的增加。

接下来看看分布式系统架构之可扩展手段有哪些？

 1.7. 分布式系统架构之可扩展手段

工作中我们或许常常会听到redis存储容量不够需要扩容，fastdfs存储容量不够需要扩容等。这是服务器层面的扩展。但经常听到话：最近新加了需求增加几个功能点xxx来修改下这个功能，接手的这个人如果看到一堆无扩展性的面条代码，心里肯定是mmp勒，修改一处，牵一发而动全身。属实的有点操蛋。如何优雅风骚的写代码？设计模式是不二之选。

设计模式的精髓就是预测变化封装变化。在这里说一下我亲身遇到的场景：工作中遇到最多的就是多情况多条件的if else，之前做的一个需求如下：收银台支付的时候可以选择不同的渠道进行支付。如果很日隆的写如下：

if("payMethod".equals("中国银行")){}

else if("payMethod".equals("工商银行")){}

else if("payMethod".equals("建设银行")){}

else if("payMethod".equals("招商银行")){}

这样写维护麻烦，不便于扩展，如果换成设计模式来做就是另外一种画风了。

草图如下：

实现思路：收银台通过上下文对象可以得到银行接口，具体什么银行收银台是无感知的，是我们内容上下文里面完成的。上下文里面维护了渠道类型和不同渠道的map集合。如何优雅的扩展渠道而不修改其他的代码？新增渠道只需要新增一个渠道实现类，并在类上加上渠道类型注解。

这里面会用到的设计模式有：单例模式+策略模式+简单工厂模式。

类似的场景还很多，请各位在工作中的情况对号入座，if else if else if else。

1.8.1  分布式系统架构之安全手段

常见的安全手段有：鉴权认证、加密、脱敏、防SQL注入、XSS攻击等等

1.9. 分布式系统架构之全链路监控

分布式系统架构中出现问题的几率非常大，这个时候需要健全的全链路监控系统，不仅是针对CPU、IO、内存、数据库、中间件的监控。以及对业务系统的操作日志进行监控。例如调用某某API接口服务出现错误3次，会邮件或者短信的信息通知到相关人员及时响应问题，解决问题。

到此、本次旅途已结束，坐的舒服吗？该下车休息了。敬请期待下一期分布式系统架构实战篇。系统如何优雅的拆分？服务粒度以什么维度拆分？系统边界如何划分？系统与系统如何优雅的协作！！！