基于docker的云解决方案

版本	时间	作者	修订章节	修订内容
1.0	2015-12-16	秋波	全部	init
1.1	2016-01-28	秋波	5.8	增加网络部分

1. 应用

1.1 yiji-boot应用

应用切换到yiji-boot后，会提供如下能力：

• healthcheck

  对于应用来说，如果它所有依赖的资源(db、mq、cache、内存，cpu、磁盘io等)都健康，我们可以认为应用是健康的。

  对于所有的外部资源，我们都会提供组件，组件中包含healthcheck的能力。对于系统资源，watcher和yiji-boot提供了内存、磁盘、负载、文件描述符、线程死锁等健康检查。

• metric

  我们需要知道某些组件(比如线程池，连接池)运行时实时状态，根据这些状态，我们可以实现监控、动态扩容的能力。

• dtrace

  在分布式系统中，我们需要了解一个请求处理的整个链路，对于我们分析问题，优化请求路径，关键链路监控都很有帮助。我们在所有的组件上加入dtrace埋点。

• hera

  hera提供配置管理和动态修改配置的能力。我们所有的组件开发时，把组件的动态修改能力交给hera，我们可以在不停机的状态下对线程池、连接池等限制资源调整。

以上能力还不够，我们后面会结合业界的最佳实践(比如spring cloud)，完善yiji-boot。对于基于yiji-boot开发的应用来说，这些非功能性需求能力会随着yiji-boot的升级，能力一步一步增强。

1.2 非yiji-boot应用

很不幸，这个世界总有不完美的地方。某些应用可能因为一些限制，很难切换到yiji-boot上,这些应用没有上面谈到的yiji-boot的能力，但是我们要求应用必须遵循各种规范，规范也是契约，通过契约，我们来实现统一的监控、健康检查、日志收集。

2. 轻量级虚拟化-docker

docker提供了轻量级的、基于内核虚拟化的、高性能解决方案，运行视图称之为容器，它表现为linux上的一个进程，它通过cgroups、namespace、unionfs实现了资源隔离。

docker镜像是容器的静态视角，镜像是程序、数据和及其所依赖的程序的集合。我们把应用build成一个docker镜像，镜像是自包含，通过一条命令把docker镜像run起来。

对于yiji-boot应用和非yiji-boot应用，构建docker镜像后，我们有了统一应用的启动、停止操作。

3. 集群-kubernetes

kubernetes是google开源的应用集群管理工具，我们使用它来管理docker容器。它吸收了borg的优秀理念.在google内部,借助于borg：

We launch over 2 billion containers per week.

针对集群面临的问题，我们一一列举解决方案：

3.1 资源调度

集群核心的问题是资源调度。我们对应用进行分类并描述应用所需要的资源(比如cpu、内存)，kubernetes会根据应用资源需求，并去对各个物理节点上的资源打分，选取合适的资源来运行应用。

通过metrics、healthcheck、watcher提供的能力，我们在资源调度策略上能做到自动化水平扩展。

3.2 请求路由

应用要对外提供服务，需要把用户的请求路由到对应的服务器。

3.2.1 入口系统

对于入口系统，我们应用前面会有nginx，nginx来实现负载均衡和请求分发。(下图省略某些中间环节)

                    ---->web
browser->dns->ngnix-|
                    ---->web

通过kubernetes提供的services，我们的拓扑会调整为如下的结构：

                                              ---->web
browser->dns->ngnix(L4/L7)->dns->kub services-|
                                              ---->web

kubernetes会提供服务注册、服务发现、服务路由的能力，并通过健康检查实现动态请求调度。(kubernetes services的高可用和性能需要评估，如不满足，可以用固定ip的方式玩)

3.2.2 内部系统

目前我们内部系统使用了dubbo，dubbo自带服务注册，服务发现，服务路由能力。借助kubernetes的replication controller，控制应用副本数量。

3.3 应用优雅停机

当dubbo服务关闭时，会通知服务调用方，不要发送新的请求过来，服务把请求处理完毕并返回后才关闭应用。我们设置应用停机超时时长为3分钟，对于超时的应用，保留应用现场dump(系统层面和jvm层面，并持久化到物理机文件系统），杀死应用。通过应用现场dump数据，我们可以分析应用的问题。

对于入口系统，通过kubernetes提供的钩子，同样提供应用优雅停机的实现。

3.4 服务平滑升级

通过kubernetes提供的rolling update能力，实现多个应用逐步发布。

3.5 日志搜索

应用都在kubernetes集群内，看日志是个大问题。我们通过elk，把所有日志收集起来，为开发同学提供统一的查询视图。

3.6 应用状态监控

通过metrics、healthcheck、watcher，我们暴露了容器的系统运行状态、组件运行状态、健康状态，我们会把这些数据实时收集起来，为应用自动动态水平扩容、垂直扩容提供依据，为开发同学提供统一的状态视图。

3.7 业务监控

通过收集所有的业务日志，按照业务规则定制监控、统计指标，提供统一的查询视图。

3.8 容器状态视图

通过kubernetes容器数据收集插件，为运维提供容器状态统一视图。

3.9 dtrace

SOA架构体系下，服务能力由多套系统提供，如何快速定位出问题的节点是个麻烦的事。

通过dtrace对rpc框架埋点，我们能获得请求链路日志，为开发同学、运营同学提供多个系统之间请求流转视图，并能根据历史访问情况提供监控、报警能力。

通过dtrace对所有资源组件埋点，为开发同学提供应用内部的请求流转视图，为性能优化、故障分析提供数据支持。

4. 迁移计划

4.1 yiji-boot

我们计划在2016年3月份完成所有应用切换成yiji-boot。

4.2 kubernetes集群

我们计划在测试环境实现所有的无状态应用切换到kubernetes集群上。把测试环境所有的硬件资源充分利用起来，并验证整个体系，同时也增强各个功能组件(日志搜索、应用状态监控、dtrace)。

5. 主要任务

5.1 kubernetes

• kubernetes services 高可用评估
• 安全需求评估

5.2 dtrace

5.2.1 实现应用内的资源调用跟踪

• 对外部的所有调用视为对资源的调用，所有涉及到网络io的请求都是资源(磁盘io先不管，我们的发展趋势是，应用除了写日志，不会设计磁盘io)
• 尽量无侵入的实现跟踪代码插入，改写公共包+Java agent 加载时织入
• 可以动态修改每一种资源是否启用跟踪(配置数据写到配置管理系统)
• 入口请求都启用跟踪

5.2.2 应用内跟踪数据统计

• 展示应用所有调用链路
• 展示应用调用链路统计数据，平均，最大，最小，方差

5.2.3 监控报警

• 根据接口调用历史数据报警
• 根据异常等级，频次等阈值报警

5.3 实时状态采集

实时状态功能主要从应用中，获取应用当前信息(watcher、metric、healthcheck)，应用运行环境信息。

• 灵活的实现服务发现(kubernetes、CMDB)+手动添加服务
• 定时主动从应用层采集数据
• 收集数据形成报表，报表可以考虑Grafana

5.4 日志收集

5.5 业务监控

5.6 服务鉴权

实现操作人和服务之间的认证、授权。认证授权信息从OA(OA中有人员组织关系，权限)中获取。

5.7 跨机房

我们的现状(金融在重庆，其他在天津)决定我们一个数据中心已经跨机房了。在多个机房中部署基础镜像(主机房推送到其他机房)。发布上线时，通过非专线网络传输应用镜像层(docker分层文件系统)。在其他机房build镜像发布上线。

有状态的服务不放入kubernetes集群，网络上维持原状，保证重庆集群和天津集群的互联互通。

5.8 网络

1. 网络组件选型

   性能、安全、高可用

初步选型flunnel+ovs

6. 写在最后

愿景很宏大，很美好，但是还有不少路要走。还需要不少组件需要开发，还有一些关键组件的评估。先感谢各位同学能在2016年3月份之前完成应用切换。感谢帮助我们完成构想的同学，希望我们能一起来完成这个大工程。