前言

负载均衡的实现

• TCP 层实现的负载均衡，例如：LVS（调度性能强悍）
• 应用层实现的负载均衡，例如：Nginx、Haproxy、Apache、Varnish、Squid、Ribbon

Keepalived 概述

Keepalived 简介

  Keepalived 是 Linux 下一个轻量级别的高可用开源解决方案，高可用 (High Avalilability)，其实两种不同的含义：广义来讲，是指整个系统的高可用行，狭义的来讲就是之主机的冗余和接管，它与 HeartBeat RoseHA 实现相同类似的功能，都可以实现服务或者网络的高可用；但是又有差别，HeartBeat 是一个专业的、功能完善的高可用软件，它提供了 HA 软件所需的基本功能，比如：心跳检测、资源接管、检测集群中的服务、在集群节点转移共享 IP 地址的所有者等等。HeartBeat 功能强大，但是部署和使用相对比较麻烦，与 HeartBeat 相比，Keepalived 主要是通过虚拟路由冗余来实现高可用功能，虽然它没有 HeartBeat 功能强大，但是 Keepalived 部署和使用非常的简单，所有配置只需要一个配置文件即可以完成。Keepalived 实现了轻量级的高可用，一般用于前端高可用，且不需要共享存储，一般常用于两个节点的高可用。而 Heartbeat 用于服务的高可用，且需要共享存储，一般用于多节点的高可用。

  Keepalived 起初是专为 LVS 设计的，用来管理并监控 LVS 集群系统中各个服务节点的状态，后来又加入了可以实现高可用的 VRRP 功能。因此，Keepalived 除了能够管理 LVS 软件外，还可以实现任意两台主机之间，例如 Master 和 Backup 主机之间的故障转移和自动切换，这个主机可以是普通的不能停机的业务服务器，也可以是 LVS 负载均衡、Nginx 反向代理这样的服务器。Keepalived 软件主要是通过 VRRP 协议实现高可用功能的，VRRP 是 Virtual Router Redundancy Protocol（虚拟路由冗余协议）的缩写，VRRP 出现的目的就是为了解决静态路由的单点故障问题的，它能保证当个别节点宕机时，整个网络可以不间断、稳定地运行。所以，Keepalived 一方面具有配置管理 LVS 的功能，同时还具有对 LVS 下面节点进行健康检查的功能，另一方面也可以实现系统网络服务的高可用功能。

索引的介绍

索引是一种特殊的文件（InnoDB 数据表上的索引是表空间的一个组成部分），包含了对数据表里所有记录的引用指针。索引分单列索引和组合索引。单列索引，即一个索引只包含单个列，一个表可以有多个单列索引，但这不是组合索引。组合索引，即一个索引包含多个列。创建索引时，需要确保该索引是应用在 SQL 查询语句的条件 (一般是 WHERE、JOIN 子句的条件)。

索引的类型（四种）

• FULLTEXT：即为全文索引，目前只有 MyISAM 引擎支持，其可以在 CREATE TABLE，ALTER TABLE，CREATE INDEX 使用，不过目前只有 CHAR、VARCHAR、TEXT 列上可以创建全文索引
• HASH：由于 HASH 的唯一性及类似键值对的形式，很适合作为索引，HASH 索引可以一次定位，不需要像树形索引那样逐层查找，因此具有极高的效率。但是，这种高效是有条件的，即只在 = 和 in 条件下才高效，对于范围查询、排序及组合索引仍然效率不高
• BTREE：一种将索引值按一定的算法，存入一个树形的数据结构中（二叉树），每次查询都是从树的入口 Root 开始，依次遍历 Node，获取 Leaf，这是 MySQL 里默认和最常用的索引类型
• RTREE：在 MySQL 很少使用，仅支持 geometry 数据类型，支持该类型的存储引擎有 MyISAM、BDb、InnoDb、NDb、Archive

Puppeteer 介绍

Puppeteer 是什么

Puppeteer 是一个 NodeJs 库，它提供了一个高级 API 来通过 DevTools 协议控制 Chromium 或 Chrome。相比较 Selenium 或是 PhantomJs，它最大的特点就是完全可以在内存中模拟 DOM 操作，即在 V8 引擎中处理而不打开浏览器，而且关键的是该项目是 Chrome 团队在维护，会拥有更好的兼容性和前景，更多资料可参考以下站点：Puppeteer Github、Puppeteer 中文文档、DevTools Protocol 文档、Chromium 命令行启动参数。

Puppeteer 的功能

• 生成页面的截图和 PDF
• 自动提交表单，进行 UI 测试，键盘输入等
• 捕获网站的时间线跟踪，用来帮助分析性能问题
• 抓取 SPA（单页应用），并生成预渲染内容，即 “SSR”（服务器端渲染）
• 创建一个最新的自动化测试环境，使用最新的 JavaScript 和浏览器功能，直接在最新版本的 Chrome 中运行测试
• 测试浏览器扩展，Chrome / Chromium 扩展当前只能在非无头模式下使用，目前还无法测试扩展弹出窗口或内容脚本

前言

容器化技术的出现标准化了服务的基础设施，统一了应用的打包分发、部署及操作系统相关类库等，解决了测试及生产部署时环境差异的问题，更方便分析排查问题。对运维来说，由于镜像的不可变性，更容易进行服务部署升级及回滚。另外利用诸如 Kubemetes 之类的容器管理平台，更容易实现一键部署、扩容、缩容等操作，更能将微服务架构、DevOps、不可变基础设施的思想落地下来。本文重点讲述 Spring Cloud 如何使用 Docker 实现容器化。

Java 服务 Docker 化

基础镜像选择

操作系统层面，可以选择传统的 Centos、Ubuntu 或者轻量级的 Alpine。其中 Ubuntu 16.04 版本的镜像大小约为 113M，压缩后大约 43M；Centos 7 版本的镜像大小约为 199M，压缩后大约为 73M；而 Alpine 3.7 版本镜像大小约为 4.15M，压缩后约为 2M。关于基础镜像的选择，一个是考虑镜像大小，一个是只提供最小的依赖包。关于第二点，不同的服务应用依赖包是不同的，这里不再展开，只从镜像大小角度考虑的话，Alpine 是首选，镜像小，远程推拉镜像的速度快，更为方便，这里建议釆用 Alpine 镜像作为基础镜像。从 Docker 镜像分层缓存的机制来考虑，如果选择了比较大的基础镜像，DockerFile 编写时可以适当分层，然后集中在几台镜像打包机上处理镜像打包及上传，这样可以充分利用打包机镜像分层缓存的机制，减少上传镜像的耗时。但是对于分布式服务的 Docker 部署，目标服务实例部署的机器比较多而且是随机的，就没办法利用这个机制来加快镜像下载速度。

前言

很多优秀的程序员和技术人员喜欢写技术文章和技术博客，通过这样的方式分享传播知识和经验，扩大自己的知名度和影响力，吸引粉丝关注，甚至有些技术博主还通过写文章来获取广告收入，还通过这种方法获得了出版书的机会以及工作机会。因此，写技术文章是一件非常值得投入的事情，帮助了自己，也让大众受益。但是，写技术文章通常也很耗时，特别是一些优质文章，不仅需要旁征博引、构思文章结构、照顾读者受众，还需要做很多前期工作，例如搭建环境、写 Demo 代码、测试代码等等。一篇优质技术文章通常需要 3-6 个小时来完成，可花了很多时间来写文章，最终发布出来的文章得不到很多人的关注是一件相当令人沮丧的事情。因此，优质文章值得获取关注和传播，让更多的技术工作者通过阅读文章获取知识获益。每个技术博主都有自己喜欢的技术媒体平台，例如简书、知乎、掘金、CSDN、微信公众号等等。很多技术博主也喜欢将文章发布在不同的平台上，寻求最大的关注度，同时也防止自己辛辛苦苦写的文章被别人复制粘贴盗版过去。然而，在多个平台上发文是一件麻烦的事情：博主需要同时登陆多个媒体平台，将自己的文章复制一个一个粘贴过去；更麻烦的是，有些平台只支持 Markdown，有些平台只支持富文本，博主需要在这两者之间来回转换，这增加了工作量。一文多发平台 ArtiPub 就解决了这样的问题，下面将介绍开源的一文多发平台 ArtiPub。

ArtiPub 简介

ArtiPub（Article Publisher 的简称，意为” 文章发布者”）是一款开源的一文多发平台，可以帮助文章作者将编写好的文章自动发布到简书、掘金、SegmentFault、CSDN、知乎、开源中国等技术媒体平台，传播优质知识，获取最大的曝光度。ArtiPub 安装简单，提供了多种安装方式（Docker、NPM、源码），可以一键安装使用，安装一般只要 5 分钟。ArtiPub 目前支持文章编辑、文章发布、数据统计的功能，后期会加入存量文章导入、数据分析的功能。此外，ArtiPub 日后还会接入更多媒体渠道，真正做到让文章随处可阅。用户使用 ArtiPub 也很简单，只需要在浏览器上打开 ArtiPub 的 Web 界面，将文章以 Markdown 的形式输入到编辑器，然后点击一键发布，等待不到 1 分钟，文章就自动同步到各大技术媒体平台了。此外，文章的阅读、点赞、评论数据还将周期性的被同步回来，让作者可以近实时看到文章的传播情况。

上篇 - Gateway 入门教程（基础篇）

• Gateway 入门教程 - 基础篇

前言

版本说明

在本文中，默认使用的 Spring Cloud 版本是 Finchley.RELEASE，对应的 Spring Boot 版本是 2.0.3，特别声明除外。

Gateway 基于服务发现的路由规则

Gateway 的服务发现路由概述

Spring Cloud 对 Zuul 进行封装处理之后，当通过 Zuul 访问后端微服务时，基于服务发现的默认路由规则是：http://zuul_host:zuul_port/微服务在 Eureka 上的 serviceld/**。 Spring Cloud Gateway 在设计的时候考虑了从 Zuul 迁移到 Gateway 的 兼容性和迁移成本等，Gateway 基于服务发现的路由规则和 Zuul 的设计类似，但是也有很大差别。Spring Cloud Gateway 基于服务发现的路由规则，在不同注册中心下其差异如下：

• 如果把 Gateway 注册到 Consul 上，通过网关转发服务调用，服务名默认小写，不需要做任何处理
• 如果把 Gateway 注册到 Zookeeper 上，通过网关转发服务调用，服务名默认小写，不需要做任何处理
• 如果把 Gateway 注册到 Eureka 上，通过网关转发服务调用，访问网关的 URL 是 http://Gateway_HOST:Gateway_PORT/大写的 serviceld/*，其中服务名默认必须是大写，否则会抛 404 错误；如果服务名要用小写访问，可以在属性配置文件里面加 spring.cloud.gateway.discovery.locator.lowerCaseServiceId=true 配置解决

Reactor 与 WebFlux 介绍

Reactor 是什么

为了应对高并发的服务器端开发，在 2009 年 的时候，微软提出了一个更优雅地实现异步编程的方式 - Reactive Programming，中文名是响应式编程或者叫反应式编程。随后，其它技术也迅速地跟上了脚步，像 ES6 通过 Promise 引入了类似的异步编程方式。Netflix 和 TypeSafe 公司也提供了 RxJava、Scala、Akka 技术，让 Java 平台也有了能够实现响应式编程的框架，现在比较熟知的 Hystrix 就是以 RxJava 为基础开发的。到了 2017 年，虽然已经有不少公司在实践响应式编程，但整体来说应用范围依旧不大，主要原因在于缺少简单易用的技术将响应式编程推广普及，诸如 MVC 框架、HTTP 客户端、数据库技术等整合。终于，在 2017 年 9 月 28 日，Spring 5 正式发布，而 Spring 5 其最大的意义就是将响应式编程技术的普及向前推进一大步。在背后支持 Spring 5 响应式编程的框架正是 Reactor，它是由 Pivotal 公司（开发 Spring 等技术的公司）开发的，实现了 Reactive Programming 思想，符合 Reactive Streams 规范（Reactive Streams 是由 Netflix、TypeSafe、Pivotal 等公司发起的）的一项技术。Reactive 与 Servlet 的技术栈对比图如下：

Consul 介绍

Consul 是什么

作为集群系统的灵魂，服务治理框架一直都受架构师的青睐。随着微服务思想的普及，越来越多的服务治理框架如雨后春笋般冒了出来。除了 Eureka，HashiCorp 公司的 Consul 也让诸多架构师青睐有加。Consul 是一个分布式高可用的服务网格（service mesh）解决方案，提供包括服务发现、配置和分段功能在内的全功能控制平面。这些功能中的每一个都可以根据需要单独使用，也可以一起使用以构建完整的服务网格。简单来说，Consul 是一个分布式高可用的系统服务发现与配置工具，它跟 Eureka 的核心功能一样，但略有不同：

• Consul 使用 Go 语言编写，以 HTTP 方式对外提供服务
• Consul 支持多数据中心，这是它的一大特色
• Consul 提供了可视化的 Web 界面
• Consul 的一致性协议是 CP（Raft）
• Consul 除了服务发现之外，还有一些别的功能，例如配置功能

上篇 - Config 入门教程（中级篇）

• Config 入门教程 - 中级篇

前言

版本说明

在下面的的教程中，使用的 Spring Cloud 版本是 Finchley.RELEASE，对应的 Spring Boot 版本是 2.0.3，特别声明除外。

Config 高可用

对于线上的生产环境，通常对其都是有很高的要求，其中高可用是不可或缺的一部分，必须要保证服务是可用状态，才能保证系统更好地运行，这是业务稳定的保证。

Config 客户端高可用

对于客户端的高可用，这里的方案主要还是用 File 的形式，本质与 “客户端回退” 的思路大体一致。客户端高可用主要是解决当服务端不可用的情况下，客户端依然可以正常启动。从客户端的角度出发，不是增加配置中心的高可用性，而是降低客户端对配置中心的依赖程度，从而提高整个分布式架构的健壮性。客户端加载配置的高可用流程图如下，点击下载完整的案例代码。

相关站点

• Consul 官方安装教程
• Consul Docker 官方安装教程

拉取 Consul 镜像

1
2
3
4
5

# 拉取最新版本的镜像
# docker pull consul:latest

# 拉取特定版本的镜像
# docker pull consul:1.7.3

Docker 安装 Consul（单机）

1
2
3
4
5
6
7

# 创建并启动容器，默认是以开发模式启动，数据保存在内存中
# docker run -d --name=consul -e CONSUL_BIND_INTERFACE=eth0 consul:1.7.3

#　查看容器的运行状态
# docker ps
CONTAINER ID   IMAGE          COMMAND                  CREATED          STATUS         PORTS                                                        NAMES
7c43babcc760   consul:1.7.3   "docker-entrypoint.s…"   38 seconds ago   Up 37 seconds  8300-8302/tcp, 8500/tcp, 8301-8302/udp, 8600/tcp, 8600/udp   consul