分布式系统的演进和架构ppt课件.pptx
分布式系统的演进和架构,背景,随着社会的发展，技术的进步，以前的大型机架构由于高成本、难维护等原因渐渐地变得不再那么主流了，取而代之的是分布式架构，从大型机到分布式，经历了好几个阶段，我们弄明白各个阶段的架构，才能更好地理解和体会分布式架构的好处。 成熟的大型网站的系统架构并非从开始就能设计的非常完美，也并非一开始就具备高性能、高并发、高可用、安全性等特性，而是随着用户量的增加、业务功能的扩展逐步演变过来，慢慢的完善的。 针对不同业务特征的系统，各自都会有自己的侧重点，比如淘宝这类的网站，要解决的重点问题是商品搜索、下单、支付等问题; 腾讯类的网站，要解决的是数亿级别用户的实时消息传输;而百度类的公司所要解决的是海量数据的搜索。每一个种类的业务都有自己不同的系统架构,背景,下面我们来简单的模拟一个架构的演变过程。 搭建一个简单的电商系统，从这个系统中看系统的演变过程。注意的是接下来的演示模型， 主要关注的是数据量、访问量提升，网站结构的变化， 而不关注具体业务的功能点。其次，这个过程是为了让大家能更好的了解网站演进过程中的一些问题和应对策略。 假如我们系统具备以下功能:用户模块:用户注册和管理。商品模块:商品展示和管理。交易模块:创建交易及支付结算。,阶段一,这个阶段是网站的初期，也可以认为是互联网发展的早期，系统架构如上图所示。我们经常会在单台服务器上运行我们所有的程序和软件。 把所有软件和应用都部署在一台机器上，这样就完成一个简单系统的搭建，在这个阶段的追求的主要是效率。,阶段二：应用服务器和数据库服务器分离,随着网站的上线，访问量逐步上升，服务器的负载慢慢提高，我们应该在服务器还没有超载的时候就做好规划、提升网站的负载能力。假若此时已经没办法在代码层面继续优化提高，那么在单台机器的性能遇到瓶颈的时候，增加机器是一个比较简单好用的方式，投入产出比相当高。这个阶段增加机器的主要目的是将 web 服务器和 数据库服务器拆分开来，这样做的话不仅提高了单机的负载能力，也提高了整个系统的容灾能力。,阶段二：应用服务器和数据库服务器分离,这个阶段的系统架构，应用服务器和数据库服务器完全隔离开来，相互互不影响，大大减少了网站宕机的风险，此阶段我们已经开始关注到应用服务器的管理了。,阶段三：应用服务器集群,这个阶段，随着访问量的继续不断增加，单台应用服务器已经无法满足我们的需求。 假设数据库服务器还没有遇到性能问题，那我们可以通过增加应用服务器的方式来将应用服务器集群化，这样就可以将用户请求分流到各个服务器中，从而达到继续提升系统负载能力的目的。此时各个应用服务器之间没有直接的交互，他们都是依赖数据库各自对外提供服务。,阶段三：应用服务器集群,系统架构发展到这个阶段，各种问题也会接踵而至：用户请求交由谁来转发到具体的应用服务器上(谁来负责负载均衡)用户如果每次访问到的服务器不一样，那么如何维护session，达到session共享的目的。那么此时，系统架构又会变成如下方式,阶段三：应用服务器集群,负载均衡又可以分为软负载和硬负载。软负载我们可以选择Nginx、Apache等，硬负载我们可以选择F5等。而session共享问题我们可以通过配置tomcat的session共享解决。,阶段四：数据库压力变大，数据库读写分离,架构演变到上面的阶段，并不是终点。通过上面的设计，应用层的性能被我们拉上来了， 但数据库的负载也在逐渐增大，那如何去提高数据库层面的性能呢？有了前面的设计思路以后，我们自然也会想到通过增加服务器来提高性能。但假如我们单纯的把数据库一分为二，然后对于数据库的请求，分别负载到两台数据库服务器上，那必定会造成数据库数据不统一的问题。 所以我们一般先考虑将数据库读写分离。,阶段四：数据库压力变大，数据库读写分离,这个架构设计的变化会带来如下几个问题：主从数据库之间的数据需要同步(可以使用 mysql 自带的 master-slave 方式实现主从复制 )应用中需要根据业务进行对应数据源的选择( 采用第三方数据库中间件，例如 mycat ),阶段五：使用搜索引擎缓解读库的压力,我们都知道数据库常常对模糊查找效率不是很高，像电商类的网站，搜索是非常核心的功能，即使是做了读写分离，这个问题也不能得到有效解决。那么这个时候我们就需要引入搜索引擎了，使用搜索引擎能够大大提升我们系统的查询速度，但同时也会带来一 些附加的问题，比如维护索引的构建、数据同步到搜索引擎等。,阶段六：引入缓存机制缓解数据库的压力,随着访问量的持续不断增加，逐渐会出现许多用户访问同一内容的情况，那么对于这些热点数据，没必要每次都从数据库重读取，这时我们可以使用到缓存技术，比如 redis、memcache 来作为我们应用层的缓存。另外在某些场景下，如我们对用户的某些 IP 的访问频率做限制， 那这个放内存中就又不合适，放数据库又太麻烦了，那这个时候可以使用 Nosql 的方式比如 mongDB 来代替传统的关系型数据库。,阶段七：数据库的水平/垂直拆分,我们的网站演进的变化过程，交易、商品、用户的数据都还在同一 个数据库中，尽管采取了增加缓存，读写分离的方式，但是随着数据库的压力持续增加，数据库的瓶颈仍然是个最大的问题。因此我 们可以考虑对数据的垂直拆分和水平拆分。垂直拆分:把数据库中不同业务数据拆分到不同的数据库。,阶段七：数据库的水平/垂直拆分,水平拆分:把同一个表中的数据拆分到两个甚至更多的数据库中，水平拆分的原因是某些业务数据量已经达到了单个数据库的瓶颈，这时可以采取将表拆分到多个数据库中。,阶段八：应用的拆分,随着业务的发展，业务量越来越大，应用的压力越来越大。工程规模也越来越庞大。这个时候就可以考虑将应用拆分，按照领域模型将我们的用户、商品、交易拆分成多个子系统。 这样拆分以后，可能会有一些相同的代码，比如用户操作，在商品和交易都需要查询，所以会导致每个系统都会有用户查询访问相关操作。这些相同的操作一定是要抽象出来，否则就是一个大问题。所以可以通过走服务化路线的方式来解决。,阶段八：应用的拆分,那么服务拆分以后，各个服务之间如何进行远程通信呢? 通过 RPC 技术，比较典型的有:dubbo、webservice、hessian、http、RMI 等等。前期通过这些技术能够很好的解决各个服务之间通信问题，但是， 互联网的发展是持续的，所以架构的演变和优化也还在持续。,分布式系统的意义,之所以要发展分布式系统架构，是因为单机系统存在着如下诸多缺点等待被解决：升级单机处理能力的性价比越来越低我们知道单机的处理能力主要依靠 CPU、内存、磁盘。通过升级硬件来这种垂直扩展的方式来提升性能，成本会越来越高。性价比会越来越低。单机处理能力存在瓶颈并且单机处理能力存在瓶颈，CPU、内存、磁盘都会有自己的性能瓶颈， 就算你不惜成本去提升硬件，但是硬件的发展速度和性能也还是有限制的。稳定性和可用性这两个指标很难达到最后就是单机系统存在可用性和稳定性的问题，这两个指标又是我们亟待要去解决的问题。,分布式系统的优势,资源共享。系统中的数据、程序、外设等资源都可由各子系统共享，这也是提高性 能价格比的重要方面，同时也增加了系统的适应性与灵活性。性能价格比高。采用低价的微机构成高性能的系统，与同样功能的大、中型计算机 相比，分布式多微机系统的价格仅为几分之一甚至几十分之一 采用模块化结构。使系统容易实现通用化与系列化，系统的扩充也很方便，还可以 对系统进行重构，实时地动态分配与管理系统，以适应不同环境和用户的要求。 可靠性高。子系统故障一般不会影响全局，可由其它子系统以“容错”方式带故障 运行。各子系统间还可互相诊断、检测和保护，从而提高了整个系统的可靠性。 响应速度快。可通过并行处理或各子系统分别处理来实现快速响应。集中式控制则采用分时处理方式对多个对象的申请按优先级排队响应，往往滞后与等待时间较长。,主流的分布式架构,SOA架构解析SOA 全称是: Service Oriented Architecture，中文释义为 “面向服务的架构”，它是一种设计理念，其中包含多个服务， 服务之间通过相互依赖最终提供一系列完整的功能。各个服务通常以独立的形式部署运行，服务之间 通过网络进行调用。架构图如下,主流的分布式架构,ESB (企业服务总线)跟 SOA 相提并论的还有一个概念叫 ESB(企业服务总线)，简单来说 ESB 就是一根管道，用来连接各个服务节点。ESB的存在是为了集成基于不同协议的不同服务，ESB 做了消息的转化、解释以及路由的工作，以此来让不同的服务互联互通,SOA所要解决的核心问题,系统间的集成 : 我们站在系统的角度来看，首先要解决各个系统间的通信问题，目的是将原先系统间散乱、无规划的网状结构，梳理成规整、可治理的星形结构，这步的实现往往需要引入一些概念和规范，比如 ESB、以及技术规范、服务管理规范。这一步解决的核心问题是【有序】。系统的服务化 : 我们站在功能的角度，需要把业务逻辑抽象成可复用、可组装的服务，从而通过服务的编排实现业务的快速再生，目的是要把原先固有的业务功能抽象设计为通用的业务服务、实现业务逻辑的快速复用;这步要解决的核心问题是【复用】。业务的服务化 : 我们站在企业的角度，要把企业职能抽象成可复用、可组装的服务，就要把原先职能化的企业架构转变为服务化的企业架构，以便进一步提升企业的对外服务的能力。“前面两步都是从技术层面来解决系统调用、系统功能复用的问题”。而本步骤，则是以业务驱动把一个业务单元封装成一项服务。要解决的核心问题是【高效】。,主流的分布式架构,微服务（MicroServices）架构微服务架构和 SOA 架构非常类似,微服务只是 SOA 的升华，只不过微服务架构强调的是“业务需要彻底的组件化及服务化”，原先单个业务系统会被拆分为多个可以独立开发、设计、部署运行的小应用。这些小应用间通过服务化完成交互和集成。 组件表示的就是一个可以独立更换和升级的单元，就像 PC 中的 CPU、内存、显卡、硬盘一样，独立且可以更换升级而不影响其他单元。若我们把 PC 中的各个组件以服务的方式构建，那么这台 PC 只需要维护主板（可以理解为ESB）和一些必要的外部设备就可以。CPU、内存、硬盘等都是以组件方式提供服务，例如PC 需要调用 CPU 做计算处理，只需知道 CPU 这个组件的地址就可以了。,主流的分布式架构,微服务的特征,通过服务实现组件化开发者不再需要协调其它服务部署对本服务的影响。按业务能力来划分服务和开发团队开发者可以自由选择开发技术，提供 API 服务,微服务的特征,去中心化每个微服务有自己私有的数据库持久化业务数据每个微服务只能访问自己的数据库，而不能访问其它服务的数据库某些业务场景下，需要在一个事务中更新多个数据库。这种情况也不能直接访问其它微服务的数据库，而是通过对于微服务进行操作。数据的去中心化，进一步降低了微服务之间的耦合度，不同服务可以采用不同的数据库技术（SQL、NoSQL等）。在复杂的业务场景下，如果包含多个微服务，通常在客户端或者中间层（网关）处理,微服务的特征,基础设施自动化(devops、自动化部署)Java EE部署架构，通过展现层打包WARs，业务层划分到JARs最后部署为EAR一个大包，而微服务则打开了这个黑盒子，把应用拆分成为一个一个的单个服务，应用Docker技术，不依赖任何服务器和数据模型，是一个全栈应用，可以通过自动化方式独立部署，每个服务运行在自己的进程中，通过轻量的通讯机制联系，经常是基于HTTP资源API，这些服务基于业务能力构建，能实现集中化管理（因为服务太多，不集中管理就无法DevOps）。,SOA 和微服务架构的差别,微服务不再强调传统SOA架构里面比较重的ESB企业服务总线，同时以 SOA 的思想进入到单个业务系统内部实现真正的组件化。Docker 容器技术的出现，为微服务提供了非常便利的条件，比如更小的部署单元，每个服务可以通过类似 Spring Boot 或者 Node 等技术独立运行。 还有一个点大家应该可以分析出来，SOA 注重的是系统集成，而微服务关注的是完全分离。,分布式架构的基本理论,CAP 理论一个分布式系统不可能同时满足一致性(C:Consistency)、可用性(A:Availability)及分区容错性(P:Partition tolerance)这三个基本要求一致性 : 所有节点上的数据时刻保持同步可用性 : 每个请求都能接收一个响应，无论响应成功或失败分区容错 : 系统应该持续提供服务，即使系统内部(某个节点分区)有消息丢失。比如交换机失败、网址网络被分成几个子网，形成脑裂、服务器发生网络延迟或死机，导致某些 server 与集群中的其他机器失去联系。CAP 并不是一个普适性原理和指导思想，它仅适用于原子读写的 NoSql 场景中，并不适用于数据库系统。,分布式架构的基本理论,BASE 理论在分布式(数据库分片或分库存在的多个实例上)前提下，CAP 理论并不适合数据库事务(因为更新一些错误的数据而导致的失败，无论使用什么高可用方案都是徒劳的，因为数据发生了无法修正的错误)。 此外 事务虽然保证了数据库在分布式系统下的 ACID (原子性、一致性、隔离性、持久性)特性，但同时也带来了一 些性能方面的代价，对于并发和响应时间要求都比较高的电商平台来说，是无法接受的eBay 尝试了另外一条完全不同的路，放宽了数据库事务的 ACID 要求，提出了一套名为 BASE 的新准则。BASE 全称为 Basically Available,Soft-state,Eventually Consistent. 系统基本可用、软状态、数据最终一致性。相对于 CAP 来说，它大大降低了我们对系统的要求。,分布式架构的基本理论,Basically Available(基本可用)如果系统，出现了不可预知的故障，但还是能用，相比较正常的系统而言:响应时间上的损失,功能上的损失Soft state（软状态）允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时Eventually consistent（最终一致性）最终一致性强调的是系统中所有的数据副本。在经过一段时间的同步后，最终能够达到一个一致的状态。因为最终一致性是需要系统保证最终数据的能够达到一致，而不需要实时保证系统数据的一致性。,谢谢！,
