分布式专题1-了解分布式

前言

      我是一名工作时间不长但是也不短的java民工。因为在小城市发展，所以程序开发仅仅是单机就能搞定一切业务啦。这也导致自己能力停滞不前。写这个专栏不仅仅是为了拓宽视野，同时也希望能够增长一些知识。本专栏是我一边不断学习一边总结的结果，可能有不对的地方，如有发现请及时告知，万分感激！因为也是作为初学者，所以专栏对于新手来说可能较为友好，我会将我学习过程中遇到的疑问一一列出来，尽自己全力进行解答。

      如今在招聘网站上，经常能看到要求有分布式经验的。而且分布式和集群以及大数据常常挂在很高端的讨论位置上，那么什么是分布式？什么是集群？为什么会有他们呢？我相信大部分人都能说出各七七八八，如今学习一定时间以后，我发现其实分布式和集群就是用来折磨人的。因为单机的应用，也就是我们常用的tomcat+jsp+servlet+mysql架构就能搞定一般的小型应用了，不仅部署简单而且便于修改，查找错误也较为迅速。但是唯一的缺点就是能支持的访问量有限，试想一台计算机能够同时支持多大的访问呢？更何况我们常常是将应用与数据库同时部署在一台服务器上，让其进行资源的竞争。

有人会说一台不够就两台，两台不够加N台。这个问题将在下面给出答案。不单纯的靠增加机器来应对业务的井喷式增长就是集群以及分布式会出现的原因。

1.什么是分布式？

     我们以一个电商应用为例，首先电商应用包括：用户管理、订单管理、支付管理以及库存管理等等。如果按照单机应用部署的话，假设可能支持的访问量只有500，这里的访问量指并发状态下的500。架构如下：

 

然而当我们业务发展很好，用户数据大量增加时，这一台机器就将无法满足业务需求，最先想到的方案就是加机器。如果业务一直增加，那么完全靠加机器吗？这种方法可以实现，但是金钱不允许啊，况且其中的一些业务仅仅是用的较为少资源的一个功能，这样过于浪费资源。这个时候就是涉及到分布式系统来解决这个问题。

分布式系统中的多个模块在不同服务器上部署，即可称为分布式系统，如Tomcat和数据库分别部署在不同的服务器上，或两个相同功能的Tomcat分别部署在不同服务器上。

主要涉及两个问题：

• 任务分解
• 节点通信

      任务分解就是将电商的每个功能都单独作为一个功能，你可以理解为将原来的一个应用分为多个应用进行部署。至于具体如何分解就需要根据具体业务以及业务的访问情况来划分啦。

       节点通信就是各个功能拆分出来以后，部署到相应的服务器上，那么服务器相互之间如何进行通信？现在我们常用的都是httpClient或者较为老的WebService或者目前的restful风格的接口调用，实际这里涉及的知识就是网络通信以及网络传输。

2.分布式和集群的关系？

他们的关系就是

集群保证高可用

分布式保证高性能

分布式将拆分的应用部署在单机上，这样足以满足高并发带来的访问量。而当例如像订单这样的业务较为多时，可以将订单这样的业务进行集群部署，什么是集群呢？

集群我个人理解就是将同一应用部署到多台服务器上。这样当其中一台机器挂掉的时候，用户依旧可以对该应用进行访问，从而

提高了可用性，这样妈妈再也不用担心我访问不到购买页面啦。

我们常说大型网站才需要分布式以及集群架构，那么什么是大型网站呢？用什么指标来衡量呢？分布式和集群一定要一起出现吗？

我们经常开发的管理系统怎么就不用这个分布式呢？

3.什么是大型架构（或什么是大型网站）

• 访问量（tbs,qps）
• 数据量(存储数据量)

   当访问量以及数据量到达一定程度时就是大型网站了。例如当访问量每秒到1000次或者数据存储量达到一定规模时。例如TB级别。那这里是大数据了吗？严格讲不是的，大数据不是说数据达到一定量了，而大数据是对海量数据进行处理分析才叫大数据，这里单纯知识存储，谈不上大数据。如果你想通过这些购买数据来分析用户的购买意向，那就需要大数据来帮忙了。

  至于大型网站为什么要用分布式架构，最合理的解释就是解决高并发、高访问量问题。而集群也是为了配合其处理该类问题。其实一切新技术或者新的架构都是为了更好的服务人们，没有最好，只有最适合。

   说了这么多，接下来我们通过架构的演变来说明分布式架构的发展以及涉及的问题和解决方案。

这里提一句，如果相对自己单机项目进行压力测试的话，使用roadrunner或jmeter都可以。

4.名词解释

为了更好的解释分布式系统，下面名词请记住：

高可用系统中部分节点失效时，其他节点能够接替它继续提供服务，则可认为系统具有高可用性

集群一个特定领域的软件部署在多台服务器上并作为一个整体提供一类服务，这个整体称为集群。如Zookeeper中的Master和Slave分别部署在多台服务器上，共同组成一个整体提供集中配置服务。在常见的集群中，客户端往往能够连接任意一个节点获得服务，并且当集群中一个节点掉线时，其他节点往往能够自动的接替它继续提供服务，这时候说明集群具有高可用性

负载均衡请求发送到系统时，通过某些方式把请求均匀分发到多个节点上，使系统中每个节点能够均匀的处理请求负载，则可认为系统是负载均衡的

正向代理和反向代理系统内部要访问外部网络时，统一通过一个代理服务器把请求转发出去，在外部网络看来就是代理服务器发起的访问，此时代理服务器实现的是正向代理；当外部请求进入系统时，代理服务器把该请求转发到系统中的某台服务器上，对外部请求来说，与之交互的只有代理服务器，此时代理服务器实现的是反向代理。简单来说，正向代理是代理服务器代替系统内部来访问外部网络的过程，反向代理是外部请求访问系统时通过代理服务器转发到内部服务器的过程。

5.架构演变

还是以电商平台为例，（谁让电商平台用户量这么大呢）

1.单机架构

网站最初用户量较少，应用以及数据库部署在同一服务器上。

发展瓶颈：随着用户数的增长，Tomcat和数据库之间竞争资源，单机性能不足以支撑业务

2.第一次演变，tomcat和数据库分离部署

Tomcat和数据库分别独占服务器资源，显著提高两者各自性能。

发展瓶颈：随着用户数的增长，并发读写数据库成为瓶颈。

3.第二次演变，引入本地缓存和分布式缓存

在Tomcat同服务器上或同JVM中增加本地缓存，并在外部增加分布式缓存，缓存热门商品信息或热门商品的html页面等。通过缓存能把绝大多数请求在读写数据库前拦截掉，大大降低数据库压力。其中涉及的技术包括：使用ehcache或memcached作为本地缓存，使用Redis作为分布式缓存，还会涉及缓存一致性、缓存穿透/击穿、缓存雪崩、热点数据集中失效等问题。

发展瓶颈：缓存抗住了大部分的访问请求，随着用户数的增长，并发压力主要落在单机的Tomcat上，响应逐渐变慢。

4.第三次演变，引入反向代理实现负载均衡

此时tomcat分别部署不同机器，使用反向代理软件（Nginx）把请求均匀分发到每个Tomcat中。其中涉及的技术包括：Nginx、HAProxy，两者都是工作在网络第七层的反向代理软件，主要支持http协议，还会涉及session共享、文件上传下载的问题。

发展瓶颈：反向代理使应用服务器可支持的并发量大大增加，但并发量的增长也意味着更多请求穿透到数据库，单机的数据库最终成为瓶颈

5.第四次演变，数据库读写分离

把数据库划分为读库和写库，读库可以有多个，通过同步机制把写库的数据同步到读库，对于需要查询最新写入数据场景，可通过在缓存中多写一份，通过缓存获得最新数据。其中涉及的技术包括：Mycat，它是数据库中间件，可通过它来组织数据库的分离读写和分库分表，客户端通过它来访问下层数据库，还会涉及数据同步，数据一致性的问题。

发展瓶颈：业务逐渐变多，不同业务之间的访问量差距较大，不同业务直接竞争数据库，相互影响性能

6.第五次演变，数据库按业务分库

把不同业务的数据保存到不同的数据库中，使业务之间的资源竞争降低，对于访问量大的业务，可以部署更多的服务器来支撑。这样同时导致跨业务的表无法直接做关联分析，需要通过其他途径来解决。同时也可以根据业务不同进行分库这种做法显著的增加了数据库运维的难度，对DBA的要求较高。数据库设计到这种结构时，已经可以称为分布式数据库，但是这只是一个逻辑的数据库整体，数据库里不同的组成部分是由不同的组件单独来实现的，如分库分表的管理和请求分发，由Mycat实现，SQL的解析由单机的数据库实现，读写分离可能由网关和消息队列来实现，查询结果的汇总可能由数据库接口层来实现等等，这种架构其实是MPP（大规模并行处理）架构的一类实现。

发展瓶颈：数据库和Tomcat都能够水平扩展，可支撑的并发大幅提高，随着数据的丰富程度和业务的发展，检索、分析等需求越来越丰富，单单依靠数据库无法解决如此丰富的需求

7.第六次演变，引入NoSQL数据库和搜索引擎等技术

当数据库中的数据多到一定规模时，数据库就不适用于复杂的查询了，往往只能满足普通查询的场景。对于统计报表场景，在数据量大时不一定能跑出结果，而且在跑复杂查询时会导致其他查询变慢，对于全文检索、可变数据结构等场景，数据库天生不适用。因此需要针对特定的场景，引入合适的解决方案。如对于海量文件存储，可通过分布式文件系统HDFS解决，对于key value类型的数据，可通过HBase和Redis等方案解决，对于全文检索场景，可通过搜索引擎如ElasticSearch解决，对于多维分析场景，可通过Kylin或Druid等方案解决。

当然，引入更多组件同时会提高系统的复杂度，不同的组件保存的数据需要同步，需要考虑一致性的问题，需要有更多的运维手段来管理这些组件等。

发展瓶颈：引入更多组件解决了丰富的需求，业务维度能够极大扩充，随之而来的是一个应用中包含了太多的业务代码，业务的升级迭代变得困难

8.第七次演变，大应用拆分为小应用

按照业务板块来划分应用代码，使单个应用的职责更清晰，相互之间可以做到独立升级迭代。这时候应用之间可能会涉及到一些公共配置，可以通过分布式配置中心Zookeeper来解决。

 

发展瓶颈：不同应用之间存在共用的模块，由应用单独管理会导致相同代码存在多份，导致公共功能升级时全部应用代码都要跟着升级

9.第八次演变，复用的功能抽离成微服务

如用户管理、订单、支付、鉴权等功能在多个应用中都存在，那么可以把这些功能的代码单独抽取出来形成一个单独的服务来管理，这样的服务就是所谓的微服务，应用和服务之间通过HTTP、TCP或RPC请求等多种方式来访问公共服务，每个单独的服务都可以由单独的团队来管理。此外，可以通过Dubbo、SpringCloud等框架实现服务治理、限流、熔断、降级等功能，提高服务的稳定性和可用性。

发展瓶颈：不同服务的接口访问方式不同，应用代码需要适配多种访问方式才能使用服务，此外，应用访问服务，服务之间也可能相互访问，调用链将会变得非常复杂，逻辑变得混乱