2016/09/12 CNUT Container 容器大会 2016 笔记

[sivagao]

两天的会议中，先后听了十几篇分享，议题涉及到如下层面：应用如何微服务，大数据结合，平台搭建和运维（devops，CI/CD持续集成和部署，容器编排（mesos，kubernetes，swarmkit等，应用场景：电商金融等。
整体感觉主会场的三篇，还有第二题早上的海外创业分会场中分享都是特别的棒！剩下的更多集中在DI/DC，运维视角下的还颇要慧眼识金去探寻~ 其中『docker化 - 容器应用基石』，『从SOA到微服务的技改之路』，『爱奇艺 - 日志容器』都是相对比较浅显易懂的，甚至其中讲到的一些做法和遇到问题也是我们当下有的并且解决的。

以下是我对重点分享的笔记和总结。

PS：后续的分享应该会随后带来。
PPS：梁总和烈波大神的ppt请自行取阅，吓尿指数飙升~

Netflix cloud native 微服务生态系统

网飞家的微服务实践从来都是业界最前沿最开放的典范了，这次通过这次一瞥网飞家的微服务实践的现状还有开源技术方案大练兵还是收获不少的。之前还有一份分享非常有参考性（ http://www.slideshare.net/aspyker/netflix-and-containers-titus 是AWS的Meetup 上分享的）

现状：online video streaming （最早是邮寄video），500+微服务，8kw的订阅用户，日播放1亿2500小时，双活的region，1/3北美互联网下载流量峰值

打造微服务和团队文化是离不开的：

• high aligned，loosely coupled - 高一致，低耦合的团队 - 没有专门的客户体验部门，
• freedom & responsiblity （devops就是体现，开发的人就要把部署可能遇到的坑全填满）;
• context，not conrol
• high trust, high performance （所有的决策会挑战，但是owner对决策负责）
• minimum process 少规则条例

这样背后的云生态体系是：

• 微服务
• 不可变基础设施
  （美国传统的部署方式，到数据中心特定机器部署，有问题就修复，宠物和畜牲。但是云后，有问题就替换掉.前提是你的应用是可以，通过中心的配置中心）
• 去中心，持续交付devops
• 弹性，抗脆弱性
• 自助服务 & 自动化

实现这些涉及的开发技术包括：

• 服务发现 eureka - restufl service used in aws cloud for locating
  services for the purpose of load balancing and failover of
  middle-tier servers.
• 熔断器 hystrix 每个微服务有很多依赖（软硬件），
• simian army （猴子军团）- 云端的多层的隔离，需要一个软件去测试不同的隔离可靠性（去kill
  vm，把regin中的traffic转向）
• 持续部署 spinnaker
• 配置管理 archaius（变色龙，不同环境下不同的状态下，就想是应用的配置）-
  测试上线和failover不failover
• 分布式缓冲 - evcache （适用于公有云，多节点多隔离的）
• 数据管道 keystone pipeline（众多节点上的产生的数据收集起来）
• 监控报警 atlas
• 双活区域迁移
• 更多 More:https://netflix.github.io/
• 如何开发，运维，整合微服务
  • build a microservice
    • 优化交付速度，和快速迭代 - MVP，
    • 多范式多语言（如ruby, haskell，Java等） - 多情景下的（JVM，Java，Node.js 大马路
      • 支持更多，你也可以用小众语言最终会）
  • 整合微服务
    • 服务发现（device,internet, elb/proxy, api - disovery(->
      private ips[microservices - 和不同微服务间也是靠服务发现去做])）
    • embrace failover
      • （默认不可靠，断路器-防止雪崩不要因为一个导致全部大面积出问题），chaos
        engineering（instance termination，zone partitioning,
        region evacuation）， limit blast radius（）
      • 意味着 states need to be available across all regions at
        any point of time(cassrone快速写，但是读慢 - 通过分布式的cache)
    • cache replication （eventual consistent replication
      protocol， event
      sourcing，同一个请求进来后会同时给其他的instance发送message去离线去处理，而不仅仅xx）
  • 运维
  • 优化
    • incremental features
    • data driven

各个微服务间的链接

CloudNative 微服务App使用Spring Boot

这次分享还是比较合胃口的，尤其是包含了目前我们也正在实践的SpringBoot，SpringCloud的一些，也包含了一些我们没有做到的高阶实践。
作者主要从12军规开始，加上Spring母公司Pivotal新提出的3条，组成了：

• codebase
  • git，全是maven专家构建（gradle，普通服务端用maven，不灵活可以加一些约束）
  • gitlab group来组织产品线代码
  • 应用代码和共享代码（被service
    api，一些连接db，连接cache，应用逻辑的代码都会被拿去，而不是用我们提供的api，更灵活）
  • 适当的代码重复在微服务中是允许的（为了每个微服务的独立性）
  • maven插件来记录追溯（git操作等），选用git（强大功能和社区提供多样化的）
• api first
  • 限定上下文，semantic versioning
  • 大多数下层服务都是Java Interface的，api设定要review，release note进入git repo等
  • 基础服务器如消息，缓存，配置，使用业界API，结合ali中间件实现
  • 使用spring boot去封装（JMS，JCache，Spring @value API等 ） 底层的MetaQ,
    Tair, Diamont 等
  • 不要仅仅去考虑功能实现，而是看业界的API是怎么定义的
• dependencies
  • SpringBoot 内嵌http容器有tomcat，有人生没有养的服务（有Java6的不兼容的）
  • 在微服务改造升级的（很多应用是spring2的，跨越8年，不要只给目标要给过程）技术升级改造的迭代（先从边缘的，然后全厂）
  • log4j到logback和self
  • 使用snapshot parent pm（小心！）和maven-enforcer-plugin做强制的
  • BOM管理版本（一些）
  • spring boot的一些扩展（endpoint，来访问应用程序的现状）如使用了那些低版本的依赖，拉取来升级！
• build, release,run
  • 独立的测试和发布系统，高度自动化，
  • 监控检查，注册到负载均衡，beta发布，回滚等
  • 大公司要考虑历史问题（不会一下子做的很理想）
• configuration
  • spring boot后，同一个binar，ali启动binary会从diamond去拉取不同环境的配置（而不是把配置打入镜像中）immutable
  • 构建时配置 vs 启动时配置
  • Spring Cloud 和 diamond （DiamondPropertiesLoader 去拉取）
• log
  • 应用写本地磁盘写日志，agent收集，传递到日志分析系统（独立的ELK的分析和展现等）
  • java社区的log方案各种打架
• disposability
  • 安全的快速启动和关闭（衡量微服务没有什么硬性指标），3min（Ali的中间件比较多）
  • 优雅的上下线（先从负载均衡中去掉再实施，不然重启会被投诉-如果那几分钟用户比较多）
• backing services - circuit breaker
  • 一定要看不然被搞死了
  • release it 这本书
• benvironment parity
  • it works on my machine 解决环境不一致的
• port binding
• stateless
  • 所以状态放在数据库，缓存，大数据
• concurrency
• telemetry
  • 遥感技术，卫星上去出问题了不可能再派机器上去（你不要上机器去看应用本身去收集信息去反应出来）
  • 监控，健康检查等暴露出来
• auth and authorization

这样依次查看，要实现应用微服务化。必须要做到这些，这是容器甚至集群的前置工作基本功。

Docker 服务编排 - swarmkit

这一场是有docker官方的开源负责人东洛先生讲解的，除了ppt让我们看到官方的思路想法，也通过了简单的swarmkit demo给我们演示了具体的例子。

微服务带来部署的挑战 - 复杂化：
资源管理，任务调度，系统安全和网络通讯，运维开销等等，从而提出了集群管理的思路和社区实现（k8s,mesos等

为什么docker要做编排？
对于社区现有的mesos, k8s等（相互不兼容的，带着厂商vendor的业务特征）
官方要对『build, ship, run application』做的 battery included, but replacement and removable 可插拔

Docker在容器化的项目：
从engine，compose(container deploy多个机器)， swarm(很多节点 group 到cluster) 【compose 把任务推送到swarm】， machine（准备运行环境，机器中有tls，有docker内置了）， distribution， libnetwork， docker for mac/windows, swarmkit

容器编排需要考虑的问题：
• 编排:如何将任务匹配到对应的计算,网络,存储资源上来提供服务
• 集群管理:如何管理各种系统资源,包括计算,存储,网络;如何自劢的处理系统变化,如节点离线
• 任务调度:如何调度任务到对应节点并路由请求,如何管理任务的整个生命周期
• 用户接口:如何定义服务架构来进行编排
• 安全性:如何实现端到端安全保障 - 实现端到端的加密，密钥的安全，分发）
• 适用性:如何解决公有云,私有云和混合云的部署;如何协劣企业进行测试及生产环境部署

从compose+swarm到swarmkit
前者：（1.12前）
container api 去管理（用swarm知道把任务如何分发
服务管理，负载均衡，状态和网络都是由外部去
后者：
service api（定义service包含task【由容器去实现】）
服务生命周期内置，系统状态保存在内置的raft store上，直接对服务做负载均衡，集群内置ca进行，所有通讯加密，网络状态内置，通过gossip来传播

前后架构对比图：

Swarm Mode的架构
• Docker发布以来的一次重大架构变化,引入了集群管理和服务;同时向后兼容
• 多个管理者节点(manager)使用raft实现(coreos/etcd)组成高可用,强一致性Quorum以管理集群
• 内置分布式K/V仓库保存系统状态,支持批处理状态更新
• 多个管理者分担工人(worker)连接
• 管理者进行资源管理,调度任务,监测服务,通过gRPC进行任务分发和状态收集
• 工人节点执行任务,反馈任务状态
• 工人节点通过gossip协议实现分布式消息同步,消除overlay延时线性增长问题
• 内置CA进行秘钥分发和更新,所有节点通讯加密

然后又看了 Docker 1.12 下的网络（1.9 overlay. 1.11 内置dns， 1.12 内置集群（不需要外部的kv store和LB，dns服务发现），服务请求路由，安全性（manager节点有leader，内置CA，分发和定时更新

在最后，faq环节，因为有T恤送，所以我也提问了。☺

• 社区中的编排方案和官方的方案的对比，如何看待的
  • 非常欢迎外部的贡献，提供了一些好的技术方案从而是良性的相互促进
  • 在国外的趋向， 编排在很多公司不是第一位的（是image的build，在ci/cd上更多投入让流程更快更好运行，而编排是可以延迟去推后的），所以编排那么早会阻力很大（小心一点不要太快）
• 大数据的上的方案？
  • （在k8s上没有很好的，mesos上适合大数据的paas它做的不错，它的framework能很好
  • 除了大数据还有其他的服务（有不同的framework去做，从而复杂度更高了）
  • GPU 怎么在docker和编排上的运用，的确是研究的一个重点，不同平台都会有一些支持大数据的一些模式出现
• docker的集成度越来越高，很多外部进来，感觉不是很open了（如plugin让正常使用有很多限制），后续的想法是？
  • release多了，很多功能进来，会不会更复杂了不能manage
  • 先去分层（如engine，xx
  • dockercon上用户的声音（两个极端 - 要提供更多功能，其他要太快catch不住）
  • 以后docker放慢节奏更稳定，对于编排也是自己的思路
  • 关于网络现在有很多方案（BGP方案，overlay是一种可移植性好的方案，在任何地方可以原封不动去用。但是如果你希望用外部的那么可移植性就没那么好了）

Kubernetes 和 AI

大数据和容器化集群管理现在是非常明显的一大趋势，解决计算资源分配问题
微服务（要多micro，足够小，让k8s能够见缝插针去）， 程序要写的硬件配置无关的（譬如你的process不要假设要启动64G内存，不要写中断要kernel）
并行计算框架变得很容器（很多算法几千行go写的mapreduce，写一些新的framework并行开发技巧，而不是使用一种的hadoop等，节省大量的计算浪费） - researcher了解怎么写分布式系统，工程师了解AI潮流（不需要博士是本科）

会什么在一起？解决计算问题给AI，计算节点
计算级别： alpha go（4000 GPU）， deep speech （32 GPU）， siri （8GPU）

AI，互联网兴起：
（搜索引擎（图书管理员），推荐（服务推销员和报刊亭）和广告（而不是广告代理公司）三大业务。互联网金融（合作信用社））
用户行为数据log（有机会收集数十亿用户的行为数据）

互联网数据是长尾数据：
用户（绝大数用户少于5部），电影（绝大部分电影很少人评论）
产品运行一段时间后，数据就很稀疏了，稀疏矩阵的计算等

长尾才是真金：
去噪声（出现频率很低，不重要的），稀疏性，指数族分布，冷启动问题、
通过（ 红酒木瓜汤【小众case】（出什么广告，应该是丰胸的 - 语义分析系统 - topic id，weight，keywords ）， 苹果（大众case）- （苹果，手机，范冰冰）【巨量文本训练后的关联词】 苹果大尺度 （范冰冰）来具体case展示了长尾的价值

长尾数据引入了计算更大（不能去噪

之前的问题：
手工管理集【每个团队申请机器不愿归还，数据计算后放哪里，后续有task怎么办】，HPC集群，Mesos和Yarn

云之声的设计架构：

使用k8s遇到的一些问题：
单机操作系统：CoreOS -为什么因为包管理器各个语言版本等，通过自动安装和部署的sextant，
Ceph最早的时候（大的存储卷被join后切分逻辑卷，因为之前的虚拟化需要。但是现在在k8s中，不需要大的操作系统。所以ceph现在做的）
网络性能（k8s虚拟网络，不是网卡路由器。是软件开发，类似于Google GAE的网络方案）

Datacenter operating system (DC/OS) overview

这一篇，Timothy让我们见识到了Mesosphere家产品的无穷魅力（尤其是DC/OS使用起来尤其方便，第三方社区的插件非常多，web ui精美，在最后的demo环境（展示了部署twitter clone，然后如何扩缩容，如何数据分析-利用部署大数据计算节点和分发task等） https://github.com/mesosphere/time-series-demo

首先讲了 为什么是DC/OS：

• 分布式OS作业系统，描述不同的容器间的关系（描述对网络，硬件的要求等）
• 资源使用率非常低（所以需要把之前部署在各个独立机器上的独立类型的应用-如redis，mongo等）
• 所以需要一个分布式的操作系统（ 把很多物理机器，把底层的云提供商抹平）
  

为什么要DC/OS：
即使你有了mesos但是你还是需要做很多事情（去装framework，去装load balance等）- 最大不同和其他的集群方案（islolation隔离非常灵活）

• Containers! (High resource utilization, etc)
• Extensible Isolation
• Public and Private Service repositories
• Cloud Agnostic Installer
• WebandCommandLineInterfaces
• Service Discovery and Load Balancing

DC/OS具体包含了哪些：