独立开发一个云(PaaS)的核心要素, Go, Go, Go!!!

原文链接:https://yq.aliyun.com/articles/2783

最近一年的工作,有很大的比重在做云平台的事情,简单来说,就是为公司内用户提供一个PaaS,用户可以在我们的云平台上方便的将单机服务程序扩展为多实例程序,以平台服务化的方式对外提供。在这里简单分享一下。

首先简单说一下我们解决了用户的什么需求,或者说痛点。

基础算法直接以库的形式提供给应用方?

用户提供了一个基础算法,这个算法可能以一个动态库的形式提供,那么使应用方需要关注编译依赖,需要关注词典等模型文件,开发成本比较高。尤其是如果这个基础算法需要升级,或者模型文件需要升级的时候,还需要通知应用方进行修改。而且,如果基础算法不稳定,有出core的行为,那么势必影响了应用方的服务质量。还有就是,如果基础算法非常耗资源,比如CPU,内存占得太多,可能会影响应用方程序对于资源的使用。

基础算法的服务化

为了避免基础算法以动态库提供给应用方的种种弊端,基础算法可以以网络服务的形式提供,这就是基础算法的服务化。就是说,基础算法是一个网络服务,用户直接访问这个网络服务即可。这样,基础算法的服务接口只要不变,不论它如何升级,都不需要应用方做任何修改。开源的Thrift,等等RPC的方案,都很好的满足了基础算法服务化的需求。

服务化的质量如何衡量

那么一个服务化的基础算法,如何保证上面所说的服务质量和延时上的要求呢。尤其是服务质量,或者说可靠性。如果我们假设机器永远无故障,网络设备也永远运行正常,服务也足够稳定,不会有core,也不会升级等等,那么直接找一些机器拉起来就万事大吉了。但是,现实却是残酷了,首先服务可能会有故障,它应该会不断升级(如果有一个不用升级的程序,要么是太完美了,要么就是没有人用了,大家写程序都知道,完美的程序你永远写不出来,少写点烂代码才是正常追求),升级的过程不能影响服务质量,还有服务不可能独占机器的,很有可能会和其他服务混布,那么如何选择合适的机器部署,也是一个问题。还有,很多时候一个服务实例是满足不了需求的,可能要部署多个服务实例,这里边的问题就更多了,请求发给哪个实例,负载均衡,等等等。

服务平台化需要面对的问题

我们下面将服务化的基础算法,以承诺的服务质量对外提供的过程,称为服务的平台化。就是说,服务化的基础算法,经过一个平台对外提供,就能获得相应的服务质量。那么平台化的挑战有哪些呢?

如果一个基础算法自己想实现平台化,闭门造车,需要做很多工作。这也是PaaS存在的意义,将大家服务化的工作都通用化,让策略开发者解放出来。那么,平台化要解决的哪些问题,或者基础算法服务化的痛点在哪里呢?

服务的平台化,并不是简单的在几台机器上把一个服务部署起来,对外提供服务,尤其是对应用方承诺了服务质量的时候。而且,为了提升机器的资源利用率,一般几个服务会混布在一起,因此如何合理部署服务也是一个问题。除此之外,服务的平台化还需要关注很多事情,用户一般需要关注以下几点:

1.    如何定义服务接口,使得用户根据这个服务接口就可以自助完成服务访问

2.    服务寻址:应用方通过何种方式访问访问后台的策略服务,如何做请求的负载均衡,后台服务地址变更时,如何通知应用方

3.    服务上线:既要保证上线新的服务不能影响老的服务,又要满足当前服务的资源需求

4.    服务扩容:随着请求的增加,如何扩展实例数来满足应用方需要

5.    机器故障:机器出现故障时,如何保证服务质量不受影响,如何将故障机器上的服务迁移到其他的节点

6.    服务升级:如何实现在不影响服务质量的前提下完成服务的升级

7.    访问统计:如何统计访问量,服务延时,能够区分不同用户访问的不同服务等,类似于Hadoop Counter,实现一个比较简单通用的Counter

8.    监控与报警:服务出现问题时,如何实现报警机制,以便第一时间发现并解决问题

9.    访问权限与流控:服务属于保密性质,只能让指定用户使用;应用方的访问频度需要按照约定来进行限制

10. 服务实例的动态扩容与缩容:为了节省资源,增加资源利用率,需要有动态扩容与缩容的机制:即服务实例负载高的时候,能够扩容以满足计算需求,而在负载低的时候,缩减服务实例以将机器资源给其他服务使用。

 

架构当然要去解决基础算法平台化的时候遇到的上述问题。但是除了这些问题之外,还需要关注以下问题:

1.    资源管理和调度:服务要分配哪些机器

2.    服务的部署:分配了机器后,服务实例的程序包如何下载,下载后如何拉起服务

3.    服务地址的汇报和更新:服务实例拉起后,如何汇报服务地址,让应用方使用这些地址,还有地址更新后,如何通知到应用方

4.    资源隔离:只能给服务以承诺的配额,比如多少CPU,多少内存;避免有问题的服务影响其他的服务

5.    不能影响服务的性能:这就要求不能用有性能损耗的虚拟化技术来做隔离等,我们要实现用户直接使用物理机相同的性能效果

6.    计费系统,按照不同的资源使用情况来计费。对于公司内部平台来说,如果机器是平台的,用户只是使用,那么可以没有这个系统;但是如果需要服务的提供方提供机器,来换取相应的计算资源,那么还是需要的。

由于以上问题,RD不能专注于核心策略的实现,不得不做很多平台化的事情。当然了,部分问题可以通过人工运维的来完成的,但是这又会造成服务的维护成本过高。而且,人工运维总有一定的滞后性,可能在某些场景下会出现服务质量下降的问题。还有机器的资源利用率的问题,也是一个复杂问题。

 

如何解决上述问题

那么如何解决上述问题,这里我们给出一些可能的解决方案:

1.    如何定义服务接口:使用一些通用的RPC解决方案,比如Thrift。像我们使用的是sofa-pbrpc,https://github.com/baidu/sofa-pbrpc。这个是百度内部应用比较广泛的一个RPC,有针对于公司内部应用场景的丰富组件。

2.    服务寻址:简单来说定义一个接口通知应用方后台服务的地址。当然sofa-pbrpc有实现的一个寻址组件,应用方只需要指定一个名字就可以完成寻址,这个组件也完成了负载均衡的策略,能够将请求打散平均发送到后台的服务商。当然可以以ZK来实现寻址。比如服务实例拉起后将自己的地址添加到ZK的一个节点下,退出时由于与ZK的连接断开而自动删除自己。这样应用方只要监控这个节点的数据变化即可。负载均衡的话最简单的就是将请求按照顺序发送到后台。但是有一个问题就是机器可能处理能力是不相同的,就是集群的机器都是异构的,因此可以记录一下每个节点的处理能力,当一个服务节点pending的请求比较多时,那么就优先发给处理请求比较快的节点上。

3.    服务上线:这个实际上需要集群资源管理与调度的功能,就是用户提交了服务上线的请求时,按照用户的资源请求,比如每个服务实例需要多少CPU Core, Memory以及网络等的情况,还有实例的个数,为这个服务分配计算资源。集群会选择符合这个服务的机器节点,分配给服务。这个分配算法业界也有很多研究,核心就是提供资源利用率,而又要保证服务的质量。对这个有兴趣的可以看一下dominant resource fairness算法。

分配了计算资源后,就需要在节点上把这个服务部署好,部署完成后把服务拉起。

4.    服务扩容:当服务的负载变高时,需要扩容服务实例数。这个其实和服务上线差不多,需要分配计算资源,部署,服务拉起等。

5.    机器故障:任何云平台都要考虑这个情况,尤其是机器数量多的时候,机器故障几乎成为一个必然会发生的事情。这个需要下线这个机器,即资源调度模块标记该机器未不可用。其次还需要将该机器上运行的服务实例迁移到其他节点。

6.    服务升级:这个过程可以不需要资源调度模块的参与:在各自的服务实例所在的节点上就地升级,比如直接下载程序包,下载完成准备好环境后直接停止原来的进程,启动新部署的即可。当然这个进程重启势必会影响服务质量。如果服务要求不需要是100%的,那么可能这个最简单的方法也是可以接受的。当然也可以在客户端加重试的逻辑,如果延时能够忍受的话。

另外一个方法就是重新分配一些节点,然后启动新的服务实例后,将老的机器先从应用方的寻址中删除,保证不会再有新请求达到老的服务实例。在服务实例的负载都为0时,老的服务实例下线。这样做稍微复杂,但是不会影响服务质量。但是如果服务实例数百上千,那么这个代价会比较高,甚至没有足够的节点来完成这个升级。当然可以分批次升级,这样无疑有复杂了些。

第一个方法有一个优点,由于都是就地升级的,因此可以快速回滚的老的版本,因为不需要下包了,回滚的时间开销就是进程重启的时间。

7.    访问统计:互联网公司都会有这个模块,就是分布式日志的收集,汇聚和展现。以便展示服务的调用量,延时,等等的报表。这个开源社区也有很多的实现。一般来说就是每个服务实例打印访问统计的日志,这些目标日志会被部署到每个节点的agent收集,发送到比如一个MQ里,然后由一些工作线程去处理这些日志。

8.    监控与报警:平台资源的整体使用量,集群节点的资源使用情况,比如CPU IDLE,Memory的监控,服务实例状态的监控等。在检测到异常触发阈值时报警给用户,或者集群管理员等。

9.    访问权限与流控:这个可以和公司的账号体系打通,这样就可以追踪到非常细粒度的访问权限控制,当然简单的做法也可以直接使用访问者IP来做限制,实行IP白名单的制度。流控对于离线服务比较重要,离线服务注重吞吐,但是有时候一个Hadoop任务起来,可能发到后台的压力非常大,因此流控可以保证后台服务不被压垮,或者保证每个Task不会与其他的Task有资源的竞争。对于在线服务,流控有的时候也会有,比如拒绝一部分请求,总比大家都一起慢下来,但是谁都用不了好。说道这里,又想起一个集群的慢节点的问题,就是一个集群有dead的节点不害怕,就怕有比较挫的节点,运行超慢但是半死不活,特殊情况下可能会拖累整个平台。可以看一下这个文章:http://danluu.com/limplock/

10. 服务实例的动态扩容与缩容:有的同学会问服务实例如果没有计算,就空跑在那里呗,但是至少它会占用内存,而且,一般集群为一个服务分配计算资源时,一般会以CPU,内存为度量单位,因此如果一个服务占用了CPU,内存,那么就会保证它至少能用到这些,对于在线服务来说,“虚拟”一些资源出来在某些场景下会影响服务质量的。 


上面这个问题,任何一个问题都可以衍生出好多问题。因此,本文是我想给大家分享的自己构建一个云平台的时候,需要注意的事情和需要关注的点。完全是抛砖引玉。

我们在过去的一年中,使用Go实现了这么一个云平台。在这里也推荐一下Go。标题中的Go,实际上就是Go的意思。Go,云时代的系统编程语言,就像过去十年服务器的编程语言是C一样,学了你就知道这句话什么含义了。

 

最后做一个广告吧,百度的同学如果看到这篇文章,可以搜索内网搜索SofaCloud,一个彻底解决策略开发者的平台化之痛的云平台。除此之外,我们通过架构优化,还可以节省85%的业务方机器!!我们当前日均数百亿的计算量,数千个计算实例,服务数十个产品线!!!想什么呢,还不赶紧迁移到我们这上边来!!!


用了SofaCloud后,明明的头发都长出来了有没有!!!气色变好了,有没有!!!

 

Cloud,Go!

展开阅读全文
博主设置当前文章不允许评论。

go or not

10-04

事情是这样的,有一家天津的软件公司在招程序员的学徒,用的是DELPHI开发工具,我现在只过了计算机二级,我想去试一试,当程序员学徒,不知这样的公司是不是骗人的?rn他们在CSDN上的招聘在:rnwww.csdn.net/expert/topic/1056/1056887.xml?temp=.5444147rn就是以下的这些话:rn公司介绍:rn 1、本公司坐落于天津华苑软件出口基地,环境优美,配套设施完善;rn 2、本公司主要开发零售业、分销业物流管理软件同时开发医院管理系统兼营大型项目系统集成rn 3、本公司负责安排外地员工住宿,三餐免费,基地食堂伙食不错;rn 4、提供良好的UML语言培训,让新员工能迅速提高项目设计规划能力。rn 5、电话:022-23080098 林经理rn edward666888@hotmail.comrn专职招聘要求:rn 1、熟练delphi或pb,事业心强,好学肯干。rn 2、熟悉财务进销存或医院管理软件者优先且薪酬较高。rn兼职招聘要求:rn 1、必须是大学计算机系教师,能组织带领学生一起兼职开发rn 2、编程工具用delphi、ASP、VB.NET、C#中的一种rndelphi学徒工要求:rn 1、好学、求知欲望强烈、不怕背计算机英语术语。rn 2、负责食宿、每月零花500元。按水平可升职为程序员。rn[b]待遇:[/b]rn 1、程序员1000-2500元,资深程序员2500-6500元rn 2、实施项目经理2000-5500元rn 3、开发部项目经理2500-6000元rn 4、系统流程分析师、高级项目经理5500-15000元rn 5、公司负责吃住rnrnrn不知他们说的是不是真的?rn我很怕被人骗。 论坛

go go go 一起学编译原理去!

10-24

Part1:rn 对于一个编译器,它的编译过程分为以下几个阶段:首先进行词法分析,识别出合法的单词;其次进行语法分析,得到由单词组成的句子结构;然后是进行语义分析,并且生成目标程序;按接着产生中间代码;并对中间代码进行优化;最后从优化的中间代码生成目标程序.rn Part2:rn 在编译原理中,语言是有限字母表上有限长度字符串的集合,而正规式是一个有限字母表,它共有四种形式:r|s rs r* (r) ,其中r和s分别表示集合L(r)和L(s),而一个正规式所表示的正规集均可以用一个不确定的有限自动机(NFA)来表示,而NFA的不确定性,导致了在识别正规式时,要尝试完全部可能的路径,而且进行了大量的回溯,从而使人们希望能产生一种一对一关系的自动机,这就是后来出现的确定的有限自动机(DFA),它的状态转换是唯一的,而对于两个等价的DFA,它们的状态又有所不同,有一些状态少,有一些状态多,这样就引伸出了一种新的确定有限自动机--最小化DFA,最小化DFA是利用了可区分的概念,将所有不可区分的状态看作是一个状态.到此,一个词法分析器也就构造成功!不过请大家注意了,这种从正规式--到不确定自动机NFA--到确定有限自动DFA---到最小化DFA,来构造一个词法分析器的过程,是针对已知的正规式来讨论的,而对于如何构造一个能识别的任意正规式的词法分析器,本人也没什么高见,请各路朋友赐教!!rn Part3:rn 构造语法分析器的方法有两种:一种是自上而下分析方法(递归下降分析方法),一种是自下而上 分析方法.rn 词法分析器识别的是记号,而语法分析器识别的是句子,在这个阶段,句子通过由与上下文无关语言产生,而该语言又是通过与上下文无关的文法通过产生式进行推导而得出,而文法G(N,T,P,S)则是由非终结符(N),终结符(T),开始符号(S),和产生式(P)组成,而随着对产生式的不同约束又产生了4种类型的文法,它们分别是:0型文法、上下文有关文法、上下文无关文法和正规文法,每一种文法都对应变着一种产生式、语言和自动机,通过不同的语法分析,可以断定所给出的方法是否为合法的句子,进而把合法的句子结构送往语法分析器,进行下一步的编译工作。 rn 待续! rn 论坛

Go Go Gorelians

12-31

DescriptionnnThe Gorelians travel through space using warp links. Travel through a warp link is instantaneous, but for safety reasons, an individual can only warp once every 10 hours. Also, the cost of creating a warp link increases directly with the linear distance between the link endpoints.nnThe Gorelians, being the dominant force in the known universe, are often bored, so they frequently conquer new regions of space in the following manner.nn1) The initial invasion force finds a suitable planet and conquers it, establishing a Regional Gorelian Galactic Government, hereafter referred to as the RGGG, that will govern all Gorelian matters in this region of space.nn2) When the next planet is conquered, a single warp link is constructed between the new planet and the RGGG planet. Planets connected via warp links in this manner are said to be part of the Regional Gorelian Planetary Network, that is, the RGPN.nn3) As additional planets are conquered, each new planet is connected with a single warp link to the nearest planet already in the RGPN, thus keeping the cost of connecting new planets to the network to a minimum. If two or more planets are equidistant from the new planet, the new planet is connected to whichever of them was conquered first.nnThis causes a problem however. Since planets are conquered in a more-or-less random fashion, after a while, the RGGG will probably not be in an ideal location. Some Gorelians needing to consult with the RGGG might only have to make one or two warps, but others might require dozens---very inconvenient when one considers the 10-hour waiting period between warps.nnSo, once each Gorelian year, the RGGG analyzes the RGPN and relocates itself to an optimal location. The optimal location is defined as a planet that minimizes the maximum number of warps required to reach the RGGG from any planet in the RGPN. As it turns out, there is always exactly one or two such planets. When there are two, they are always directly adjacent via a warp link, and the RGGG divides itself evenly between the two planets.nnYour job is to write a program that finds the optimal planets for the RGGG. For the purposes of this problem, the region of space conquered by the Gorelians is defined as a cube that ranges from (0,0,0) to (1000,1000,1000).nnInputnnThe input consists of a set of scenarios where the Gorelians conquer a region of space. Each scenario is independent. The first line of the scenario is an integer N that specifies the total number of planets conquered by the Gorelians. The next N lines of the input specify, in the order conquered, the IDs and coordinates of the conquered planets to be added to the RGPN, in the format ID X Y Z. An ID is an integer from 1 to 1000. X, Y, and Z are integers from 0 to 1000. A single space separates the numbers. A value of N = 0 marks the end of the input.nnOutputnnFor each input scenario, output the IDs of the optimal planet or planets where the RGGG should relocate. For a single planet, simply output the planet ID. For two planets, output the planet IDs, smallest ID first, separated by a single space.nnSample Inputnn5n1 0 0 0n2 0 0 1n3 0 0 2n4 0 0 3n5 0 0 4n5n1 0 0 0n2 1 1 0n3 3 2 0n4 2 1 0n5 3 0 0n10n21 71 76 4n97 32 5 69n70 33 19 35n3 79 81 8n31 91 17 67n52 31 48 75n48 90 14 4n41 73 2 21n83 74 41 69n26 32 30 24n0nSample Outputnn3n2 4n31 97 问答

没有更多推荐了,返回首页