|
|
51CTO旗下网站
|
|
移动端

【分享】运维团队的服务公共化实践

服务公共化是运维团队必须迈出去的一步,这一步事关后面的无状态的技术架构实现。在运维侧,基本上现在我们公共服务的维护都只需要一个人负责,大大降低了运维成本。在研发侧,他们对运维的需求接口更简单了,服务更专业化。最终我们想做到的目标是,研发只需要编写业务逻辑代码就好了,其他的各个专业服务基于客户端Library的Api调用即可。

作者:王津银(老王)来源:互联网运维杂谈|2015-08-12 16:41

服务公共化也算是一种标准化,它是线上的技术架构标准化。

之前有一篇讲了运维标准化是运维的基础,更是运维自动化的基础。但我觉得高效运维的关键是第二阶段---架构服务化更是关键,此项工作的深入推动需要运维和研发强力配合,这种配合不仅仅是技术和执行层面上的配合,有时候还需要一些部门文化和目标层面上的配合。为了强力推进这部分的工作,有时候甚至需要运维自己组建公共服务的研发团队。在小的IT企业中,大家对这块的认识应该不会太深刻,到一个中等规模(比如说多个产品线、服务器千台规模以上等等),此时更需要架构的公共能力服务化来形成技术架构的标准化,从而解决IT服务的效率和运维问题。有时候,你可以把这个服务化理解成PAAS平台化的一部分。 

备注:相同服务的多组件会导致服务质量下降,组件引入的越多,对研发、测试和运维的要求越高,很难找到这种多组件能力的维护团队;业务的敏捷性要求越来越高,传递给后端技术服务能力也要越来越敏捷,这个时候只能公共化服务能力才能满足这一要求,把这种服务能力变成一种自服务的能力,变成一种api的能力;运维管理必须以可运维性为目标,把技术架构中的公共服务能力打造到极致,比如说mysql、cache、文件存储的服务等等。

备注:这是一个通用的互联网技术架构,不做详述。

备注:在通用架构中,架构中的点和线如果选型不当或者技术把控不足,就会带来以上的技术失控(Out Of Control)。对于每一层的技术架构来说,我们组件选型会泛滥,其实这种泛滥许多时候都是基于团队或者个人的偏好来进行的,而不是真正的合理评估。在一个完全没有接维的IT组织中,这种情况更是比比皆是,所以说有时候还是需要中心化的管理。一个离散式的组织中,必然会打来混乱和选型失控的情况。这个地方要注意线的失控,所谓线的失控就是服务间调用的失控,有些是通过lvs、有些是通过dns、有些是通过配置文件等等,如果有可能完成统一的标准制定,比如说我现在在UC用的就是名字服务中心。

备注:我在统计学的角度也做了一个解释,组件越多,每个组件的维护能力下降,带来的可用性必然是很低,由此多组件构建的技术架构可用性是一个乘积效应。在失控组件数量N大于可控组件数量M的情况下,前者的可用性必然是低于后者的。

备注:公共服务化也有标准的实现路径可循,对于一个不复杂的业务来说,其实基本上可以按照1.识别--》2.抽象--》3.选型--》4.实现--》5.接入推广几个阶段来完成。其中关键是第四步实现,这个地方就需要一个很强有力的技术实现小组来完成,肯定会出现的一种情况是,初步实现没法满足所有业务的需求,甚至是有些业务的需求根本就没有预估到,那么需要技术实现小组,边接入边优化。这次我们在把MC切到内部的分布式cache服务上就遇到了这类问题,只能在接入过程中,快速实现。这也是公共服务化的一个好处,研发能力的快速支持,当作一个产品来做。 

备注:核心能力是【可运维性】,可以分解到不同维度上【服务透明】【可管理性】与【自服务】。【服务透明】是提供一种内在的容错机制、去状态的位置透明服务能力;【可管理性】,需要把运维的核心场景可视化实现,比如说数据迁移、cache扩缩容等等;【自服务】是想把这种服务能力提供给所有人,甚至给周边的一些业务系统,供其api直接调用。

备注:在来UC的一年多时间里,基本上把技术架构中公共需求都统一切到公共服务平台上。目前这些平台对某个运维人的依赖越来越低。在非运维主导的这块,还有服务间调用解耦用到的【飞鸽系统】与统一消息推送系统【飞雁系统】。在技术架构里面,我们正在和研发推动统一的业务灰度发布系统、统一服务降级系统、语音实时消息公共平台。

备注:以上两个图,是我们的统一分布式cache服务---浮云,用来替换memcache,传统的memcache散落在各个业务的服务器上,完全的组件化能力,需要每个人掌握memcache的运维能力,切换到统一的浮云后,一切运维能力可视化,在线管理变更、在线状态查询、在线统计的分析等等。最关键的是,这套技术架构更考虑可运维性的要求,比如说容灾容错等等,甚至是跨机房之间的cache数据同步都在这层解决。

备注:

【公共架构团队】,必须要有一个公共架构团队,不过这个公共架构团队,适当的需要纳入业务研发团队的成员,避免需求偏离。

【强有力的领导】,没有强有力的领导,这套技术标准很难推行。

【架构和运维的深度融合】,不管是技术上的融合,还需要在团队间合作上的融合。

【一致的方向理解】,大家需要形成一致的方向理解能力,认同统一的目标和方向。这个一致的理解不仅仅是在研发和运维之间,甚至是研发团队之间。

【持续的目标认同及滚动】,不可避免在切换的过程中或多或少会出现一点问题,前提是我们必须做好灰度控制。过程中出现的问题,不应该成为阻碍,我们需要承认这种临时的不完美,然后持续向前滚动。

备注:以前想在九游这边所有业务推动webP图片压缩,碰到一个现实的问题,图片存储不集中,没法要求所有的研发团队处理。现在我们把所有的图片能力接管以后,我们做webP图片的压缩,完全不依赖业务方的实现,由图片云统一处理。这是一个公共服务化后,让IT组织技术成本更低的一个例子。

总结:一定要记得避免选型泛滥,这个泛滥后面就需要来打扫战场,非常痛苦。服务公共化是运维团队必须迈出去的一步,这一步事关后面的无状态的技术架构实现。在运维侧,基本上现在我们公共服务的维护都只需要一个人负责,大大降低了运维成本。在研发侧,他们对运维的需求接口更简单了,服务更专业化。最终我们想做到的目标是,研发只需要编写业务逻辑代码就好了,其他的各个专业服务基于客户端Library的Api调用即可。

【编辑推荐】

  1. 运维跟开发一定有仇吗?
  2. 电商混合云在1号店的运维实践
  3. 【重磅】运维自动化的最佳实践探索
  4. 【专题】运维人,绝对值得你关注的运维实践分享
  5. 为什么运维人的耻辱感能助力你的职业上升
【责任编辑:火凤凰 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

读 书 +更多

主流ARM嵌入式系统设计技术与实例精解

本书重点介绍了主流ARM应用系统的开发与实践。全书基于目前较为通用、流行的ARM处理器,介绍了其原理、硬件结构、硬件电路设计与开发和软件...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊