软件技术学习笔记

在分布式系统中，我们一般把日志集中收集到EFK或ELK中。默认情况下，Elasticsearch（ES）收集到的是一行一行日志文本，但是，这样的日志不方便业务检索，也没有充分发威ES的检索能力。

为了方便业务检索，我们做结构化日志，输出的内容均为JSON格式，经过Filebeat的简单处理，扔给ES存储与建立索引。查看日志时，可以对特定的业务字段做过滤，比如: user.id: 123。 日志输出格式如下，一条日志一行JSON：

在互联网大数据时代，海量数据的存储只能数据分片与分布式存储，在数据处理时又需读写分离、结果归并到应用服务节点。在云原生与微服务中，以下几种数据库均占有自己的一席之地，没有谁可以代替谁：

1. 传统关系数据库的MySQL、PostgreSQL等，节省空间，可联合查询。
2. NoSQL的MongoDB、HBase等，具有天生的分布式能力。
3. NewSQL的TiDB、ShardingSphere中间件、云数据库。NewSQL数据库与云数据库，很新很强大，但是成熟度不高。

在微服务系统中，数据架构经历了以下几个过程：

1. 原始方式，在业务代码中与不同的分片数据库交互，在业务代码中结果归并。
2. 侵入式Library，业务代码中不感知分片信息，但不支持跨语言。
3. 中间件Proxy模式，独立的中间件服务，支持不同的语言。是目前最流行的大数据架构方案。
4. 未来Database Mesh，跨语言，去中心化。

落地分布式微服务架构时，遥测信息收集是一个重要的环节。如果没有日志收集、指标收集、分布式追踪、应用性能管理，将导致问题定位效率低下、无法自动弹性伸缩、无法自动预警等，最终可能导致微服务架构落地失败。

在K8s中，我们可以使用Elastic Stack完成这些事情。Elasticsearch完成数据存储与搜索；Kibana提供可视化的用户界面；Beats完成数据采集；APM完成分布式追踪、应用性能管理。

在K8s集成Istio之后，虽然Jaeger可以追踪到Mesh边界，但仍需在代码中转发x-request-id与x-b3-...等头部信息，也没有比Elastic APM优美。同时，我们大部分时候只关注应用边界的性能，很少关注Mesh边界的性能。因此，在单独K8s或K8s + Istio集群中，Elastic Stack满足了我们的APM需求。

在本地演练K8s，我们不一定需要分布式存储，只需一个本地存储就可以满足我们的需求。但是，本地存储不能自动分配持久化卷(PV)，需要我们先创建好PV，PVC才能获取到资源。

Istio是非入侵式的跨语言服务治理方案，与业务代码达到进程解耦，以SideCar模式完成服务治理——流量管理、安全、策略、遥测。Istio架构比Dubbo、Spring Cloud先进。

本文将演示：在K8s集群中部署Istio与其BookInfo样例。

1. 准备条件

• 安装Helm与Tiller：参考“给K8s安装Helm与Tiller”。
• 更大的内存。最小内存要求：主节点3GB，2个工作节点各6GB。

Helm与Tiller是C/S模式配合工作的，它们已变成K8s事实上的标准部署工具。本地快速部署工具Draft也依赖Helm。

Helm是安装在本地的，读取/home/$USER/.kube/config与远程的Tiller或K8s API通信。 Tiller是安装在K8s集群中的，有一个独立的Pod与Service。

在k8s-master节点执行：

wget https://get.helm.sh/helm-v2.14.3-linux-amd64.tar.gz
tar -zxvf helm-v2.14.3-linux-amd64.tar.gz
sudo cp linux-amd64/helm /usr/local/bin/
sudo cp linux-amd64/tiller /usr/local/bin/

kubectl apply -f https://raw.githubusercontent.com/istio/istio/1.3.3/install/kubernetes/helm/helm-service-account.yaml
helm init --service-account tiller --tiller-image doublemine/kubernetes-helm.tiller:v2.14.3 --skip-refresh   --upgrade

# check version info
xxx@k8s-master:~$ helm version
Client: &version.Version{SemVer:"v2.14.3", GitCommit:"0e7f3b6637f7af8fcfddb3d2941fcc7cbebb0085", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.14.3", GitCommit:"0e7f3b6637f7af8fcfddb3d2941fcc7cbebb0085", GitTreeState:"clean"}

看得Server端的版本信息，说明工具部署完成。

在K8S集群中，比较麻烦的是：有状态服务持久化，并且保证高可用。面临的问题：

1. 有状态服务POD死亡时，持久化数据能够立刻转移到新拉起的POD。
2. 持久化数据本身读写的高可用。

Ceph分布式存储就是解决问题2；同时使用独立的分布式存储集群，分离PV与工作节点的耦合，确保PVC能够转移给新的POD，解决问题1。

本文将演练：部署一个Ceph分布式存储单例，通过CephFS集成到K8s。

目前，微服务是比较流行且成熟的后端架构。这几年来，K8S、云原生与Service Mesh也比较火热。

去年开始接触到K8S，然后开始学习互联网架构与云原生，前段时间有空在自己的笔记本中搭建开放环境。环境准备如下：

• DNS服务：阿里云域名服务，解析qinzhiqiang.cn的子域名到本地VM IP
• 宿主：Windows 10 专业版 + Hyper-V，CPU四核八线程，内存32G，使用Docker CLI
• VM1：Ubuntu 18.04 Server + Docker，提供Docker daemon、Docker registry服务，内存2G
• VM2：Ubuntu 18.04 Server + Docker，提供GitLab服务，内存8G
• VM3：Ubuntu 18.04 Server + Docker，提供K8S服务，内存16G

Kubernetes (K8s)是云原生生态的基石，是CNCF中第一个毕业的项目，是事实上的“云操作系统”标准；后续的分布式微服务都部署在K8s中。

演练K8s集群（CNI + IPVS模式），我们使用3个虚拟机（Ubuntu Server 18.04），需要SSD磁盘作为存储。K8s本身的微服务就不少，磁盘操作次数比普通的单应用服务的多。如果使用普通的机械磁盘，K8s集群的启动都困难。

内部DevOps环境，一般需要部署私有的Docker Registry服务，避免打包的镜像需要上传到公网，加速私有服务容器的部署。

本文使用独立的Ubuntu Service 18.04服务器提供Docker registry服务，使用80与443端口。使用Nginx接入Docker registry与registry-ui的流量，均使用Docker容器提供服务（Everything in Docker）。