应用落地
微服务架构下的十二条最佳实践指导原则
- 基础代码: 一份代码多份部署
- 依赖管理: 明确定义项目依赖
- 配置: 以配置文件或环境变量的方式注入应用中
- 后台服务: 无状态应用更易管理，需要与有状态服务进行隔离
- 进程管理: 进程应该是无状态的，任何数据都不应该做本地持久化
- 端口绑定: 以端口绑定的形式发布服务，容器进程运行在不同的网络命名空间，彼此隔离
- 并发: 应用可以按需伸缩
- 易管理: 快速启动时保证应用灵活部署的前提条件
- 研发生产环境的一致性
- 日志
- 管理进程
Dockerfile的编写要考虑分层的复用、缓存的清理，或者使用多阶段构建(多个from)，最终镜像只会留下所需要的内容
对于容器多进程场景下容器的主进程选择，主流方案Systemd、Supervisior等，要能够负责业务进程的启动，接管孤儿进程回收僵尸进程，支持SIGTERM信号的处理，向子进程传播SIGTERM信号，优雅地结束所有子进程后退出。
监控和自动修复
基础平台服务的监控，实时监控核心组件(API Server、调度器、控制器、kubelet和kube-proxy等)的健康状态、用以发现用户流量好组件CPU、内存、网络的使用情况
监控系统的数据分为两大类，指标和日志
指标监控系统
- Heapster + InfluxDB + Grafana
- Metrics-server + InfluxDB + Grafana
- 各种Exporter + Prometheus + Grafana + Alertmanager
日志系统
- Filebeats + Logstash + Elastic + Kibana: ELK套件
- Fluentd + Fluentd Aggregator + Influxdb + Grafana
服务的关键性指标
- SLA: 服务级别协议
- SLI: 服务水平指标
- SLO: 服务水平目标
DevOps
一个中心，两个基本点，以业务敏捷为中心，构造适应快速发布软件的工具和文化。透过自动化透明的"软件交付"和"系统变更"的流程，构建、测试、发布系统应用能够更加快捷、可靠。
GitOps使得整个交付系统以声明式方式进行描述，使用版本控制系统(Git)作为唯一的部署来源，其内包含应用部署于Kubernetes的所有信息。
5%的时间用于编码，95%的时间用于测试: 不可测试和没有经过测试的代码是不能交付的
测试需要贯穿始终