# 简介

# 配置信息

项目的配置信息分为多种,管理措施也不同:

  • 源代码
    • 用 Git 或 SVN 服务器管理。
  • 运行环境
    • 比如运行项目需要的操作系统、依赖软件。
    • 如果项目部署在虚拟机上,可用 Ansible 批量管理主机。
    • 如果项目部署在容器中,可用 Dockerfile 配置运行环境。
  • 配置文件
    • 有的项目没有准备配置文件,而是将配置信息直接写在代码中。这样不方便管理配置信息,仅适用于开发阶段。
    • 配置文件可能包含服务器密码等敏感信息,因此不应该保存在项目的代码仓库中,否则会被所有人可见。
    • 常见需求:
      • 静态配置
        • :程序一般只需在启动时读取一次,不需要经常更新。
        • 如果存在大量非私密的静态配置信息,可以保存到一个独立的 Git 仓库中,并进行版本控制。
      • 动态配置
        • :程序在运行时可能多次读取,需要经常更新,甚至实时更新。
        • 用传统的 Ansible 等脚本工具不方便管理,建议使用 Consul 等配置管理工具。
      • 服务发现
        • :指程序需要获取某些服务的数量、地址。
        • 可能属于静态配置,也可能属于动态配置。
  • 构建产物
    • 称为构件、工件,或者 artifact、component 。
    • 应该根据文件格式,用各种仓库存储。例如 jar 包存储到 Nexus 服务器,Docker 镜像存储到 Harbor 服务器。

# 配置管理工具

适合批量管理主机的工具:

  • Ansible
    • 一个命令行工具。
    • 采用 Python 开发,于 2012 年发布。
    • 采用主从架构。以 SSH 方式控制远程主机,可以执行任意命令、传输文件。
  • Saltstack
    • 一个命令行工具。
    • 采用 Python 开发,于 2011 年发布。
    • 采用 C/S 架构。需要在主控主机上运行 master 进程,在受控主机上运行 minion 进程。它们之间通过消息队列 ZeroMQ 进行通信。
  • Puppet
    • 一个 Web 服务器。
    • 采用 Ruby 开发,于 2005 年发布。
    • 采用 C/S 架构、HTTP 通信。需要在主控主机上运行 master 进程,在受控主机上运行 agent 进程。
  • Chef
    • 一个 Web 服务器。
    • 采用 Ruby 开发,于 2009 年发布。
    • 采用 C/S 架构、HTTP 通信。
  • Terraform
    • 一个命令行工具。
    • 2014 年由 HashiCorp 公司开源,采用 Golang 开发。
    • 可用 HCL 格式的配置文件定义 VPS、VPC、S3 Bucket 等基础设施,然后批量创建、管理。
    • AWS、Azure 等云平台已允许用户通过 terraform 管理云资源。

适合动态配置的工具:

  • confd
    • 一个命令行工具,采用 Golang 开发,用于自动生成配置文件。
    • 原理:从 zk、etcd、consul、redis 等后端轮询配置参数,根据 Golang 模板文件,渲染出配置文件。
  • Apollo
    • 一个 Web 服务器。提供了丰富的配置管理功能,支持划分环境、版本回滚、安全审计。
    • 由携程公司开源,采用 Java 开发。

适合服务发现的工具:

  • Zookeeper
  • etcd
  • Consul
  • Nacos
  • Eureka :2014 年由 Netflix 公司开源,2021 年停止更新。

# GitOps

:一种配置文件的管理方案,于 2017 年提出。

  • 特点:
    • 将配置文件全部存储在 Git 仓库中,能够据此重新部署项目。
    • 当用户修改 Git 仓库中的配置文件时,会自动触发 CI/CD 部署脚本。
  • 优点:
    • 记录每次修改的版本,并可以回滚。
    • 多个用户操作时,可以通过发出合并请求的方式,修改配置文件,实现流程审批。

# 微服务

:Microservices ,一种服务端架构,将业务系统从单个大型服务,拆分成多个小型服务,有利于模块化。

  • 特点:

    • 每个微服务独立部署,低耦合。
    • 微服务之间通过 API 交互,可以采用不同的编程语言。
    • 需要一个服务发现机制,让微服务之间能够连通。
    • Docker 技术流行之后,微服务变得容易实现。通常将每个微服务部署到一个 Docker 容器中。
  • 从头搭建微服务系统很麻烦,通常使用开源的微服务框架。例如:

    • Spring Cloud
      • :一个 Java 框架。微服务之间通过 RESTful API 进行通信,性能比 RPC 低。
    • Dubbo
      • :一个 Java 框架,由阿里巴巴公司发布。微服务之间通过 RPC 协议进行通信。
  • 单体服务工作时主要调用一些内部函数,较少与外部交互。而微服务之间经常相互调用,存在大量 API 请求,因此通常使用 API 网关来统一管理。例如:

    • Zuul
      • :由 Netflix 公司开源,成为了 Spring Cloud 自带的组件。
      • 性能较差,因此出现了试图取代它的新项目 Spring Cloud Gateway 。
    • Kong
      • :一个基于 OpenResty 服务器的网关。
      • 提供了 7 层代理、4 层代理(TCP/UDP)、动态路由、健康检查、限流、身份认证、权限控制、日志、监控等功能。
    • APISIX
      • :一个基于 OpenResty 服务器的网关,比 Kong 的功能、性能更好。
      • 2019 年开源,由 ASF 基金会管理。
      • 采用 etcd 数据库。
      • 提供了 Web 操作页面。
      • 支持多种语言开发的插件。

# 服务网格

:Service Mesh ,新一代的微服务技术,于 2016 年提出。

  • 特点:
    • 引入一个网络代理层,自动转发服务的流量,并进行服务发现、负载均衡。
    • 属于透明代理,不需要服务编写代码来使用代理。
  • 常见的几种框架:
    • Envoy
    • Linkerd
    • Istio
      • 比 Linkerd 的功能更多。
      • 在 k8s Pod 中加入一个 init 类型的容器,名为 istio-init 。负责设置 iptables 规则,将服务的出入流量转发到 Envoy 。
      • 在 k8s Pod 中加入一个 sidecar 类型的容器,名为 istio-proxy 。负责运行 Envoy ,代理服务的流量。
    • Consul Connect