云粘合平台漫谈及代码理解初步例子NULL 博文链接：https://lokki.iteye.com/

文件名称: 云粘合平台漫谈及代码理解初步例子

所属分类: 其它

开发工具:

文件大小: 731kb

下载次数: 0

上传时间: 2019-03-23

提供者: weixin_********

下载 (731kb)

不能下载？报告错误

详细说明：NULL 博文链接：https://lokki.iteye.com/blog/1041255大规模自动化服务,及以上以下的一些名词,但大多数都只实现了简单的服务和功能部件,也未能很好地"动态化、按需化、快速化”。而在互联网服务新阶段,云计算基础设施里,分布式海量储存、 cache、 KeyValue、 KeyList、非关系式储存、 MapReduce、 Loadbalance、CDN、 ondemand等,这些名词是常见和普及化的。用后面介绍的名词来说要有专业方向云技术部件” “SLA服务品质保障协议”。云服务的可靠供给、不间断和“动态化、按需化、快速化(无缝切换) 是有具体数字指标和协议的,即使是自己公司内部开发给自己使用的基础设施。 12云计算情景年青的时候,脑里经常幻想着机房里成千上万台 Server farm轰鸣所带来的浑身澎湃动力,也知道 google和 amazon的技术和结构很了不起,运算力/grid和内外存按需分配。但感性又简单的场景认识却是没有的,直到几年前在这个网站看到这个感性的架构图 http://www.heroku.com/how/architecture Routing Mesh Dyno Grid 看起来真美!因此脑里随时在想具体软件结合的情景,怎么实现他。我还有一篇《內存数据层和商品数据粒子化》PDF和一篇《 Redoflow说明和分布式事务》PDF,也是有实际意义的,但这架构做起来必须要有管理细致的自动化OPS支撑,否则人力就疲于处理故障了 2云的名词、分类和组成常见:在“云”这个字前面或后面加上自己的行业名词,就表示自己的系统和“大规模上关系了 (1)建造大系统,资源自用,为私有云”;将运算力和容量,将资源量化成价钱销售给客户,为云租用/ 云服务平台。但无论怎样,都要能将资源量化单元化地控制好,才能知道怎控制"可伸缩在 Gartner技术生命周期图(2010 Hype cycle里,分开为 Cloud/ Web platforms"、“ Cloud Computing";、" Private Cloud Computing"。 Web platforms或许指的是下面说到的SaaS系统。 (2)“云这个计算机/网络/软件系统,自下而上可堆叠为这3部分组成:云计算基础设施、专业方向云部件、云业务。无论“私有云”,“云服务平台”,都有这个堆叠结构云业务是面向终端用户和企业的大规模商业服务。专业方向云部件是处理大流量大数据的技术部件,包括处理型、储存型、网络接口型等,比如第3页共15页 lucene及其卫星产品、 hadoop(及其卫星产品, HBase、Hive、HDFS、 zookeeper)、 mysql、 memcache、 cassandra.redis等等这些被各大互联网公司和架构证实成熟了的部件。网络接口型包括http接口的各用途 webserver和专用接口的sere容器这些基础的技术部件被业务数据和技术数据所广泛使用,技术数据包括日志系统、容灾系统、监控和 profile/trace系统等。海量的机器和技术部件需要有一个云粘合平台将这些有规则、高效地管理起来,也不能让硬件资源太空闲。云粘合平台是云计算基础设施的软件环境。 (3)将资源提供给外部使用的云服务平台,按技术/服务的程度,可分为:SaS、PaaS和laS这3个常见名词。由于本文主讲述的是底下“云计算基础设施中软件结构,所以没讨论这3个的前景等事宜 saS类似 salesforce,将业务功能都开发好,将运行资源都安装部署好给客户了,即连“云业务的功能都交付了 PaS是由客户自己开发业务功能的主流程,由PaS平台安装/署运行,提供所需的资源,以及高性能储存服务。交付了“云计算基础设施”、“专业方向云部件→高性能储存服务” las是提供硬件基础设施给客户,客户可按需调整操作系统等环境,运行自己的功能。主要以交付云计算硬件基础设施为主。 (4)无论是私有云,还是云服务平台中的PaS/SaS,都要管理/粘合好各种异构的软件坏境和软件技术部件,所以“云粘合平台”是必须的,只是有些可能只是几份复杂的脚本 3云粘合平台 31云粘合平台交付的功能 (1)云计算基础设施软件要交付的功能,必须要交付的一项是:自动化发布部署系统比如: linkedin的自动化部署系统gu(开源) http://inkedin.github.com/glu/docs/latest/html/index.htm在g的旧文档,在overview这角度会更清晰/简单,而新文档, overview图示没那么直观了,而在内部结构/生产环境的操作说明上更详细周到了。gu用了she|本+ grail+java开发功能,用了 zookeeper做配置管理,支持多war部署到同一 P上。 (2)有的私有云平台,还可能交付了一些编程模型:即要求功能/云业务的开发者要按特定于本平台的格式写代码,然后运行时进程内,会以特定的结构运行。 Java web server是wa格式的编程模型,同理特定的 container总有一个编程模型。比如: twitter新开发了一个 container: blender http://engineering.twittercom/2011/04/twitter-search-is-now-3x-faster1656.html 这个 blender用java编写,没有粘合任何现成的 Java Web server( jetty/ tomcat),而是以net为网络基础代码,实现了http和内部RPC网络接口协议,这个containe在内部还实现了单元化的service机制, 第4页共15页以及用 workflow机制来表达 service间的依赖和 service间的处理衔接。那这个 container,没有用很多现成的 Javaee标准,大部分机制和功能都是为自己的需要而写。这篇文章没有透露出单元化的 service是怎么使用 Classloader的,也没透露出 service是怎么部署/ update的,但肯定有这两个机制比如 hadoop,让业务开发者只继承 MapReduce Base写一个新类,编译后投入它的系统里就可以运行了,而 hadoop为这个模型开发了一套复杂庞大的支撐系统。不过业务类里只有一个简单 MapReduce 子类的 hadoop业务系统也是很原始的,应该还要自己开发很多周边服务供 MapReduce取来源/放结果/ 报告,这套系统才是细致/友好的 32云粘合平台的产品化和所用语言云计算基础设施软件“云粘合平台的开发技术,和“开发云业务”所用的语言是分开的,可为she脚本、 python、uby、java这几个。而云粘合平台肯定要交付的自动化部署系统”,一个好的部署系统必须有可以记录部署操作过程/状态的持久化功能,单纯的she|脚本比较难做到持久化复杂的信息,she|脚本也很难做到跨机处理衔接。所以在云粘合平台里,she脚本肯定要有,但代码/重要性占的比例应该不高。 she脚本(自己写的)重要性高的系统,都可以称之为轻量级"的系统,肯定不会交付一个新的编程模型,而是基于现有的war等标准编程模型,感觉上这样的系统,难改不敢改,或容易被得面目全非,产品化程度就不高。而像 hadoop,虽然是一套组件非常多、非常复杂的重量级系统,但基于独特难替代的业务功能( Mapreduce),众人拾柴火焰高发展了那么多年后,被全世界所认可,这个产品化是成功的。所以开发“云粘合平台”,粘合,应该是从“轻量级粘合到“更多自定义化”,入侵应该是从无入侵”到交付编程模型”。特别是在“私有云”系统里,比如 twitter blender,如果不涉及到JBC这一块,是在一个 Java application上自定义了自己进程内的运行结构,不怎么理会 JavaEE标准,所以他的性能非常高,团队里云业务的开发效率经过培训后也是很好的,因为多余的东西少了。 33粘合程度:共享资源和充分利用的层次要低成本,就要能共享一些硬件资源,共享硬件资源有几种层次/方式 (1)虚拟机方式:多个虚拟机共享同一台实体机,这种方式除了在网卡共享的安全性要确认好外,是最现成最简易的,但资源利用率是最低的,因为同一实体机上有多个操作系统实例在运行,分母变大了业务线程能分到的资源就小了。但安全性是最高的。 (2)多服务进程方式:一台机器上,多个不同的业务进程分别同时运行,用 chroot实现安全隔离,这个安全性也是可接受的,资涼利用率也比(1扃高,自动化脚本复杂度和(1)差不多。如果是C语言开发的软件, 由于各软件间共用的资源不算多的,用这种方式也好的 (3)同- container进程多服务方式:如果是java开发的应用,在安全能接受的情况下,多个业务以不同的 WebApplication方式或不同 OSGi bundle方式或不同 Service,在同一个 container jvm进程内一起运行,能比较充分地共享/利用资源。但对业务程序的结构、代码质量、问题 profiling工具、OPS系统的要求很高。各方式,没有优劣,得看场景期望/要求第5页共15页 34粘合程度:不间断/无缝切换的层次将软件的功能,不影响用户地从旧功能升级到新功能,有几种方式 (1)重启进程方式:简单地将进程停掉,前鳊会连不上入口,而 failover到同—功能的其它C| uttering|P 上,部署好新代码后再重启。 (2)不停WM进程方式:只将某业务从前端入口避过此|P后,利用进程内更新执行代码的方式,升级到新功能。两种方式,无论哪种,最可靠的都要入口先停,业务代码后停,启动时要业务代码先起,入口后打开。这都要控制开关,开关成本和复杂度其实差不多,不过(1已经有F5、 apache+modk支持简单的 htp端口的开关和 failover功能,如果端口 listen了很久,业务还未就绪,这就要计较问题大小和解决方案了。综合起来,(1)是现成的,(2)看起来更酷、复杂、开发成本高点,但有些软件结构需要这种不重启的方式。 35本文的云粘合平台面对的情景和要达到的要求私有云”,和“云服务平台中的PaS,在软件基础设施上的结构是差不多的,但PaaS在共享资源层次、不间断层次上,达到多服务进程方式上就可以了,如果一个 container进程里复合运行了来自不同客户的代码,安全性就成问题而私有云和PaaS在资源单元化和量化上的要求也差不多,只是PaaS按运算力和容量向客户收钱, 私有云要各业务小组监测好容量规划。所以说,私有云的技术要求,比PaS的要求更高,比如在“开关”支持的细致程度上,需要支持上百台机器/几十应用联动和有先后顺序。同时,在私有云系统里,几种共享资源的方式,几种不间断的方式,不同等级的安全性要求,都要可选择才好,这样各业务小组才会满意。本文云粘合平台要达到能实现复杂私有云系统的要求 (1)在资源利用上,要达到“同- container进程多服务方式”,达到更大的降低成本效果 (2)在发布新功能上,支持停进程和不停进程的方式。“不停进程就能更新运行代码”,肯定不是“完全透明地”、“无入侵地”,有的业务团队(业务开发小组)的编程模型/技巧未达到不停进程的要求,那当然采用旧模式 (3)有web界面的整体OPS,及自动部署系统,支持人性化地管理上百开关和先后联动,以及操作审计所以会有开关的编程模型”,将本进程内的控制开关暴露岀去(拿岀去)给』M外的OPS控制 (4)以上3点功能,是本云粘合平台要交付的业务功能,要交付这些业务功能,就必须要有交付一个灵活的单元化的编程模型。这个编程模型,指的是进程内的模型”,除了适合以上3点业务功能的进程外, 也适合其它一些业务功能的进程。要说明的是:像 monitor/ tracing/ profiling的专业功能不是单靠进程内第6页共15页的编程模型”就能解决的,还必须从专业方向深化 36是否需要云粘合平台在章节“2云的名词、分类和组成中说到云的软件组成部分包括这3个:软件基础设施云粘合平台”、专业方向云部件、云业务。其中后两者肯定必不可少,比如总要有个类似MSQL持久化的专业方向云部件吧,而“云粘合平台是否必要,或是否能更轻量化点呢? 心里已经偏颇一方的比较性”文字和图示给不了读者明确结果的,这样说更简单做好云粘合平台,是属于附加了磨刀工序的工作,只有已发展到大事情的情形才需要磨刀,或许有的事情需要更大更利的刀。在有资源的情况下,有云粘合平台和架构肯定好点,在资源不充裕时,应先投入到专业方向云部件去,要玩转专业方向云部件已经需要不少精英花不少时间。如果你的业务已进入到大团队大流量大机器数并分开多个应用的阶段(有5个以上相关应用,每应用有10台以上机器),就可以考虑投入3个精湛人力开发云粘合平台,形成这方面的基础设施/架构。如果能再有额外的2人,投入对业务研发团队的培训则更好有云粘合平台和架构,能收到如下好处 ()有规则:应用程序模型有规则,能迅速面对变化进行调整和切换。 (2)高效:在系统关联性复杂的情況下,对于SA来说,如果没有云粘合平台联合各部件来提供人性化的界面和调整计划,SA的操作步步惊心 (3)充分利用硬件资源,降低成本:在应用程序模型能攴撐的情况下充分利用硬件资源,SA复合利用机器而不乱。最高效使用实体机资源的方式是这机器上只有一个操作系统实例,里面只有一个大内存的vn 然后多个业务可以同存于这个m实例内。但如果没有应用模型支持和开发人员的承诺/计划,SA只会在一个jⅦm实例上运行一个war应用,即使这个war消耗的资源不大机器越多、业务越多越复杂,越能体现出有规则应用模型充分复合利用硬件资源的威力。 37开发本文云粘合平台的成本、实现步骤图示当别人看到一个比较长的文档或比较复杂的架构图时,心里的感觉通常是这样:“这东西可能是好的但成本和要花费的时间可能不少”,一个“复杂的说明给到人初步的感觉就是这样,红明同学表达了他对第一版文档的感觉,这是给我提了意见“这份文档不够好”。所以第二版,在结构上更完整和承上启下了。承上启下就“短不了”,唯有加入本章节,对实现云粘合平台的成本/时间和步骤,作一个图示,并且图示出一些额外可以做的功能,显示出这东西可能有更大的价值下图为一个 xmind作的图,在PDF页面上会压缩尺寸显示,可从以下链接看清全图 http://lokki.iteve.com/picture/89536 做好这个" OSGi container+RPC机制+OPS管理界面 OpsWeb",或许2个人3个月就能建第7页共15页出来。我从公司的RPC学到了透明使用RPC、透明寻址的经验。部署了传统war 问分离依赖的方式1:手动编码连接上 Localservice LocaleryicesBundle再连挠上 RpcProvider 能透明地离线更新依赖分高依赖的方式2部了声月了rort位赖的新wr 方式乙和方式让结合林透明地使用支持 Seryleteundle ba是 container范围的 ocalservices能支持“sNA+ oscAche”中sNA的 update 编程模型支持 ServiceComponent 安排好先后顺序就能安全地热替换 nstance 只有 Remotingcmd和mAt才能发出变更 request,所以需要 Apse或“s脚本+r ⊙R 将各专业方向云部件的客户端封装成unde,并以 zookeeper作统 catr,能讠应用开发者更透明/更间便/更快地使用各专业云部件并且控制种出了m和业务应用之外,这不算是基础走吗 ①自动化测试环境支持因为是RPC所以需费“P白名单位于扬收者端用zook∈per实现 ResourceLocator 寻址透明 RPC service ④4避免9FcF:eorm/ ip swAtch by Opsweb 碌露出 OSGi configuration e 灭多开关控削赖了 emoting runbase上cps-f/s- verify这些机制和 bund e对可靠性相当重要 remotngamd-n 依 Irematingmsg Ops web 因为是remg所以需要“白名单位于请求授收者端基于 unbe9 ⑤人性化,开发局期长云粘合和控制平台的建立过程 P白名单位于请求接收者端” whitelistAt Request Receiver 分割线:以上是完整的基础(优先级14),已具备支持快速调整、RPC和安全的功能, 以下是别入可以做的(优先级5)。以上花费时间其实不需要3个发布/部署系统和 HostAgent是 Ops Web/ rumbas上面加上技术业务 bundle的演练,是云计算基础设施 remotingcmd控制的 instance factory总线 nstance sii总线 oler比较安全控制功能控制系统是云计算基础设施 witchvalueToBean 避免sPoF: Data SourceSwitch 了只有很花时间开发的人性化和才是定和可靠的基础其它的专业方向快送调整6分离依的方式3中包系”基于来换依和 HostAgent上有一个 bundle给监控 Center post监控业务型rrb里安甚了 Monitor serv写入监控og HostAgent上有一个 bundle可以在这host上按部署系统积累的经验快速安装 zookeeper或edis HostAgent上有一个 bundle可以给Hado系统上传日志lag 业务型 nbase里安装了分布式文件服务或图片处理服务的 bundle 有那么多 bundle、各种业务的war和经验corg,肯定需要 repository server ☆对云粘合制平台,20pm作为统的配置管理,用好相当重要有空玩玩 profiling/ trace不错 38图示云粘合平台的技术选型策略同一 container进程多服务方式”,有几种方案可以达到,比如第8页共15页 (1)用 JavaeE WebServer部署多个war (2)如 twitter blender,用 Classloader,但是采用自己的机制搞定 (3)用 OSGi Container标准这里不采用多war的方式,是因为 Javaee Web标准,没有涉及war间的互动,如果自定义 Webapp classloader建立互动,那不如更直接点,并且有一个 Web server这么重的太上皇在控制死了整个进程的结构,要作出改变很难。比较了3种方式后,作出了这个技术选型策略:云粘合平台用非标准的方式当然可以将众多开源部件粘合在一起,但强力推行过程中团队内外总会遇到很多质疑和争论,那不如选取适用的、成熟的、常见的、轻量化的标准去粘合。其实OSGi对于产生这篇文档已经是“先入为主”,所以总会凑够理由来选定它。其实OSGi标准/技术并不是那么难学,深入去体会, OSGi container/标准已经为业务开发制定/提供了很多合理的东西, 但OSGi在和 Javaee标准交叉的领域是遵守并扩展的,所以云粘合平台所用的技术会涉及到很多技术组织。并且和所有标准给过我们的经历一样,选取适用的,抛弃不适用的,技术选型策略图示 JavaeE标准开发云粘合平台或类似开发标准里常用和 ubuntu发行系统的方式成功的部分圆环标准里的开源实现标准里不太成功的部分(圆环) 云粘合平台粘合和监管 ( profile/trace)所需的自己实现和web界面 OAS|S标准 OSGi标准专业方向的云部件和概念(常见的)(技术上的业务上的) 个人期望:云粘合平台用美妙的web控制界面人性化地管理和维护众多和复杂的云机器云系统。 39内部结构图以下有两张图,第一张显示了 OSGi Container内有Web业务组件、有RPC业务组件,一些开关和 instance会被外部OPS在线控制着,在线的意思是“外部直接和这个进程通信,这进程要活着”。第二张图则重点表达了OPS功能、离线控制是通过 HostAgent控制,以及服务器端安全白名单”功能 HostAgent,是另一个小内存m进程不间断运行(有别于业务jm进程),因此它可以对其它 unease instance进行 offline控制/本地 filesystem处理,并能达到SA脚本的功用。也能对c语言的专业部件作外部控制。事情不是那么容易说清楚的,目前只是展示出两张图,还待时间开源可以了的源代码在PDF页面上会压缩尺寸显示,可从以下链接看清全图 http://lokki.iteye.com/picture/89592 http://lokki.iteye.com/picture/89594 第9页共15页」 avaOps和 unease架构图打包系统 Clustering和 Zookeeper 应用A: 应用B witch 手动御 web rpc manager zookeeper biz biz (and ( ResourceAnd (SNA) (SNA) Lifecycle) INodeA iClassLoader ClusterNode DB 发指令 resource instance switch ps Exec tor稼验执行情况 value instanceholder /factory (指令队列) d坊/( psCenteropsWeb 每|P集一序本地储存夹 java runbase Forcennector web file( config) protocol rpc bundle protocol transfer repository Getty) 特殊颜色说明 rpc WebBrowser 先实现/收获的环节 protocol Node B 第二研究实现的环节 OSGi container HostAgent和」 avaOps架构图 key DB value 储存夹 war 3080 Jetty web protocol warl repository web expose war deployer config 服务器端安全白名单 zookeeper rpc protocol psEXector rpc expose remotingcmd 打包系统 runbase w ith jetty 查询 offline deploy start/stop deploy runbase instance1 remotingcmd pushCommand remotingcmd Server returnResut Sender more agent Ops Erector OpsCenter components 服务器端 web 安全白名单 postResultFile 第10页共15页

(系统自动生成,下载前可以参看下载内容)