No.53期分享实录:应用场景驱动容器方案选择设计

今天的线上分享,我们来说说容器和应用这亲密的哥俩。

你对应用系统好,那么应用系统就对你好。

你对应用系统说,hi,上container吧! 一切问题都解决,那么就等着应用系统忽悠你。

应该说container比起VM更贴近应用,可以理解为应用的"虚拟机",对应着VM是OS的虚拟机。

我们上container的目的是为了应用,因此问题的本源是应用而非container,一个应用系统本身设计的好坏决定了最终应用的效果, 因此说设计好应用,才能用container的手段更好地支撑它。

从应用的性能和稳定性说起,有如下五点:

 

  1. 容器的启动时间和应用模块的初始化时间共同决定了应用的准备时间
  2. 容器和节点的关系的选择影响着性能和稳定性
  3. 应用的数据结构影响着容器应用的性能
  4. 应用采用的中间件影响着容器伸缩的形式
  5. 应用的结构设计影响着使用容器的方式

  

1、容器的启动时间和应用模块的初始化时间共同决定了应用的准备时间

容器的启动时间为秒级,但这只是OS上启动一个进程的时间而已,并不是一个应用启动的时间时间,一个应用加载后会有个初始化的时间,对一些应用的不同环节,会有不同的考虑,比如需要数据缓冲服务的进程,在加载的时候就需要把数据读入到内存中来,这类我们可以称之为有数据服务。当这个加载服务还未完成时,是不能对外提供服务的,因此实际的时间应该是启动开始到能实际提供服务的时间,而非容器本身的启动时间。

这类的问题可以通过容器的提前启动来解决。

2、容器和节点的关系的选择影响着性能和稳定性

 (1) 如下这个图,容器a在节点node1上,容器b在节点node2上,这两个容器通过网络进行数据和信息的传递

再看一下另一种形式:

(2) 如下图,容器a和b都运行在同一个节点node1上,容器之间通过内存或非物理网络进行数据和信息的传递

 

(1)和(2)比,a拥有node1的计算能力,b拥有node2的计算能力,整体而言计算能力强过(2),但这是以a,b都是密集型计算任务为前提的,对于普通的处理,a,b对node1和node2的资源占用远未带到满负荷的程度,那么这个比较没有实际意义。

而(2)的好处是相对于(1)容器a,b之间的数据交换不通过物理网络,可以以非常高的效率进行。

考虑到实际的场景,我们可以归纳如下:

从上图比较,我们很难区别出哪个方式更好,只能说按场景进行不同的侧重选择,比如(1)可以减少网络的占用,这里我们再考虑再具体一点的场景,比如容器a跑的是应用,而容器b跑的是数据库,那么比较就更加具体了,我们知道数据的HA比普通的应用得HA麻烦一些,这时候我们就只能判断出从稳定性上而言(1)会好过(2),因为这时候(1)的好处是应用出问题时不会引起数据库的切换,数据库的切换与app server不同,有数据完整性等的要求,而且切换时间一般比较长,因此对于数据的HA建议如下:

也就是说数据的HA尽量不要跟其他环节的HA混在一起。

3、应用的数据结构影响着容器应用的性能

大家都在说微服务,实际上微服务本身跟容器没有关系,但容器可以使微服务更好地发挥作用,微服务的划分有个粒度的问题,而这个粒度很多时候是跟数据结构相关的。

对于一个乐队,每人一件乐器,也就是乐队的乐器是按人为粒度设计的,恰到好处,如果设计成一个笛子两个人共同吹可能就会有些问题,参考如下建议原则:

 

  1. 对于要处理的数据列比较少,并且来源于同一个表,那么对这个的数据处理单元就不要按列再去拆分成更小的微服务。
  2. 对于要处理的数据记录比较大,那么这时候按也业务区间进行更小的服务拆分是可以的。
  3.  对于大量的数据分析查询,数据的读取也会使一个时间成本,这时候采用列式数据存储可以大大缩短数据读取的时间。

  

4、应用采用的中间件影响着容器伸缩的形式

说到容器的伸缩,我们自然想到是在空闲的节点上启动容器,这里我们再具体一些,比如用了中间件,这时候情况就有些具体的不一样了,我们知道中间件有:

 

 

  • 可伸缩性
  • 高可用
  • 应用程序故障转移
  • 管理据库连接池

  

以weblogic 为例,可以理解为下图:

weblogic有自己的一套集群管理和应用负责调度机制和规则,相对于容器,weblogic更接近应用和数据库,还有在一个weblogic节点里会有多个用户并发访问并调度到不同节点的EJB里,原因是基于中间件开发的应用系统是安装中间件的一套规范来进行的,因此中间件直接感知的就是应用的流程和状态。在这个场景下,用户请求在不同中间件的调度管理就交给中间件本身。 而容器平台所做的就是将每个中间封装在容器镜像里,根据实际的部署需求在不同的节点上运行起中间件容器即可,并且外部访问入口的负载分发也可以交给容器平台来调度。 因此总结建议如下:

如果要上更好地上容器,那么可以考虑变成如下形式:

由于Servlet和EJB属于同一个节点,Servlet和EJB之间不存在负载偏转调度的问题,那么全靠容器平台伸缩了,对容器而言可控性更强。

5、应用的架构设计影响着使用容器的方式

不同的业务场景和性能会要求应用系统和容器平台系统有不同的侧重点,比如业务计算并不复杂,而且负载主要来自用户并发的压力,和业务本身就比较需要计算量,在小并发时就有着负载的要求的侧重就会不同,前者要求依据好的规则将入口的请求分发到不同节点,后面服务端根据负载的并发变化而伸缩。 后者则需要设计好后端的逻辑流程,数据结构和存储等环节来更好地适应容器特性,如果是两者的特性都具备,那么就入口分发规则和后端规则需要一并考虑。

对于一个业务应用系统,数据是核心,因此这里从数据开始展开,我们知道一个业务系统会有很多种不同的查询工作,也就是对数据库而言是一些数据的读取和运算过程,这里就会有两个选择:

 
(1)数据的运算放在存储过程里,外面的容器通过接口只取到最终结果即可

(2)数据的运算放在跟数据库相连的分布处理容器里,数据库只负责存储管理数据和一些基本的简单查询,就算有存储过程也是简单的存储过程,太复杂或耗时的运算放在应用容器里。

  

对于(1),当同时的写请求比较多或数据更新比较频繁的时候,数据存储过程的执行本身会成为一个瓶颈,而这时容器里的应用只在等待数据返回的结果,在数据处理计算上无法帮助数据库,因此在数据库服务器不是高性能节点时不推荐这这种方式上容器,因为设计上无法让应用容器进行数据计算负载的伸缩。我们归纳为下表:

通过如上表格可以看到,用好容器,可以使性能更高,更加容易部署和维护数据库相关的计算。

我们把方案(2)用图表示出来:

容器虽说是生命周期应该短,用时启动即可,用完销毁,但为实际的应用考虑,可以预先启一些容器,可以成为某个服务的container pools,并对这些container定时作服务路径完成性检查,以确保服务的性能和稳定性。所以上述图中举了两个容器服务池:

 

  1.  buffer pools:数据库缓冲服务池,池里的容器分担数据库的读负载,读的越多越频繁时,缓冲池的效果越明显。
  2. job pools:作业任务池,这个池里是提交和预先准备的需要进行计算的程序逻辑,有了容器后,这个提交工作变得简单了,这个简单是对增加了新的类型任务逻辑而言的,只需要提交测试过的容器镜像即可,job manger会根据任务的类型需要启动哪个类型的任务。

  

作者介绍  代豪

  • 有容云联合创始人兼CTO;
  • 超7年中科院研发经历;
  • 32年资深编程老手;
  • 深入研究高性能计算、分布式计算、网格计算、通信、数据库、集群、移动终端。


时间: 2024-09-19 16:05:51

No.53期分享实录:应用场景驱动容器方案选择设计的相关文章

优云敏捷运维分享之:业务场景驱动的服务型CMDB

最近这几年,国内外CMDB失败的案例比比皆是,成功的寥寥可数,有人质疑CMDB is dead?但各种业务场景表明,当下数据中心运维,CMDB依然是不可或缺的一部分,它承载着运维的基础,掌握运维的命脉. 分析以往失败的案例,静静的想一想,失败无非两点: 一.CMDB自身建设能力不够,无法适应当下数据中心和云环境的新形势.当下数据中心的特点是敏捷.动态.持续发展.甚至当风暴来临时,数据中心的环境是瞬息万变.传统型CMDB跟不上节奏,只能望洋兴叹,频繁应付处理各式各样的问题. 二.非场景驱动,无法支

分享 21 个最新的超酷 web 设计特效

日期:2012-3-25  来源:GBin1.com 如果你想让你的网站与众不同并且留给访客极深的印象,创建一个超炫的特效网站绝对是你第一步需要去考虑的,这里我们收集了21个超酷设计特效的网站.希望能够给大家带来灵感,如果你也喜欢我们的收集,请给我们留言,谢谢! Layrr 如果你访问这个网站,你将体验到超酷的滚动特效.滚动将显示网络中体现他们项目创意的大量信息 Contain.r 当悬浮于一个项目图片后,将会展现快速显示的幻灯,当你离开,则恢复到目前图片. Faces of New York

第1期Talk实录 | CN-DBpedia构建技术和思路

[ Q & A ] 在QA环节中,谢博士请来了知识工场指导老师,复旦大学肖仰华教授,为大家深入解答所有问题.肖老师简介参看http://gdm.fudan.edu.cn/GDMWiki/Wiki.jsp?page=Yanghuaxiao. - 01 - Q: 请问中文的特定领域nlp模型训练怎么解决标注集不足? A: Good question. 领域样本总是稀疏,可以考虑迁移学习,特别是基于深度学习的迁移学习,目前这个领域的研究刚刚开始,可以参考:http://gdm.fudan.edu.cn

PaperWeekly 第53期 | 更别致的词向量模型:Simpler GloVe - Part 2

  前言 本文作者在更别致的词向量模型:Simpler GloVe - Part 1一文中提出了一个新的类似 GloVe 的词向量模型 - Simpler GloVe. 本期我们将带来该系列的后半部分,包括对该词向量模型的详细求解.结果展示,以及代码和语料分享.  模型的求解 损失函数 现在,我们来定义 loss,以便把各个词向量求解出来.用 P̃ 表示 P 的频率估计值,那么我们可以直接以下式为 loss: 相比之下,无论在参数量还是模型形式上,这个做法都比 GloVe 要简单,因此称之为 S

第2期Talk实录 | 词向量的几何分布及其应用

[ Q & A ] 本次 Talk 中涉及的三篇 paper 如下: https://arxiv.org/abs/1702.01417 https://arxiv.org/abs/1611.09799  https://arxiv.org/abs/1610.07569 请问穆博士,您能详细的讲一下 subspace representation 的方法吗? 穆佳琦:感谢提问!首先将所有词的 vector 堆叠成一个矩阵,提取这个矩阵的若干个(3-5)主成分,然后这几个主成分对应的 vector

第4期Talk实录 | 基于知识库的问答

Q & A Q 请问崔博士,在 EntityLink 部分可以推荐一些比较好的 link 工具吗? 崔万云 应该还没有特别好的,我们在自己实现.不过有大量的相关文献.英文也有现成的应该.中文的必须自己实现.可以搜一下 gerhard weikum 在 sigmod 的一个教程,里面有提到. Q 请问一下,在基于多粒度的神经网络模型中,没一种特征采用了不同粒度的表示,请问在用不同粒度表示的向量在 merge 的时候是直接 concatenate 还是加权求和,或者其他?如果是加权的话,对于不同的粒

第3期Talk实录 | 数据驱动的大规模分类体系构建

Q & A Q 对于关系传递性的正确性判断这篇论文,文章是建立在构建标注数据和特征上来做的,想请问下有没有一个宏观的解释,在什么情况下传递性成立以及什么时候不成立呢?换句话说,不成立主要是因为什么引起的呢? 梁家卿 因为我们使用的是一个黑核,就是机器学习模型,所以我们很难知道它具体是由于什么原因引起的.我猜想的话,主要是因为中间词 B 意思的偏移,但是这个偏移我们很难严格的定义.总来说很难知道具体原因是什么,因为机器模型实在是不可解释. Q 对于 recall 的评估,文章的模型发现的错误 is

爱游戏精品指南第53期

忍者下落前言:苹果iPhone资深玩家以及正版软件 用户对于苹果App Store限时免费与冰点降价应用可谓是情有独钟,随着苹果iOS系统平台 应用数量的不断增长,每日的限时免费与冰点降价应用也愈加增多.在这些琳琅 满目的苹果iOS应用中,究竟哪些游戏最好玩呢?就请您关注 蚕豆网开辟的全新栏目--爱游戏精品指南,我们每天都为您推荐最吸引人的苹果iPhone游 戏,帮您节省宝贵的时间与金钱![忍者下落](Ninja Fall Down)水墨风格的动作休闲游戏,考验玩家操作的游戏,规则很简单,控制左

聊聊移动场景下的图像处理应用设计

  毫无疑问,手机拍摄.移动端处理图像,已成为社交平台图片分享的主要路径.本文将通过一些案例,和大家探讨下从PC端转向移动端,图像处理体验将如何更好地适应小屏操作,以及不同类型的图像处理应用在功能设计上不同的偏重 >>> 那个"兴冲冲地在电脑上导入相机刚拍摄的照片,打开PS处理照片,再上传至图片社区"的日子仿佛离我们越来越远. 随着社交平台移动化,我们更关心是否能及时.快速地分享照片.现在,移动端的图像处理应用层出不穷,愈加优秀的手机硬件性能为图像类应用创造了更多可能