我的服务公共化实践

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

之前有一篇讲了运维标准化是运维的基础,更是运维自动化的基础。但我觉得高效运维的关键是第二阶段---架构服务化更是关键,此项工作的深入推动需要运维和研发强力配合,这种配合不仅仅是技术和执行层面上的配合,有时候还需要一些部门文化和目标层面上的配合。为了强力推进这部分的工作,有时候甚至需要运维自己组建公共服务的研发团队。在小的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调用即可。

本文分享自微信公众号 - 互联网运维杂谈(waynewang_ops)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-11-13

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏eguid开源技术分享

myBatis动态语句详解

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。 ...

8830
来自专栏挨踢小子部落阁

面试题:Redis 40 道

Redis 是完全开源免费的,遵守BSD协议,是一个高性能的key-value数据库。

6110
来自专栏eguid开源技术分享

shiro开发,shiro的环境配置(基于spring+springMVC+redis)

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。 ...

9610
来自专栏健程之道

Java 中的四种引用

之前我们提到过 GC,但当 Java 中引用的对象越来越多,会导致内存空间不足,最终会产生错误 OutOfMemoryError,并让应用程序终止。那为什么 G...

4520
来自专栏Lambda

面试题:Spring为什么默认bean为单例?

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。 ...

8920
来自专栏健程之道

Disruptor原理探讨

先介绍一下我的这个服务。这个服务主要是作为游戏服务器的游戏逻辑部分,包括帧同步逻辑及其他在游戏过程中玩家产生的一些业务逻辑。

6410
来自专栏业余草

HTTPS虐我千百遍,我却待她如初恋!

原文链接:https://zhuanlan.zhihu.com/p/75461564

8320
来自专栏锐智互动

自动售货机软件系统开发

自动售货机是一种全新的商业零售形式,从自动售货机的发展趋势来看,他的出现是技术科技向人力转变的产物,随着科技的发展及人们的生活水平提高,自动售货机市场越来越呈现...

20940
来自专栏Lemon黄

服务器配置优化

query_cache_size:查询缓存 OLAP 类型数据库,需要重点加大此内存缓存. 但是一般不会超过 GB. 对于经常被修改的数据,缓存会立马失效。 我...

8220
来自专栏Java研发军团

【附源码】Spring Boot 实现微信点餐系统,可以拿来吹了

线程锁:当某个方法或代码使用锁,在同一时刻仅有一个线程执行该方法或该代码段。线程锁只在同一JVM中有效,因为线程锁的实现在根本上是依靠线程之间共享内存实现的。如...

10120

扫码关注云+社区

领取腾讯云代金券

年度创作总结 领取年终奖励