docker微服务最佳实践

docker 微服务

问题：
    1. 随着项目的迭代，主机上面的镜像越来越多，消耗主机空间的同时也不利于管理
    2. 项目测试，项目灰度发布，项目高峰期扩展
    3. 项目的负载均衡

基础镜像的选择

alpine
an explicitly empty image, especially for building images "FROM scratch"

镜像标签

project_name(service_name)/(service_name)-(开发版本,master,dev,test,scale,blablabla,...):[latest,1.1.1]

主机中镜像管理

1. 镜像的基础操作，打标签，构建新镜像
2. 每一个项目(服务)的镜像在主机上面保留10个版本,超过十个就把老的镜像删除

镜像仓库

1. 仓库存放所有的镜像
2. 根据项目名称等分类
3. 每个镜像拥有不同的标签
4. 每种镜像保留20个版本
5. 编写每个镜像的dockerfile，操作方式

镜像部署

1. 项目类型的镜像用docker service
2. 工具类型的用docker run

服务注册中心

用于服务注册以及服务的健康检查
用于配置中心

1. etcd
2. consul

服务注册

1. 发现docker容器，并注册到注册中心去
2. 用自动发现工具，registrator
3. 自己通过docker API读取信息，并注册

负载均衡

1. nginx
2. haproxy
3. gobetween

1. 从服务注册中心读取配置信息并反映到nginx上面
2. 通过nginx模版读取配置信息并动态生成nginx配置文件，并重新加载配置
3. 现有的负载均衡工具的缺点在于不能切换服务，就是新版本和旧版本的切换问题
4. 让nginx配置文件中兼容新旧两个版本的配置。有切换时间，操作方面。
比日：新旧版本的主机一样，端口和容器名子不一样，那么把新旧容器都注册到nginx中，当新版本不存在的时候，nginx自然会调用旧版本的，新版本存在后，就把旧版本下线了，通过这样的切换规则，能够让nginx同时支撑新旧版本的替换。
5. 通过灰度发布。属于后启动，有切换时间，操作方面。所谓灰度发布就是线上的环境不是全部替换的，而且是一步一步的替换(根据docker service update本身的特性)
6. 在路由中切换版本。在路由网管APi中提供一条API能够指定当前服务的服务名称和版本，这样的话能够通过API的方式切换到不同的版本了。同时每一个版本上都有nginx作为均衡负载。这样能够避免因启动而浪费切换时间的问题。
7. 通过consul更改nginx配置文件的方式启动，自动化操作，切换时间较短，时间消耗在nginx更新配置文件上面

监控

1. 企业级监控，时速云，daocloud，oneapm一站式性能监控平台，监控宝，有容云，青云，阿里云等等
2. cAdvisor + InfluxDB + Grafana
3. prometheus，open-source monitoring solution
4. cloudinsight，开源企业级
5. http://docs-ci.oneapm.com/quick-start/
6. StatsD
7. Datadog
8. collectd example
9. 小米监控
10.