前言

官方教程

• Docker Install Gitolite
• Centos7 使用 Gitolite 搭建 Git 服务器

镜像数据卷目录

Docker 安装 Gitolite

这里直接使用国外开发者构建好的 Docker 镜像 elsdoerfer/gitolite，不再通过手写 Dockerfile 来构建 Gitolite，具体使用方法如下：

1
2

# 拉取镜像
# docker pull elsdoerfer/gitolite:latest

ECMAScript

ECMAScript 简介

ECMAScript 是一种由 Ecma 国际（前身为欧洲计算机制造商协会，英文名称是 European Computer Manufacturers Association）通过 ECMA-262 标准化的脚本程序设计语言。ECMAScript 是浏览器脚本语言的规范，而 JavaScript 和 JScript 都是 ECMAScript 规范的实现者。

前端发展历程回顾

• Web 1.0 时代

  • 最初的网页以 HTML 为主，是纯静态的网页。网页是只读的，信息流只能从服务到客户端单向流通。开发人员只关心页面的样式和内容即可。

• Web 2.0 时代

  • 1995 年，网景工程师 Brendan Eich 花了 10 天时间设计了 JavaScript 语言。
  • 1996 年，微软发布了 JScript，其实是 JavaScript 的逆向工程实现。
  • 1996 年 11 月，JavaScript 的创造者 Netscape 公司，决定将 JavaScript 提交给标准化组织 ECMA，希望这种语言能够成为国际标准。
  • 1997 年，ECMA 发布 262 号标准文件（ECMA-262）的第一版，规定了浏览器脚本语言的标准，并将这种语言称为 ECMAScript，这个版本就是 1.0 版。
  • JavaScript 和 JScript 都是 ECMAScript 规范的实现者，随后各大浏览器厂商纷纷实现了 ECMAScript 规范。

前言

继 Nacos 1.0 发布以来，Nacos 迅速被成千上万家企业采用，并构建起强大的生态。但是随着用户深入使用，逐渐暴露一些性能问题，因此启动了 Nacos 2.0 的隔代产品设计，时隔半年终于将其全部实现，实测性能提升 10 倍，相信能满足所有用户的性能需求。

Nacos 简介

Nacos 是一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。它孵化于阿里巴巴，成长于十年双十一的洪峰考验，沉淀了简单易用、稳定可靠、性能卓越的核心竞争力。

Nacos 2.0 架构

2021 年 03 月 30 日，Nacos 2.0 正式对外发布。全新的 2.0 架构不仅将性能大幅提升 10 倍，而且内核进行了分层抽象，并且实现插件扩展机制。Nacos 2.0 架构层次如下图，它相比 Nacos 1.X 的最主要变化是：

• 通信层统一到 gRPC 协议，同时完善了客户端和服务端的流量控制和负载均衡能力，提升的整体吞吐。
• 将存储和一致性模型做了充分抽象分层，架构更简单清晰，代码更加健壮，性能更加强悍。
• 设计了可拓展的接口，提升了集成能力，如让用户扩展实现各自的安全机制。

前言

官方教程

• Next 官方教程 - 常见问题
• Next 官方教程 - 内置标签
• Next 官方教程 - 第三方服务集成

版本说明

本文使用各软件的版本如下：

Next 第三方服务集成

前言

• Next 官方教程 - 开始使用
• Next 官方教程 - 主题配置
• Next 官方教程 - 常见问题

Next 安装

版本说明

本文使用各软件的版本如下：

前言

软件环境

前言

概述

Kubernetes 系统的各组件需要使用 TLS 证书对通信进行加密，本文使用 CloudFlare 的 PKI 工具集 cfssl 来生成 Certificate Authority (CA) 和其它证书，使用证书的组件如下：

Kubernetes 概述

Kubernetes 简介

Kubernetes 是 Google 开源的一个容器编排引擎，简称 K8s，是用 8 代替 8 个字符 ubernete 而成的缩写。Kubernetes 可用于管理云平台中多个主机上的容器化的应用，支持自动化部署、大规模扩缩容、应用容器化管理。在生产环境中部署一个应用程序时，通常要部署该应用的多个实例以便对应用请求进行负载均衡。Kubernetes 提供了应用部署、规划、更新、维护的一种机制。在 Kubernetes 中，可以创建多个容器，每个容器里面运行一个应用实例，然后通过内置的负载均衡策略，实现对这一组应用实例的管理、发现、访问，而这些细节都不需要运维人员去进行复杂的手工配置和处理。

各种部署方式的区别

传统的应用部署方式是通过插件或脚本来安装应用，这样做的缺点是应用的运行、配置、管理、所有生存周期将与当前操作系统绑定，这样做并不利于应用的升级更新、回滚等操作；当然也可以通过创建虚拟机的方式来实现某些功能，但是虚拟机非常重，并不利于可移植性。新的方式是通过部署容器方式实现，每个容器之间互相隔离，每个容器有自己的文件系统，容器之间进程不会相互影响，能区分计算资源。相对于虚拟机，容器能够快速部署，由于容器与底层设施、机器文件系统解耦的，所以它能在不同云、不同版本操作系统间进行迁移。容器占用资源少、部署快，每个应用可以被打包成一个容器镜像，每个应用与容器间成一对一关系也使容器有更大优势，使用容器可以在 build 或 release 的阶段，为应用创建容器镜像，因为每个应用不需要与其余的应用堆栈组合，也不依赖于生产环境基础结构，这使得从研发到测试、生产能提供一致环境。类似地，容器比虚拟机轻量、更 “透明”，这更便于监控和管理。

1、前言

• Knife4j Github 项目
• Knife4j 官方示例代码
• Knife4j 官方中文文档 - 最新
• Knife4j 官方中文文档 - 旧版

1.1、Knife4j 简介

Knife4j 是为 Java MVC 框架集成 Swagger 生成 Api 文档的增强解决方案，前身是 swagger-bootstrap-ui，致力于 springfox-swagger 的增强 UI 实现。knife4j 为了契合微服务的架构发展，由于原来 swagger-bootstrap-ui 采用的是后端 Java 代码 + 前端 UI 混合打包的方式，在微服务架构下显的很臃肿，因此项目正式更名为 knife4j，更名后主要专注的方面如下：

• 后端 Java 代码以及前端 UI 模块进行了分离，在微服务架构下使用更加灵活
• 提供专注于 Swagger 的增强解决方案，不同于只是单纯增强前端 UI 部分

1.2、Knife4j 模块

JWT 的概述

JWT（JSON Web Token）是目前最流行的跨域身份验证解决方案。

传统的身份验证

• 用户向服务器发送用户名和密码
• 验证服务器后，相关数据（如用户角色，登录时间等）将保存在当前会话中
• 服务器向用户返回 session_id，Session 信息都会写入到用户的 Cookie 中
• 用户的每个后续请求都将通过在 Cookie 中取出 session_id 并传递给服务器
• 服务器收到 session_id 并对比之前保存的数据，确认用户的身份

这种模式最大的问题是，没有分布式架构，无法支持横向扩展。如果使用一个服务器，该模式完全没有问题。但是，如果它是服务器群集或面向服务的跨域体系结构的话，则需要一个统一的 Session 数据库（Redis）来保存会话数据实现共享，如果保存 Session 的数据库（Redis）挂掉，整个认证体系都会挂掉。