分布式架构

目录 熔断设计 限流设计 降级设计 框架选型 熔断设计 熔断器模式是用来防止应用程序不断地尝试执行可能会失败的操作，使得应用程序可以继续执行，而不会浪费 CPU 时间去等待长时间的超时产生。 时序图 （本图来自 Martin Fowler 的 Circuit Breaker） 熔断器的几种状态 闭合（Closed）状态 ：熔断器处于闭合状态时，会有一个基于时间的调用失败计数器，如果在这个时间内的失败次数超过了给定的阈值，那么将切换到断开状态。 断开（Open）状态 ：在断开状态下，对应用程序的请求会立即返回错误响应，而不调用后端的服务。当切到断开状态后，会开启一个超时时钟，当时间超过了该时间，将切到半开状态。 半开（Half-Open）状态 ：在半开状态下，允许应用程序一定数量的请求去调用服务。如果这些请求调用成功，那么熔断器将切换到闭合状态；如果有一定数量的请求调用失败，那么熔断器将切换到断开状态。 状态机 （本图来自 Martin Fowler 的 Circuit Breaker） 限流设计 限流是通过对并发访问进行限速，一旦达到限制的速率，就会触发相应的限流行为。目的是为了：应对突发的流量、保证系统在某个速度下的响应时间及可用性、节约成本等。 限流行为： 拒绝服务。把多出来的请求直接拒绝掉。 服务降级。关闭或是把后端服务做降级处理。 特权请求。把有限的资源分给VIP用户。

我们讨论了hystrix+feign+ribbon，但是可能很多人都知道hystrix还有线程隔离，信号量隔离，等等各种参数配置，在这几就记录下hystrix的参数， br/>一、hystrix参数使用方法 通过注解@HystrixCommand的commandProperties去配置， 如下就是hystrix命令超时时间命令执行超时时间，为1000ms和执行是不启用超时 了解springcloud架构可以加求求：三五三六二四七二五九 @RestController public class MovieController { @Autowired private RestTemplate restTemplate; @GetMapping("/movie/{id}") @HystrixCommand(commandProperties = { @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "1000"), @HystrixProperty(name = "execution.timeout.enabled", value = "false")},fallbackMethod = "findByIdFallback") public User findById

一、事务与分布式事务 事务,在数据库中指的是操作数据库的最小单位,往大了看,事务是应用程序中一系列严密的操作，所有操作必须成功完成，否则在每个操作中所作的所有更改都会被撤消。 那为什么会有分布式事务呢?单机事务是通过将操作限制在一个会话内通过数据库本身的锁以及日志来实现ACID.因为引入了分布式架构,所以事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上.简单说就是多各数据库之间无法保证保证各自的操作同时成功或同时失败。 二、介绍 Seata:Simple Extensible Autonomous Transaction Architecture，简易可扩展的自治式分布式事务管理框架，其前身是fescar。阿里巴巴GTS的开源版实现，是一种分布式事务的解决方案。 三、架构 Coordinator Core：最下面的模块是事务协调器核心代码，主要用来处理事务协调的逻辑，如是否 Commit、Rollback 等协调活动。 Store：存储模块，用来将我们的数据持久化，防止重启或者宕机数据丢失。 Discover：服务注册/发现模块，用于将 Server 地址暴露给 Client。 Config：用来存储和查找服务端的配置。 Lock：锁模块，用于给 Seata 提供全局锁的功能。 Rpc：用于和其他端通信。 HA-Cluster

大数据技术的体系庞大且复杂，基础的技术包含数据的采集、数据预处理、分布式存储、NoSQL数据库、数据仓库、机器学习、并行计算、可视化等各种技术范畴和不同的技术层面。首先给出一个通用化的大数据处理框架，主要分为下面几个方面：数据采集与预处理、数据存储、数据清洗、数据查询分析和数据可视化。 一、数据采集与预处理 对于各种来源的数据，包括移动互联网数据、社交网络的数据等，这些结构化和非结构化的海量数据是零散的，也就是所谓的数据孤岛，此时的这些数据并没有什么意义，数据采集就是将这些数据写入数据仓库中，把零散的数据整合在一起，对这些数据综合起来进行分析。数据采集包括文件日志的采集、数据库日志的采集、关系型数据库的接入和应用程序的接入等。在数据量比较小的时候，可以写个定时的脚本将日志写入存储系统，但随着数据量的增长，这些方法无法提供数据安全保障，并且运维困难，需要更强壮的解决方案。 Flume NG作为实时日志收集系统，支持在日志系统中定制各类数据发送方，用于收集数据，同时，对数据进行简单处理，并写到各种数据接收方(比如文本，HDFS，Hbase等)。Flume NG采用的是三层架构：Agent层，Collector层和Store层，每一层均可水平拓展。其中Agent包含Source，Channel和 Sink，source用来消费(收集)数据源到channel组件中

用一个例子介绍集群与分布式： 小餐馆原来只有一个厨师，切菜洗菜备料炒菜他都全干。后来餐馆的客人多了，厨房里一个厨师忙不过来，又请了个厨师，两个厨师都能炒一样的菜，这两个厨师的关 系是集群。为了让厨师专心炒菜，把菜做到极致，又请了个配菜师负责切菜，备菜，备料，厨师和配菜师的关系是分布式，一个配菜师也忙不过来了，又请了个配菜 师，两个配菜师关系是集群。 一、分布式： 分布式是指将多台服务器集中在一起，每台服务器都实现总体中的不同业务，做不同的事情。并且每台服务器都缺一不可，如果某台服务器故障，则网站部分功能缺失，或导致整体无法运行。存在的主要作用是大幅度的提高效率，缓解服务器的访问和存储压力。 分布式的优点是细化了应用程序的功能模块，同时也减轻了一个完整的应用程序部署在一台服务器上的负担，用了分布式拆分后，就相当于把一个应用程序的多个功能分配到多台服务器上去处理了。 注意：该图中最大特点是：每个Web服务器（Tomcat）程序都负责一个网站中不同的功能，缺一不可。如果某台服务器故障，则对应的网站功能缺失，也可以导致其依赖功能甚至全部功能都不能够使用。 二、集群： 集群是是指将多台服务器集中在一起，每台服务器都实现相同的业务，做相同的事情。但是每台服务器并不是缺一不可，存在的作用主要是缓解并发压力和单点故障转移问题。可以利用一些廉价的符合工业标准的硬件构造高性能的系统。实现：高扩展

如果我们正在使用Session，那么构建高性能可扩展的ASP.NET网站，就必须解决分布式Session的架构，因为单服务器的SESSION处理能力会很快出现性能瓶颈，这类问题也被称之为Session同步。微软有自己的分布式Session的解决方案，那就是SessionStateServer，我们可以参考： ASP.NET Session State Partitioning http://blog.maartenballiauw.be/post/2008/01/23/ASPNET-Session-State-Partitioning.aspx ASP.NET load balancing and ASP.NET state server http://blog.maartenballiauw.be/post/2007/11/ASPNET-load-balancing-and-ASPNET-state-server-(aspnet_state).aspx 不过本文是要换一个方案，那就是使用Memcached来到达分布式SESSION的架构。Memcached作为分布式的缓存服务器已经被广泛应用在网站建设中。 一：Session的机制 Session是针对用户的，我们也可以理解为是针对浏览器的。在浏览器首次访问ASP.NET网页的时候（网页没有关闭session功能）

WCF是FrameWork3.0下的分布式框架。 本文讨论WCF与现行分布式通讯框架的性能对比。要求阅读者有一定的WCF基础（可以参照 Windows Communication Foundation Architecture Overview ）。 2：目标 本文的目的是WCF与现存的分布式通讯技术进行对比。这些现存的分布式通讯结构如下： ASP.NET Web Services (ASMX) Web Services Enhancements (WSE) .NET Enterprise Services (ES) .NET Remoting 本文中提供的场景和技术对于理解不同技术的性能来说非常有用，但是不能作为选择某项架构的决定因素。因为优秀的SOA架构依赖于服务本身而不在于通讯技术。 3：对比 所收集的数据来自于相同的硬件环境。如图14所示。提供足够多的客户端使服务端满负荷运行。测试过程中的数据为平均数值。本为旨在比较“吞吐量”图表中的线段越高性能越优越。 3.1 ASP .NET Web Services (ASMX) 本次比较WebService和WCF，比较的内容是客户端和服务端交互的性能。客户端请求整型的数据服务端获取请求分别返回1，10以及100个对象的数组。 服务端方法为 Order[] GetOrders( int NumOrders); { Order[]

本文转载自 石杉的架构笔记 背景引入 首先，我们一起来看看这个问题的背景？ 前段时间有个朋友在外面面试，然后有一天找我聊说：有一个国内不错的电商公司，面试官给他出了一个场景题： 假如下单时，用分布式锁来防止库存超卖，但是是每秒上千订单的高并发场景，如何对分布式锁进行高并发优化来应对这个场景？ 他说他当时没答上来，因为没做过没什么思路。其实我当时听到这个面试题心里也觉得有点意思，因为如果是我来面试候选人的话，应该会给的范围更大一些。 比如，让面试的同学聊一聊电商高并发秒杀场景下的库存超卖解决方案，各种方案的优缺点以及实践，进而聊到分布式锁这个话题。 因为库存超卖问题是有很多种技术解决方案的，比如悲观锁，分布式锁，乐观锁，队列串行化，Redis原子操作，等等吧。 但是既然那个面试官兄弟限定死了用分布式锁来解决库存超卖，我估计就是想问一个点：在高并发场景下如何优化分布式锁的并发性能。 我觉得，面试官提问的角度还是可以接受的，因为在实际落地生产的时候，分布式锁这个东西保证了数据的准确性，但是他天然并发能力有点弱。 刚好我之前在自己项目的其他场景下，确实是做过高并发场景下的分布式锁优化方案，因此正好是借着这个朋友的面试题，把分布式锁的高并发优化思路，给大家来聊一聊。 库存超卖现象是怎么产生的？ 先来看看如果不用分布式锁，所谓的电商库存超卖是啥意思？大家看看下面的图： 这个图，其实很清晰了

本文围绕如下几点进行阐述: 为什么使用消息队列？ 使用消息队列有什么缺点? 消息队列如何选型? 如何保证消息队列是高可用的？ 如何保证消息不被重复消费? 如何保证消费的可靠性传输? 如何保证消息的顺序性？ 1. 为什么使用消息队列？ 解耦，异步，限流 1.1 解耦 1.1.1 传统模式 传统模式的缺点： 系统间耦合性太强，如上图所示，系统A在代码中直接调用系统B和系统C的代码，如果将来D系统接入，系统A还需要修改代码，增加维护难度 1.1.2 中间件模式 中间件模式的的优点： 将消息写入消息队列，需要消息的系统自己从消息队列中订阅，从而系统A不需要做任何修改。 1.2 异步 1.2.1 传统模式 传统模式的缺点： 一些非必要的业务逻辑以同步的方式运行，太耗费时间。 1.2.2 MQ中间件模式 中间件模式的的优点： 将消息写入消息队列，非必要的业务逻辑以异步的方式运行，加快响应速度 1.3 限流 1.3.1 传统模式 传统模式的缺点： 并发量大的时候，所有的请求直接怼到数据库，造成数据库连接异常 1.3.2 中间件模式 中间件模式的的优点： 系统A慢慢的按照数据库能处理的并发量，从消息队列中慢慢拉取消息。在生产中，这个短暂的高峰期积压是允许的。 2. 使用消息队列有什么缺点? 导致系统可用性降低，若MQ发生故障会影响系统可用性。系统复杂性增加，引入MQ会引入新的关注点

2018 年 12 月 25 日，在 TGO 鲲鹏会杭州分会「E 家宴」的现场，阿里巴巴系统软件、中间件、研发效能负责人毕玄做了《云时代的软件架构》分享，本文根据其演讲整理而成，有部分删节。TGO 鲲鹏会公众号（ID：tgo-kunpenghui）授权 InfoQ 转载。1奠定阿里五年业务快速发展基础的架构改造 阿里经历了几次较大的软件架构迭代，首先是分布式时代的阿里电商架构。淘宝从 2007 年开始做新一轮架构改造，淘宝从 2007 年开始碰到的最大的问题，即访问量增长太快，导致出现了一个问题：不能加机器了，即伸缩性的问题。淘宝在业务发展过程中，2008 年以前所有的解决方案就是简单加机器就能解决，但是到 2007 年突然出现加不了，那时候淘宝数据库用的是中国最好的 IBM 的小型机。 以前数据库连接我们用 Oracle，Oracle 数据库最大的问题是每个链接消耗的内存特别大。因为内存始终有瓶颈，所以当我们内存、数据库连接不够的时候，我们的解决办法是多插内存条，后来内存条插满了，就没有办法了。所以 2007 年淘宝判断必须做新一轮的架构改造，让我们具备水平伸缩能力。 大家现在都知道一个思路，既然一个系统加不了机器，数据库抗不住，那就把一个数据库拆成两个数据库，把访问数据库的业务尽可能集中。以交易为例，以前是所有的 web 应用都要访问的，如果你把交易逻辑抽象出来