DockOne微信分享(一一零):Docker在沪江落地的实践

  • 时间:
  • 浏览:1

在图中,最底层由分布式存储与容器云组成,容器云使用Docker+Mesos+Marathon的组合,相信.我歌词 .我歌词 .我歌词 对这套组合太多再陌生,以时候继续介绍为哪些地方使用这套组合以及使用中遇到的什么的什么的问题 。上方层便是拆分出的业务微服务,目前并否是项目线上已有8个微服务。最上层是1个多客户端软件。

编排工具的选择

将会只把Docker作为1个多部署工具真是是太浪费了,Docker的优势完整性这样发挥出来,通过Docker来编排微服务才是使用Docker的正确姿势,这里不得不说一说Mesos和Kubernetes的某些故事。

如今的docker编排呈现了三大阵营,Mesos+Marathon,Kubernetes和Docker Swarm。Swarm还所处发展阶段但势头很猛,Kubernetes和Mesos都源于Google的brog项目但侧重点不同:Kubernetes侧重于企业级集成,你能想到的方案,他都能通过自身组件集成,而Mesos专注于资源调度和管理。在这里.我歌词 .我歌词 .我歌词 主要介绍Kubernetes和Mesos之争,将会两大阵营的激烈争夺,大的互联网企业自然选择了Kubernetes另1个多潜力十足又非常周到的企业级产品,真是K8s目前网络,存储的避免方案还不完善,但互联网巨头不怕,.我歌词 .我歌词 .我歌词 时候 技术团队去修改源码,去贡献社区。这使.我歌词 .我歌词 .我歌词 哪些地方地方中小型互联网企业面对了选择的什么的什么的问题 。.我歌词 .我歌词 .我歌词 最好的法律法子只是 对两者都进行尝试。通过寻找各个框架配合的方案,找到最符合.我歌词 .我歌词 .我歌词 需求的方案。经历了99 81难后,.我歌词 .我歌词 .我歌词 给出了下图的比较

在沪江,.我歌词 .我歌词 .我歌词 的避免方案是使用Mesos Consul、Consul、Consul Template等某些列配套工具。当扩容的容器通过Mesos启动后,Mesos Consul(Cisco开源)会自动读取分配的IP和port注册到Consul(1个多专业服务注册软件)中。.我歌词 .我歌词 .我歌词 再用Consul Template(1个多官方定时读取Consul内注册服务的组件)对Nginx进行改造,每次得到更新的微服务信息后更新Nginx配置。通过另1个多一套辅助软件,.我歌词 .我歌词 .我歌词 便可不前要实现自动化的扩容了。

以上内容根据2017年03月14日晚微信群分享内容埋点。分享人黄凯,沪江Java 架构师。计算机硕士毕业。拥有10多年Java研发经验, 6年从事云计算研发和架构经验, 先后任职于 HP、IBM 等云计算部门, 对 IaaS,PaaS 和SaaS, 尤其是云存储有较深入的了解。 2015 年加入沪江, 主导的产品有:课件云存储, 任务调度系统等。现跻身于容器技术的热潮中,希望能凭一技之长,“云”化沪江。 DockOne每周时候 组织定向的技术分享,欢迎感兴趣的同学加微信:liyingjiesz,进群参与,您有想听话语题将会想分享话语题都可不前要给.我歌词 .我歌词 .我歌词 留言。

可不前要看出,使用Docker相比传统应用,可不前要部署更多的应用,QPS增加,资源降低,效果十分明显。Docker与微服务真是时常博得大众的眼球,但实际操作落地却不须容易。沪江并这样走大厂Kubernetes的技术路线,只是 采用更稳定、更灵活的Mesos+Marathon编排也是结合了企业自身的技术能力和业务场景。.我歌词 .我歌词 .我歌词 真是根据自身需求,暂时避免了Docker容器编排、网络、存储、监控、扩容等相关什么的什么的问题 ,但这并时候 终点,.我歌词 .我歌词 .我歌词 将持续对Docker容器应用进行研究。这只是 我今天所有的分享,感谢.我歌词 .我歌词 .我歌词 倾听。

Q&A

Q:Ceph 集群在使用过程所含遇到过哪些地方坑吗,可不前要分享一下?

Mesos将会历史悠久,性能不差,组合方便成为了.我歌词 .我歌词 .我歌词 最终的选择

网络避免方案

Docker网络是.我歌词 .我歌词 .我歌词 遇到的最头疼也是最迫切的什么的什么的问题 之一。站在巨人的肩膀上,业内性性心智心智成熟期的句子图片 图片 期的避免方案有Calico,flannel,docker vxlan,weave,Macvlan等。Calico对物理网络侵入交多,weave性能过差暂时不考虑,统统矛盾集中在flannel和docker network的选择上。网上时候 张著名的性能比较图。

当应用服务的压力达到一定的阈值后,自动扩容应用程序便会通过Mesos Metrics检测到,一起去通知Marathon根据既定的策略进行扩容。当应用服务的压力减小后,扩容应用程序要能进行自动缩容,只是 会根据策略选择缩容法律法子,比如设定当应用服务压力减少到20%后,午夜2点始于了减小容器个数。

总结

通过上述方案,Docker终于在沪江落地了,那它的结果如保呢?下图是.我歌词 .我歌词 .我歌词 对使用前后做的对比图:

本文作者:黄凯

原文标题:DockOne微信分享(一一零):Docker在沪江落地的实践

而Google的Kubernetes则认为存储并否是应该和Docker甚至容器是隔离的,即任何存储时候 卷(volume)。不管是本地存储还是网络存储,应该时候 以前建立好的,在容器看来都只是 1个多卷,通过统一的驱动挂在即可。.我歌词 .我歌词 .我歌词 属于墙头草派。结合两者的特点,首先创建并否是存储卷,再通过Docker的卷驱动进行挂载。其底部形态如下图所示

本文来自云栖社区合作法律法子法律法子伙伴Dockerone.io,了解相关信息可不前要关注Dockerone.io。

沪江在使用Docker前,首先对业务进行了拆分,把传统服务拆分成微服务后再实践Docker部署。今天我以沪江的课件云为例,先讲解一下服务的拆分遇到的什么的什么的问题 。微服务的颗粒度老只是 众多架构师探讨的什么的什么的问题 之一,在众多的讨论中,我比较欣赏微服务教父Sam的1个多定义:微服务是1个多要能在1个多星期内重构完成的小应用程序。统统在拆分课件云业务之初,就以两星期原则为拆分法子,分为下图另1个多的底部形态:

Docker Network方案是由Docker公司开发的,对Docker并否是有足够的支持。在网络隔离性上时候 一定的控制,比如保不前要控制1个多Overlay网络之间互访。在传输波特率上将会使用了内核级分包拆包,传输波特率和资源消耗要远小于Flannel。Docker Network的使用过程中,.我歌词 .我歌词 .我歌词 也遇到了某些的坑,同类 内核的版本或Docker版本过低由于 网络不稳定等,建议使用并否是网络方案的同学把linux内核升到4.4,Docker版本升到1.11以上。对于将来,.我歌词 .我歌词 .我歌词 计划研究一下Calico网络,毕竟村里人 称Calico是产线上最好的网络避免方案。

存储避免方案

业务对于存储的需求,大致有两点:日志和共享存储。这两点恰恰反应了Docker本地存储和网络存储的避免方案。在存储上Docker和Kubernetes有一定的分歧,Docker公司比较推行Volume-driver的理念,即所有的存储时候 驱动,本地存储和网络存储只是 对应的驱动不同而已。

【上海站|四天 烧脑式微服务架构训练营】培训内容包括:DevOps、微服务、Spring Cloud、Eureka、Ribbon、Feign、Hystrix、Zuul、Spring Cloud Config、Spring Cloud Sleuth等。容器化技术在过去的几年甚至到现在时候 1个多十分红火的技术,每1个多对技术某些追求的公司对容器某些时候 些蠢蠢欲动与研究,我厂只是 例外。今天.我歌词 .我歌词 .我歌词 就来谈谈Docker是如保在沪江落地的。

Docker与微服务

微服务与Docker时候 着简单轻量的代言,以至于.我歌词 .我歌词 .我歌词 说起Docker便会联想起微服务。但真是两者这样本质的关系,Docker可不前要不依赖于任何语言、框架或系统,而微服务负责拆分业务,解耦比较复杂应用。将会Docker相比VM更加轻量,更加灵活,正好符合了微服务的某些原则,统统.我歌词 .我歌词 .我歌词 老要使用Docker来部署微服务。

原文发布时间为:2017-03-19

.我歌词 .我歌词 .我歌词 针对Flannel和Docker Network也进行了性能的比较后发现,在大并发的状态下,Flannel网络CPU占用过低,这是将会Flannel基于大三层对tcp请求进行了封包与拆包由于 ,Docker network真是也前要封包拆包,但其过程所处在内核中,性能要优于Flannel。具体网络拓扑见下图:

目前Docker的监控方案有统统,同类 Google的cAdvisor,Datado,SoundCloud的Prometheus等,.我歌词 .我歌词 .我歌词 选择了使用Mesos自带的Metric做为.我歌词 .我歌词 .我歌词 监控的元数据。其原理是:任何使用Mesos Framework启动的任务,都能通过Mesos的Matrics API获取到。通过并否是底部形态,Docker的CPU、内存、磁盘利用率就能监控了。至于还原现场,统统公司都各显神通。.我歌词 .我歌词 .我歌词 对此需求时候 怪怪的强烈,统统这样研究。

扩容避免方案

对微服务进行扩容是相当麻烦的事。微服务并否是部署数目众多,扩容只是 会只扩容几条Instance,将会是人工运维话语,前要对上层的LB逐一的修改配置。这肯定不符合工程师们“懒才是推动技术发展动力”的观念,如保对微服务进行自动扩容成为了.我歌词 .我歌词 .我歌词 新目标。