月度归档:2019年02月

人永远不够用——在复旦大学分享SRE团队组织和管理

从10月底到12月初, 数人云与复旦大学合作开授了面向复旦大学软件工程学院软件工程硕士的《信息系统工程概论(SRE:大规模应用运维实践)》系列选修课程,今天小数为大家带来此次选修课上有关SRE团队建设的精彩分享。

源于Google的SRE有助于解决传统运维模式上的问题,SRE是在运维模式上的全新探索,也是DevOps思想在运维方面的真正实践。SRE代表了一套先进的、完整的运维体系,作为Google最早提出,又经由Google发展完善的一个崭新概念,SRE已成为一个涵盖运维理念、思路、组织架构、和具体实践的完整体系。

SRE团队的建设和管理是SRE体系中重要的部分,今天我们来介绍一下SRE团队组织和管理,其中包括SRE工程师的特点,SRE的团队组织和工作原则,SRE的内部沟通机制,SRE的新人培训,SRE团队学习演练和总结。

SRE是这样一种人

SRE(Site Reliability Engineer)即站点可靠性工程师,是一种和传统系统管理员以及普通软件工程师有所区别的新型职业类型。从这张表里我们可以看到这三类人群从工作内容、关注点、技能特长和思维特征都不尽相同。

关于程序员、系统管理员、SRE在关注事项上的区别我们可以用一个例子来说明。比如图上这是一个标准的三层结构网站,对于这样一个结构的网站,程序员的着眼点是如何处理前端HTTP的request和生成response,如何构建数据库表的结构,通过API来访问数据库以及如何优化SQL语句来提高查询的效率。

系统管理员则关注的是如何承载业务压力,规划容量和保证日常运维工作的顺利开展。这包括服务器和网络的配置是什么,如何配置和对接监控和收集日志,该使用哪种版本的中间件和数据库,防火墙和iptable的设置等等。

而一个SRE人员关注的是什么呢?重点是如何在系统地灵活性和可靠性之间找到一个平衡。比如Web服务器的负载均衡策略是什么;数据库的高可用该选择什么样的方案;如果数据库未来需要扩容,当前方案是否支持;是否要跨地域多中心地部署,相应的流量引导和数据同步问题如何解决,评估系统变化对于可靠性和可扩展性的影响等等。

所以,综上所述可以归纳出SRE应该是这样的人。他们关注问题发生的根本原因,更够通过现象看本质,能够将复杂的问题切分成很多部分,这就是我们常说的决策树。再针对这些拆分的部分提出假设,并进行测试。不断深入不同的分支,直到找到根本的原因。他们能够根据大量信息进行归纳和抽象,以便进行深入的调查。基于现有数据和经验进行判断,拒绝主观的臆断。他们不拘泥于现成的“最佳方案”而是根据实际情况追求各方诉求的动态平衡。不但解决眼前出现的问题,还会预见未来的风险和扩展可能性,从而设计出有长远目标的实施方案。最后他们不默守陈规,勇于拥抱变化,不断打破旧的经验,重复造轮。

SRE的团队组织和工作原则

下面我们来介绍一下Google的团队组织和工作原则。Google在团队组建的时候秉承的是多样化原则。团队组织成员如果过于专业化虽然能够提高成熟度,但是只有多样化才能不断解决新的问题。Google SRE团队中有着包括“技术负责人”(TL)、“SRE经理”(SRM)和“项目经理”(PM/TPM/PGM)等多种角色。

很多时候组织内部是一个动态的环境,各种角色之间可以动态地协商切换责任。一般来说,越动态的团队成员的个人能力越强,每个人都要能写代码,每个人都要具备通用的工程能力。但是动态的团队不得不面临在沟通上需要花费更多时间的问题,因此这就要求团队持续进行沟通用以平衡多样化带来的弊端。

虽然团队的角色是多样化的,但是每一项工作内容要求专业化,明确区分系统性和值班化的工作,每个阶段都必须要有一个单一的目标,确保专注做好每件事情。

SRE的内部沟通机制

Google SRE一般是通过生产会议(production meeting)来进行内部的有效沟通。会议组织者一般由相关的SRE进行轮值,项目经理、所有SRE、开发团队代表、商务等任何和项目相关的成员都会被邀请参加会议。一般这个会议一周一次,一次一个小时左右。会议的议程包括变更预告、SLO review、故障的事后总结、警报紧急评估等相关议题。

SRE的新人培训

如何培养一个合格的SRE,Google也积累了一些内容和方法。这张图内包含了SRE团队可以采用的几个培训新员工的最佳实践,同时保证老员工不会落伍。从下面描述的很多个工具中,我们可以从中选择最适合团队的几个来使用。

这张图中包含两个轴 :

  • X 轴代表了工作类型的范围,从抽象的,一直到具体的工作;
  • Y 轴代表了时间,从上至下,新加入的SRE通常对系统和服务知识了解很少。

阅读之前故障的事后总结对他们很有帮助。新的SRE也可以试图从基本元素出发反向工程整个系统,因为他们本来对系统也没有任何了解。当学员对系统有一定程度的了解,并且已经进行了一些实际操作时,SRE就可以参与见习on-call值班了,同时可以修订文档中不完善或者过时的部分。

阅读上述图表的一些建议 :

  • 正式参加on-call值班是SRE新员工的一个重要里程碑,在这之后,学习过程将基本靠自己主导,是未定义的——所以SRE参与on-call值班之后的培训计划都是用虚线标注的;
  • 三角形的“项目工作”意味着新项目刚开始都很小,随着时间推移复杂程度逐渐增大,所需投入也在增加,很有可能在参与on-call值班之后还会继续;
  • 这里的某些活动是抽象性的,还有些是被动性的。其他的一些活动,则是非常具体和非常具有主动性的,还有一些活动则是混合型的,这样的安排是为了满足不同学习方式的人,让他们都能找到合适自己的活动;
  • 为了使培训效果最优,培训课程应该节奏合理:有些可以立即开始,有些则应该在SRE正式参见on-call之前开始,而其他的则应该是持续性的,同时要求SRE老员工也参与的,在SRE正式参加on-call之前,应该处于持续不断的学习过程中。

SRE的团队学习演练

故障处理分角色演习

当面对一个经验各异、能力各异的SRE团队时,如何能够将所有人紧密结合在一起启发他们互相学习是一个挑战。同时,如何将SRE文化——不断解决问题的文化——传授给新员工,同时保证老员工始终能跟上不断变化的环境和服务发展也是一个挑战。Google的SRE团队通过一个老传统——“故障处理分角色演习”来解决这些问题。这个活动同时也被称为“不幸之轮”(Wheel of misfortune)或者“走木板”(Walk the plank)等。这个活动能很好地帮助全体成员每周共同学习并且富有趣味。具体过程很简单,和桌上RPG游戏类似:“主持人”(GM)选择两个团队成员成为主on-call和副on-call;

这些SRE与GM同时坐在房间的最前面。主持人宣布某个警报发生了,这个on-call团队就需要进行调查和现场处理该报警。

GM事先准备一个故障场景,这个场景可能是某个以前发生过的故障,新成员可能没有经历过,老成员可能已经忘记了。或者该场景是某个新功能或者马上上线的功能的假想故障场景,这样参与的所有人都不知道如何处理。

在接下来的30~60分钟内,主on-call和副on-call要试着寻找问题的根源所在。GM会随着问题的展开而提供更多的信息,例如可能会告知大家某个监控图表的走势等。如果该问题需要向其他团队寻求帮助,GM会假扮成其他团队成员回答问题。

当灾难演习RPG运转成功时,每个人都会从中学到一点东西:可能是一个新工具、新技巧,或者解决问题的另外一个角度,或者(对新员工来说)对成功解决某个问题的认可。也许这项练习可以鼓励团队成员面对下周的挑战,甚至成为接下来某一周的GM。

总结

我们已经讲过构建一个合理的错误预算是非常重要的,极端的可靠性会带来成本的大幅提升,这也包括SRE团队的人力成本。因此对SLO要有一个量化的评估,以确保和人力水平相匹配。要从根源上解决问题就是要减少琐事,将重复性工作自动化,消除运维负载,否则人永远不够用。

http://blog.shurenyun.com/shurenyun-sre-203/

SRE系列教程 | 孙宇聪:来自Google的DevOps理念及实践(下)

上一期孙宇聪老师关于SRE基本概念和核心原理的线上分享一经推出就引起了小伙伴们的热烈关注,看来大家对SRE的相关内容很感兴趣呀。

今天小数继续为大家带来孙老师的第二次线上分享内容,探讨SRE的一些最佳实践和成功标准,希望大家阅读愉快并持续关注我们后续的SRE内容:)

接下来聊一聊SRE的一些最佳实践,我认为Google做得比较好的几点。

SRE的最佳实践

建设平台化服务体系

首先, Google现在是一个六万人的公司,涉及到的产品线可能一百多个,各个部门之间差距很大,而且Google全球几百个数据中心,有很多机器,它如何管理?如果按照国内公司的方式去管理早就累死了。因为国内很多运维部门从上到下什么都管,从买机器开始,一直到最上面安装服务器、调试,配网络,所以业务线、运维部门经常好几千人。Google做得比较好的一点就是它把一个东西横向切分,因为它很早之前就意识到很多部门或者很多人之间有共性?像现在国内有的公司也开始讲的,运维部门要输出能力,公司内部也要服务化,因为只有服务化才能让每个团队更加专业化。

所以回到Google这个平台上,我认为它实际上是不停的在切分,就是横向切分。首先最底下是所谓的资源供给层,就是相当于把数据中心这件事情真的当成了一个资源,可以服于用户。就是用户需要什么样的机器,配置架构怎么样,怎么设计数据中心,这些东西它都帮用户做好。有一个专门的团队去做这件事情,这个团队也有自己的研发,也有自己的运维,也有自己的operation、PM,什么都有。

往上是技术架构,技术架构是大家经常听说的Borg系统等,让一些比较通用的技术或者通用的架构都能形成平台式的东西。

再往上才是产品线,每一层实际上都有自己的SRE部门、运维部门,都是一个项目。所以把这个平台搭起来之后,上层的人可以越来越少关心底下的细节问题,一定程度的减少了他很多精力、减少了很多官僚主义上的问题。需要计算资源的时候就给资源,不是还要先去审批又买机器,什么样的机器,什么样的配置都不一样,所以整个公司是一个非常同质化的公司,很多业务底下共享的东西很多。工作在越底层的人如果能服务的人越多,就会产生一个所谓的放大效应。可能大公司都是这样的,它有平台化效应,底下的人可以搞出一个世界最好的数据中心,可以同时服务几十个产品线的业务;搞出一个更好的数据库,所有人都可以用,这是Google做得比较好的一点。

容量规划和容量管理

然后大家会发现在做一个业务层运维的时候,可以关注更高级的东西,不是关心买什么样机器,而是更多关心到底需要多少容量,这些容量应该在什么地方。在YouTube我们经常在办公室摆一个世界地图,大家经常会讨论这里有一个数据中心,那里有一个数据中心,然后讨论在这边放多少容量,在那边放多少容量,它们之间如何灾备,我们可以考虑这些更高级的、更抽象的东西。这样的好处是可以真正的做到容灾,就是所谓的N+M。就是如果平时需要的峰值流量是N,M是作为灾备流量或者是这个冗余流量。N和M到底是什么?很多公司连自己的N都不知道,从来没有说过我们到底要处理多少流量,有些领导说我们“双11”想来多大量的就来多大量,这怎么能搞好?

这个问题是运维部门独特的功能或者独特的角色,要负责将把这个东西确定下来,我们到底要承担多大的流量,要有多少冗余。接下来就是验证这件事情,到底有没有这样的能力,能不能处理这么大的流量或者这么大的需求? Google有一个内部指标就是130%,比如可以处理1秒交易量是一百万,实际上集群的峰都是按照一百万的130%来处理。130%是负载均衡或者是一些外界波动导致的,它实际上是不平均的。我们可以说它是一百万条交易的负荷,但实际上不可能说一百万零一条这个系统就崩溃了。可以留一下窗口,留一些冗余量来处理一些操作中的未知性,还有一些特殊意外情况,所以130%是一个我们常用的指标。

在Google里面已经很少提灾备这件事情,就是对我们来说我们没有灾备容量,都是平均负载均衡的。可能有一些冗余,比如一个系统只能一千台机器,这一千台机器并不是说我有十台是不接受业务处理的,而是我们所有机器都是接受业务处理,只不过他们处理能力可能没有把所有的资源都用完。这也是Google有很多经验教训,如果一个东西老是不用的话,它就是坏的,你平时再怎么演习、怎么用,一到关键时刻它就过不去、它就是有问题,所以更多的时候压根不讨论灾备的问题,所有东西永远都是在线的,这也是为什么说想把Google.com给弄坏是一件非常困难的事情,得全球几百个数据中心同时出问题,才可能会出现不可用的情况。所以Google全球业务是不可能中断的,不管出现多大的自然灾害,它这个业务都是不可能中断的。可能只有局部地区受损,只有基础设施受损的地方,它才会有一些问题,所以这就是灾备。

实战演习

另外一个更关键的一点是做实战演习。刚才也提到了,SRE以业务小组为单位,每周都会做实战演习,整个公司实际上每年也会做一次非常大的实战演习。我可以举几个例子,Google很多地方都有办公室,有一年某个办公室食堂的菜有问题,导致所有人都拉肚子进了医院。这是Google总部啊,一万人、两万人这样。于是我们就提出这样一个问题,说如果这个地方没有人来上班了,网站到底还能不能正常运行啊?我也曾经问过百度、腾讯,他们所有人都在一个大楼里,如果大楼突然断网了,公司还运转不运转?这是一个很大的问题,不管是地质灾害问题、自然灾害、人文灾害,这些虽然听起来好像比较极端,但确实能考验出一个组织的业务持续能力。实际上这是Google做得比较好的一点。刚才说的都是比较夸张的例子,是比较大范围的。一些比较小的例子,比如这个系统就是你这个小组负责,你们这个小组到底有没有单点故障,这个人是不是能休假,如果一旦出现问题是不是所有人都能去解决这个问题。我们经常互相出题去做这种测试,然后去分享一些知识。我想这更多是一种风气吧。首先你认同这个目标,目标当然就是把这个系统建设得更可靠。认同了这个目标,接下来就是不停地去考验还有哪些漏洞,并确保整个团队其他人也有同样的知识,同样的技能去解决这个问题。

其实说到Google在这一点上,也有所谓的运动式演练。每年1、2月份都会组织一次运动式演练,整个公司所有部门都要参与。在这一个星期的时间里实际上公司是不干什么正经事的,所有人都想出各种各样的方法去测试或者去提高系统的可靠性。

ONCALL的正确姿势

刚才说的这种比较大的所谓实战演习,具体到工作的时候也有几个,就是我们的轮值制度值班。国内小公司都是没有轮值制度的,所有人手机24小时开机,随时打电话,随时得解决问题,一个箭步从被窝里爬出来,赶紧上去解决问题。实际上这跟Google不一样。Google的值班方式更多的是八个人每人值一个星期,值一个星期,剩下的时间你就自己去写程序、做工程研发。但是在这一个星期里,你必须能处理生产上发生的一切问题,这才是真正值班。只有你值班,别人休假了,这才是值班,否则就不叫休假,也不叫值班。所以Google有一个非常明确的规定,Google认为一个事故的正确处理或从发生到解决到事后解决需要六个小时,它认为需要六个小时。运维人员每次值班一般都是值十二个小时的班,大概从早上五点到晚上五点或者是从早上十点到晚上十点。因为它所有的值班都是由两地互相倒的,在美国有一部分,在欧洲有一部分,我们上班的时候我们值班,他们上班的时候他们值班。Google认为其实一天最多只能发生两次事件。不管什么样的系统问题,首先要保证一定要有足够的时间去处理问题。因为如果问题发生太频繁了,就像有些互联网公司,每天一上班这手机就开始“嗡嗡”在桌子上不停的响。一旦有一会儿不响了,就开始担心说这个监控系统到底是是不是坏了。

如果处理太多了,实际上就变成什么呢?两个比较重要的因素,第一个因素是你没有办法好好处理,你处理相当于就是上去敲一个命令,没有时间去想到底这个东西为什么会出现这个问题,以后怎么避免这个问题。所以这个叫(狼来了)效应,你on call的时候已经没有时间去思考了。第二个会发生“狼来了”事件。本来可能是两次完全不一样的事故,但是你上一次处理的时候,你发现重启就行了,下一次你就条件反射,出现这个问题的之后你又去重启了,但它实际上可能是另外一个问题,可能是完全不相关的问题,你重启可能导致这问题更糟糕。所以如果你总是用这种模式处理问题的话必然会出问题,早晚这个灾难会升级。本来是一个很小的问题,结果可能变成一个很大的问题。

运维重要一点是解决线上问题。很多软件工程师做运维会钻牛角尖,这个线上系统出问题了,比如商城里不能购买了,这时候如果钻到这个程序里考虑要这么写还是那么写,实际上是不解决线上的问题。作为运维这个职业或者作为运营这个职业来说,它唯一的目标就是要保证系统的正常。有的时候需要用一些比较low的手段或者是方式。比如在项目初期机器有问题,我们就把它们都停了,然后使用一些新的服务器重新搭起来。事实上也不知道这个东西为什么坏了,就把它放在这儿,先去解决生产上的实际问题。实际上我认为这是运维最大的价值。运维部门目标就是保证业务的持续性。

事后总结

接着是做总结,写一些事后总结。Google的事后总结都是非常专业的,是非常对事不对人的,它会非常详细地列出来在什么时间出现了什么问题,谁去操作的,他执行了什么操作,这个操作到底是解决问题还是没有解决问题,如果没有解决问题的话该怎么去确保不会去执行这个操作。这是一个循环往复的过程,是一个不停锤炼的过程。把解决问题当成一个职业来对待的话,所有事情都很好办了。这回出现这个问题,解决了一遍,然后发现执行了某些地方可能是系统给出错误的信号,可能是文档有问题,把它都一一解决了。下回再执行的时候,可能换了一拨人来执行这个,也能保证不会出现问题。这就是事后总结带来的最大利益。

SLO预估

最后说说SLO。SLO是运维部门的一个关键工具。服务质量实际上是运维部门唯一负责的事情。公司要求员工达到某某指标,那员工怎么去达到这一点?第一,要先帮助制定SLO,要用事实、数据去说明白达到这个服务质量到底需要多少投入、需要多少流程改进、需要多少系统改进。第二,要确保达到这个服务质量不会影响创新速度。这要有一个平衡的取舍,要用数据去说话,一个每天只能down一分钟的系统和一个每天可以down四个小时的系统,它所能承受的更新频率是不一样的,部署的要求和方式肯定都是不一样的,所以要围绕着这个去做,要把这些理念推行到研发部门和产品部门。最后就是把可靠性当成产品的一个重要组成部分,研发也得关心可靠性,他在写代码的时候得知道这个东西一定是要可靠的。把可靠性一直推到产品设计或者是业务层次去,它才能贯彻到底层的研发、运维,才能把它做好。

SRE模型成功的标志

最后就是说到底SRE成功还是不成功,实际上就是看这两条曲线。上面这条线是部署规模,大家都知道互联网的业务都是爆发式增长,它是指数型的。如果说按照常规的那种招聘曲线,直线性的,那么永远赶不上这个规模,所以运维事务必须要把它压下来。Google经常做这种统计,到底我们业务规模扩大之后,扩大了多少工单数量,然后出现了多少事故,造成了多大问题。实际上只有统计这个事情,才能知道你到底做得好不好。当这个系统成熟到一定程度之后,SRE的运维速度是固定的,甚至是越来越少的。只有做到这一点,才相当于把运维这个事情做好,剩下的时间或者剩下的精力才能去接手更多的业务、做更多的技术研发。

我分享的东西也到此结束了,谢谢大家!

SRE系列教程 | 孙宇聪:来自Google的DevOps理念及实践(上)

http://blog.shurenyun.com/shurenyun-sre-189/

SRE系列教程 | 孙宇聪:来自Google的DevOps理念及实践(上)

SRE(Site Reliability Engineering)是最早由Google提出,又经由Google发展完善的一个崭新运维理念。如今SRE已成为一个涵盖运维理念、思路、组织架构和具体实践的完整体系。数人云推出SRE系列教程,由SRE经验丰富的技术大牛们为大家分享运维一线的独家干货,揭示SRE背后的秘密。

今天为系列教程第一期,我们邀请了前Google SRE、《SRE Google运维解密》的译者孙宇聪与大家进行了线上分享。本文为上篇,讲述了SRE的基本概念和核心原理。与孙老师本人一样风趣幽默的文章,小数希望大家阅读愉快:)

今天与大家分享的内容是关于最近我翻译的这本书,据说反响还不错,今天借这个机会聊一聊书中的内容,并与大家分享一下我回国两年多以来,Google经验在国内的一些思考和落地实践。

什么是SRE?

很多时候国内把DevOps的范围定得有点狭窄, DevOps这件事情在国外更多是整个行业内的一个趋势。DevOps是一种模式,主要是让IT相关的东西与商业结合得更紧密一些,迭代速度变得更快一些,所以它适用于各个行业。今天说的SRE,我认为也是在运维行业上的一部分。

概括来说,我认为《SRE Google运维解密》这本书是一个文集。GoogleSRE全球一千多人,这个组织在公司里相对比较小众,但又是一个比较重要的部门,整个Google所有业务线的运维环境都由SRE来负责。SRE是一个非常分散的组织,每个业务线、每个部门其实都有自己的SRE小团队。这本书里共有一百多个作者联合写成,其中也包括我以前所在的团队,我们做过的一些Project也在书中也有提到,所以它是一本文集。我与原著的三个编辑聊天时,他们说成书最大的难处就是删减内容,当时征集来的内容大概有一千多页,最后删到了五百多页。这也是这本书比较有意思的一个花絮。

回到这本书的宗旨, SRE到底是什么?SRE是Google发明的一个词语或者新定义的一个职业。以前这个运维角色,大家叫运维,美国叫Operation。现在Google把这个职位扩展为SRE,就是用软件工程师的方法和手段,招了一些软件工程师来解决运维的难题,这是SRE的官方定义。

传统运维模式的弱点

现在传统的计算机行业的运维方式,大部分都是采用系统管理员的模式。大家最熟悉的运维方式是这样:招聘一些系统管理员,他们有负责采购机器的,有负责维护数据中心的,也有专门维护数据库的等等。系统管理员模式有几个特点,他们只是把一些现成的组件组装起来,并不会自己开发和创造新的系统,比如拿了MySQL把它跑起来,或是研发部门开发出来的新代码组装成之后提供这样一个服务。这是运维部门的一个特色,负责把这个东西运行好。

举一个例子,在美国的时候我们经常自嘲,说自己是流水线上的工人。因为这个流水线实际上是别人设计出来的,总得有人去操作这个机器,而我们就是一线的操作流水线的工人。又比如,我们好像是发电站里的工作人员,又或者是飞机驾驶员。飞机驾驶员就是开别人造出来的飞机,这和运维部门的职责很像。

那么这样一个运维部门的职责包括哪些呢?首先最重要的是应急事件的处理,这是重中之重,也是最唯一的职责。其次是常规更新,现在的业务发展越来越快,每周都有新的东西上线,比如说今天要买新机器,明天要改IP地址,大家可能80%的投入都是在这些事上,这就是系统管理员或者是现在运维行业的工作模式。

但是系统管理员模式有一个最大的弊端,按照传统的组织架构模式或者是这种运维模式运行会导致这个团队持续扩张,业务越来越多,需要不停的招人去应付各种各样的事。刚开始接手生产的时候,也许一周就出一次事或者是需要更新一次。因为人的沟通能力总是有限的,招了五个人之后,这五个人之间的传达问题就形成了一个困难。当你把一个精神传达给这五个人,他们事后执行出来的结果都不一样,这就是传统模型一直想要解决的问题。但是这种模型也有好处,就是市场招聘比较容易。

Google有几个比较重要的特点,首先它的部署规模非常大。Google到今天已经十八年了,刚开始前几年公司所有的人平时写代码,周末去机房接机器。因为它扩展速度特别快,部署规模非常大。如果按照传统的系统管理员的那种模式操作,这个机柜归你,这个机柜归他,再下一个归另外一个人,那么Google招人的速度一定赶不上机器增加的速度,所以Google是被逼迫创造了这样的职位,因为没有办法安排团队做如此大规模的运维。

传统的运维模式还有一个更大的问题,它过于强调专业化。比如一个人是做网络的,他只做网络其他都不管,全公司可能只有他懂网络,因为他不停的在网络上投入时间,集中力气把这个事情做好。这样一个结果就是会发现运维部门没人能休假,一出事只有一个人能解决问题。不仅仅是网络,特殊硬件、一些第三方服务都存在这个问题。这就导致了知识没法共享,人灵活性受到限制,整个组织的灵活性也受限制。这个问题,我认为它最终形成了一个负反馈的循环,每个人之间越是互相隔离,越是没有办法提高,导致服务质量上不去。最大的问题是,招来更多的人其实也不解决问题,因为这个部署规模不断扩大,人之间的知识不能共享,所以招来的人只能运维新的设备,旧的设备还是这些人在做。

这是一个怪圈。回国之后我与很多公司的朋友都聊过这个问题。以前大家讲Oracle这样的公司存在老DBA,说老DBA都是难得一见的,深居简出,但是你有什么问题,只有他能解决,其实这在Google这个语境里这是一个比较不健康的状态。SRE的一大特点就是想请假的时候随时请假,每一个人都可以请假;当出现紧急情况的时候,当天值班的人真的可以处理他负责的这个服务所有的问题。

Google SRE的起源与特点

回到最开始,Google SRE的VP叫Ben Treynor,他是一个资深的软件开发经理。2003年他加入公司第一个任务,是组建一个7人的“生产运维小组”。很快他发现如果想把这件事情做好,也就是把搜索服务运维好的话,按照Google机器增加的速度,传统的模式绝对是不可能的。机器增加的速度,系统复杂度增加的速度远比人增加的速度要多得多。所以他组建的团队有以下三个特点,注意,这里我认为其实更多的是事后的总结。首先,他的执行方式是像组建一个研发团队一样来组建这个运维团队。他招了很多他熟悉的研发工程师,这些研发工程师从开发能力上没有任何问题,用现在流行的话就是全栈工程师,什么都会做。第二点,这些人对系统管理比较有热情,懂一些Linux内核知识、网络层的知识。第三点,最关键的是这些人鄙视重复性劳动,码农最痛恨的是什么事,就是反复做同一件事。他把这些人聚到一块,然后让他们执行以前传统公司运维人员来做的事情,很自然这些人不愿意手动干,于是就写程序干。多快好省,同时写程序还有一个好处,就是可以把一些最佳实践、方式、流程、方法都固化成代码,用这种方式去应对规模性的扩张,去应对复杂度的上升。

这些是SRE跟传统的运维模式最不同的一点,就是招的人研发为主,做的事也是以研发为主。这是当时SRE成立背后的故事,这些年来我认为他们做得最好的一点是一直在维持了一种平衡。将运维部门从传统执行部门往上提升,打破了传统的界限。就像刚才说的DevOps,很多人理解为就是让研发部门做运维的事,或者运维部门做研发的事情,但实际上DevOps在国外的定义更宽泛一点。DevOps的思想更多的是说把整个开发流程的界限打通,产品有的时候也要干一些研发的事,研发有时候把这个信息要很快的反馈给这个产品,开发和运维或者QA和运维之间的界限也打通。所以现在去搜DevOps的图片,会发现IBM这些人都在讲圈圈,说以前是产品研发都是一条线直着来,而现在都是转圈的,这就是DevOps理论。

按照这个理论来说,SRE就是DevOps的思想在开发和运维之间的一个平衡。

SRE的工作职责

这个图是我发明的,书中没有提到。书里大概有二十多章的内容是在讲SRE的各种日常工作,简单提了一下它的金字塔模型,于是我归纳总结了一下。这里是由下至上,下面的事份额比较大一点,上面的事份额比较小一点,分了三类。第一类,运维部门最重要的是应急响应这个问题,因为业务越来越大,与运营的结合越来越紧密,很多时候要处理的事情更多的是商业和运营上的事,也包括软件上的问题,这个部门最特殊或者最唯一的职责就是应急响应。之上是日常运维,保证机器能够正常更新、快速迭代。再往上是输出一些工程研发,无论是做工具,还是做高可用架构、提高可靠性,这些都是最上层的东西,只有把底下全部做好了才能说到上面。

应急响应

应急响应是运维部门在公司最独特的一点,表现为当公司出现问题时,应该找谁或者流程应该是怎样的。我回国之后见了不少初创企业,他们网站出问题了,往往是CEO先发现,CEO打电话“哎,这个到底是怎么回事啊”,然后每一个人都说“不知道啊,不是我负责呀,我得找谁谁”。不管多大一件事都得传遍整个公司,整个效率非常混乱。

我在Google待了八年时间,这样的流程也经历过,但是最近这几年Google非常重视这一点,建立了一整套应急事件处理方式。首先要有全面监控,监控这件事情是持久不断的,重中之重。SRE所有人都要非常了解整个监控系统在所有业务中的部署实施,其实这是我们平时花精力最多的地方。监控系统里面对整个系统所有方面都有监控,不光包括业务指标,也包括性能指标、效率指标。监控应该平台化、系统化,不停的往上积累,多做一些模板,同质化的系统就可以用同样的方法去做监控。

第二点是应急事务处理,应急事务处理分两部分,第一部分是演习,另外一部分是真正的处理流程。如何把它做好?实际上就是要不停的去演习、去做这个事情。像刚才举的例子,网站挂了,首先不应该CEO先发现,而应该是监控系统或者报警系统先告警,在发现之前就很应该明确这个东西应该谁排查,谁处理,这个信息应该早就发给合适的人去处理,甚至他应该早就在做了。如果发生特别大的,需要跨部门之间协作的问题,那不应该只是领导现场调配,而是整个组织每个人都明白这个流程应该是怎么样的,直接就做。Google甚至可以做到在一次事故中间两地交班,某个团队处理一半,然后我交接给另外一边团队,就下班回家了,持续不停的有人继续跟踪处理这件事情,而不会出现问题。这样一个模式是我觉得非常值得我们思考的。

处理完问题之后,要总结。之前听过的一个故事是,某公司业务出现了一个事故,大家加班加点,十几个小时没睡觉把这事搞定,然后领导过来就说了一句“大家辛苦了,回家睡觉吧”。但是,其实在这个时候我要说,领导光说这个其实恰恰是不够的。领导在这里应该问:为什么加班啊?这个事情为什么会发生啊,下次能不能不发生,大家能不能不加班,能不能不熬夜?这样才对, 能做到事后总结这个事情很难,但只有把这个做好了,才能降低以后问题发生的几率。

日常运维

日常运维做得最多的可能是变更管理。业务现在发展非常快,迭代速度、迭代周期非常快。其实这件事情能做好,能够做到无缝、安全、不停的变更管理,是运维部门能给公司做的最大贡献。

第二个,容量规划,当规模大到一定程度的时候,就需要有人来回答这个问题——到底要买多少新机器,能否保证明年的性能、效率,那谁来负责这件事呢?SRE部门提出这些方案,然后要确保这些指标、这些东西是有数据支撑的,确实能解决问题的。

工程研发

工程研发虽然做得少,但是工作很关键。SRE在工程研发上主要的工作,首先是帮产品部门确定一个SLO。SLO是一个服务指标,每一个产品都有一个服务指标。任何系统都不可能是百分之百可靠的,也没有必要做到百分之百可靠。这里得有一个目标,比如说可以每个月中断几分钟。这件事情是要产品部门考虑清楚的。比如我之前在YouTube做视频存储、视频点播的时候,要考虑每个视频到底是存一份还是存两份的问题,将这种问题放到一个非常大的部署规模里面的时候,只有产品部门能够拍板。说到底是要不要花这个预算,要不要花这么多钱去提高0.1%的可靠性或者0.01%的可靠性。

另外一点是无人化运维。大家都看过《黑客帝国》吧?一醒来发现大家都是电池,都是为机器服务的。其实把这个比喻放在运维部门非常合适。因为如果不停的开发出需要人来操作运维的系统,结果大家最后都是电池,明显是不可持续的。如果不停的产生这种需要人来操作的东西,不停的招人,最后就变成不停的运维这个东西。把整个流程自动化,建立一个能够应对复杂业务的平台,这就是工程研发上最需要的东西。

SRE模型成功的关键要素

SRE在Google有十几年的历史了。这个模型是如何成功的?我总结如下几点:

职业化

运维行业从来都说不清楚自己是干嘛的,这是不对的。很多人认为会操作Linux,或者是DBA、会配网络,就算运维了。实际上运维的范围要比这个大得多。运维应该是负责公司业务正常运转的角色,这才是真正的运维。在出问题的时候能解决问题,保障业务连续性,甚至避免问题发生,这才是运维职业的定义。

具体如何做呢?推演和演习。

推演是给你一套系统,你要分析出来它会有什么样的失败模式。我们当时经常在黑板上画系统图,大家一起讨论如果这个组件出问题了会发生什么情况,用户到底还能不能看视频了,用户购买流程还能不能走通。实际上这些过程很多时候软件开发是不考虑的,但是如何拆分、如何去保证每个环节的可靠,这才反是运维这个行业最关键的一点,所以一定要做这种推演。只有这种推演才能输出改变,让系统更可靠。

第二点是演习。我们当时每周都会进行一次小型灾难演习,例如把以前出现的问题拿出来一个,让新加入团队的人去演习,所有其他的人也都要去参加。这里主要是观察新人到底是怎么思考这个系统的,新人做出的决定到底是不是正确的。因为一个人做出的决定是不是正确的实际上取决于系统给的反馈到底是不是对的。Google认为运维复杂系统不是一个靠智商和记忆力就能解决的问题,不能依赖人一定要知道这段话或这个知识点,而是要知道一种方法,知道如何去排除问题或排查问题。运维系统应该提供足够的信息,让轮值的人能够用正确的方法去处理问题。这很像是背英语辞典和会用英语聊天的区别,你再怎么背辞典关键时刻也是要查辞典的,但是真正能运用这些信息解决问题,是比较难的。

此外,要区分责任和指责。责任和指责是两个事情,但是很多公司的运维经常分不清楚。什么叫责任,就是这个事到底谁负责。但是指责是另外一回事。例如一个员工敲错了一个命令,大家说 “都是因为他的错,给他扣工资、扣奖金,让他三天不吃饭”,但这其实并不真正解决问题。再例如,比如说一个系统设计电源插座,没有仔细考虑,很容易被人踢到,结果有人真踢到了,整个机房断电了出了很大的事故。那么从Google的理念来说这里不是人的问题,而是系统设计的问题。这里是不是应该有两套电源,是不是应该有保护?只有从系统设计问题的角度出发才能真正解决问题,而指责这个踢到插座的人,让他一个月不上班,甚至当时开除也并不能解决系统的设计问题,下回总会还有人踢到。

说一个故事,故事的内容是一个事故。某个数据中心有一排机器要断电,数据中心的人发了一个工单告诉操作员要把这个开关给关了。然后这个操作员去关,他关掉了开关,但是发现这一排机器的灯没灭,另外一排的灯却灭了——按错开关了。他检查一下发现按错了,“啪”把另外一个开关也关了,然后再把这一排机器给启动,结果由于启动时候过载导致整个数据中心都断电了,扩大了问题。如果单纯只是指责,这个人肯定完了,起码奖金没有了,能不能保证工作都不知道。但是Google 更关注的是这个东西为什么会容易出错,要么是开关颜色不对,要么是相同机器的操作方式靠得太近了,会让人产生这种错误的判断。所以你看Google的机房里都是五颜六色的,因为这样确实有用,比如热水管是红色的,制冷管是蓝色的,所以查起来很容易,区分起来很容易,尽量减少了这个问题。这个设计的思想在SRE日常工作里贯彻得非常深,每人在流程或工作的时候都要考虑到有没有被误用的可能,然后如何避免误用。

专业化

专业化体现在什么程度呢?要真正的去写代码,要能给业务系统或者给研发写的东西挑出问题,提高可靠性。

第一,减少琐事。运维中有很多虚假的工作。每天很忙,然而又不解决问题,做了很多假的工作。大家看起来好像很忙,一个屏幕上十几个窗口,各种刷屏,但完全不解决问题。更好的方式是用自动化、系统化、工具化的方式去消除这种琐事的存在。如果永远靠人工,那永远都闲不下来。

第二,回到SRE,SRE制度里有一条红线,运维的人只能把一半的时间花在运维上,另外一半的时间必须搞工程上、研发上的东西。研发可以是写工具,可以是参与系统设计,参与可靠性的提高,但是要保证运维不能只干运维。

第三点,我认为也是比较缺少的,运维部门光有责任没有决策权,所以大家都说一出事故,运维就背黑锅。怎么不背黑锅呢?说改这儿、改那儿,然后发现没有人批准改动,这是最大的问题。SRE做的最好的一点是管理层对SRE的工作方式非常认可、非常支持,他们认为服务质量是服务的一个重要指标。一旦上升到这个高度,SRE部门提出一些要求就比较容易理解,得到支持,因为他们是有事实根据的。当GoogleSRE发现生产出现问题的时候,标准的解决办法就是暂停所有更新,确保业务稳定。举个比较极端的例子,像刚才说的如果发现线上系统有问题的情况下,SRE是有权利拒绝接受业务更新的,只允许研发部门修bug,不允许加新功能。这个争议我在过去八年见过为数不多的几次,开发可以一直闹到 VP,SVP 这个级别。每一次都是听SRE的。

打通与产品团队的反馈回路

所有东西不都是百分之百稳定的,稳定性的提高要消耗成本,要增加更多的冗余,更多的容量,甚至只能花钱解决。运维部门的任务就是提供这些数据和方案。比如搞三个9、四个9,要如何达到,这在投入和系统设计上有很大区别。这个部分公司里没有其他人可以提出,必须要由运维部门提出。如果没有这个反馈回路的话,你会发现大家都很痛苦,很多时候做出的决定都是违背自然规律的。我看过很多这样的案例,上面拍脑门决定某个业务要100%稳定,完全不管下面怎么搞,由于反馈回路不存在或者这个反馈回路的信息流动不够顺畅,导致了这个东西最终实际做不好,这是SRE模型相当关键的一个地方。

http://blog.shurenyun.com/shurenyun-sre-188/

10位技术领袖告诉你趟过的微服务那些坑和最佳实践

切换到微服务架构似乎很容易,但技术领导者往往低估了项目的复杂性,并犯下灾难性的错误。此文对来自以色列和美国等5个国家的技术领袖进行了13次采访。这篇文章很长,内容包括如下一些方面:

• 微服务是什么 • 微服务架构优劣势分析 • 微服务面临的挑战和应对解决方案 • 微服务落地要避开的坑 • 来自技术领导型企业的微服务架构最佳实践 • 如何选择微服务当中的技术栈? • 实用的技术建议 为什么转向微服务? 企业容易犯的最大错误是在没有明确目标的情况下,转向微服务架构。需要了解并有真正的理由表明为什么要这样做。

“人们盲目进入很多领域:Docker很酷,微服务很伟大!但它可能不适合你的体系构建,你需要了解为什么要这么做。” – 来自Steven McCord, ICX Media(一家企业营销视频制作众包平台 )创始人兼CTO。

如果你的系统工作正常,那有什么动力去改变它?

如果只是因为微服务被炒作,这并不意味着你需要跳入潮流。它不一定是企业软件的最佳技术选择。

“确定原因至关重要。”这是David Dawson,Steven McCord和Avi Cavale 所强调的。

“当客户要求我实施微服务时,我会问的第一个问题是,为什么?我正在寻找的答案是,“希望更快地改变系统”和“希望利用云技术”。微服务其实比建立单一的系统更昂贵和困难。微服务在数据模型中引入网络,可以随时进行任意分割,但也可能伴随数据丢失,让企业暴露在分布式计算的恐惧之中。“ – 系统架构师 David Dawson说道。 明确定义一个微服务

“我不一定选择微服务。我倾向中型服务,所以不是从单体架构转到上百种的微服务,而是与工程团队和业务保持一致的更大的服务。” – 来自 Daniel Ben-Zvi , SimilarWeb(网站和应用追踪分析公司) 研发副总裁。

如何做?一个围观案例研究

“我们通过查看哪些代码(如果更改的话)最终确定了指数测试案例,从而确定了一个微服务。我们的目标是减少对每次改变的测试次数。如果这是你的目标,那么微服务的定义就和”计费就是一个微服务”没有什么不同。”Shippable 联合创始人兼CEO Avi Cavale 说道。 微服务架构优劣势分析

微服务显著优势 可扩展性:分析小块的应用,看每块的要求,每部分可以分别伸缩应用程序的不同部分。

“另外一个好处是,可以在任何虚拟机之外扩展容器。容器可以放置在任何形式的配置中,应用程序具有完全的可移植性。“ – ICX Media 创始人兼CTO Steven McCord说道。

更简单的可维护性:不同的团队以不同方式独立处理不同的组件。

独立部署和配置:部署和配置每个服务时,不会影响其他服务。多个团队可以将多个结果投放到生产中,不会彼此干扰。

问题隔离:更容易隔离和监测问题。

易于招聘:寻找开发人员或第三方供应商时,只需培训他们系统的一部分。

清晰的责任:一个团队负责特定的微服务。

深厚的知识:团队从内到外了解相关知识。

多种编程语言:可以使用不同的编程语言,这取决于微服务的目的。

更易于监督和理解:将庞大的代码分割成更小的项目,利于团队更好地理解。

更容易开放组件:当边界和接口被明确定义时,向新的业务单元开放组件或现有功能更容易。

微服务劣势

部署和互操作性:这是首要问题。

编程语言太多:会限制代码的可重用性以及可维护性,并且维护更加复杂。

组件一起工作:要确保服务是以一种协同工作的方式组成。只考虑改变单一的端点,会打破旧版本的其他依赖服务。

与单体系统相比,更难以对整个系统进行集成测试。

架构必须从一开始就深思熟虑:如果服务之间的凝聚力过大,也会失去大部分优势。

加大通信力度:在服务之间的通信方面,需要进行投入。服务的通信之间容易发生故障。

难以监控整个系统:大量组件对监控来说,是噩梦。

花时间学习:使用微服务需要学习,这需要时间。

复杂性:越来越多的微服务使整个系统更加复杂,难以监控。

“所有这些东西都散在周围。如果没有很好的工程流程,企业最终获得一大堆东西,然而根本不会使用。” – Shippable联合创始人兼CEO Avi Cavale说道。

“在基于微服务的平台上调试生产问题是完全不同的操作。如果没有相应的监测,记录和跟踪设施,系统的复杂性会显著增加。这就像迷宫一样。工程实践和标准化至关重要。” – SimilarWeb研发副总裁 Daniel Ben-Zvi 说道。

“记录到一个地方有挑战性。Loggly,Splunk或Heroku等第三方日志聚合服务是非常好的解决方案,但价格非常高。根据我的经验,遥测特别集中的日志是最大的难题。必须考虑每个服务的详细程度。否则,企业可能要花费50-60%的成本进行记录。”-来自微软公司SRE工程师 Sonu Kumar。 微服务面临的挑战和解决方案

当转向微服务时,如下这些是技术领导者和开发团队面临的最大挑战。 • 挑战1:一次切换所有系统 • 挑战2:拆分系统 • 挑战3:组织认同 • 挑战4:团队

> 挑战1:一次切换所有系统

“从单体架构切换到微服务架构不是一次就可以完成的。如果企业有单体服务器,那么其周围可能被存储库,部署任务,监控和其他许多事情包围。一起更改并不容易。” – AdRoll软件工程师Brujo Benavides说道。

“如果一个公司从未有任何微服务经验,即使是新建,也会比想象的更难。” – LogMeIn DevOps工程师 Viktor Tusa 说道。

white_check_mark:可能的解决方案

“那时候我们做的是保留单体服务器,但是任何新的服务都是通过微服务来开发的。”(Brujo Benavides)

挑战2:拆分系统

“如果组件和服务聚集在一起,隔离起来相当具有挑战性。(Robert Aistleitner)。需要定义各个部分之间的交互和流程。如果没有很好的定义,系统会产生更多问题。”- StyleSage高级开发人员 Jose Alvarez 表示。

“将系统拆分成微服务有许多不同的规则,没有特定的模式,没人会告诉你,如何在应用程序中使用它。而且,没有两个相同的微服务”。 – Recart 首席架构师大卫·帕普说道。

white_check_mark:可能的解决方案

“把单体系统分解成微服务的唯一方法,是首先检查单体系统,看看它最“痛”在哪里。将这些部分拿出来并转化成微服务“。 – Emarsys工程副总裁Andras Fincza表示。

监控所有部分是如何工作的以及他们在做什么。监控过程中,可以很容易地发现和解决问题。(Jose Alvarez)

模块by模块渐进地分离单片系统是最好的方法。想一次做所有事情,一定会失败的。

监控工具提示: • New Relic • Datadog • Influxdb • Grafana

挑战3:组织的支持

“获得组织认同可能是最难的部分。” – 来自 Steven McCord ,ICX Media创始人兼CTO。

这不是一个技术决定。需要清楚说明微服务架构的好处,从而说服企业重新分配资源。在企业接受变革之前,这是一个漫长而乏味的过程,组织规模越大,决策的时间越长。

white_check_mark:可能的解决方案

说服组织改用微服务的最佳方式,是将非核心部分转换为微服务。通过这种方式,来展示微服务的优势。

挑战4:团队

“团队本身面临着最大的挑战,它需要不同的思考。” “开发人员必须花费更多时间来了解什么是端到端场景。他们需要熟悉这些技术,需要转换思维方式。”

“对于一个在端到端测试的世界中工作的人来说,突然把它分解成小块,是不舒服的,这更多是文化上的变化。”-Shippable 联合创始人兼CEO Avi Cavale说道。

white_check_mark:可能的解决方案

从非常小的可以真正受益的方面开始,并选择应用程序的非关键部分。获得一个小团队的支持,并将这部分转换为微服务。一方面来证明微服务的优势,另一方面逐步向企业扩展(Avi Cavale)。

微服务落地要避开的坑

“避免同时将整个系统切换到微服务。” – Emarsys工程副总裁 Andras Fincza 说道。

“你能犯的最大的错误就是,没有创建一个微服务架构变化可能带来的影响概览。在实际开始实施新方法之前,必须包括大量移动组件。“ – Usersnap工程副总裁Robert Aistleitner说道。

“单体架构很容易改变内部接口。只需重构代码,然后运行测试。使用微服务,API必须可靠,你不一定知道你所有的客户。如果没有API的话,会给未来带来许多麻烦。此外,确保有分布式跟踪系统。”-来自 Daniel Ben-Zvi ,Similar Web研发副总裁。

“不要在没有搞清楚平台和依赖关系的情况下,尝试切换到微服务。此外,也要避免认为微服务都不错,因为每一个微服务可以用不同的语言来编写是一个不好的做法。” – 来自 Viktor Tusa ,LogMeIn DevOps工程师 。

“处理数据至关重要。搞砸数据非常容易,但是很难恢复。数据迁移需要更多步骤。” – Emarsys工程副总裁Andras Fincza表示。

“在微服务之间共享数据是一个很大的禁忌。如果两个服务操纵相同的数据,将遇到一致性问题,并消除所有权。“ – Daniel Ben-Zvi&Varun Villait二者共同认为。

“把应用程序分解成太多太小的东西,或者强迫把系统转变成微服务,这不应该是微服务 – 仅仅是炒作”。- 来自 Doctusoft首席开发Csaba Kassai 的观点。 来自技术领导型企业的微服务架构最佳实践

创建微服务之间的隔离,可以根据需要快速更改它们。这通常需要在几个层面进行隔离:

运行时流程:这是最明显的,也是普遍采用的过程。以前只有一个流程,而现在有很多。这里的主要成本是采用某种形式的分布式计算,这很难做到。会导致采用容器化,事件架构,各种http管理方法,服务网格和断路器。

团队/文化:分离团队,给予自主权,意味着划分人与人之间的沟通。这往往会导致知识孤岛和工作重叠(解决选择性与资源效率的选择)。

数据:采用像微服务这样的分布式计算最大的影响是它影响企业的数据。以某种形式对数据进行划分,需要在系统级别重新整合,以给出“一个系统”的印象。这在伸缩方面有潜在好处,但也需要相比简单的单一数据架构方法的更多想法。(来自David Dawson) 如何选择微服务当中的技术栈?

这是不同意见开始碰撞的地方…

一方面,人们认为使用什么技术和编程语言并不重要。

“几乎所有的问题都可以用任何技术解决。人们花费太多时间寻找正确的技术,如果以迭代的方式来做,你就有时间思考,并看到它的实际应用。错误的决策也可以得到缓解。” – Andras Fincza ,Emarsys 工程副总裁表示。

“大多数现代语言(Python,Java,C#,Node / JavaScript)同样快速且可扩展。从这个角度来看,语言无关紧要。每种语言都有其优点和缺点。大部分时间,语言选择是根据个人的喜好,而不是技术参数。” -Andras Fincza , LogMeIn DevOps 工程师说道。

花费大量的时间来选择最好的技术是不值得的,因为差异很小。

“选择技术的重要性被高估了。如果运行成本很重要,那么就可以接受,对我们来说没那么重要。” – Andras Fincza , Emarsys 工程副总裁。

“如果是新建项目,选择程序员最了解的语言。如果不是,选择客户端上最佳覆盖业务系统的语言。” -Viktor Tusa , LogMeIn DevOps 工程师 。

“微服务的好处在于它被封装在一个微服务中,只需要给外部的接口来谈论这件事。只要有一个界面就够了。“ -Steven McCord , ICX Media创始人兼CTO 。

选择合适的技术不仅仅是技术问题,也是一个决策。如果选择一种具有10种不同编程语言的微服务架构,要确保团队能够处理该问题。

“我不推荐混合太多的编程语言,因为招聘会变得更加困难。而且,程序员的上下文切换会减慢开发速度。“ – Robert Aistleitner , Usersnap工程副总裁。

“必须有意识地选择想要建立的开发团队类型。如果想使用许多不同的编程语言,需要建立一个能够使用和学习不同编程语言的动态团队。“ – Steven McCord , ICX Media创始人兼CTO 。 实用的技术建议 “我强烈建议在Google云端平台中使用管理服务,如App Engine。这将肩负很大的负担。此外,选择语言/技术时/框架时,选择合适的针对特定微服务的使用情况是重要的,不要因为熟悉它,而强迫选它。” – Csaba Kassai ,Doctusoft 首席开发。

以下来自Brujo Benavides:

一些技术领导者乐于推荐一些技术,这些技术可以很好地适用于服务特定角色的微服务。在选择微服务技术时,建议考虑: • 可维护性 • 容错 • 可扩展性 • 架构成本 • 易于部署 Brujo团队的一些微服务框架/技术示例: 
• Scrapy for web crawling • Celery + RabbitMQ用于微服务通信 • NLTK + Tensorflow(以及其他一些)用于机器学习部分 • AWS服务 如何选择合适的技术/语言?

在为微服务选择编程语言/技术时,需要考虑很多事情。

其中最重要的就是看你的开发人员具备哪些能力,以及语言/技术背后有多大的支持(工具,社区……)。根据我的经验,公司倾向于根据其开发人员的能力选择一种编程语言。“ – Csaba Kassai , Doctusoft首席开发人员。

“使用技术背后有很多支持(资源和活跃的社区)。我推荐Ruby和JavaScript,可以得到很多支持,如果出问题,很多人都可以提供帮助。只要确定有很多人使用它,选择语言不应该是问题。如果团队不具备这些知识,可以依靠外部资源。“ – Varun Villait,Industry CEO。

“另一个因素可能是图书馆可以用来加速项目的语言。你理想的语言的某些东西可能图书馆没有,不得不自己发明,这是另外的时间流失。容错和可扩展性也是重要因素。如果从现在开始的几个月内,你不得不重新编写一些东西,因为最初的选择无法扩展,那不如放弃。这一切都归结到一个特定的团队情况,他们愿意进行投入。” – Greg Neiheisel , Astronomer联合创始人兼 CTO 。

Emarsys就是这样看待这个过程的:

在Emarsys,如果他们想应用一种新的编程语言,开发人员需要提供真实的,合乎逻辑的理由,并咨询主要开发人员。团队聚集在一起讨论技术的优缺点。

他们总是用不同的技术创造一个尖峰解决方案。这可以让他们试验一个给定技术的边界,看看它是否可以应用于给定的微服务。这对于发现技术的局限性是完美的。

“建议使用您的团队已经熟悉的语言。这样,他们可以工作更舒适,进展较快。” –来自 Andras Fincza, Emarsys 公司工程副总裁 。

这是他们在SimilarWeb上所做的:

作为一家大数据和分析公司,我们面临着非常大的挑战,这增加了选择错误技术的风险和影响。单线程框架(如NodeJS)虽然适用于网络绑定服务,但在处理实时密集型数据处理时不会扩展。

工程师通过平衡战术和战略需求,同时考虑技术和组织的约束条件,来确定使用哪种技术。企业正处于快速成长阶段吗?服务是否需要处理大量数据?是否希望将新技术添加到堆栈中,是因为相信它的生态系统,还是使用我们已经掌握的现有技术?想要试验吗?能找到对此充满激情的工程师吗?是否愿意长期致力于这项技术?技术的生态系统是一个主要因素。我们希望与开源社区合作,使用和贡献现有的框架,而不是重新发明。

定义明确的指导方针甚至是清单可以帮助促进健康的决策过程,缩小可能的技术选择范围,从而选择最适合的团队和产品方案。

David Dawson提出的选择建议:

1.从数据架构的角度来看,需要一些可以轻松地将数据同步到服务之间的网络,并保持一致的可用状态。有很多种方法,这正是微服务部署中所需要的。可以观察实现这些模式的各种框架和技术。

2.一旦确定了模式和方法,就可以使用可用的资源来分析。如果已经决定采用大量反应式编程的数据流方法,并且拥有Java开发人员,那么选择Spring,Spring Cloud Data Flow和Kafka并且部署到某种形式的Cloud Foundry上(如果可以得到它!)。

如果需要大量更重的数据转换,请带上Spark或Kafka Streams 来解决这个问题。如果有JavaScript 开发人员,那么这个问题是没有道理的。相反,你会希望在JS运行时(clojurescript等)采用一些功能语言,再次使用一些类似的反应式集成技术(比如Kafka),并从那里采取。

关键要点: • 不要强调完美的技术,采取迭代的实验方法。 • 每个微服务架构都是独一无二的; 所选择的技术要与系统需求保持一致。 • 太多不同的技术使招聘更加复杂。 结论: 切换到微服务架构时,有很多挑战。在将系统转换为微服务之前,请确定要实现这一目的的真实原因。优点和缺点的分析会是一个很大的帮助。首先考虑系统的特性,而并非仅仅改变那些伤害最大的系统部分。不建议从头开始使用微服务架构,因为从一开始就明确界定微服务的边界是困难的。

如果决定切换到微服务,请采取渐进式方法,并从系统中取出非关键的一小部分,来了解它是如何工作的。这也是获得更多微服务的好办法。

对微服务来说,没有最好的方式可以选择完美的技术。每个与技术有关的决定都受到团队当前知识的影响,也受到公司未来招聘计划的影响。在某些情况下,选择微服务技术更多的是一个招聘决定,这取决于将来要建立一个什么样的开发团队。

为了缩窄可能的技术范围,来自Emarsys 的Andras Fincza,SimilarWeb的 Daniel BenZvi和David Dawson提供的经验值得借鉴。

文章来源: https://www.tuicool.com/articles/zaMnIz3

http://blog.shurenyun.com/10wei-ji-zhu-ling-xiu-gao-su-ni-tang-guo-de-wei-fu-wu-na-xie-keng-he-zui-jia-shi-jian/

那些没说出口的研发之痛,做与不做微服务的几大理由

创建一种新的软件项目架构,来封装离散服务,对于全新的项目来说,这是非常简单的。但是,对于大多数软件开发者来说,谁又有大把的奢侈时间一直用在全新项目上呢?

大多数软件开发人员职责更多是维护或增加现有软件系统的功能。但是,如果问开发人员究竟是愿意构建全新的项目,还是维护一个现有的系统,那么支持新项目的呼声肯定会成为压倒性的声音。事实上,希望与新技术或新项目合作也是开发人员离职的原因之一。为什么呢?

1

识别问题容易,但修复很难

维护现有系统时,很容易识别架构的问题。为什么?因为基于良好的架构,系统很容易调整。

当需要去调整一个没有设计封装波动的已有系统时,架构的弱点就不言自明。即使是最小的表层变化也会给整个系统的其他部分带来复杂的涟漪:新的依赖看似要无止境地延续下去,通过臃肿的方法签名获得更多的参数,自动化测试的规模和复杂性爆炸,同时降低了实际效用。

这些问题是不是听起来很熟悉?你企业的架构是这样的吗?

如果答案是肯定的,那么你有一个单体架构。单体架构是大多数软件开发者遇到的最常见架构。

这个单体架构来自那些根本没有设计封装波动的系统,但是随着业务需求和时间的推移,变得越来越复杂。

那么用单体架构做什么呢?

每个人在单体架构中工作时都会感到痛苦,开发和业务人员也是如此。开发者讨厌臃肿的单体架构,因为开发的难度会随着新开发动作的增加而增加。一旦单体架构达到临界值,如何改变会成为一个真正可怕的命题。这会导致生产力和团队士气下降,业务受到影响。企业需要快速行动,单体架构却会随着时间的推移而变得越来越慢。

许多开发人员都希望把已有的架构丢掉,重新开始,但是这种想法无法和业务一起成长。“最好的软件是目前就让企业赚钱的软件,无论设想中的新版本多么伟大!”

所以新的计划不能完全抛弃旧有的单体架构,业务要继续,但不会再增加单体架构的复杂度。

微服务?

微服务是一个流行的词汇,它模糊地表达了一个面向服务的架构,其中包含许多小的离散服务。

从表面上看,微服务似乎是单体架构的对立面(每个人都讨厌单体架构),许多微服务通过提出新的特性请求,并以独立服务的形式出现。这里的问题是:当单体架构封装所有系统的波动性,解耦的独立服务并不能使企业免于任何波动。

以下是用微服务实现单个功能架构,它大概像这个样子:

单体应用变得小了一点,新功能清晰地从系统的其余部分解耦。这很好吗?

当下一个功能请求进入时会发生什么?

有两个功能,我们已经看到一个问题。第二个功能建立在第一个功能之上,所以不能完全隔离。

如果随着功能请求的进入,简单地创建新的微服务,而不是封装整个波动区域:

有改善吗?来看看原始单体应用旁边的微服务:

如果仔细观察,会发现,所有服务依赖线模糊在一起,这只是发明了一个更复杂的单体架构。

小小的改变在整个系统中仍然会带来复杂的涟漪。整个系统的行为改变将涉及到改变多个微服务。所有相同的问题再次出现,甚至可能更糟糕,这加剧了依赖关系难以追踪的事实,而且,精心策划的多服务部署比庞大的单体应用更加可怕。

什么地方出了错?

问题源于微服务本身不是架构。微服务就是一个简单的词,描述了作为独立服务运行的系统,而不是一个单体应用。软件架构的实际实践包括仔细规划,在哪里划分离散服务之间的界限,从而包含波动区域。当简单地拿出一个单体应用,作为独立服务来实施时,就没有必要来考虑整个系统的封装波动。

把系统看作一个整体,才能谈架构

因此,如果单体应用,功能驱动的微服务太小,该怎么做应对?

要知道想去的方向

要像从头开始创建一样,为整个系统设计理想的架构。

企业不能一下子从一个单体架构直接进入微服务架构,但是如果第一次启动的时候,不清楚想达成的方向,那么永远也不会到达那里。

给所有希望拆分现有单体应用的软件开发者提供一些建议,但实际情况是这个路线图对于每个系统都是独一无二的。

Tips

如果只是设计新的功能而忽略已有的单体应用,则无法创建出色的架构;

如果不考虑整个系统,单体应用就不能有效分解;

微服务只是一个流行词。更小并不总是更好。精心拆分服务边界很重要;

2

微服务与团队:康威定律

微服务架构是独特的,随着时间的推移仍然保持灵活性,在一个项目的组织架构中时时发生影响 。对于大多公司而言,这非常具有挑战性,因为它要求企业重新考虑组织模式。当准备开始微服务架构时,可以先问自己:“企业的组织能力是什么?“在早期,先决条件应该是预先准备会遇到的困难,并思考应对之策。

微服务与康威定律:企业需要与团队协同的架构

当涉及到组织团队和微服务,著名的康威定律经常被提到。这项定律,越来越被广泛地接受。

这一定律的缺陷在于,它更多是一种社会学规律,而不是纯粹的科学规律,事实上,它总是以实证、实例的方式,而不是纯粹的科学逻辑来论证。一般来说,社会学的结果很难证明,因为这些论证很大程度上基于假想中的思考和概念,只能通过更多的实例来加以验证。

“组织的系统设计…往往受限于组织架构的产品设计和通信的副本。”从这个规律,可以得出一些简单的结论:

如果想要特定的结构,需要一个与组织团队协同的架构。

如果经常改变架构,组织团队也需要经常修改。

这两个断言,对于康威定律的原则,有着深远的影响。首先是一个企业的适应能力,避免了野心家的倾向,对变革的抵制等等,也引发了机器取代人力的哲学思考。

基于以上结论,要上微服务架构的第一个问题是:“组织团队如何适应这种架构?” Netflix 和亚马逊的情况,当然是很正向的,但是否你的企业是否准备好了?其中重要的是,挖掘技巧和发现问题时的“刹车”措施来规避风险。

其中的技巧能迅速提升团队的能力。在创建一个功能时,负责功能实现的团队汇集了很多不同的技巧。当架构进入微服务模式时,将出现更多的协调性需求。

另一个窍门是开源技术的治理模式。开源项目由于其分散的结构,使它能够创建高度松耦合的软件,这是微服务架构的优点之一。它因此成为与其他团队的协作方式,并推动具有代码能力的小团队,在代码中实现变化。

但是,这个逻辑和组织变革在公司的接受度如何?这些技巧是否足够在全公司范围内协调、积累经验和知识?分散的组织构建松耦合的代码,但技术或功能性的知识和技能不可能极端的解耦。否则,这就像拆东墙补西墙,是在用拆掉的墙来构建松耦合的架构。

真正的僵局会出现在文化和管理风格上,这点在最近几年有了好转。

一个比较好的例子是Spotify的框架(虽然我们应该限制自己使用meta frameworks,原因不再赘述)。Spotify采用通过使用开源组件来架构功能和治理,使用这些工具在一定规模下实现了灵活性矩阵模型。矩阵式组织必须确保知晓不同人具备的知识或技能。

最近流行的新管理方法已初见影响,特别是在那些寻求实现微服务的团队组织中。

Holacracy管理模式:满足业务模式前提下,完成微服务最佳实践

上面谈到了企业文化、主体、和变革的阻力。第一种类型的管理,来源于 Holacracy 管理模式。

Holacracy分为自治和独立,并链接比自己更高的实体。这些圈子以闭环的形式,可以互相重叠,具有自组织而被上层管理的特殊性。每个圈子对于性质和组成的变化非常敏感。

可以想象,例如,底层圈子是微服务的开发队伍,而上一层是架构和产品负责人,最顶端是应用的客户业务线。这将让产品和架构负责人要能在满足业务需求的前提下,才能保证架构的最佳实践。

这种架构方式也是开发者、软件架构师的典型方式。所有可能来自不同或重叠的圈子组织。建立这种类型的组织是为了提高知识传输和构建架构的时间效率。

我们可能会认为,这种管理比较符合传统的层级组织。事实上,即使层次是扁平的,它仍然存在,可以限制其项目团队。总之,最好的方式就是简化人与人之间的链接。

原文链接:

1、Microservices and monoliths: getting service-oriented architectures just right

https://www.tuicool.com/articles/VBzUFfJ

2、Executive Insights on the Current and Future State of Microservices

https://www.tuicool.com/articles/RfuAJn2

http://blog.shurenyun.com/na-xie-mei-shuo-chu-kou-de-yan-fa-zhi-tong-zuo-yu-bu-zuo-wei-fu-wu-de-ji-da-li-you/

实录分享|微服务落地践行渐进,4个Q&A一窥金融微服务现状

1月13日,中国双态运维用户大会在北京举办。来自银行、保险、证券、政府、央企等多个行业的330多位企业用户参加,其中工商银行信息科技部副总经理张艳,国泰君安信息技术部总经理俞枫、海关总署科技发展司运行安全处处长张芳、平安科技系统运营部总经理陈亚殊等分别发表了演讲。本文为数人云CEO王璞在双态运维用户大会DevOps、容器与微服务分论坛上的演讲实录。演讲结束,与在座金融客户展开了精彩的Q&A分享。

容器、微服务、DevOps三者,业内的共识是密不可分。没有微服务,DevOps落地不下去,没有容器,DevOps也无法真正实现敏捷运维、自动化运维。DevOps、容器、微服务为更好的构建PaaS提供了方法论和技术手段。

1、PaaS之承上启下

PaaS作为云计算的承上启下要素,向上支撑各环境应用,向下跟IaaS、计算环境、计算资源对接,是企业云化的必由之路。

PaaS三大技术趋势

1.应用容器化,容器正在成为云计算原生应用的标准交付方式。

2.微服务网格化,随着企业对微服务的认知越来越深入,下一代微服务着重把应用管理作为核心。因为企业应用一定要有很强的管理在微服务架构上,不能让应用去“裸奔”。数人云没有提微服务化,因为微服务化已经是不争的事实。应用微服务缺乏强大的管理,需要服务网格这样的下一代微服务技术。

3.行业生态化,PaaS技术本质上是支持应用的,应用跟业务紧密结合,所以PaaS最终是要和业务层面融合,行业需要生态化。

PaaS落地三大要素:

PaaS要在企业客户方面落地不可或缺三要素:规模化、统一化、标准化。企业客户落地云计算平台、技术,本质上是希望提高效率,对业务有更好的敏捷支撑。

所有应用,比如容器应用、微服务应用,都实现标准化。标准化以后进行统一化管理,包括部署、发布、故障恢复、监控告警等都实现统一化管理。最后实现模块化,整个系统都是轻量的,微小模块化的。只有基于这三点的PaaS平台和云计算平台,才能够让IT系统真正实现敏捷轻量,提高IT对业务支撑的效果。

2、企业IT架构转型之开发&运维

企业客户目前在架构转型应用中面临的现状是,企业里大量传统应用,客户希望先实现轻量的单体架构,即摆脱很多中间件,摆脱外部服务,MVC架构、单体复杂架构等首先实现轻量化。

数人云日常接触的客户中,走的比较靠前的客户已经在用Spring Cloud、Dubbo等架构,部分客户相当数量的应用已经微服务化,不过处于中间状态,正在考虑评估微服务架构的客户比例还是最大。总之,企业目前的现状是为服务应用、轻量单体应用,以及传统的巨石应用并存。

在架构转型过程中,正确和常态的路径一定是一步步走过来,而不是传统架构丢掉直接上微服务。

DevOps和容器@轻量单体应用架构

在单体应用架构下,DevOps、容器帮助企业实现敏捷IT。首先,持续集成持续交付CI/CD,只要应用是相对轻量的,就能加快中间件应用。CI/CD其中重要的一点是变更发布管理。

数人云某客户上了容器的应用都是轻量化的,基于 Tomcat 和微服务的应用。当基于容器实现快速发布以后,企业发现,所有发布里有一半的发布失败是由于配置不正确引起的。所以,如果没有发布变更管理,发布失败的中间环节有方方面面的因素。

当基于容器实现快速发布之后,容器对环境的异构做了一层屏蔽,这时如果出现处理的问题就是配置管理的问题了,由于涉及不同的环境和应用,配置环境变成应用发布很容易出错的环节。

DevOps和容器@微服务应用架构

数人云做了企业客户微服务落地状况的调研(微服务2017年度报告出炉:4大客户画像,15%传统企业已领跑),在报告中,有15%左右的企业引入了Spring Cloud、Dubbo。微服务在企业里首当其冲的是敏捷开发,因为微服务是一种切实的敏捷开发的方法。

敏捷开发在IT界已经推广多年,但很多时候敏捷开发推的都是方法论,比如Scrum。微服务是一套切实能够落地到IT人员、开发人员开发过程中的实践方法,这是微服务首当其冲的好处,很多企业的开发部门对微服务非常欢迎。不过,15%还是偏小的一个采用比例,微服务还不是企业客户主流的IT架构。

开发人员都比较欢迎微服务,因为能够提升开发效率,落地敏捷开发,但微服务的阻碍还是不小的,微服务对开发运维来说,带来的复杂度急剧上升。传统运维管理的服务器数量、应用数量有限。企业决定采用微服务本身就表明业务很复杂,单体应用做传统的瀑布式开发效率太低,微服务将应用拆分成较小的模块,因此微服务应用一旦上线,程序的数量呈现爆炸式增长。

例如,数人云某个传统企业的客户,目前部署了微服务相关的应用,基于Spring Cloud、Spring Boot,跑在几千个容器上,几千个容器如果通过传统运维方式去管理的话几乎是不可能的。这就是很多微服务无法落地的原因——很多企业客户缺乏相应的运维能力,没有相应的平台、工具、方式、方法管理微服务应用。

微服务落地的必要条件

微服务应用落地,首当其冲是配套工具链的完善。开发人员采用微服务的影响相对改变小一些。采用SpringCloud或者Dubbo、gRPC等,只是开发框架上的并更。其他开发流程如代码托管、代码审查、测试等并不涉及,所以开发流程相对简单。但微服务对运维功能的要求就会复杂,相应的快速配置能力、完备的监控能力、快速部署能力等对传统运维来说都是缺失的,容器能够补足这方面的能力,让运维部门具有DevOps的能力。

关于微服务的拆分,其实是业务部门需要真正解决的问题。微服务对组织上也有变更,将团队化整为零。通常每个单独的微服务程序都由7-10人的小团队来负责维护,这些都是微服务落地的必要条件。

对于数人云来说,直接能够给客户提供的帮助,首先是工具链方面,数人云产品层面具备丰富的微服务配套工具链,从监控、日志、调度、故障自动化修复等等都有完备的工具链。在落地方法上,数人云搭建了自己的生态圈,和很多合作伙伴合作,例如跟埃森哲公司在合作,帮助企业客户落地微服务,进行业务的梳理。

容器和微服务共生

容器技术补齐了微服务相关的工具链,对企业全面向云计算转型提供了很大帮助。应用架构是微服务分布式的,相应的运维也要有自动化、敏捷运维的能力。微服务跑在容器上才能发挥它最好的特性。容器是目前最流行的应用环境,基于容器的微服务部署和更新更快,更轻量,服务之间的调用、服务发现、负载均衡等更灵活。

不过,微服务不是万能的。简单的业务场景单体应用其实足够,微服务一定是应用在复杂的业务场景下,只有复杂的业务场景才有很大的维护成本、维护压力,微服务是用来降低复杂业务场景的维护成本。

基于容器云的微服务运行时管理体系

一个完整的微服务管理体系,除了开发框架之外,对运维部门来说,运维微服务应用最基本的路由、负载均衡等功能,容器可以提供,不过容器提供的只是一部分跟微服务相关的能力和工具链。周围还有一大批需要配套的工具,比如配置管理、API网关、注册发现、应用监控等等。这里的监控不是容器CPU内存的监控,而是业务逻辑的监控,更准确一点是全链路跟踪的全链路监控。容器满足了微服务运行时管理的需求,不过周边许多权限、网关、配置等尚无余力满足。

统一配置中心是微服务体系的核心

统一配置管理,是微服务落地时很核心的点。要在平台工具上落地微服务首先要具备快速配置能力,因为客户采用微服务和容器平台以后,很快会发现50%以上的发布失败是因为配置没搞对,因此配置管理是微服务里首当其冲的问题。

因为每个企业客户都有开发环境、测试环境、生产环境等很多环境,同一个应用不同版本在不同环境下的配置不同。几何级数的配置项、配置元素的增长会导致配置管理的复杂度急剧上升,需要统一的配置中心进行管理。数人云在帮助企业客户落地微服务时,首先会做的是把配置搞定,没有灵活快速的配置管理能力,微服务运行不起来。

变更发布管理(灰度发布 v.s. 蓝绿部署)

在发布管理方面,数人云帮助企业落地的发布管理主要是蓝绿部署,因为很多企业的应用本身不支持灰度发布。蓝绿部署也是切切实实的快速发布,发布用变更窗口的方式来实现。

例如,周五晚上12点起进行发布变更,12点就要停服务中心。蓝绿部署可以显著地缩短服务不可用的变更窗口。怎么做呢?客户在线上有两个版本,蓝版本和绿版本。现在负载均衡器将流量指向对外提供服务的绿版本,蓝版本作为备用的方案。同时,新程序往蓝版本上部署推送,更新时只需要把流量切换到蓝版本。发布流程最后简化为只需要进行流量的切换。流量可以快速切换,中间的窗口期只有短短几分钟,如果流量切换过来一切正常发布即完成,如果流量切换过来发现问题,可以再将流量切回去。这样开发人员、运维人员不必当场熬夜去修复,极大地减轻了发布的压力。

传统发布方式下,每次变更窗口有好几个应用排队发布,一个应用发布完成后才可以发布下一个应用,一旦中间某一个应用发布失败现场修复的压力非常大,短短的发布窗口需要几个小时内完成抢修,非常不可控,团队经常需要晚上熬夜排队。而结果往往等了半天,前面的应用没发布成功,后面的还得继续排队等。

3、金融行业之践行渐进

数人云在金融、能源、制造、快消、政企等行业的基础上,继续深耕强监管、强安全,高复杂度的金融行业。以某商业银行为例,数人云帮助落地了大规模微服务容器平台。该商业银行近年来互联网业务发展迅猛,原有系统架构无法支撑其未来规划。2016年6月开始全面实施应用微服务化,已实现蓝绿发布。

首先,营销系统全部是轻量化的应用,基于Spring Boot、Tomcat、SpringCloud等,跑在容器平台上。该银行对外营销频次非常高,通过线上微信公众号、手机APP、线上门户、合作伙伴等渠道,每月对外营销达上百场。

每次营销活动或多或少都对IT系统有变更,哪怕是配置变更,因此每次营销活动对IT系统都是一次不小的挑战。发布的时候仅仅靠容器是不够的,需要实现模板的批量发布。每次发布看起来只是一个个的容器程序,实则不然,其实是一组组一批批的容器,只有帮客户做到批量的应用发布,才能显著提升发布效率。

蓝绿部署方面,该银行密集的线上营销中,每一天会有一个重点营销活动,那么营销活动的流量如何分到特别的人群、区域?在后台应用的上千个实例中,并不是每一个实例都分配同等的流量,要通过流量分发,做线上流量控制。数人云借鉴Google做灰度发布的方式为客户提供图形化的流量控制,这和微服务实施后的限流分流是息息相关的。

另外,该银行客户的数据流量非常大,对日志收集带来非常大的的压力。数人云建议客户将应用程序的日志全部交给Kafka采集,Kafka可以做到很大数据流量的分布式消息应用。

分布式数据传输分布式消息应用很难保证每一个消息都可靠地传递。Kafka有两种模式:一种保证消息传递至少一次,但也可能多次,对很大的日志量来说偶尔丢一两条可以忽略不计。Kafka的并发量很大,可能带来偶尔很小的数据量丢失,也可能带来日志的乱序,这在分布式系统下都是可以容忍的,“鱼和熊掌不可兼得”。

关于快速建立支撑微服务体系,数人云有几点总结:

1.开发框架不能用重量级的应用体系,要么是轻量化单体架构的Tomcat等,要么采用Spring Cloud等微服务架构。

2.要有微服务平台,具备快速配置管理能力、部署能力、监控能力、应用管理能力等配套管理能力。很多企业的痛点是,开发人员快速学习微服务开发技术,基于Spring Cloud做业务系统后,业务系统无法上线,因为运维部门缺乏配套的工具、平台支撑微服务线上运行管理。

3.DevOps融合,平台管理需要把链条全打通,实现快速发布、快速上线、自动修复等。容器经过几年的普及企业已经相对了解,但容器本身是纯技术平台,基于容器、DevOps的落地还有很长的路要走。

数人云微服务On PaaS 产品体系

数人云现在的重点是微服务、轻量单体应用。以前数人云帮企业客户落地重应用的容器平台,但后来发现价值不大,反而对企业来说,除了维护重的应用外还需要维护容器,容器平台并不能实现自动化运维。经过几年的实践和摸索,数人云跟企业客户达成的共识是,传统应用不经过改造无法上到云PaaS平台。

轻量架构下的应用如何基于PaaS平台支撑?以敏捷开发为例,企业客户通常选择 Spring Cloud、gRPC 等主流的开发框架,然后在微服务工具链层面配置监控、报警、部署、快速发布等方方面面的能力,最下面承载的则是容器平台。

数人云现在还可以帮助客户落地服务网格化技术。它能够进行异构架构的兼容,gRPC就是服务网格的一部分,Google推的 Istio,Linkerd的Kubernetes 都支持 gRPC,gRPC成为通讯协议的一部分。基于通讯协议相应周边的管理,在服务网格这一层可以做灰度发布、A/B测试、流量控制、高级熔断、加密、白/黑名单机制、权限访问控制等等。

服务网格被称作下一代的微服务,因为用了服务网格以后,所有微服务管理的诉求都自动化地满足了。80%-90%的应用管理需求都在服务网格里自动涵盖。这对开发人员来讲,微服务开发的门槛急剧降低,不需要考虑未来应用上线时流量控制、灰度发布等等,只需要考虑业务。数人云微服务On PaaS 目的就是帮助企业客户降低微服务架构、上云转型的门槛。

Q&A

Q1:感觉对DevOps的理解不太到位,能不能具体地讲一下? 
A1:DevOps准确来讲,现在业内还没有统一的认识。互联网公司的DevOps目前是比较统一的,比如Goolge,但是互联网公司的DevOps,我个人理解没办法在企业直接落地。

在Google,程序员不止要负责应用的开发,还要负责相应的测试,单元测试、集成测试等等。另外,应用的部署、发布、上线也是开发人员自己做。所以互联网公司讲DevOps,更多讲的是开发运维的融合。我之前在Google时,不仅要做代码开发,也要把测试的代码全写出来。

Google有一个理念,开发人员每写一行业务代码,测试代码要写十行。然后,开发人员利用各种发布平台定期发布,比如每周做发布,在Google 运维的人员叫“SRE”。SRE部门准备好各种平台,开发人员可以用这些平台做发布、监控、日志管理等工作。

Google目前有三万名左右的IT人员,其中SRE的运维人员只有一千多,比例很低。所以在Google运维人员不可能帮每一个开发人员或者业务部门做上线。像传统IT开发人员提工单给运维,在Google是不可能的。Google这种做法,它让开发做更多的事情,运维人员很少,只是负责维护平台。所以,Google一千多人管理着几百万台服务器,平均每人管两千台。

但传统企业目前不是这样,传统企业开发和运维之间壁垒比较大。数人云帮助客户落地DevOps 时,基于的理念是,不要破坏现有开发的流程。DevOps应该是开发和运维深度融合才能做到的。讲DevOps,首先要讲理念、组织的变革,但是要想把文化变革、组织变革打破要很长时间。

从落地的角度,DevOps更多落地在运维部门,很具象的工作就是,帮助运维部门去实现DevOps的能力,比如快速部署、快速上线,应用的快速配置,自动化管理能力、故障的自动化处理等等。把以前的运维工作尽可能的自动化,提高效率,这是狭义的DevOps理念,也是我们现在接触到的。数人云不会帮客户落地像互联网公司那样的DevOps,开发做很多事情,运维可做的很少,并不是这样的。

Q&A

Q2:微服务适合复杂的场景,那么一个简单的促销是不是适合?微服务有多“微”呢?微服务和ESB 服务相比,有什么差别? 
A2:第一个促销场景,促销场景本身有些条件,促销很重要一点就是必须特别频繁,促销内容在平台要发生变化。比如,今天的促销内容和明天的不太一样,或者这周的促销和下周的不太一样,业务平台需要频繁变更,这时候微服务是适合的。

因为微服务是一种敏捷开发的落地实践方法,只要业务频繁变更,对开发的要求就必须敏捷开发,快速实现。所以,只要业务场景在不停地快速变化,促销又是互联网线上的方式,肯定是适合的。

关于复杂性,如果业务逻辑简单,逻辑变化少,并不适合微服务。比如数人云和很多银行客户合作,银行核心系统很复杂,但是银行系统并不是需求频繁变化的场景。很多银行在做“瘦核心系统”,就是银行核心系统的功能越来越单一,越来越瘦,并不是把复杂的周边的业务也放到银行核心系统里。银行核心系统虽然复杂,但业务不会频繁变化,也不一定要上到微服务场景下。复杂的业务系统,业务需求又不停变化,这种场景适合微服务。

第二个问题是和ESB 比,服务网格和 ESB 有很多相像的地方。ESB有业务逻辑串起来,很多不同的业务系统都上到ESB,互相的权限通过ESB打通。从功能角度讲,ESB和服务网格之间很相像,不同点在于ESB是传统架构下的,并没有考虑频繁迭代、流量集中爆发等问题。

但是微服务情况下,整个之间的互相请求、依赖、通讯等等都会进行统一的管理,这种情况下也很像ESB把不同业务之间的流量进行统一管理,但是服务网格更看重的是面向大规模的控制,那流量突发怎么做限流,或者突然故障怎么做熔断等等。最本质的问题是类似的,但是具体的问题表象和需求不同。 Q&A

Q3:在实际部署过程中,PaaS平台在底层资源的调用一定要用分布式云架构,传统主机是否可以?两者在最后效果上有没有什么异同? 
A3:数人云当初两种情况都有,有些场景比如业务量比较大,企业客户为了减少复杂度,容器PaaS平台直接落地到物理服务器上。还有客户为了方便管理,把PaaS落地到IaaS上,两种情况都有。

这其中的考虑是,首先业务量大如果再引入虚拟化这一层会引来额外的复杂度,此时用物理服务器更好。其次,客户有很大规模的物理服务器,直接在上面部署PaaS,在物理服务器上去调用。

第三种,资源动态的调整或资源频繁调配,这个场景很常见,需要IaaS。比如银行客户,内部业务系统分不同的域,不同域的业务复杂性随时间变化经常会发生变化,需要不停地做资源动态的调整。如果用物理机太麻烦,企业客户会选择下面有一层IaaS来做。

基于PaaS也能做一部分的资源动态调配,但是调配维度不同。数人云帮客户落地PaaS时会做资源的整合。从划分的维度,PaaS平台是按照应用程序来划分,IaaS的资源划分是按照业务系统。

Q&A

Q4:微服务重新开发,最佳的开发框架或者实践有什么可以分享的?第二,旧有的系统改造到微服务这块有没有什么经验?第三,DevOps以前也有很多像敏捷开发的方法论,它们之间有没有什么关系? 
A4:首先第一个问题,微服务的开发框架。企业客户在做选择时都希望降低风险,选最主流的框架,现在看最主流的开发框架就是Spring cloud,这也是业界的自然选择结果。其他语言也都有些微服务开发,但是用的人少一些。如果是Java应用,目前比较好的选择是Spring Cloud,也有很多客户用了Dubbo,其他架构都是偏小众的架构,主要还是看客户自己的需求。

第二个问题,传统业务要转到微服务架构上,一定要循序渐进。比如Java应用,首先Java中间件的应用,先脱掉,不要再基于这么重的Java中间件。目前相对流行的是Spring Boot这套逻辑。

有了轻量的单体化应用之后(基于Tomcat),往后走基于微服务的框架,上到Spring Boot,再上到Spring Cloud,这是比较平滑的方式。Spring Boot 在很企业客户中用的非常多,是很方便的一套单体开发架构。

企业客户目前的现状是老的应用很多,不会一次就改造完,传统的应用可以先选择一部分容易转的转到轻量单体架构上,然后再转到微服务框架上。目前企业客户是轻量的单体架构、微服务架构,以及大量传统的架构应用并存。老的架构应用目前上不到PaaS平台,只有轻量的单体化加微服务应用才能上到PaaS平台。

现在业内的共识是,微服务、容器、DevOps这三者是密不可分的。微服务更多是针对开发人员,是一种真正落地的云开发方法。很多企业客户也讲敏捷开发,派团队成员学习敏捷开发的方法论,但是敏捷开发仍然无法在企业当中落地。

这是因为,只学会了方法,但没办法落地到具体的编程,即开发环节上去,自然没办法做到敏捷开发。很多开发者回来写的程序依然是J2EE。J2EE 编程的理念和方法并不是敏捷开发的,是偏向于瀑布式的。

微服务是具体的开发环节上的敏捷开发方法,开发能力化整为零,每个团队做简单、具象、单一的逻辑。微服务首先是一个具像的敏捷开发方法,实践方法。

微服务在落地时,比如程序运行时,复杂度很高,因为不是一个程序,是一批程序一起运行,对运维的管理就比较复杂,这时候可以利用容器实现微服务应用的自动化管理。微服务一般都会上到容器,因为微服务应用不再是单体的部署方式,不再是部署到Java中间件上。基于微服务架构,几百个进程进来,用容器的方式实现快速部署动态调度,微服务部署到容器上,实现基础的轻量化运维。

轻量化运维,快速部署、自动化调度,逐步往DevOps方向走。DevOps更多强调自动化的运维能力,提高运维的效率,快速部署,出了问题自动化修复。需要用到工具和平台,这就是数人云现在帮客户去做的。

把微服务业务在运行时缺失的管理方式方法、工具平台,工具链补齐。首先是配置管理能力、完备的监控能力等等,普及之后运维人员就有能力来管微服务应用。这其实是DevOps里面最狭义的,让运维的能力变得轻量。

如果要真正实现DevOps,就像目前一些互联网公司做到的,开发和运维真正的深度融合在一起。企业目前的运维一般不具有编程能力,所以真正的DevOps还需要很长时间去落地。