一张图简介分布式架构架全貌

前言：

本文在书写之前，拜读了张开涛：《亿级流量网站架构核心技术》一书，该书写的系统性很强，建议购买阅读。

本文仅代表个人观点。

本文通过一张图，将分布式开源技术的知识点串起来，方便整体了解和查阅。

整体架构

下图源于《亿级流量网站架构核心技术》一书。描述的是一个比较完整的电商系统架构。

整体架构分为六层：网络接入层、web接入层、服务层、数据缓存层、数据DB层。

一、网络接入层与应用接入层

在网络接入层中，DNS之后，通常会配置软负载。

硬件负载均衡器，F5、A10等，读者们应该都不会陌生。接下来，我们看看软负载如何实现的。

常见的软负载，有LVS、HAproxy、NGINX等。下面我们进行简单对比：

1.1 软负载支持的路由方式

1.1.1.NAT方式

1.1.2.Direct Routing方式

从访问方式看，在NAT方式下，客户端请求入口和出口相同，都会经过软负载。而在Director Route方式下，客户端请求入口和出口不同，因此软负载的压力会小很多。

目前LVS和HAproxy都支持NAT和DR这两种方式。

1.2.性能极限

HAproxy性能参考：http://www.haproxy.org/10g.html

单个haproxy节点跑满10Gbps吞吐，单个haproxy单位时间响应最大请求数为20000个，可以维护40000个并发连接。

关于LVS的最大性能。此前我们内部做的一些测试，单个LVS节点可以维护超过10万的并发连接。

而一位淘宝的大牛，通过优化，可以将LVS达到如下性能：

1.3.方案建议

首先我们先看一个技术专家的建议：

http://www.jianshu.com/p/184243e36318

现在网站发展的趋势对网络负载均衡的使用是随着网站规模的提升根据不同的阶段来使用不同的技术：

第一阶段：利用Nginx或者HAProxy进行单点的负载均衡，这一阶段服务器规模刚脱离开单服务器、单数据库的模式，需要一定的负载均衡，但是仍然规模较小没有专业的维护团队来进行维护，也没有需要进行大规模的网站部署。这样利用Nginx或者HAproxy就是第一选择，此时这些东西上手快， 配置容易，在七层之上利用HTTP协议就可以，这时是第一选择。

第二阶段：随着网络服务进一步扩大，这时单点的Nginx已经不能满足，这时使用LVS或者商用F5就是首要选择，Nginx此时就作为LVS或者 F5的节点来使用，具体LVS或者F5的是选择是根据公司规模，人才以及资金能力来选择的，这里也不做详谈，但是一般来说这阶段相关人才跟不上业务的提 升，所以购买商业负载均衡已经成为了必经之路。

第三阶段：这时网络服务已经成为主流产品，此时随着公司知名度也进一步扩展，相关人才的能力以及数量也随之提升，这时无论从开发适合自身产品的定制，以及降低成本来讲开源的LVS，已经成为首选，这时LVS会成为主流。 最终形成比较理想的状态为：F5/LVS<—>Haproxy<—>Squid/Varnish<—>AppServer。

以上的观点我基本赞同。

笔者的建议是，对于金融行业对软负载有一定性能要求的场景，可以使用LVS+HAproxy两层架构来实现软负载。这样做到了将LVS和HAproxy做到优势互补，架构又比较简洁。

在技术支持方面，可以通过购买红帽RHEL订阅加一定量的人天服务，作为技术保障，为客户托底。

所以，在网络接入层，我们可以在DNS后架设LVS，后面再接haproxy。

在应用接入层，使用NGINX，可以实现比较好的效果。

二、Web应用层

web应用层，通常使用tomcat。大家也都比较了解，这里不做过多赘述。

值得一提的是，随着容器的盛行，不少客户已经将web应用层放到电商里。红帽官方也提供容器化的tomcat镜像：

三、服务层

京东、淘宝都有比较典型的电商，也有自己的分布式架构和微服务架构。很多电商的业务也实现了容器化。微服务未必一定需要容器化应用；但容器可以使微服务的落地更加简便。

从IT行业角度看，目前微服务架构知名度比较高的开源方案是Spring Cloud。通过Spring Cloud与容器进行结合，能够较为便捷地构建电商类的互联网架构。此前，笔者通过实验进行过验证。

例如下面实验案例的电商平台，是模拟To C网购的，名字叫coolstore。用户登录这个网站，可以购买如红帽子、杯子、T-Shirt、眼镜物品，就如同我们在京东、天猫的购物体验相同。

电商的微服务架构，如下图，每一个模块都是一个微服务。

从最外端的Web UI开始，这是一个用node.js写的微服务。用于对外提供访问，接受用户的请求。接下来是CoolStore的GW,其实就是这套微服务的API Gateway，Spring boot书写。指向到CoolStore的GW的Hystrix和Turbine负责微服务的熔断。

接下来的六个微服务，从左右往右：Rating Service、Review Service、Inventory Service、Catelog Service、Cart Service、Pricing Service。则是我们网购的时候，调用后端的微服务。其实也就是网购具体的应用。

接下来，我们详细解释每一个微服务对网购的作用：

• Catelog Service，也就是目录服务 - JBoss 的Java应用程序，为零售产品提供产品和价格.
• Cart Service,也就是购物车服务 - 在每个客户管理购物车的JDK上运行的Spring Boot应用程序
• Inventory Service，也就是库存服务 - 在JBoss EAP 7和PostgreSQL上运行的Java EE应用程序，为零售产品提供库存和可用性数据
• Pricing Service，也就是定价服务 - JBoss BRMS产品定价业务规则应用
• Review Service，也就是审查服务 - 在JDK上运行的WildFly Swarm服务，用于撰写和显示产品评论
• Rating Service，也就是评级服务 - 在JDK上运行的Vert.x服务用于评级产品
• Coolstore API网关 - 在JDK上运行的Spring Boot + Camel应用程序作为后端服务的API网关。
• Web UI - 在Node.js容器中运行的基于AngularJS和PatternFly的前端。也就是客户访问电商的界面展示。

我们可以看到，在上图中，Rating Service、Review Service、Inventory Service、Catelog Service这四个微服务，都有自己的数据库。这其实正是符合微服务的share as little as possible原则。即说微服务应该尽量设计成边界清晰不重叠，数据独享不共享。实现所谓的“高内聚、低耦合”。这样有助于实现独立可部署（independently deployable）。

四、缓存层

目前分布式架构中的缓存，比较流行的就是redis。Redis是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。

缓冲分为两种：应用层缓存和分布式缓存。

1.应用层缓存：是在应用服务器上部署一套Redis，称之为local redis cache。也就是说，应用直接读取本机redis获取数据。应用服务器读取本地redis，适用于数据量访问不是特别大的情况。如果特别大，则需要使用分布式缓存。

2.分布式缓存：如果数据访问量达到单个应用服务器无法承受，则需要使用分部署redis缓存。

4.1 Redis集群部署方式

Redis-Sentinel是Redis官方推荐的高可用性(HA)解决方案，当用Redis做Master-slave的高可用方案时，假如master宕机了，Redis本身(包括它的很多客户端)都没有实现自动进行主备切换，而Redis-sentinel本身也是一个独立运行的进程，它能监控多个master-slave集群，发现master宕机后能进行自懂切换。

Sentinel它的主要功能有以下几点：

• 不时地监控redis是否按照预期良好地运行;
• 如果发现某个redis节点运行出现状况，能够通知另外一个进程(例如它的客户端);
• 能够进行自动切换。当一个master节点不可用时，能够选举出master的多个slave(如果有超过一个slave的话)中的一个来作为新的master,其它的slave节点会将它所追随的master的地址改为被提升为master的slave的新地址。

目前Redis集群有多种部署方案：

方案一：全套Sentinel主备监控切换功能

此方案存在以下优点：

• 官方2.8之后的主流方案。存在大量案例经受考验。
• 有人贡献单独的console进行管理。

此方案存在以下缺点：

• 应用端须采用Sentinel的接入方式，对现有接口API部分需要进行调整。
• 同时目前jedis版本不支持同时支持Sentinel和sharding。可能需要进行取舍。
• 仲裁机制比较复杂。目前项目中可能采用更为简洁的方式就可以。部分Redis的切换依赖于自开发脚本；因主备切换存在丢失数据可能，因此对主备切换较为审慎的，采用人工审核确认后手动切换。
• 需要独立部署Sentinel集群以监控Redis主从，从而引入更多的依赖。

方案二：Sentinel感应升主+F5感应并VIP切换

此方案存在以下优点：

• 因为应用端不采用Sentinel的接入方式，对现有接口API部分不需要进行调整。

此方案存在以下缺点：

• 和现有方案一样，F5和Sentinel无法同步协作，健康检测部分重复，对master的不可用确认，可能会存在时间差，从而对Redis主备提升的衔接出现问题。
• 目前采用此种方式的案例比较少。

需要独立部署Sentinel集群以监控Redis主从，从而引入更多的依赖

方案三：Redis Cluster加主从切换

在Redis的3的大版本中，已经自带了Redis Cluster。除了主要提供分片集群的功能，还涵盖了sentinel中主从检测切换的功能。

此方案存在以下优点：

• 因为应用端不采用Sentinel的接入方式，对现有接口API部分不需要进行调整。
• 将主从选择和切换交由集群负责，免去原有架构中人工脚本或Sentinel外部的依赖
• 部署结构相对简单，建议容器化处理

五、数据层/DB

在分布式架构中，大多数的RDBMS已经使用MySQL。

目前，MySQL集群实现方式主要有以下两种：

1. 主从复制

2. 基于Galera协议复制

基于Galera协议复制的方式，对应能损耗较大，本文篇幅有限，暂不进行讨论。

基于主从复制的Mysql集群，有三种配置方式。

1. 一主一从

2. Master High Availability集群（MHA）

MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。

3. Master-Master replication manager for MySQL（MMM）

MMM（Master-Master replication manager for MySQL）是一套支持双主故障切换和双主日常管理的脚本程序。MMM使用Perl语言开发，主要用来监控和管理MySQL Master-Master（双主）复制，虽然叫做双主复制，但是业务上同一时刻只允许对一个主进行写入，另一台备选主上提供部分读服务，以加速在主主切换时刻备选主的预热，可以说MMM这套脚本程序一方面实现了故障切换的功能，另一方面其内部附加的工具脚本也可以实现多个slave的read负载均衡。

在以上三种模式中，双节点主从配置最简单高效；MHA最为成熟，MMM比较复杂，不建议使用。

参考文献：

《亿级流量网站架构核心技术》张开涛

https://db-engines.com/en/ranking

http://www.cnblogs.com/lben/archive/2012/11/19/2777632.html

http://www.cnblogs.com/gomysql/p/3671896.html

https://github.com/jbossdemocentral/coolstore-microservice。

https://baike.baidu.com/item/%E6%AD%A3%E5%90%91%E4%BB%A3%E7%90%86/9524799?fr=aladdin

https://baike.baidu.com/item/%E5%8F%8D%E5%90%91%E4%BB%A3%E7%90%86/7793488?fr=aladdin

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Load_Balancer_Administration/ch-keepalived-overview-VSA.html#s1-lvs-basic-VSA

http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.performance.html

https://wenku.baidu.com/view/62eb30050740be1e650e9af4.html

http://www.ha97.com/5646.html

http://blog.csdn.net/gzh0222/article/details/8540604

http://blog.csdn.net/chengxuyuanyonghu/article/details/60468829