之前提到过，这个时代对程序员来说，是最好的时代，也是最坏的时代。说其好，是群雄逐鹿，英雄辈出的时代；说其坏，是因为一旦固步自封会淘汰的比任何其他行业都要快。
云计算时代，你是否意识到自己所设计的一切都应该是“现代服务”，是以容器承载，运行在弹性计算环境中的Cloud Native应用？既然是在建设“现代服务”，需要学习和了解哪些方面的知识才能让我们作出更好的服务设计？下面我们来简单梳理一下。
作为云计算时代的Cloud Native应用，我们至少应了解和学习：容器，存储，网络，监控，日志，部署和安全等方面的知识。
1 容器
1.1 技术原理
容器本质上并不存在，当执行“docker run -d nginx:1.10”命令时，宿主机上并没有运行一个容器，而是启动了一个进程组，如下图所示：
这个进程组的资源耗用是受控的。因此，容器是一个抽象概念，指代的是Linux的namespaces和cgroups。从概念上讲，一个Linux容器由如下三部分构成：
namespaces，用于计算隔离
cgroups，用于资源耗用限制和资源耗用报告
支持写入时复制（copy-on-write），用于保存状态的文件系统
容器是一个进程（组），一个进程（组）可以在一个或多个命名空间中，并且可以被一个或多个cgroup控制。
1.1.1 Linux namespaces
Mount/CLONE_NEWNS
(始于Linux 2.4.19) 通过/proc/$PID/mounts: 文件系统挂载点
UTS/CLONE_NEWUTS
(始于Linux 2.6.19) 通过 uname -n, hostname -f : 节点名/主机名和 (NIS) 域名
IPC/CLONE_NEWIPC
(始于Linux 2.6.19) 通过 /proc/sys/fs/mqueue, /proc/sys/kernel, /proc/sysvipc: 进程间通信资源隔离，通道为System V IPC对象，POSIX消息队列
PID/CLONE_NEWPID
(始于Linux 2.6.24) 通过 /proc/$PID/status: 进程ID编号空间隔离；PID名称空间可以嵌套
Network/CLONE_NEWNET
(完成于Linux 2.6.29) 通过 ip netns list, /proc/net, /sys/class/net: 网络系统资源（网络设备，IP地址，IP路由表，端口号等）
User/CLONE_NEWUSER
(完成于Linux 3.8) 通过 id, /proc/$PID/uid_map, /proc/$PID/gid_map: 用户和组ID编号空间隔离. UID+GIDs在名称空间内部或外部
Cgroup/CLONE_NEWCGROUP
(始于Linux 4.6)通过 /sys/fs/cgroup/，/proc/cgroups，/proc/$PID/cgroup
1.1.2 Linux cgroups
cpu/CONFIG_CGROUP_SCHED ( Linux 2.6.24)
cpuacct/CONFIG_CGROUP_CPUACCT ( Linux 2.6.24)
cpuset/CONFIG_CPUSETS (Linux 2.6.24)
memory/CONFIG_MEMCG (Linux 2.6.25)
devices/CONFIG_CGROUP_DEVICE (Linux 2.6.26)
freezer/CONFIG_CGROUP_FREEZER (Linux 2.6.28)
net_cls/CONFIG_CGROUP_NET_CLASSID (Linux 2.6.29)
blkio/CONFIG_BLK_CGROUP (Linux 2.6.33)
perf_event/CONFIG_CGROUP_PERF (Linux 2.6.39)
net_prio/CONFIG_CGROUP_NET_PRIO (Linux 3.3)
hugetlb/CONFIG_CGROUP_HUGETLB (Linux 3.5)
pids/CONFIG_CGROUP_PIDS (Linux 4.3)
1.1.3 COW（copy-on-write）文件系统
AUFS
btrfs
Overlay File system
Unionfs
ZFS on Linux
1.1.4 namespaces和cgroups相关工具
cinf
nsenter
unshare
man lsns (also: announcement lsns)
systemd-cgtop
cgroup-utils
yadutaf/ctop
1.2 运行时
容器的具体厂商实现有多种，如：Docker， CoreOS appc，Canonical LXC/LXD, 和 OpenVZ等。
AppC/rkt，是由CoreOS推动的新兴标准
Docker，是由同名公司提供的，现已改名为Moby
LXC， 由Canonical驱动的
OCI runC，后起之秀，或许在2017年可能成为新的标准。
cri-o，基于OCI的Kubernetes容器运行时接口的实现
containerd， 兼容OCI的Docker运行时
systemd-nspawn
1.3 设施供应和容器编排
Kubernetes (orchestration)
Marathon (orchestration)
Nomad (orchestration)
Swarm Kit (orchestration)
Terraform (provisioning)
1.4 容器仓库
在线容器仓库服务：
AWS EC2 Container Registry
CoreOS Quay.io
Docker Hub
Google Cloud Container Registry
JFrog Artifactory
SUSE Portus
本地
Docker registry
Nexus
Artifactory
Gitlab
1.5 CaaS
Amazon EC2 Container Service (ECS) 是一个Container as a Service
Empire, 基于ECS的 PaaS
Convox, 基于ECS的 PaaS
Blox, 开源工具集，用于为ECS构建自定义的Schedulers
Azure Container Service (ACS) 有三种选择: DC/OS, Docker Swarm, 或 Kubernetes
Google Container Engine (GKE) 一个托管的Kubernetes产品
Last.Backend, 基于Kubernetes的CaaS / PaaS产品
1.6 测试，调试和内省
AWS X-Ray
docker exec 或 调试一个Docker容器（http://pothibo.com/2015/7/how-to-debug-a-docker-container）
artillery.io, 一个现代的负载测试工具包
asobti/kube-monkey, 为Kubernetes集群提供的一个Netflix's Chaos Monkey实现
dcos-labs/drax, DC/OS的弹性自动化Xenodiagnosis工具
mhausenblas/cinf, 用于查看命名空间和cgroup的命令行工具
OpenTracing
Weave Scope
2 存储（Storage）
2.1 容器存储解决方案
EMC REX-ray
libStorage
2.2 消息队列
ActiveMQ，SQS，Apollo，Apache Kafka，RabbitMQ，...，参考：queues.io
2.3 对象存储
Amazon S3 (受控)
Azure Storage (受控)
Google Cloud Storage (受控)
LeoFS是一种非结构化的高可靠的对象/数据存储系统，支持S3和NFS。
minio是S3的开源替代品，可以自行决定部署在何处以及如何使用。另请参阅Minio客户端mc。
2.4 时间序列存储
Geras：支持一些IoT格式/协议，如开箱即用的MQTT。
InfluxDB: 用Go编写的开放源码的分布式时间序列数据库，没有任何外部依赖关系。拥有强大的类SQL查询语言，利用正则表达式并支持连续查询，以及一些聚合函数如PERCENTILE。提供基于Raft的群集模式。
KairosDB: 一个以Cassandra为底层存储的分布式可扩展的时间序列数据库。
kdb+: 提供具有时间原语和执行控制查询语言，支持与R集成。
OpenTSDB: 在Apache HBase之上提供的一种成熟的实现。支持数十亿个数据点存储，每秒可获取10万个数据点。
Prometheus: Soundcloud开源的服务监控系统和时间序列数据库。Prometheus适用于记录任何纯数字时间序列。它适合以机器为中心的监控以及高度动态的面向服务架构的监控。
2.5 工具
boto, Amazon Web Services的一个Python接口
lsyncd 将本地目录与远程目标同步
rsync 跨（远程）文件系统进行同步
rclone 是一个命令行程序，可以将文件和目录同步到几乎所有的目标。
scp 复制到远程文件系统或者从远程文件系统复制。
3 网络
3.1 负载均衡
AWS Elastic Load Balancing
Azure Load Balancer
Docker Cloud proxy
Google Cloud Load Balancing
HAProxy, the work horse
Kubernetes external load balancer
Marathon-LB
NGINX
Tr?f?k
3.2 DNS
数字IP地址，如123.45.6.7，很不方便：机器和人类都更好地处理逻辑名称，如selfie-service.example.com。可以参考howdns.works，了解如何将数字IP地址映射到逻辑名称（实际上称为完全限定域名或FQDN）及其查找由域名服务（DNS）规范定义。
3.3 Content Delivery Networks (CDN)
如果物理距离远离服务器，则数据到达之前需要更长时间。现在留出可用的带宽，可以通过就近为最终用户提供内容获得更多的收益。内容分发网络（CDN）完全符合这一点：它们在物理上靠近你，减少延迟并提供更好的UX，通常用于静态内容。
3.4 时间同步
分布式系统的一个非常重要的方面就是时间。存在多重挑战：
在集群中的每个机器上，都有一个本地概念即当前时间是什么;我们需要确保所有节点都是时间同步（不会发生时钟偏移）的。解决方案通常是使用逐渐过时的ntp或者新的systemd-timesyncd与外部的NTP服务器进行同步。
时间可能不会单调增加。这很像是时间倒退，如闰秒等。
现代分布式系统对时间的同步要求越来越高。
4 监控
在运行一个节点集群，每个节点运行一个或多个容器时。我们很希望在任何时间点都能够了解节点、容器和服务中发生的情况。
对每一个节点，我们可以使用collectd 和 cAdvisor在本地归集数据，然后可以选择其他功能进行后续处理：
event router:
fluentd http://www.fluentd.org
Flume https://flume.apache.org
Kafka https://kafka.apache.org
logstash https://www.elastic.co/products/logstash
Riemann http://riemann.io
storage:
Elasticsearch https://www.elastic.co/products/elasticsearch
Graphite https://graphiteapp.org
InfluxDB https://influxdata.com/time-series-platform/influxdb
KairosDB (on top of Cassandra) https://kairosdb.github.io
OpenTSDB (on top of HBase) http://opentsdb.net
(others such as using a local filesystem, Ceph FS, HDFS?, etc.)
dashboard:
D3 https://d3js.org
Grafana https://grafana.net
signal fx https://signalfx.com
alerting:
BigPanda https://bigpanda.io
PagerDuty https://www.pagerduty.com
signal fx https://signalfx.com
VictorOps https://victorops.com
还有一些集成的端到端的解决方案以及第三方提供的监控管理的产品：
Amazon CloudWatch https://aws.amazon.com/cloudwatch
AppDynamics https://www.appdynamics.com
Azure Monitor https://azure.microsoft.com/services/application-insights
Circonus https://www.circonus.com
DataDog https://www.datadoghq.com
dcos/metrics
Ganglia http://ganglia.info
Google Stackdriver https://cloud.google.com/monitoring
Hawkular http://www.hawkular.org/
Icinga https://www.icinga.com
Librato https://www.librato.com
Nagios https://www.nagios.org
New Relic https://newrelic.com
OpsGenie https://www.opsgenie.com
Pingdom https://www.pingdom.com
Prometheus https://prometheus.io
Ruxit http://www.dynatrace.com/en/ruxit
Sensu https://sensuapp.org
Sysdig https://sysdig.com
Zabbix http://www.zabbix.com
5 日志
日志可分为三个级别：
主机级别或主机间日志，指主机上的系统日志和服务日志以及捕获不同主机之间的通信的日志。
容器级和容器间日志，也就是说，容器是如何运行的，具体取决于Docker引擎级别或其他主管进程的运行时类型。
服务或应用程序级以及业务相关的日志，也就是在容器中运行的服务中生成的日志及其通信方面的日志。
具体的工具有：
Centralized App Logging with fluentd
DC/OS logging
Docker logging drivers
ELK stack log shipping, with ELK == Elasticsearch, Logstash, Kibana
Graylog
Kubernetes logging
Loggly
Papertrail
Scalyr
Splunk Logging Driver for Docker
Sumo Logic
systemd's journalctl
6 部署
健康检查
滚动升级
金丝雀部署
蓝-绿部署
可用的工具：
DC/OS zero downtime deployment
Docker Swarm
Kubernetes
VAMP
7 安全
7.1 Encryption, Authn & Authz
使用Let's Encrypt获取SSL证书
使用SSO Auth0 和 JWT
了解HTTP 安全头，并通过securityheaders.io进行检查
7.2 容器
了解容器相关的安全理论
不要将敏感信息打包到容器镜像中，可以使用环境变量或分布式内存键值对存储来保存秘密数据。常用方案：
Vault
Keywhiz
Crypt
对容器进行脆弱性分析。
总结
本文大多数内容整理自http://some.ops4devs.info/,文中很多连接请参考原网站。