朱晔的互联网架构实践心得S1E8：三十种架构设计模式（下）

接上文，继续剩下的15个模式。

数据管理模式

1六、分片模式：将数据存储区划分为一组水平分区或分片

一直有一个说法就是不到没路可走的时候不要考虑数据库分片。有的时候业务量大到单个业务表在通过缓存+队列削峰等措施以后的平均的TPS超过1万，单表实在是扛不住，仍是只能考虑分片手段。

分片前：

· 须要根据数据分布、压力状况、业务逻辑肯定分片的方式，按照条件仍是范围仍是哈希等等（三个图展现了三种策略）。

· 须要进行业务代码改造，改掉全部不容许的SQL。

· 须要肯定用HardCode方式仍是框架方式仍是中间件方式作数据路由。

分片后：

· 须要有运维工具能够对这么多套分片的数据进行统一的加索引等操做。

· 最好有数据仓库能够汇总全部数据，使得adhoc查询能够更方便。

· 最好有辅助工具能够用来帮助定位数据会在哪一个分片中。

1七、静态内容托管模式：将静态内容部署到基于云的存储服务，能够将它们直接传递给客户端

相信互联网公司90%+确定都使用了这个模式。把静态资源从动态网站中剥离由Nginx等高性能服务器来处理静态资源，而后使用三方CDN对静态资源进行加速，不但减轻了动态网站的负载并且数据在边缘节点加速让用户的访问跟快，使用单独的一个或多个子域名作静态资源还能提升下载资源的并行度提升网页加载的速度。

使用CDN来进行资源加速通常有主动数据传送到CDN存储和在CDN配置回源站拉取两种方式，文件类通常使用主动推送数据，静态资源类通常使用回源方式。在使用CDN的时候考虑下面的问题：

· CDN以什么方式来认定同一个文件的，CDN提供了什么工具来刷新边缘节点的缓存？根据不一样的策略作相应的缓存刷新方案。

· 源站对于相同的文件须要有一致性（最好版本变化后文件名变化），不能今天是这个版本明天是另外一个版本，这样极可能致使边缘节点缓存了不一样版本的文件，致使各类怪问题。

· 使用了CDN后不一样地区的用户访问的都是CDN节点上的数据，一旦出现问题排查比较困难，考虑引入前端的错误处理框架来记录前端出现脚本错误时的调用栈，方便定位问题。

1八、索引表模式：为查询常常引用的数据存储区中的字段建立索引

在第三第五两篇文章中我都提到了索引表的作法。出于下面的缘由，咱们会考虑索引表：

· 虽然咱们的关系型数据库大多支持主键以外的非汇集索引，可是在某些状况下直接对大表作不少索引性能并很差。

· 作了Sharding后咱们确实没有办法以分片键以外的维度来查询数据。

· 但愿以空间换时间，直接把某个维度的复合查询做为主键单独保存一份数据。

不过须要考虑一点索引只有在数据区分度高的状况下才能发挥价值，若是90%以上的数据都是相同的值，那么走索引进行查询性能会比全表扫还要差一点。

设计和实现模式

1九、前端专用的后端模式：经过使用单独的接口来分离读取数据和更新数据的操做

这里说的是不一样的前端配以不一样的专用后端。好比PC网站和APP的后端是两套程序。这种模式是否适合其实仍是看两端的后端提供的数据差别有多大，咱们老是但愿能够尽可能统一一套后端，业务逻辑不用重复写，可是咱们要考虑到PC网站和APP的差别性：

· APP系统的接口交互通常会签名验证，有的时候还会加密

· PC系统的流程通常和APP系统不同

· PC一个页面能显示的内容会比APP一个界面显示的更多

· 安全性设计上PC和APP不同，APP不多有图形验证码

考虑到这些差别，咱们是在一个工程内根据来源作适配，仍是独立两套工程来作独立的后端取决于差别度有多大了。

20、计算资源整合模式：将多个任务或操做整合到单个计算单元中

这个模式从资源节省的角度来讲咱们的计算单元任务能够进行一些合并，减小由于资源限制致使没必要要的开销。

2一、选举模式：经过选举一个实例做为负责管理其它实例的负责人，来协调分布式应用程序中的协做任务实例集合执行的操做

对于分布式服务，咱们趋向于把服务设计为无状态能够任意扩展的，可是在某些业务场景下咱们不得不在服务中选举出一个Leader（Primary节点，Master节点）来作一些不适合重复作的协调管理工做。这个时候咱们须要有算法来作选举。

最多见的实现方式是使用Zookeeper来实现，咱们知道ZK的znode有Sequence和NonSequence两种，前者多个客户端只有一个可建立成功同名节点，后者建立后会自动加上序列号命名多个客户端能够建立多个同名节点，利用这个特性有两种常见实现方式：

· 非公平实现。多个客户端同时建立EPHEMERAL+NONSEQUENCE节点。只有一个能够建立成功，建立成功的就是Leader，其它的Follower须要注册watch，一旦Leader放弃节点（注意，EPHEMERAL意味着Leader待机后Session结束节点被删除），再一次重复以前的过程注册节点抢占成为Leader。这个模式实现简单，问题是在节点数量过多的时候一旦发生从新竞选，这个时候可能会有性能问题。

· 公平实现。多个客户端同时建立EPHEMERAL+SEQUENCE节点。客户端均可以建立成功节点，客户端若是判断本身是最小的节点则为Leader不然为Follower。每个Follower都去watch序号比本身小的节点（你们都看前一位）。一旦有Leader节点由于宕机被删除（仍是EPHEMERAL特性），收到通知的节点会看本身是否是最小的序号，若是是的话成为Leader。节点宕机后，原先watch宕机节点的客户端从新watch比本身序号小的有效节点。这个模式实现复杂，可是因为watch的都只是一个节点因此不会发生像非公平实现的性能问题，并且竞选根据节点序号来而不是抢占式因此显得Leader的选举公平有序。

2二、管道和过滤器模式：将须要执行复杂处理的任务分解成能够重复使用的一系列单独的元素

在软件设计模式中过滤器构成的管道这种模式很常见（图上的业务逻辑就是Handler，以前的那些Task就是Filter，模式上能够是Filter+Handler也能够是Filter+Handler+Filter也能够是Handler+Filter），无论是Spring MVC框架也好，Netty这种网络框架也好都提供了这样的设计。每个过滤器单独完成一个功能，能够独立插拔随意组合配置成一套管道，不但数据处理的整个过程清晰可见还增长了灵活性。

对于架构上也能够有这样的模式，在数据源进入到业务逻辑处理以前（或以后，或先后），咱们能够配置一系列的数据过滤器完成各类数据转化和处理的任务。Task和Task之间能够是同步调用，也可使用MQ作必定的可伸缩性设计。还能够把过滤器的配置信息保存在配置系统中甚至根据上下文动态构建出管道，实现更灵活的前置或后置流程处理。

消息模式

2三、竞争消费者模式：使用多个并发消费者来处理在同一消息通道上接收的消息

这里说的是消息队列的消息消费者是一组对等的消费者，经过竞争方式来拉取数据执行。以前提到过这是MQ的最多见的一种模式，通常而言咱们会部署多个消费节点进行负载均衡，在负载较大的时候能够方便得增长消费者进行消费能力扩容。不过对于这种模式消费者应当是对等的无状态的，在某个消费者在消费失败的时候消息从新回到队列随后可能会被另外一个消费者进行处理。

2四、重试模式：在应用程序尝试链接到服务或网络资源遇到预期的临时故障时，让程序经过透明地重试之前失败的操做来处理

重试适用于瞬态故障，以后会提到断路器模式，两种模式能够结合使用。首先说说重试的几个发起人：

· 让用户本身发起，遇到错误的时候及时返回错误信息，让用户本身稍后重试整个业务功能。这种方式不容易产生瞬时的压力，可是体验较差。

· 在中间件自动发起，好比在RPC调用的时候遇到服务超时自动进行必定次数的重试，这样能够在外部没有感知的状况下有必定几率消除错误。这个方式要求服务是支持重试的。

· 由业务逻辑手动发起，不一样的业务逻辑根据需求在代码中去写重试的逻辑（固然也能够经过相似Spring-Retry这种组件来作）。实现繁琐可是不容易出错。

· 由补偿逻辑发起进行同步转异步操做，非重要逻辑同步行则行，不行不在主流程重试，由单独的异步流程进行重试补偿。

重试也要考虑几种策略：

· 次数。最多重试几回。

· 异常。遇到什么样的异常（黑白名单）应该去重试。

· 等待。考虑每次重试是相同的间隔呢仍是有一个延迟的递增，随着重试次数增长而增长延时时间。

2五、调度、代理、主管模式：在一组分布式服务和其它远程资源之间协调一组操做

这个模式说的是三者的角色：

· 调度负责安排任务，在执行每一个步骤的时候维护任务的状态，具体业务逻辑由代理负责。

· 代理负责和远程的服务和资源进行通信，实现错误处理和重试。

· 管理者负责监视任务的执行状态，做为调度的补充，在合适的时候要求调度进行补偿。

三个角色相互配合完成复杂的，具备较多远程服务参与的任务，确保任务的最终有效执行。在以前架构三马车一文中说到定时任务的时候提到过一种任务驱动表的模式，说到了一些驱动表的实现细节，其实总体和这个模式是相似的思想。当咱们的一个复杂逻辑有多个步骤构成，每一步都依赖外部服务，这个时候咱们能够选择全程MQ+补偿方式（乐观方式），也能够选择全程任务驱动的被动模式（悲观方式），具体选择取决于更看重可靠性仍是及时性。

弹性模式

2六、舱壁模式：将应用程序的元素隔离到池中，若是其中一个失败，其它的将继续运行

资源隔离有好几个层次，能够在进程内部作线程池或队列的隔离，在微服务的服务划分上考虑隔离出单独的物理服务，或是在服务器层面经过虚拟化技术或Docker技术进行资源隔离。隔离了就不会相互影响，可是会有成本、性能、管理便利性方面的开销。实现可以根据需求分析出可能的资源相互影响的点，提早规划隔离每每能够避免不少问题的发生。以前有遇到过几个事故是这样的：

· 程序内部大量使用了Java8的ParallelStream特性进行并行处理，因为默认共享了相同的线程池，某一个业务的执行占满了线程影响了其它业务的正常进行。

· 消息队列由于没有对执行过屡次失败的死信消息和正常的新消息进行隔离，致使一些业务下线后没法处理的死消息占满了整个队列，正常消息没法消费。

· 某个服务提供了相似文件上传的重量级操做，也提供了数据查询的轻量级操做，在上传业务大的时候服务的线程都被IO所占满，致使其它查询操做没法进行。

2七、断路器模式：链接到远程服务或资源时, 处理可能须要花费时间来修复的故障

分布式应用环节多网络环境复杂，若是遇到依赖服务调用失败的状况咱们或许能够进行重试期待服务立刻能够恢复，可是在某些时候依赖的服务是完全挂了而不是网络故障没法及时恢复，若是不考虑进行熔断的，可能服务调用方会被服务提供方拖死。这个时候能够引入断路器机制，如图所示断路器通常采用三态实现，瞬间恢复可能会让底层服务压力过大：

· 关闭：出现错误的时候增长计数器

· 打开：计数器到达阈值打开断路器，直接返回错误

· 半开：超时后容许必定的请求经过，成功率达到阈值关闭断路器，操做仍是失败的话仍是进入打开状态

实现模式的时候考虑下面注意点：

· 考虑熔断后怎么来处理，熔断后咱们确定拿不到实际的处理结果，这个时候考虑是功能降级仍是采用后备的数据提供方来提供数据

· 紧急的时候须要人工介入，最好在外部提供手动的方式能够干预断路器的三态

· 不一样的业务考虑不一样的断路器打开阈值，每个错误还能有不一样的权重，好比对于下游程序返回了太多请求的错误，每次错误能够+2提升权重尽量早断路

· 断路器应当记录熔断时的请求原始信息，在以后必要的时候能够进行重放或数据修复工做

· 注意设置好外部服务的超时，若是客户端超时比服务端短，极可能进行错误的熔断

实现上咱们能够看一下Netflix的Hystrix进行进一步了解。

2八、事务补偿模式：撤消经过一系列步骤执行的工做，它们一块儿定义最终一致的操做

这个模式说的是失败时必须进行撤销的操做，能够由一组补偿程序来作相应的补偿。在这里我想说的更广一点，在服务调用的时候，调用失败有几种可能：

· 请求客户端发出可是没到服务端，业务逻辑没有执行

· 请求客户端发出服务端收到也处理成功了，业务逻辑执行了客户端没收到结果

· 请求客户端发出服务端收到但处理失败了，客户端没收到结果

因此在出现服务调用失败或超时的时候，服务端执行究竟有没有成功客户端是不明确的（只有客户端收到了明确的服务端返回的业务错误才真正表明执行失败），这个时候须要有补偿逻辑来同步服务端的执行状态。若是这样的补偿不可避免并且须要补偿的服务特别多，这样的逻辑逐一来写是一件很烦的事情，咱们能够把这个工做封装成一个补偿中间件来处理：

· 全部关键服务调用标记为须要自动补偿

· 补偿中间件在数据库记录服务的调用状态

· 关键服务的提供者提供统一状态查询接口，消费者提供统一的补偿回调接口（来处理成功和失败的状况）

· 补偿中间件根据数据库的记录调用服务提供方的状态查询和服务消费方的补偿回调接口进行补偿

这样，咱们在服务调用的时候就不须要考虑补偿逻辑的实现，只要实现这个标准便可。

安全模式

2九、代客密钥模式：使用向客户端提供对特定资源或服务的有限直接访问权限的令牌或密钥

这个模式说的是，在访问敏感资源的时候，咱们能够没必要让应用程序在其中做为一个代理转一层作权限控制，而是生成一个密钥，让用户直接拿着密钥到资源池换数据。

一些CDN在提供资源上传下载服务的时候通常都会提供相似的安全策略，须要实现生成Token才能去使用下载和上传服务，避免了CDN数据被非法利用做为图床的可能。

实现上比较简单，应用程序和资源提供方约定好Token的生成算法，对资源+请求资源的时间+密钥联合在一块儿作签名，资源提供方若是校验到签名不正确或Token过时或资源不匹配都将拒绝服务。

30、联合身份模式：将认证委托给外部身份提供者

这个模式说的是将身份验证委托给专门的程序或模块来作。使用专门的模块来统一负责登陆受权不只仅能够提供单点登陆的功能，并且服务实现上更简单不须要每次都考虑登陆那套东西。实现上能够看一下Spring Security实现的OAuth 2.0。

总结一下，对于其中的不少模式，咱们能够发现其实在以前的一些介绍或多或少有一些涉及。这里提到的30种模式有些体现的是一些设计细节，有些体现的是一种设计理念，它们大多时候是组合使用的，适合的就是最好的，你们能够细细品味一下每种模式的适合场景，在合适的时候能够想到它或许会有一种豁然开朗的感受。